A DMARC record validator helps you answer a deceptively simple question: can receiving mail servers find and understand the DMARC policy for your domain? That is essential, but it is only the first check—your mail will pass DMARC only when an SPF or DKIM result also aligns with the domain visible in the From header.

DMARC is an email-authentication policy and reporting protocol. Its purpose is to let a domain owner publish handling guidance for mail that claims to be from that domain but fails DMARC evaluation. The core DMARC standard is RFC 9989; aggregate-report handling is defined separately in RFC 9990, and failure-report handling in RFC 9991. Earlier documentation may instead refer to RFC 7489, which the newer standards replaced.

This guide shows exactly what a DMARC record validator should check, how to validate a record yourself, how to fix the errors validators commonly find, and how to prove your actual email—not merely your DNS—works as intended.

What a DMARC record validator actually validates

A DMARC record validator is a DNS and syntax diagnostic. You enter a domain such as example.com, and the validator looks for a TXT record at this hostname:

_dmarc.example.com

It then assesses whether the returned TXT data is a usable DMARC policy record. A good validator should distinguish among several outcomes:

No DMARC record found: There is no usable policy at the expected lookup location, or the validator cannot resolve it.
Record found and syntactically valid: The record begins with the correct version tag and contains valid tag/value formatting.
Conflicting records: More than one DMARC policy record was published at the same lookup name. This is not a stronger configuration; it is a configuration error.
Record is valid but incomplete operationally: For example, the record contains an external aggregate-report address that is not authorized to receive reports.
Policy is published but mail does not pass DMARC: DNS syntax is fine, but SPF and DKIM authentication or domain alignment is failing in real messages.

That last distinction matters most. A validator can read your policy, but it cannot infer every system that sends mail for you. A newsletter platform, CRM, billing app, support desk, recruiting tool, Google Workspace tenant, Microsoft 365 tenant, and transactional email API can each create a separate authentication path.

A clean validator result therefore means: receivers can discover and parse your published instruction. It does not mean every message with your domain in the From header will authenticate.

How DMARC works: SPF, DKIM, and alignment

To understand a validator result, separate the three layers involved.

SPF authorizes the envelope sender

SPF evaluates the domain used in SMTP’s envelope sender, commonly called MAIL FROM, Return-Path, or the bounce domain. Its DNS record typically begins with v=spf1 and lists authorized sending services or IP addresses.

SPF can pass while DMARC still fails. That happens when the envelope-sender domain is unrelated to the domain people see in the message’s From header. For example:

Visible From: updates@example.com
Envelope sender: bounce@mailer.vendor-example.net

If SPF passes for mailer.vendor-example.net, it does not automatically satisfy DMARC for example.com.

DKIM signs the message

DKIM adds a cryptographic signature to the email. The signature includes a signing domain, shown in the d= value of the DKIM-Signature header. Receivers use DNS to retrieve that domain’s public key and validate that signed portions of the message were not changed after signing.

DKIM is often the more durable path for DMARC because forwarding can break SPF: the forwarding server may not be authorized by the original sender’s SPF policy. A mailing list can also break DKIM if it alters signed message content, which is why testing indirect mail flows remains important.

DMARC requires one aligned pass

DMARC evaluates the domain in the visible RFC 5322 From: header. To pass DMARC, at least one of these must both pass and align with that visible From domain:

SPF passes and its authenticated envelope-sender domain aligns with the From domain; or
DKIM passes and its d= signing domain aligns with the From domain.

For direct mail, Google describes this as alignment between the domain in the From header and either the SPF or DKIM domain. Google requires SPF or DKIM for all senders to personal Gmail accounts; senders that send more than 5,000 messages per day to personal Gmail accounts must use SPF, DKIM, and DMARC. Yahoo similarly requires bulk senders to use SPF and DKIM, publish at least a p=none DMARC policy, and achieve alignment through either SPF or DKIM.

The DMARC record syntax a validator expects

A DMARC policy is a DNS TXT record. The most compatible record format begins with v=DMARC1, followed by semicolon-separated tag/value pairs.

A practical monitoring-mode record looks like this:

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

Publish it at:

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

Most DNS dashboards automatically append your root domain when you enter _dmarc in the host field. In that interface, entering _dmarc.example.com could accidentally create _dmarc.example.com.example.com. Always check the final hostname shown by the DNS provider.

The important tags

Here are the policy tags most administrators will encounter.

