DMARC Record Checker: Check, Interpret, and Fix Your DMARC Record

A DMARC record checker tells you whether a domain publishes a usable DMARC policy in DNS—but a green result alone does not prove that your real email passes DMARC. To protect a domain without blocking legitimate mail, you need to check the DNS record, verify SPF and DKIM alignment on live messages, and use reports to uncover every sending service.

What a DMARC record checker actually checks

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It lets the owner of the domain shown in an email’s visible From: address publish a DNS policy describing how receivers should handle mail that fails DMARC, and where receivers may send reports about mail using that domain. The current core DMARC specification is RFC 9989; it supersedes the older RFC 7489 specification that many tools and tutorials still reference. (datatracker.ietf.org)

A DMARC record checker normally performs a DNS lookup for a TXT record at this hostname:

_dmarc.example.com

It then parses the record’s tags and looks for common configuration problems. Depending on the checker, it may also inspect related SPF and DKIM records, identify report destinations, warn about a weak policy, or explain alignment settings.

A good checker answers four separate questions:

1. Does a DMARC TXT record exist at the correct hostname?
2. Is the syntax valid enough for receivers to understand?
3. What policy have you requested for messages that fail DMARC?
4. Can mail sent by your actual systems pass through aligned SPF or DKIM?

The first three are DNS questions. The fourth is a message-authentication question. That distinction matters: a checker can confirm that p=reject is published, but it cannot prove every CRM, help desk, invoice platform, or product-email provider is signing and aligning mail correctly unless it evaluates real sent messages or the reports generated from them.

How DMARC decides whether an email passes

DMARC does not replace SPF or DKIM. It uses their results and adds alignment with the domain people see in the From: header.

For a message claiming to come from updates@example.com, a receiver evaluates the visible header domain, example.com. The message passes DMARC if at least one of these paths succeeds:

• SPF passes for the SMTP envelope sender domain—and that domain aligns with example.com.
• DKIM passes for the domain in the signature’s d= value—and that domain aligns with example.com.

If neither aligned path passes, the message fails DMARC. Microsoft documents the same rule: an email passes when either aligned SPF or aligned DKIM passes; it fails when both fail. (learn.microsoft.com)

SPF authentication is not the same as SPF alignment

SPF checks the domain used in the SMTP envelope sender, often visible to recipients as Return-Path. That address may differ from the friendly From: address.

For example:

Visible From:       orders@example.com
Envelope From:      bounces@mailer.vendor.example
SPF result:         pass

SPF can pass here while DMARC SPF alignment fails, because mailer.vendor.example is not necessarily aligned with example.com. A sending platform may authenticate its own bounce domain successfully without authenticating your visible brand domain.

DKIM is often the easiest DMARC path for SaaS senders

DKIM adds a cryptographic signature to a message. For DMARC, the domain after d= in the DKIM-Signature header must align with the visible From: domain.

Example:

From: orders@example.com
DKIM-Signature: d=example.com; s=marketing;
DKIM result: pass

This is aligned and passes DMARC, assuming the visible From: domain is example.com. If the signer is d=vendor-mail.com, DKIM may pass technically but does not satisfy DMARC alignment for mail from example.com.

Google explains DMARC in the same practical terms: the domain in the From: header must sufficiently match the SPF or DKIM-authenticated domain. (support.google.com)

Run a DMARC record checker in three ways

A browser-based checker is convenient, but you should know how to independently confirm its finding. DNS dashboards occasionally append the base domain automatically, cache old data, or show a record editor differently from the public DNS answer.

Option 1: Use a web-based DMARC lookup tool

Enter only the domain, such as example.com, not the full _dmarc.example.com hostname unless the tool specifically requests it. A useful result should show:

• the exact TXT record returned by DNS;
• the hostname queried;
• parsed tags and values;
• syntax errors or duplicate records;
• the effective policy for the organizational domain and subdomains;
• report destinations; and
• related SPF and DKIM observations, clearly labeled as separate checks.

Treat a tool’s “score” as a convenience, not a security verdict. A record with p=none can be syntactically correct and entirely appropriate during discovery, but it is not a request for enforcement against spoofed messages.

Option 2: Query DNS from a terminal

On macOS, Linux, or Windows with DNS utilities installed, run:

dig +short TXT _dmarc.example.com

On Windows Command Prompt, use:

nslookup -type=TXT _dmarc.example.com

You want one DMARC policy record beginning with v=DMARC1. A typical response looks like this:

"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

DNS providers can display a long TXT value in quoted chunks. That does not automatically mean it is broken; DNS software reconstructs adjacent chunks into one TXT value. What matters is the assembled record returned to a resolver and whether the parser sees one coherent DMARC policy.

Option 3: Inspect a message that you actually sent

