DMARC Record Check: How to Validate, Fix, and Test Your DNS Policy

A DMARC record check is more than looking for a TXT record in DNS. A useful check confirms that the record is published at the correct hostname, uses valid syntax, requests an intentional policy, has a working reporting destination, and—most importantly—matches the SPF and DKIM authentication on real email.

DMARC protects the domain in the visible From: header against impersonation. It does that by requiring either SPF or DKIM to pass and align with that visible domain. A valid-looking record alone cannot prove that your newsletters, receipts, support replies, and employee mail will pass, so the process needs both DNS inspection and live-message testing.

What a DMARC record check should tell you

When someone searches for a DMARC record checker, they usually need answers to four practical questions:

1. Is a DMARC record publicly available for my domain?
2. Can receiving mail servers parse and apply it?
3. Will legitimate mail pass DMARC through every sender we use?
4. What will happen when an attacker sends a fake message using our domain?

A complete check answers all four. Many free lookup tools only answer the first two, which is useful but incomplete.

DMARC is a DNS TXT record published under the _dmarc subdomain. For example.com, the normal lookup name is:

_dmarc.example.com

The record tells receivers how to handle messages that fail DMARC. The three common policy values are:

• p=none — request monitoring only; receivers can still make their own delivery decision.
• p=quarantine — request suspicious messages be treated as spam or otherwise quarantined.
• p=reject — request rejection of unauthenticated, non-aligned mail.

These are requests to receivers, not a promise of a universal outcome. DMARC contributes authentication and policy information to a receiver's mail decisions; it does not guarantee inbox placement for authenticated campaigns.

How DMARC validation works

A DMARC record check becomes much easier once you separate the three domains that can appear in a message.

The visible From domain

This is the domain recipients see in their mail client:

From: Acme Updates <news@example.com>

For DMARC, the relevant domain is example.com. It is often called the Header From or RFC 5322.From domain.

The SPF domain

SPF authenticates the envelope sender, commonly visible as Return-Path. A marketing platform might send a message with:

Return-Path: bounce@mailer.example.net

SPF can pass for mailer.example.net while still failing DMARC alignment for example.com. That is why an SPF pass by itself is not always a DMARC pass.

The DKIM signing domain

DKIM adds a cryptographic signature to the message. In message headers, it looks roughly like this:

DKIM-Signature: v=1; d=example.com; s=mail1; ...

If the signature verifies and d=example.com aligns with the visible From: example.com, the message can pass DMARC even if SPF does not align. In practice, aligned DKIM is often the more resilient option for third-party senders because forwarding can disrupt SPF.

The pass rule in plain English

DMARC passes when at least one of these conditions is true:

• SPF passes and its authenticated domain aligns with the visible From domain, or
• DKIM passes and its d= signing domain aligns with the visible From domain.

It does not require both SPF and DKIM to pass for a DMARC pass. However, major mailbox providers require bulk senders to configure both SPF and DKIM, so operating with both is the sensible baseline even when only one aligned mechanism is needed per message.

Run a DMARC record check from the command line

A browser-based checker is convenient, but command-line DNS lookups are a reliable way to see what public resolvers can retrieve. They also help distinguish a DNS publishing problem from a checker-tool problem.

macOS and Linux: use dig

Run this command, replacing the example domain:

dig +short TXT _dmarc.example.com

A healthy result might be:

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

Some DNS providers split a long TXT record into quoted chunks. That does not necessarily mean the record is broken: DNS clients concatenate TXT chunks when interpreting the value. What matters is that the resulting text is one valid DMARC policy record.

To inspect the full DNS response, including which name servers answered and the TTL, remove +short:

dig TXT _dmarc.example.com

Windows: use nslookup

In Command Prompt or PowerShell, run:

nslookup -type=TXT _dmarc.example.com

If the result says the domain does not exist or returns no TXT answer, check the record name in your DNS provider. A common error is entering the complete name in a control panel that automatically appends the zone name, producing _dmarc.example.com.example.com.

Check a specific public resolver

If DNS changes appear inconsistent, query a public resolver directly:

dig @1.1.1.1 +short TXT _dmarc.example.com
dig @8.8.8.8 +short TXT _dmarc.example.com

Different results can indicate DNS propagation or caching. Do not assume a DNS change is live just because your DNS provider's dashboard displays it. Confirm the public record resolves correctly before moving to email testing.

Read a DMARC record tag by tag

