DMARC Record Errors: How to Find, Fix, and Prevent Them

DMARC record errors can leave a domain unprotected from spoofing, prevent legitimate email from being delivered, or make a policy appear valid while receivers ignore it. The fastest fix is to separate the problem into four layers: DNS publication, DMARC record syntax, SPF/DKIM alignment, and the policy or reporting behavior that follows.

DMARC—Domain-based Message Authentication, Reporting, and Conformance—uses a DNS TXT record to tell receiving mail systems how to evaluate mail that uses your domain in the visible From: header. A message passes DMARC when either SPF or DKIM passes and the passing identifier aligns with that visible From: domain. That distinction explains why a record can be perfectly written yet your marketing, support, invoicing, or application mail still fails.

This guide covers the errors that matter in production, how to inspect each one, and how to prove the repair worked before moving to an enforcement policy.

What counts as a DMARC record error?

“DMARC record error” is often used for several different failures. Treating them as one issue wastes time because the fix for a malformed TXT record is completely different from the fix for a message that fails DKIM alignment.

The practical categories are:

1. Publication errors: the record is missing, published at the wrong hostname, hidden by a DNS mistake, or duplicated.
2. Syntax and tag errors: v=DMARC1 is misspelled, required tags are in the wrong order, delimiters are missing, or a tag has an invalid value.
3. Authentication errors: SPF and DKIM do not pass, or they pass for domains that do not align with the visible From: domain.
4. Reporting errors: aggregate reports are pointed at a mailbox that cannot receive them, use an invalid URI, or require external-destination authorization that is absent.
5. Policy errors: p=quarantine or p=reject is activated before every legitimate mail stream is authenticated.
6. Interpretation errors: a DNS checker reports a warning about a deprecated or optional tag, but the record is still usable; or it reports a valid record even though real messages fail DMARC.

A DMARC validator can tell you whether DNS returns a record it understands. It cannot, by itself, prove that every mail system sending as your domain has correct SPF, DKIM, envelope sender settings, and header alignment.

How DMARC evaluation actually works

Before changing DNS, understand the identifiers that DMARC compares. The visible sender address is not always the same identity used by SMTP or DKIM.

A typical message has at least these relevant values:

• Header From / RFC 5322.From: the address recipients see, such as billing@acme.example.
• Envelope From / MAIL FROM / Return-Path: the bounce address used during SMTP delivery, such as bounce@mailer.acme.example or bounce@vendor-mail.example.
• DKIM signing domain: the value after d= in a DKIM-Signature header, such as d=acme.example or d=send.acme.example.

DMARC starts with the domain in the visible From: header. It then checks whether either SPF or DKIM both authenticates and aligns.

SPF alignment

SPF evaluates whether the server that sent the message is authorized to use the envelope-from domain. For DMARC to use that SPF result, the envelope-from domain must also align with the visible From: domain.

Example:

From: invoices@acme.example
Return-Path: bounces@mailer.acme.example
SPF: pass

With relaxed SPF alignment (aspf=r), mailer.acme.example can align with acme.example because it is a subdomain within the same organizational domain. With strict alignment (aspf=s), it would fail because the domains are not identical.

A common failure looks like this:

From: updates@acme.example
Return-Path: bounce@provider-mail.example
SPF: pass

SPF passes for provider-mail.example, but it does not align with acme.example. That SPF pass cannot make DMARC pass. If DKIM is aligned and passes, the message can still pass DMARC; if not, it fails.

DKIM alignment

DKIM validates a cryptographic signature added to the email. DMARC uses the domain in the signature’s d= value.

Example:

From: news@acme.example
DKIM-Signature: d=acme.example; s=mail1; ...
DKIM: pass

That passes DKIM alignment in both relaxed and strict modes. This also passes relaxed alignment:

From: news@acme.example
DKIM-Signature: d=mailer.acme.example; s=mail1; ...
DKIM: pass

But it fails strict DKIM alignment because mailer.acme.example is not exactly acme.example.

The rule that prevents confusion

A message does not need SPF and DKIM to both pass DMARC. One aligned pass is enough. Conversely, a message can have SPF=pass and DKIM=pass in a mail header and still fail DMARC if both passing domains are misaligned with the visible From: domain.

That is why the first diagnostic question should be: Which domain passed SPF, which domain passed DKIM, and do either match the domain in From:?

The correct location and minimum DMARC record syntax

Publish DMARC as a DNS TXT record at this exact name:

_dmarc.yourdomain.example

For a domain named acme.example, the full record name is:

_dmarc.acme.example

The minimum practical record is:

v=DMARC1; p=none

A more useful monitoring record sends aggregate reports to a mailbox you control:

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

In a DNS-zone-file format, that might look like:

_dmarc.acme.example. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@acme.example"

Your DNS provider’s interface may ask for a Host, Name, or Record name field. If the DNS zone is already acme.example, the correct value is often _dmarc, not _dmarc.acme.example. Providers differ: inspect the resulting authoritative DNS name rather than trusting the label in the dashboard.

Required parts and safe common tags

A conventional record uses tag-value pairs separated by semicolons:

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

The most useful tags are:

Use adkim=r and aspf=r only when you want to state the defaults explicitly. Relaxed alignment is usually the safest starting point because many legitimate platforms sign from a subdomain. Strict alignment is an intentional control, not a generic deliverability improvement.

Record-order rule that causes avoidable errors

The v=DMARC1 tag must appear first. A record such as this can be treated as invalid:

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

Use this instead:

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

Spaces around semicolons are normally harmless, but do not add explanatory prose, quote marks copied from an instructional page, or a second unrelated TXT value into the DMARC record.

The most common DMARC record errors and their fixes

1. The record is published at the root domain instead of _dmarc

This is the classic error:

acme.example TXT "v=DMARC1; p=none"

That is not a DMARC record. Receivers look under _dmarc.acme.example, not at the domain apex.

Fix: create a TXT record named _dmarc in the acme.example zone, then query the full hostname:

dig +short TXT _dmarc.acme.example

You should see the DMARC string returned. If you see no answer, query the authoritative nameservers or check that you edited the active DNS provider rather than a parked or old zone.

2. More than one DMARC TXT record exists

A domain must not publish multiple DMARC policy records at the same _dmarc hostname. Combining one record for marketing with another for corporate mail does not create two policies. It creates ambiguity, and receivers can treat the policy as unusable.

Problem example:

_dmarc.acme.example TXT "v=DMARC1; p=none"
_dmarc.acme.example TXT "v=DMARC1; p=reject; rua=mailto:reports@acme.example"

Fix: merge intended tags into one record:

v=DMARC1; p=none; rua=mailto:reports@acme.example

Do not confuse a single DNS TXT value split into quoted chunks by a DNS provider with multiple DMARC records. Long TXT data is often displayed as adjacent quoted strings in zone output; that can still represent one logical record. What matters is whether the DNS response contains more than one independent DMARC policy value beginning with v=DMARC1.

3. v=DMARC1 is misspelled, lowercased, or not first

Examples of invalid or risky entries include:

v=dmarc1; p=none
version=DMARC1; p=none
p=none; v=DMARC1
v=DMARC; p=none

Fix: use exactly v=DMARC1 as the first tag. Avoid adding a version tag twice.

4. The p value is missing or invalid

The policy tells receivers what you request for mail that fails DMARC. Valid policy values are:

p=none
p=quarantine
p=reject

These are not interchangeable spelling variations. p=monitor, p=spam, p=block, and p=100 are invalid.

Fix: use p=none during discovery, p=quarantine when you have validated mail sources, and p=reject when you are confident that unauthenticated mail using the domain should be refused. A receiver’s final handling can still incorporate its own local policies and reputation signals; DMARC is a requested disposition, not a guarantee of inbox placement.

5. A wildcard TXT record is being returned

Some zones have wildcard DNS entries such as *.acme.example. A lookup for _dmarc.acme.example may then return an SPF string, a site-verification token, or unrelated content rather than a DMARC policy.

A returned result like this is wrong:

v=spf1 include:mail.example -all

It means a DMARC lookup got an SPF record, not that SPF has somehow configured DMARC.

Fix: publish an explicit _dmarc TXT record. Also review wildcard DNS entries so they do not accidentally answer mail-authentication lookups with unrelated values.

6. Semicolons, equals signs, or URI formatting are broken

These syntax mistakes are easy to miss in DNS dashboards:

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

Fix: separate tags with semicolons, use =, and include mailto: in email reporting URIs:

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

A comma separates multiple report URIs, not multiple policies:

v=DMARC1; p=none; rua=mailto:dmarc@acme.example,mailto:security@acme.example

Keep the list intentional. Every destination should be controlled and monitored because DMARC aggregate reports contain useful operational information about mail claiming to be from your domain.

Why a valid DMARC record can still fail email

DNS validity is only the beginning. Most production DMARC incidents happen because a sender was omitted from the authentication inventory.

Common senders include:

• Google Workspace or Microsoft 365 user mail.
• Transactional application mail sent through an email API.
• Marketing automation and newsletters.
• CRM sequences and sales-engagement tools.
• Customer support platforms and ticketing systems.
• Payroll, invoicing, billing, and ecommerce platforms.
• Website forms, WordPress plugins, scanners, and monitoring alerts.
• Internal systems, printers, NAS devices, and legacy SMTP relays.

Each system may use a different envelope-from domain, DKIM selector, signing domain, or outbound server. A vendor can send a message that looks like it comes from you@acme.example while authenticating only its own vendor domain. That message may pass ordinary SPF but fail DMARC alignment.

The sender inventory you need before enforcement

Build a table for every system that sends mail using your visible domain:

The third row is the issue to solve before enforcement. The normal solution is vendor-specific domain authentication: configure a custom DKIM domain, a branded return-path/bounce domain, or both. Your provider should supply the exact DNS records and sending-domain settings. The platform’s default shared domain is often not enough for DMARC alignment.

If you send product or transactional mail, use the provider’s domain-authentication process and then verify the exact headers from a delivered test message. Your email API setup guides should be treated as the operational source of truth for the service you use, because required CNAME, TXT, DKIM, and return-path settings are vendor-specific.

SPF failures that create DMARC failures

SPF can fail for several reasons:

• The sending IP or service is not authorized in the SPF record.
• You accidentally published more than one SPF TXT record at the root domain.
• An include: mechanism references the wrong provider or an obsolete provider.
• SPF DNS lookup limits are exceeded during evaluation.
• A forwarding system changes the sending path, causing SPF to fail downstream.
• The envelope-from address belongs to a vendor domain, so SPF passes but cannot align.

Do not try to solve every DMARC failure by continually adding include: mechanisms to SPF. SPF has a DNS-lookup limit, and a sprawling SPF record becomes fragile. Aligned DKIM is usually the more resilient authentication path for third-party mail, particularly when forwarding or intermediary systems are involved.

DKIM failures that create DMARC failures

DKIM failures are typically caused by:

• A missing public key at selector._domainkey.yourdomain.example.
• A selector mismatch between the message signature and DNS record.
• A copied key that was truncated or altered in DNS.
• A provider signing with its own domain instead of your authenticated domain.
• A key rotation where the old selector was removed before all senders changed.
• A mailing list or intermediary changing signed content in a way that breaks the signature.

When investigating DKIM, copy the d= and s= values from the message’s DKIM-Signature header. Then query:

dig +short TXT selector._domainkey.example.com

Replace selector and example.com with the values from the actual message. This is more reliable than guessing which DNS record a vendor intended to use.

DMARC reporting errors: why rua does not work

Aggregate reports are compressed XML summaries that receiving organizations may send to the address in rua. They are useful for discovering unknown senders, identifying unauthenticated traffic, and tracking DMARC pass rates over time.

A common monitoring record is:

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

Use a dedicated report destination

Do not point reports at an individual employee’s inbox. Report volume depends on your sending volume and the receivers that choose to send reports. Use a dedicated mailbox, group, or reporting service designed to parse compressed XML attachments.

Reports are not a real-time alerting feed. Different receivers generate and deliver them on their own schedules, and not every receiver sends them. Therefore, the absence of a report does not prove that your record is broken or that no one is spoofing your domain.

External report destination authorization

If rua uses a different organizational domain, the report destination needs to authorize receiving reports for your DMARC policy domain. This prevents someone from maliciously directing a large volume of DMARC reports to an unrelated third party.

Suppose acme.example sends reports to dmarc@reports.example.net:

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

The report-receiving domain needs an authorization TXT record at:

acme.example._report._dmarc.reports.example.net

With a value such as:

v=DMARC1

The report provider usually publishes this record for you, or asks you to publish it in a delegated DNS zone. Follow its documented process exactly. Adding the authorization record to acme.example when the provider controls reports.example.net will not solve the permission problem.

Failure-report tags need special care

Some older guides recommend ruf, fo, rf, and ri settings. Support for detailed failure reports has historically varied, and these reports can have privacy and operational implications. Aggregate reporting through rua is the essential reporting mechanism for most organizations.

Modern DMARC specifications separate core behavior, aggregate reporting, and failure reporting into different documents. Receiver support and behavior can vary, so do not make your enforcement plan depend on getting per-message forensic reports. Begin with aggregate data and message-header testing.

A worked example: fix a failing marketing sender safely

Assume Acme uses Google Workspace for employee mail and a newsletter platform for campaigns. Its DNS contains:

_dmarc.acme.example TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@acme.example; adkim=s; aspf=s"

Campaigns are landing in spam or being rejected. A test campaign produces these relevant authentication results:

From: Acme News <news@acme.example>
Return-Path: bounce@mailer.vendor.example
Authentication-Results: mx.recipient.example;
  spf=pass smtp.mailfrom=mailer.vendor.example;
  dkim=pass header.d=vendor.example;
  dmarc=fail header.from=acme.example

The record is syntactically valid. The failure is not a DNS syntax problem.

Step 1: Read the result literally

• SPF passes, but for mailer.vendor.example, which does not align with acme.example.
• DKIM passes, but for vendor.example, which also does not align with acme.example.
• With strict alignment enabled, neither result can qualify.
• The message therefore fails DMARC.

Step 2: Identify the correct vendor-side repair

In the newsletter platform, look for settings named domain authentication, sending domain, custom DKIM, authenticated domain, branded sending domain, or custom return-path.

The desired end state is generally one of these:

DKIM-Signature: d=acme.example

or, under relaxed alignment:

DKIM-Signature: d=mail.acme.example

The vendor will typically provide DKIM CNAME or TXT records and may provide a custom bounce-domain configuration. Add exactly the supplied records, wait until the vendor marks the domain authenticated, and send a new test campaign.

Step 3: Use relaxed alignment while discovering senders

For a domain early in deployment, replace the strict-alignment record with a monitoring configuration:

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

This does not fix a vendor that signs only as vendor.example; the vendor must still authenticate your domain. But relaxed alignment avoids unnecessarily failing mail that uses legitimate subdomains such as mail.acme.example or bounce.acme.example.

Step 4: Test again and inspect the headers

After vendor authentication, the desired result might be:

From: Acme News <news@acme.example>
Return-Path: bounce@mail.acme.example
Authentication-Results: mx.recipient.example;
  spf=pass smtp.mailfrom=bounce@mail.acme.example;
  dkim=pass header.d=mail.acme.example;
  dmarc=pass header.from=acme.example

Now either SPF or DKIM can satisfy DMARC under relaxed alignment. Having both aligned is better operationally because it provides resilience if one mechanism later fails.

Step 5: Monitor before enforcing

Keep p=none while reports and test messages show that every known sender passes. Add newly discovered sources to the inventory, fix their domain authentication, and retest. Only then move to a stronger policy.

How to check whether your DMARC fix worked

Use three separate checks. Passing only one is not enough.

1. Check public DNS

Run:

dig +short TXT _dmarc.acme.example

Expected output resembles:

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

Confirm all of the following:

• The query is for _dmarc.yourdomain.
• The returned value begins with v=DMARC1.
• There is one logical DMARC policy record.
• p has a valid intended value.
• The rua address is deliberate and correctly formatted.

Use a public DMARC lookup tool as a second view, but prioritize the actual DNS response and authoritative DNS configuration if tools disagree.

2. Test every sending platform with real messages

Send a new message from each sending system to a mailbox where you can view original message headers. In Gmail, use the message menu and choose Show original. In Microsoft Outlook and Microsoft 365, inspect message headers or the relevant security and mail-flow tools.

Look for an Authentication-Results: header and record:

spf=pass
smtp.mailfrom=...
dkim=pass
header.d=...
dmarc=pass
header.from=...

The key outcome is dmarc=pass. If it says dmarc=fail, compare header.from, smtp.mailfrom, and header.d to identify the missing alignment.

3. Review aggregate reports and delivery signals

Aggregate reports should eventually show the sources using your domain, their IP addresses, authentication results, and policy evaluation. Parse them with a DMARC reporting service or an internal tool rather than manually opening every compressed XML file.

Also watch operational outcomes: bounces, vendor dashboards, recipient complaints, spam placement, and Gmail Postmaster Tools where applicable. For senders delivering more than 5,000 messages per day to personal Gmail accounts, Google requires SPF, DKIM, and DMARC; it allows a DMARC policy of p=none for that requirement, but authentication still must be correctly configured.

Choosing none, quarantine, or reject

DMARC policy should reflect what you have proven, not what looks strongest in a security checklist.

p=none: monitor without requesting enforcement

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

Use this to discover senders and analyze failures. It does not ask receivers to quarantine or reject messages that fail DMARC, so it is not the final anti-spoofing posture for a sending domain. It is, however, the right starting point for most domains with complex or poorly documented mail flows.

p=quarantine: request suspicious treatment

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@acme.example

This asks receivers to treat failing mail as suspicious, often by sending it to spam or junk. It is a useful transition stage when legitimate mail is consistently passing but you want to observe real enforcement effects before requesting outright rejection.