Send an email from each important sending path to a mailbox where you can view full headers. Look for an Authentication-Results header. A successful result generally resembles:

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=bounces.example.com;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

The exact header format varies by receiver, but the fields reveal the key facts: SPF result, SPF domain, DKIM result, DKIM signing domain, DMARC result, and visible From domain. Microsoft 365 adds authentication results for SPF, DKIM, DMARC, and its composite-authentication assessment to received messages. (learn.microsoft.com)

Do this for more than one email type. A password-reset message, newsletter, sales sequence, support reply, billing notification, calendar invitation, and message sent from an employee mailbox can each travel through different infrastructure.

Read the DMARC record syntax without guessing

A DMARC record is a DNS TXT value made of semicolon-separated tag/value pairs. The basic, widely deployed format is:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Place it at:

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Some DNS control panels want the full hostname _dmarc.example.com; others expect only _dmarc and append the zone name. Check the provider’s field labels before saving. Publishing _dmarc.example.com.example.com is a common operator error.

The tags that matter most

Google’s example includes p, rua, pct, adkim, and aspf; the policy values are none, quarantine, and reject. (support.google.com)

Choose the right policy value

The p tag expresses the domain owner’s requested disposition for mail that fails DMARC:

p=none

Monitoring only. Receivers may send reports, but you are not asking them to quarantine or reject failures.

p=quarantine

Request suspicious handling, commonly spam-folder placement. It is an enforcement step, but receiver behavior can vary.

p=reject

Request rejection of mail that fails DMARC. This is the strongest common policy and is the end state for many domains once legitimate sources are known and aligned.

DMARC policy is a request to receiving organizations, not a guarantee that every receiver will take identical action. The protocol lets receivers use the published policy while making their own mail-handling decisions. (datatracker.ietf.org)

Relaxed versus strict alignment

Alignment has two modes:

• Relaxed alignment (r) allows related subdomains under the same organizational domain to align.
• Strict alignment (s) requires an exact domain match.

For example, with visible From: alerts@example.com:

DKIM d=mail.example.com

typically aligns in relaxed mode but not strict mode. The same concept applies to SPF’s envelope sender domain.

Relaxed alignment is a practical default for many organizations because email platforms often use branded subdomains such as bounce.example.com or mail.example.com. Strict alignment can be appropriate when you fully control every sending stream and want the tightest possible relationship, but enable it only after verifying real messages.

A worked example: check and repair a domain safely

Assume Acme uses acme.example for employee email, newsletters, receipts, support messages, and an application that sends login links. The marketing team has added a DMARC record, but a checker reports a warning and a few customers say receipt emails land in spam.

Step 1: Retrieve the published record

Run:

dig +short TXT _dmarc.acme.example

Result:

"v=DMARC1; p=reject; rua=mailto:dmarc@acme.example; adkim=s; aspf=s"

The record is syntactically plausible. It requests rejection and strict SPF and DKIM alignment. That is not automatically wrong, but it is high-risk if Acme has not tested every sender.

Step 2: Make a sender inventory

Before changing DNS, list systems that can send a message with From: ...@acme.example:

1. Microsoft 365 or Google Workspace employee mail.
2. Transactional application mail.
3. Marketing automation and newsletters.
4. CRM sales sequences.
5. Customer-support ticket replies.
6. Invoicing, e-signature, survey, and scheduling platforms.
7. Infrastructure alerts, status notifications, and monitoring tools.

Do not rely only on who “owns email.” Ask finance, support, product, engineering, sales, HR, and IT. The sender most likely to break an enforced DMARC policy is often an overlooked SaaS tool configured years earlier.

Step 3: Test live mail from each source

Acme sends one message from each system to a controlled test inbox and views headers.

The newsletter shows:

spf=pass smtp.mailfrom=mail.acme.example
dkim=pass header.d=acme.example
dmarc=pass header.from=acme.example

That is healthy.

The application login email shows:

spf=pass smtp.mailfrom=amazonses.com
dkim=pass header.d=amazonses.com
dmarc=fail header.from=acme.example

Both SPF and DKIM have technically passed, but neither authenticated domain aligns with acme.example. That message is exposed to Acme’s p=reject policy.

Amazon SES, for example, can satisfy DMARC through aligned DKIM or through SPF when a custom MAIL FROM domain is configured. Its default MAIL FROM domain is under amazonses.com, so relying solely on its default SPF identity does not produce SPF alignment with a customer’s visible From domain. (docs.aws.amazon.com)

Step 4: Fix the source, not the DMARC symptom

Acme should configure the application’s sending provider to DKIM-sign with an aligned Acme domain—such as d=acme.example or a properly aligned Acme subdomain—or configure a custom bounce/MAIL FROM domain where the provider supports it. The provider will usually supply DNS records for domain verification and DKIM.