The current DMARC core specification is RFC 9989, which retains v=DMARC1 as the record version. It supersedes the older RFC 7489 specification. Existing records using the familiar DMARC1 format continue to be recognizable, but some older optional tags have changed status in the newer standard.

For most organizations, a small record with an intentional policy and aggregate reporting is easier to operate than a long string of poorly understood options.

Required and high-value tags

Here is a practical record for monitoring:

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

The important tags are:

The v tag must be DMARC1, and it should be the first tag. Do not publish a separate TXT record for each tag. The DMARC policy is a single semicolon-delimited string in one DNS TXT record.

Relaxed versus strict alignment

Relaxed alignment allows subdomains within the same organizational domain to align. For example, with relaxed DKIM alignment, a visible From domain of example.com can align with a valid DKIM signature from mail.example.com.

Strict alignment requires an exact domain match. If a message says From: billing@example.com, a DKIM signature with d=mail.example.com would not strictly align.

Start with relaxed alignment (adkim=r; aspf=r) unless you have a controlled, well-inventoried sending environment and a specific reason to require exact matches. Strict alignment can be valuable, but it frequently breaks legitimate mail from platforms that use delegated or subdomain-based sending identities.

The subdomain policy tag

sp= controls the requested policy for subdomains that do not publish their own DMARC record. For example:

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

This asks receivers to reject DMARC failures for example.com but quarantine failures for subdomains such as news.example.com, unless that subdomain has its own policy record.

If sp is omitted, the parent domain policy is generally used for subdomains. Check subdomain behavior deliberately if you use separate domains for product mail, transactional email, customer communications, or regional brands.

Reporting tags and the newer specification

rua requests aggregate reports: machine-readable XML summaries that show sending IPs, authentication results, aligned domains, policy outcomes, and message counts. They are the foundation of a safe DMARC rollout.

Some older records also include ruf, fo, pct, rf, and ri. The newer DMARC specifications separate core behavior and reporting, and treat several historical tags differently. In particular, pct, rf, and ri are no longer active core-policy tags in RFC 9989-era deployments, although older receivers and tooling may still recognize them. Avoid treating pct as a dependable modern enforcement control.

A conservative record check should flag unfamiliar or malformed optional tags, but it should not automatically call every legacy tag a fatal error. Record interpretation can differ while mailbox providers and DMARC tools transition between specifications. The safest operational rule is simple: verify the behavior of live mail, rather than relying only on what a parser labels valid.

Check whether you have the right DNS record

A DMARC lookup can fail even when you believe you published a record. Work through this checklist before changing policy values.

1. Confirm the hostname

For the root domain example.com, create a TXT record named:

_dmarc

or:

_dmarc.example.com

Which form you enter depends on the DNS host's interface. If the provider already shows the zone as example.com, entering _dmarc is usually correct. Consult the provider's field labels rather than guessing.

For a separate sending subdomain such as mail.example.com, the lookup target is:

_dmarc.mail.example.com

2. Ensure there is only one DMARC policy record at that hostname

DMARC requires a single valid policy record at the queried _dmarc name. Multiple TXT records can coexist at a hostname for unrelated purposes, but publishing two separate values that both begin with v=DMARC1 creates an invalid DMARC result.

This often happens after a team adds a new record instead of editing an existing monitoring record. Delete or consolidate duplicate DMARC policies; do not try to split them by mail provider.

3. Check for a typo that changes meaning

These mistakes are common:

• v=DMARC instead of v=DMARC1
• policy=reject instead of p=reject
• A missing semicolon between tags
• Curly quotation marks pasted from a document editor
• A comma where a semicolon is required
• rua=mailto:reports@example.com pointing to an unmonitored mailbox
• p=reject applied before every legitimate sender has been tested

Spaces after semicolons are normally fine, but avoid adding spaces inside tag names, values, or email addresses.

4. Check the report mailbox or service

Aggregate report attachments can arrive in large volumes for active domains. Use a dedicated mailbox, group, or reporting platform rather than an employee's normal inbox. Google specifically recommends a dedicated destination because large organizations can receive hundreds or thousands of reports daily.

If rua points to an address outside the protected domain—for example, a DMARC analytics vendor—external report authorization may be necessary. The receiving domain publishes a special DNS authorization record so report generators can verify that it accepts reports for your domain. Good DMARC platforms provide the exact hostname and TXT value; copy it exactly and verify it separately.