Tag	What it does	Typical value
`v`	Identifies the DMARC version. It must be first.	`DMARC1`
`p`	Requests handling for mail that fails DMARC for the policy domain.	`none`, `quarantine`, or `reject`
`rua`	Requests aggregate reports at one or more destinations.	`mailto:dmarc-reports@example.com`
`adkim`	Sets DKIM alignment mode.	`r` or `s`
`aspf`	Sets SPF alignment mode.	`r` or `s`
`sp`	Sets a policy for subdomains when applicable.	`none`, `quarantine`, or `reject`

The p tag is the main policy decision:

p=none asks receivers to monitor failures without requesting quarantine or rejection under the DMARC policy.
p=quarantine asks receivers to treat failed mail as suspicious, commonly by placing it in spam or a similar folder.
p=reject asks receivers to reject mail that fails DMARC.

DMARC policy is receiver guidance, not a guarantee of identical treatment at every mailbox provider. Receivers can consider local anti-abuse signals, message context, and operational constraints when deciding final delivery handling.

Relaxed versus strict alignment

The alignment tags accept r for relaxed and s for strict.

With strict alignment, the authenticated SPF or DKIM domain must exactly match the visible From domain. If the message is from news.example.com, then example.com does not strictly align.

With relaxed alignment, related domains within the same organizational domain can align. For a common configuration, mail from news.example.com may align with an authenticated domain of example.com under relaxed alignment.

Start with relaxed alignment unless you have mapped every approved sending domain and have a clear reason to require exact matches. Strict alignment is not inherently more deliverable; it is a tighter control that can expose gaps in vendor configuration.

A worked DMARC record validator example

Assume a fictional company sends marketing and product email with the visible From address hello@northstarcoffee.example. It uses a transactional email provider and wants aggregate DMARC reports delivered to dmarc@northstarcoffee.example.

Step 1: Inventory every sender before changing policy

List systems that can send email with this domain in the visible From address:

Google Workspace or Microsoft 365 user mailboxes.
The transactional email provider.
The marketing automation platform.
Support software that sends ticket notifications.
Billing, invoicing, and e-commerce tools.
Calendar, recruiting, status-page, and form-notification services.

Do not limit this list to your primary mail provider. A DMARC deployment often breaks overlooked third-party messages, not employee mailbox mail.

Step 2: Confirm SPF and DKIM are configured for each sender

For each service, identify which authentication path will align:

Does it use a custom return-path or bounce domain beneath northstarcoffee.example so SPF can align?
Does it DKIM-sign with d=northstarcoffee.example or a subdomain such as mail.northstarcoffee.example?
Is the service still sending with the provider’s default DKIM domain, such as vendor-example.net?

For the transactional provider, configure a custom sending domain and enable the provider’s DKIM records before moving past DMARC monitoring. When you operate several sending services, centralizing this inventory alongside your email API reference and setup guides prevents a DNS record from becoming the only documentation of your sending architecture.

Step 3: Publish a monitoring record

Create this TXT record:

_dmarc.northstarcoffee.example. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@northstarcoffee.example; adkim=r; aspf=r"

In a DNS dashboard, the equivalent is usually:

Host: _dmarc
Type: TXT
TTL: provider default or an operationally appropriate value
Value: v=DMARC1; p=none; rua=mailto:dmarc@northstarcoffee.example; adkim=r; aspf=r

Do not add quotation marks unless the DNS provider explicitly asks for them. Zone-file examples use quotes to delimit a text value; many web dashboards add the necessary quoting themselves.

Step 4: Query DNS directly

Run either command from a terminal:

dig +short TXT _dmarc.northstarcoffee.example

or:

nslookup -type=TXT _dmarc.northstarcoffee.example

A healthy lookup should return one DMARC policy value beginning with v=DMARC1. DNS providers can split a long TXT string into quoted chunks at the DNS layer. That is normal when the pieces reconstruct to one record; it is different from publishing two separate DMARC policy records.

Step 5: Run a DMARC record validator

Paste northstarcoffee.example into a validator. The expected result should state that:

the record exists at _dmarc.northstarcoffee.example;
there is exactly one usable DMARC policy record;
v=DMARC1 is recognized;
p=none is valid;
the rua address has valid URI syntax; and
relaxed SPF and DKIM alignment are configured.

A validator may also warn that p=none is not enforcing against spoofed messages. That is not an error during a deliberate monitoring phase. It becomes an action item once reports and live-message tests show that legitimate mail is authenticating consistently.