Do not solve the problem by changing the visible From address to the provider’s domain. That may make authentication easier, but it damages brand consistency and can confuse recipients.

Step 5: Move back to monitoring while repairs are underway

If legitimate mail is failing and customers are missing it, Acme can temporarily publish:

v=DMARC1; p=none; rua=mailto:dmarc@acme.example; adkim=r; aspf=r

This gives the team space to find and repair sources while still collecting aggregate data. It is not the final security state; it is an investigation stage.

Step 6: Review aggregate reports, then enforce deliberately

After all known sources are aligned, Acme can move to:

v=DMARC1; p=quarantine; rua=mailto:dmarc@acme.example; adkim=r; aspf=r

Then, after continuing to confirm that legitimate sources pass:

v=DMARC1; p=reject; rua=mailto:dmarc@acme.example; adkim=r; aspf=r

Aggregate DMARC reports are XML documents sent by participating receivers to the destination declared in the DMARC record. They summarize messages seen, source IPs, authentication outcomes, and the policy evaluation rather than delivering a readable inbox-style report. (datatracker.ietf.org)

Understand checker warnings and fix the real problem

A checker’s warning language differs by vendor, but these are the errors worth treating seriously.

No DMARC record found

The lookup for _dmarc.example.com returned no DMARC policy. Create one TXT record at the correct hostname.

Start with a monitoring record if you have not inventoried senders:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Multiple DMARC records

Publishing two separate TXT records that both begin with v=DMARC1 at the same _dmarc hostname is unsafe. Receivers can treat multiple candidate policy records as an error rather than guessing which policy you intended.

Consolidate the tags into one record. For example, this is wrong as two independent DNS records:

v=DMARC1; p=none
v=DMARC1; rua=mailto:dmarc@example.com

This is the correct single record:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Invalid or misspelled tag names

Common mistakes include version=DMARC1, policy=reject, missing equal signs, smart quotes copied from a document editor, and a typo such as rua-mailto:. Use plain text and the exact tag syntax.

Unknown tags should not be treated as a safe extension point. A receiver may ignore them, leaving you with a record that looks meaningful to a human but has no operational effect.

A record at the wrong hostname

This will not work for example.com:

example.com TXT "v=DMARC1; p=reject"

Nor will this:

_dmarc.mail.example.com TXT "v=DMARC1; p=reject"

unless your visible From domain is actually mail.example.com. For mail from person@example.com, publish the policy at _dmarc.example.com.

An unverified external report destination

If example.com asks receivers to send aggregate reports to reports@another-domain.net, the destination domain must authorize that reporting relationship. The authorization record is published at:

example.com._report._dmarc.another-domain.net

with a value of:

v=DMARC1

Without that authorization, some receivers will not send reports to the external address. This mechanism prevents a domain owner from using DMARC reporting to flood an unrelated mailbox. (dmarc.org)

Strict alignment breaking valid sender setups

A checker may report that adkim=s or aspf=s is technically valid. That does not tell you whether it is appropriate for your sending architecture.

If a legitimate message passes DKIM as d=mail.example.com but uses From: sales@example.com, strict DKIM alignment fails. Relaxed alignment may be the correct configuration while you maintain strong p=reject enforcement.

SPF passes but DMARC fails

This result nearly always means one of two things:

• the envelope sender domain passed SPF but does not align with visible From; or
• SPF is aligned, but the receiver encountered a separate condition that prevents it from producing a DMARC pass.

Check the actual smtp.mailfrom= or Return-Path domain. Do not assume the visible From address tells you what SPF authenticated.

DKIM passes but DMARC fails

Look at header.d= in Authentication-Results or d= in the message’s DKIM-Signature. A third-party domain can produce a valid signature that is not aligned with your From domain.

Ask the provider whether it supports custom-domain DKIM signing. Google and Microsoft both recommend configuring SPF and DKIM before DMARC, because an enforced DMARC record without authenticated senders can create delivery problems. (support.google.com)

Check subdomains separately

A root-domain record does not mean every subdomain behaves exactly as you expect. If you send from billing.example.com, test:

dig +short TXT _dmarc.billing.example.com
dig +short TXT _dmarc.example.com

The sp= tag expresses the policy for subdomains that do not publish their own DMARC record. For example:

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@example.com

This requests rejection for the primary domain while requesting quarantine for applicable subdomain mail. A dedicated subdomain record can set its own policy when a particular sender needs different handling.

Using separate subdomains is often valuable operationally. A company can isolate marketing traffic on news.example.com, transactional traffic on notify.example.com, and employee mail on example.com. The separation makes report analysis, reputation management, vendor migrations, and debugging easier—but each subdomain that appears in a visible From address must be included in your testing plan.

Use reports as an inventory, not as a checkbox

The rua tag requests aggregate reports:

rua=mailto:dmarc-reports@example.com