A worked DMARC record check example

Assume a SaaS company, Northstar, sends four types of mail:

• Employee messages from Google Workspace using @northstar.example
• Product receipts through an email API
• Marketing campaigns through a newsletter platform
• Support replies through a help desk tool

The visible From address for all four is intended to be something@northstar.example.

Step 1: Publish a monitoring record

Northstar adds this TXT record at _dmarc.northstar.example:

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

The team verifies it with:

dig +short TXT _dmarc.northstar.example

Expected outcome: the response contains exactly one policy beginning with v=DMARC1 and including p=none.

Step 2: Inventory every sender

Before raising enforcement, Northstar makes a table. This is the step that prevents legitimate email from being rejected.

For the transactional service, the team follows the provider's instructions to add its DKIM records and a custom return-path domain where available. If you are implementing a programmatic sender, keep provider DNS values and sending-domain configuration together with your application's email API setup guides, so domain changes do not leave authentication records behind.

Step 3: Send real test messages

Northstar sends one message from each stream to test mailboxes at Gmail, Yahoo Mail, Microsoft Outlook, and a private domain mailbox. In each received message, the team opens the full headers and looks for an authentication summary resembling:

Authentication-Results: ...
  spf=pass ...
  dkim=pass ... header.d=northstar.example;
  dmarc=pass ... header.from=northstar.example;

The exact format varies by receiver. The important line is dmarc=pass, plus the aligned SPF or DKIM identity that explains why it passed.

Suppose marketing mail produces this result:

spf=pass smtp.mailfrom=bounces.vendor-mail.example;
dkim=pass header.d=vendor-mail.example;
dmarc=fail header.from=northstar.example;

The record is not the immediate problem. SPF and DKIM both pass, but neither authenticated domain aligns with northstar.example. Northstar must configure the newsletter platform's custom DKIM signing domain, custom bounce domain, or branded sending domain according to that vendor's documentation.

Step 4: Read aggregate reports before enforcement

After reports begin arriving, Northstar checks for:

• Sending IP addresses and services it recognizes
• Legitimate traffic that is failing alignment
• Unexpected countries, networks, or sources using the domain
• Mail sent from old systems nobody owns anymore
• Messages using lookalike or unauthorized subdomains

The team fixes any authorized source that fails DMARC. It does not add an unknown IP address to SPF merely because it appears in a report; that can accidentally authorize an attacker or obsolete service.

Step 5: Move toward enforcement only when evidence supports it

Once every legitimate mail stream consistently passes and reports show no unresolved authorized failure sources, Northstar can change to:

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

After continued monitoring, the more protective endpoint is:

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

A successful DMARC record check at this stage means more than “the parser says valid.” It means the record resolves publicly, the aggregate reports are arriving, known mail passes at recipient systems, and the policy does not expose an untested sender to rejection.

Troubleshoot common DMARC check failures

“No DMARC record found”

First query the exact name: _dmarc.yourdomain.com. Then check the active authoritative DNS zone, not just the registrar account. Domains are frequently registered with one company while DNS is hosted with another.

Also inspect the record name for accidental duplication. A record shown as _dmarc.yourdomain.com.yourdomain.com will not answer a normal DMARC query.

“Multiple DMARC records found”

Remove duplicate v=DMARC1 records at the same hostname and keep one consolidated policy. You cannot publish one DMARC record for Google Workspace and another for a marketing platform; DMARC represents the domain owner's single policy.

“SPF passes but DMARC fails”

This is an alignment problem. Compare the visible From domain with the SPF-authenticated envelope domain. Configure a custom return-path or use DKIM aligned to the visible From domain.

Do not solve every alignment problem by weakening policy. First determine whether the vendor supports a branded sending domain, custom DKIM, or custom bounce domain.

“DKIM passes but DMARC fails”

Inspect the DKIM d= value. A vendor signature such as d=vendor.example proves the vendor signed the mail, but it does not authenticate your visible From domain for DMARC.

Set up the vendor's domain-authentication flow, usually by publishing CNAME or TXT records for a selector under your domain. Then resend a test message and verify header.d= is aligned.

“DMARC reports are not arriving”

Check that the rua URI uses the required mailto: form and that the mailbox can receive attachments. Some receivers do not send reports for every domain or every day, so absence of one provider's report does not prove the record is broken.