Step 6: Send real messages and inspect authentication results

Send one message from every sending source to test mailboxes at Gmail, Outlook.com, Yahoo Mail, and a mailbox you control. Open full message headers and locate an Authentication-Results header.

A successful result resembles this shape:

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

The exact wording differs by mailbox provider. What matters is that the receiver reports dmarc=pass and identifies the visible From domain you intended.

Step 7: Read aggregate reports before enforcing

Aggregate reports requested through rua are XML documents, often compressed. They summarize traffic by source IP address and include the receiver’s SPF, DKIM, and DMARC evaluation results. They are not individual-message inbox logs.

Review reports for unknown senders, expected vendor sources that fail alignment, and unexpected traffic volume. A dedicated reporting mailbox can receive a substantial number of reports, especially for organizations with high mail volume; use a DMARC reporting service or XML parser if manually inspecting compressed XML is impractical.

Only after you recognize legitimate traffic and see it passing DMARC should you consider raising the policy to quarantine and eventually reject.

How to interpret common validator errors

A DMARC record validator is most useful when you treat its finding as a diagnosis, not a generic red or green badge.

“No DMARC record found”

First, query the exact hostname:

dig +short TXT _dmarc.example.com

If it returns nothing, check the DNS zone, host field, and nameservers authoritative for the domain. Common causes include publishing the record at example.com instead of _dmarc.example.com, editing DNS at a registrar that is not hosting authoritative DNS, or checking before DNS changes have propagated through recursive resolvers.

Also verify that you are testing the precise domain used in the visible From header. example.com and mail.example.com can have different DMARC policy discovery behavior.

“Multiple DMARC records” or “conflicting policies”

You must publish one DMARC policy record at a given DMARC hostname. Do not create separate records for separate providers, such as one record for Microsoft 365 and another for a marketing platform.

This is invalid:

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:ops@example.com"
_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:security@example.com"

Merge the intention into one policy record instead. Multiple aggregate-report addresses can be listed in the same rua tag, separated by commas:

v=DMARC1; p=none; rua=mailto:ops@example.com,mailto:security@example.com

The same rule does not prohibit a DNS host from returning multiple quoted character strings that compose one TXT record. Long DNS TXT values are often displayed that way by lookup tools.

“Missing or invalid version tag”

DMARC policy records must begin with the DMARC version identifier:

v=DMARC1;

Putting p=none first, using v=DMARC, adding explanatory prose, or pasting DNS-provider instructions into the value can make the record unusable. A case of stray punctuation can matter too: use semicolons between tags and a single equals sign between a tag and its value.

Correct:

v=DMARC1; p=none

Incorrect:

p=none; v=DMARC1

“Unknown tag” or “deprecated tag”

Check which specification your validator implements. RFC 9989 replaced the earlier core DMARC specification and modernized policy discovery and tag definitions. Older validators may evaluate records only through the historical RFC 7489 model, while newer validators may flag legacy-oriented tags or support additional RFC 9989 policy controls.

For a broad-compatibility deployment, use the small, well-supported tag set unless you specifically need an advanced behavior:

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

Do not add tags merely because an online record generator offers them. Every tag should correspond to a policy decision you understand and can test.

“External report destination is not authorized”

An external destination means the domain after the @ in rua belongs to a different organizational domain than the applicable DMARC policy domain.

For example:

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

If this record is published for example.com, the reporting service must authorize receiving reports for your domain. Under the aggregate-reporting standard, the authorization is published beneath the destination domain using this pattern:

example.com._report._dmarc.dmarc-service.example. IN TXT "v=DMARC1"

A reputable DMARC reporting vendor normally manages this authorization record for its own reporting domain. If you control both domains, you must publish it yourself. Without a valid authorization relationship, some receivers may not send reports to the external mailbox even though the base DMARC record looks valid.

DNS mistakes a validator may not explain clearly

Wildcard TXT records can create misleading answers

A wildcard DNS record can cause a lookup for _dmarc.example.com to return unrelated TXT content: an SPF string, a site-verification token, or arbitrary text. That does not create a DMARC policy simply because it is returned from a DMARC-looking hostname.

If a validator says it found an SPF record or a domain-verification token at _dmarc, inspect DNS wildcard rules. The fix is not to modify SPF; it is to publish the correct explicit TXT record at _dmarc.example.com and reconsider whether the wildcard is appropriate.

CNAME use is provider-specific