You can list more than one destination, separated by commas:

rua=mailto:dmarc-reports@example.com,mailto:security@example.com

However, do not casually direct raw reports to shared employee inboxes. High-volume domains can receive many compressed XML attachments, and large organizations can receive hundreds or thousands of reports a day. Google specifically recommends using a dedicated group or mailbox for managing these reports. (support.google.com)

A DMARC report processor can turn XML into useful views of:

• source IP addresses sending as your domain;
• the provider or network associated with each source;
• message volume by source;
• SPF and DKIM pass/fail patterns;
• alignment outcomes; and
• possible unauthorized senders.

When reviewing results, label each source as one of the following:

1. Known and passing: retain and monitor it.
2. Known but failing: repair custom DKIM, SPF alignment, or the visible From domain.
3. Unknown but legitimate: identify the team or vendor before allowing it.
4. Unauthorized: do not add it to SPF merely because it appears in a report.

That final rule prevents a dangerous failure mode. DMARC reports reveal that an IP used your domain; they do not prove you should authorize that IP.

Why a valid DMARC record can still fail delivery

DMARC helps protect identity, but it is not a universal inbox-placement switch. The older DMARC specification explicitly notes that authenticated email does not automatically receive privileged delivery treatment. (datatracker.ietf.org)

A message can pass DMARC and still be spam-filtered because of content, sending patterns, recipient engagement, complaint rates, IP or domain reputation, malformed message formatting, or other signals used by the receiver.

Conversely, an organization can publish p=none and meet baseline DMARC publication requirements while gaining limited anti-spoofing enforcement. For high-volume mail to personal Gmail accounts, Google requires SPF, DKIM, and DMARC; its DMARC policy may be p=none, but authentication and alignment still matter. Google defines a bulk sender as one that sends close to 5,000 or more messages to personal Gmail accounts in a 24-hour period, and that classification does not expire once assigned. (support.google.com)

The practical conclusion is simple: use DMARC to control domain impersonation, then manage deliverability with authenticated mail, clean lists, useful content, sane sending practices, and reliable infrastructure.

A durable DMARC rollout checklist

Use this sequence whenever you add DMARC to a domain or prepare to move from monitoring to enforcement.

1. List every system that sends with your domain in visible From. Include staff mail, product mail, vendors, and rare operational alerts.
2. Enable SPF and DKIM for each legitimate source. Prefer an aligned DKIM signature because it survives many forwarding scenarios better than SPF alone.
3. Publish one valid DMARC TXT record at _dmarc.yourdomain. Start with p=none if the sending inventory is incomplete.
4. Set a dedicated aggregate-report destination. Use a monitored mailbox or an authorized reporting service.
5. Run a DNS-based DMARC record checker. Confirm hostname, single-record status, tags, policy, and report address.
6. Send test messages from every source. Inspect Authentication-Results, not only a provider dashboard.
7. Review aggregate reports. Resolve unknown and failing sources before enforcement.
8. Move to p=quarantine, then p=reject when evidence supports it. Keep watching reports after every policy change and vendor migration.
9. Recheck after DNS, sender, and branding changes. New platforms and new From subdomains can quietly introduce alignment failures.

The formal protocol has evolved: RFC 9989 replaced RFC 7489 as the core DMARC specification, while RFC 9990 and RFC 9991 cover aggregate and failure reporting. During real-world tool and receiver transitions, prioritize universally understood foundational tags—v, p, rua, adkim, aspf, and sp where needed—and validate behavior with actual messages rather than assuming every checker implements every newer option identically. (rfc-editor.org)

FAQ

What is the best DMARC record checker result?

The best result is not simply a perfect score. You want one valid DMARC record at _dmarc.yourdomain, an intentional policy, a working report destination, and live test messages showing dmarc=pass for every legitimate sender.

How do I check a DMARC record manually?

Query the DNS TXT record with dig +short TXT _dmarc.example.com or nslookup -type=TXT _dmarc.example.com. Then inspect a real message header for Authentication-Results to confirm aligned SPF or DKIM produces dmarc=pass.

Does p=none mean DMARC is broken?

No. p=none is a valid monitoring policy and is often the right starting point. It does mean you are not asking receivers to quarantine or reject mail that fails DMARC, so it is not the final enforcement posture for a domain that needs strong impersonation protection.

Can SPF pass while DMARC fails?

Yes. SPF may pass for a third-party envelope sender domain while failing DMARC alignment with the visible From domain. Inspect smtp.mailfrom= and compare it with header.from=.

Should I use strict SPF and DKIM alignment?

Only if your sending architecture supports exact domain matches for every legitimate source. Relaxed alignment is commonly safer for organizations that use branded sending subdomains, while p=reject can still provide strong enforcement once all senders are authenticated and aligned.