p=reject: request refusal of failing mail

v=DMARC1; p=reject; rua=mailto:dmarc-reports@acme.example

This is the strongest policy request. Use it only after verifying the senders you expect to use the domain. A reject policy will not repair a broken mail stream; it makes a broken stream visible by increasing the chance recipients will refuse it.

For subdomains, set an explicit sp policy if your subdomain intent differs from the root domain:

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

Do not assume every subdomain has independent authentication. If a platform sends from news.acme.example, verify its SPF and DKIM configuration separately.

DMARC troubleshooting checklist

Work through this sequence whenever a checker flags DMARC record errors or a sender reports authentication failure:

1. Query _dmarc.yourdomain directly with dig or nslookup.
2. Confirm one logical TXT record starts with v=DMARC1.
3. Confirm v is first and p is one of none, quarantine, or reject.
4. Confirm the DNS record is in the active authoritative zone, not an unused registrar zone.
5. Check that _dmarc was not accidentally entered as _dmarc.yourdomain.yourdomain by the DNS interface.
6. Check for wildcard TXT behavior or unrelated SPF/site-verification strings returned at _dmarc.
7. Make a complete inventory of every platform that sends with your visible From: domain.
8. Send a new test from every platform and inspect Authentication-Results headers.
9. Compare header.from against both smtp.mailfrom and header.d.
10. Fix sender-side domain authentication rather than merely weakening DMARC settings.
11. Confirm rua uses a valid mailto: URI and that the report mailbox or service is operating.
12. If reports go to another organizational domain, verify external destination authorization.
13. Keep p=none until known legitimate sources pass consistently.
14. Move through quarantine to reject only when reports and real-message tests support it.

Errors to avoid when using DMARC tools and generators

Record generators are useful, but they can encourage copy-and-paste administration. Treat generated output as a draft that must be checked against your mail architecture.

Avoid these shortcuts:

• Copying a strict-alignment example by default. Strict alignment can break legitimate subdomain sending.
• Adding every optional tag. More tags do not mean more protection. Unnecessary tags make records harder to audit and can expose differences among receiver implementations.
• Treating p=none as enforcement. It requests monitoring, not rejection of spoofed mail.
• Using a personal report mailbox. Reports can become operationally noisy and are best handled by a dedicated mailbox or parser.
• Trusting an SPF pass without checking alignment. SPF might pass for a vendor-owned envelope domain and still fail DMARC.
• Assuming an email platform is authenticated because it can send mail. Sending capability and DMARC alignment are separate configurations.
• Removing an old DKIM key immediately after rotation. Validate that every sender has switched selectors before retiring a key.
• Ignoring forwarded and mailing-list flows. Indirect delivery can alter messages or break SPF, so evaluate real-world message paths.

DMARC standards and vendor implementations evolve. If you use less common tags or a specialized reporting setup, validate behavior against the relevant mail provider’s documentation and test messages rather than assuming every receiver interprets every optional feature identically.

Conclusion

Most DMARC record errors are fixable without guesswork. First prove that one valid TXT policy is publicly available at _dmarc.yourdomain. Then move beyond DNS and test the actual mail streams that use your visible From: domain.

The durable approach is simple: publish a clean monitoring record, inventory every sender, configure aligned SPF or DKIM for each platform, inspect real authentication headers, review aggregate reports, and enforce only after legitimate mail consistently passes. That workflow protects deliverability while building toward meaningful protection against domain spoofing.

FAQ

What is the most common DMARC record error?

Publishing the TXT record at yourdomain.example instead of _dmarc.yourdomain.example is one of the most common errors. Another frequent problem is having more than one independent DMARC policy record at the _dmarc hostname.

Can SPF pass while DMARC fails?

Yes. SPF can pass for the envelope-from domain but fail DMARC alignment if that domain does not match, or does not align with, the visible From: domain. An aligned DKIM pass could still make the overall message pass DMARC.

Does DMARC require both SPF and DKIM?

No. DMARC passes when either SPF or DKIM passes and aligns with the domain in the visible From: header. Configuring both is still recommended because it gives legitimate mail a second authentication path.

Why am I not receiving DMARC reports?

Check the rua=mailto: syntax, confirm the mailbox can receive attachments, and verify external destination authorization if reports are sent outside your organizational domain. Also remember that report delivery is receiver-dependent and is not guaranteed to be immediate or universal.

Should I set DMARC to p=reject immediately?

No. Start with p=none, review all senders and real-message authentication results, then move to stronger enforcement after legitimate traffic is consistently aligned. A premature reject policy can block valid mail from forgotten vendors or internal systems.