Some hosted DMARC or DNS services instruct customers to create a CNAME at _dmarc pointing to a managed policy hostname. Follow the provider’s documented setup exactly and verify the final resolved policy with a validator and a DNS query.

Do not assume every DNS host, receiver, or tooling workflow handles indirect records identically. If you do not need delegated DMARC management, a direct TXT record at _dmarc is easier to inspect and troubleshoot.

A DNS record cannot repair a bad sender identity

A pristine record does not fix a provider that signs mail as d=provider.example while your visible From address is billing@yourdomain.com. Configure that service’s custom DKIM signing domain or aligned bounce domain, or use a From domain that the provider can authenticate correctly.

This is especially important for transactional mail. Before choosing a sending platform, compare support for custom sending domains, DKIM setup, report handling, and operational costs—not just API ergonomics. A clear view of transactional email pricing is useful when reporting, domain authentication, and sending volume are part of the same infrastructure decision.

A safe progression from monitoring to enforcement

A validator cannot decide when your organization is ready for p=reject. That decision should come from evidence gathered across normal email operations.

Use this staged process:

Publish p=none. Start receiving aggregate reports without asking receivers to quarantine or reject failed messages.
Identify legitimate sources. Match report IPs and domains to known tools, departments, subsidiaries, and vendors.
Fix alignment failures. Enable custom DKIM domains, aligned return paths, or correct From domains for every legitimate sender.
Test every important workflow. Include password resets, receipts, invoices, support replies, marketing campaigns, and employee mail.
Move to p=quarantine when known traffic passes. Continue monitoring reports and support tickets.
Move to p=reject when failures are understood. Keep reviewing reports because vendors, acquisitions, and new software can introduce new sending paths.

A practical enforcement record might be:

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

If you send from subdomains, decide whether they need their own records or whether the parent-domain policy should govern them. Use sp only when you intentionally want a subdomain policy that differs from the main p policy, and test the actual subdomain From addresses involved.

How to tell whether DMARC is working

A successful DMARC deployment has four separate signs of health.

1. DNS discovery is clean

A DMARC record validator finds one usable policy record at the expected _dmarc hostname. It reports valid syntax and does not find conflicting records or malformed version tags.

2. Real messages show `dmarc=pass`

Inspect headers from each of your sending platforms. You want the receiver’s authentication result to show DMARC pass for the From domain you use. Do not rely solely on an email provider dashboard claiming “domain verified”; inspect the delivered message result.

3. Aggregate reports identify expected traffic

Your rua reports should predominantly show known senders and passing authentication for legitimate mail. Unknown sources merit investigation: they may be an old vendor, an unauthorized system, forwarded traffic, or attempted domain impersonation.

4. Enforcement does not interrupt intended mail

When you raise policy from monitoring to quarantine or reject, password-reset and invoice emails should still arrive, campaign metrics should remain stable, and support teams should not see a surge in delivery complaints. DMARC protects the domain from unauthorized use; it should not become a surprise outage for mail you intended to send.

DMARC record validator checklist

Before treating a validator’s green status as complete, run through this checklist:

FAQ

What is the best DMARC record validator?

The best DMARC record validator is one that checks the published DNS record, identifies duplicate or malformed policy records, explains tag errors, and shows the effective policy a receiver can discover. Use it alongside direct dig or nslookup queries and live email-header tests; no DNS-only validator can prove that every sender passes alignment.

Can I have multiple DMARC TXT records?

No. Publish one DMARC policy record per DMARC lookup hostname. If you need multiple aggregate-report recipients, place multiple comma-separated mailto: URIs inside one rua tag rather than publishing competing records.

Does `p=none` mean DMARC is not working?

No. p=none is a valid monitoring policy. DMARC can still evaluate messages and produce pass or fail results, while the policy does not request quarantine or rejection for failures. It is useful while you inventory senders and correct authentication gaps.

Why does SPF pass but DMARC fail?

SPF can pass for the envelope-sender domain while the visible From domain is different. DMARC requires alignment, so the SPF-authenticated domain must align with the From domain, or a passing DKIM signature must align instead.

How long should I stay at `p=none`?

Stay in monitoring until aggregate reports and message-header tests show that legitimate mail sources are known and reliably pass DMARC. The correct duration depends on how many systems send mail for your domain and how often new services are introduced; moving to enforcement before that inventory is complete can disrupt valid mail.

DMARC Record Validator: Check, Fix, and Test Your DNS Policy