If the report address is on another domain, verify the external destination authorization record supplied by your reporting vendor. Also check spam, attachment filtering, mailbox quotas, and forwarding rules.

“Legitimate forwarded messages fail”

Forwarding can change the path that SPF evaluates, causing SPF to fail or lose alignment. Mailing lists can also modify messages and affect DKIM signatures. This is one reason to configure aligned DKIM for your own streams and to judge policy changes through report data rather than a single forwarded-message test.

What a DMARC checker cannot prove

A public DMARC checker is excellent for DNS visibility and syntax review. It cannot see private configuration inside your email platforms, verify that every application is using the approved From domain, or reproduce every receiver's delivery decision.

It also cannot tell you whether your sending reputation, list quality, content, complaint rate, reverse DNS, TLS configuration, and unsubscribe flow meet mailbox-provider expectations. Authentication is essential, but it is only one component of deliverability.

For example, Gmail requires senders of more than 5,000 messages per day to personal Gmail accounts to use SPF, DKIM, and DMARC; it permits a DMARC policy of p=none for that requirement. Yahoo's bulk-sender guidance likewise calls for SPF, DKIM, a valid DMARC policy, and alignment. Those requirements make a valid DMARC record necessary, but they do not make an unaligned or unwanted campaign deliverable.

A practical DMARC rollout path

Use a staged rollout based on evidence, not a calendar deadline.

1. Inventory all authorized senders. Include CRM tools, billing systems, form plugins, support desks, recruiting platforms, monitoring tools, and individual departments.
2. Configure SPF and DKIM for each sender. Prefer an aligned DKIM signature for every service that sends with your domain in the visible From header.
3. Publish p=none with rua. Confirm DNS resolution and report delivery.
4. Test real mail from every stream. Read headers at multiple mailbox providers and document the passing authentication path.
5. Review aggregate reports. Separate expected sources from unauthorized or unknown activity.
6. Fix alignment failures. Configure custom sending identities rather than adding blanket SPF allowances.
7. Advance to quarantine or reject. Change policy only when known, legitimate traffic is consistently passing.
8. Keep monitoring after enforcement. New tools, acquisitions, and vendor changes can introduce fresh failures.

Treat DMARC as an operating process, not a one-time DNS task. The most frequent failure is not invalid syntax; it is a team adding a new sender months later without configuring DKIM, SPF alignment, and DMARC testing.

How to tell your DMARC setup worked

Your implementation is working when all of the following are true:

• A public DNS query returns one valid v=DMARC1 record at _dmarc.yourdomain.com.
• The intended p policy is visible, rather than an old or duplicate policy.
• Your rua destination receives and processes aggregate reports.
• Each authorized sending service generates real messages with dmarc=pass.
• Each pass has aligned SPF or aligned DKIM, not merely an unaffiliated vendor pass.
• Reports identify known senders and expose suspicious unauthorized sources.
• You can safely apply the chosen policy without interrupting legitimate business email.

For most organizations, the end goal is a monitored p=reject policy on the primary brand domain, alongside deliberate policies for active sending subdomains. The correct endpoint can differ for a domain that never sends mail, a domain used only for internal systems, or a domain with complex delegated subdomains—but every case benefits from a repeatable DMARC record check.

FAQ

What is the DMARC record lookup address?

For example.com, look up the TXT record at _dmarc.example.com. For a subdomain such as mail.example.com, use _dmarc.mail.example.com.

Does a valid DMARC record mean my email will be delivered?

No. It means receivers can retrieve and parse your policy. Legitimate mail must also pass aligned SPF or DKIM, and delivery still depends on receiver-specific filtering, reputation, complaints, content, and infrastructure quality.

Should I start with p=reject?

Usually no. Start with p=none and aggregate reports unless you have a complete, tested inventory of every system that sends mail using the domain. Moving directly to rejection can block receipts, support replies, campaigns, or automated notifications that were never authenticated correctly.

Do I need both SPF and DKIM for DMARC?

A DMARC pass requires one aligned mechanism: SPF or DKIM. Operationally, configure both. Major mailbox providers require bulk senders to use both, and aligned DKIM is especially useful when forwarding makes SPF unreliable.

Why does my DMARC check say pass while a message fails DMARC?

The checker is likely validating DNS syntax and record visibility. A specific message can still fail because its SPF domain or DKIM signing domain does not align with the visible From domain. Check the message's Authentication-Results headers and configure the sending platform accordingly.