How to deal with a failing DMARC email authentication protocol?
Updated on 8 Oct 2026: We added SPF and DKIM repair checks and clarified DMARC policy testing and rejection errors.
To fix a DMARC authentication failure, first confirm what is failing. A missing DMARC record, a record set to p=none, and a real DMARC authentication failure are different problems. A p=none policy expresses no handling preference for failed mail. With aggregate reporting configured through rua, it supports monitoring without telling receivers to block mail. A real DMARC fail means the message did not pass SPF or DKIM with a domain that matches the visible From domain.
Treat this as a source inventory problem before treating it as a DNS problem. Collect DMARC reports, identify every platform sending as the domain, fix SPF or DKIM for each legitimate source, and then tighten the policy. Suped's DMARC monitoring workflow follows that sequence: collect evidence, group senders, show failures, and give clear steps to fix each issue.
- Confirm the signal: Check whether the failure is in the DNS record, the message headers, or aggregate reports.
- Separate monitoring from failure: A domain at p=none is not failing because of that policy alone.
- Fix legitimate senders: Each CRM, help desk, billing system, and mail platform needs SPF or DKIM that matches your From domain.
- Stage enforcement: Monitor first, then test quarantine before moving to reject after real mail is passing.
What a DMARC fail actually means
DMARC does not authenticate mail by itself. It checks whether SPF or DKIM authenticated the message and whether the authenticated domain matches the domain in the visible From header. RFC 9989 calls this visible domain the Author Domain. That alignment check is where many teams get caught. A message can pass SPF as a mail platform's bounce domain and still fail DMARC for your brand domain.
DMARC alignment is relaxed by default: bounce.example.com and example.com share an organizational domain. Strict alignment requires an exact domain match. The aspf and adkim tags select the SPF and DKIM modes. One matching SPF or DKIM pass is sufficient.
That distinction matters because the fix changes. If DMARC discovery finds no applicable record, publish one. If the record has syntax errors, correct the TXT value. If the policy is p=none, collect reports and plan enforcement. If specific mail sources fail, configure those sources so SPF or DKIM authenticates using a domain that matches your From domain.
Do not mistake monitoring for failure
A report screen that labels a domain as not enforced often means the record says p=none. That is not a protocol failure. It expresses no DMARC handling preference for failed mail. When rua is present, participating receivers can also send aggregate reports.
- Good use: Use p=none with aggregate reporting while discovering all legitimate sending systems.
- Bad use: Do not leave p=none forever if the domain is exposed to spoofing.
Lacking DMARC
DMARC discovery finds no applicable policy record for the Author Domain, including any applicable inherited parent-domain policy. Receivers have no published DMARC handling preference to apply.
- Main fix: Create a valid TXT record at the correct _dmarc name and send reports to a monitored mailbox or platform.
- Risk: You have little visibility into who is sending mail using the domain.
Failing DMARC
The message was evaluated and neither SPF nor DKIM passed with a matching visible From domain.
- Main fix: Configure the sending platform with authenticated DKIM or SPF for your domain.
- Risk: At enforcement, legitimate mail can land in spam or be rejected.
How to diagnose DMARC failures
Start with the visible From domain's published record. Use Suped's DMARC checker to confirm that one DMARC TXT record exists, begins with v=DMARC1, has a valid policy value, and uses valid reporting tags. If the DNS record is invalid, fix that before reading report data. If no record exists for a subdomain, check for an applicable inherited policy. In DNS editors that append the domain automatically, enter _dmarc as the host to avoid a duplicated domain name.
Then test real mail from every sending platform. In the receiving server's Authentication-Results header, compare header.from with smtp.mailfrom for SPF and header.d for DKIM. The Return-Path and the d= value in DKIM-Signature identify the domains to inspect; confirm their pass or fail results rather than assuming the header values prove authentication.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
After the record is valid, move to aggregate reports. These reports show source IPs, sending domains, pass and fail results, policy disposition, and the volume attached to each source. Separate legitimate senders from spoofed traffic; even one failed password reset or invoice deserves investigation. In XML, auth_results contains raw SPF and DKIM results, while policy_evaluated.spf and policy_evaluated.dkim include DMARC alignment.
Reports usually cover a daily reporting period, so they are not an instant test. If reports do not arrive, verify the rua mailbox receives mail and, for a destination on another organizational domain, confirm the report recipient has published external reporting authorization. Not every receiver sends reports, and absent reports do not prove authentication passes.
For a wider check, Suped's domain health checker helps spot nearby issues in SPF and DKIM. That matters because DMARC depends on at least one of them passing with a matching domain.
How to fix DMARC authentication failures
If the domain is not yet enforced, publish a monitoring record, collect representative traffic, fix sources one by one, and raise policy only when legitimate traffic passes. For a domain already at quarantine or reject, repair the failing sender and verify its mail before changing policy.
DMARC troubleshooting flowchart: check DNS, review reports, fix SPF or DKIM, test mail, and enforce policy.
- Publish monitoring: For a new deployment, start with a valid record that asks receivers for aggregate reports.
- Map every source: Identify mail platforms, CRMs, ticketing systems, finance tools, and internal servers. Record an owner for every source, including infrequent billing and account recovery mail.
- Fix the source: Enable DKIM for your domain or configure SPF so the authenticated domain matches the visible From domain.
- Retest headers: Send fresh mail after updated DNS answers are visible, allowing for cached records' TTL, and confirm that the receiver reports DMARC pass.
- Increase policy: Verify each legitimate source over representative sending cycles before quarantine, then reject. Keep monitoring after enforcement.
Starter monitoring recordDNS
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
Replace example.com with your domain and dmarc@example.com with a mailbox you control or the reporting address assigned by Suped. The address must accept aggregate reports.
When the domain has many senders, DNS changes become coordination work. Suped's Hosted DMARC helps manage policy staging without asking every DNS owner to edit records for each change. That is useful for MSPs, agencies, and companies where several teams send mail.
RFC 9989 made the old pct sampling tag historic. Use t=y to signal policy testing under the current standard, then remove it to request full application of that policy. Confirm legitimate mail passes before publishing a stronger p value, including examples with t=y.
Staged enforcement recordsDNS
_dmarc.example.com TXT "v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com" _dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com" _dmarc.example.com TXT "v=DMARC1; p=reject; t=y; rua=mailto:dmarc@example.com" _dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
Publish one stage at a time and check receiver behavior
Each line above replaces the previous record. Do not publish several DMARC records at the same name. With t=y, the domain requests handling one policy level below the stated value: quarantine becomes none, and reject becomes quarantine. Receivers using RFC 7489 rules ignore t and can apply the full published policy. Receivers still make final handling decisions under local rules.
Typical causes and fixes
Most DMARC failures fall into a small set of causes. Check these before assuming the domain has a reputation problem.
|
|
|
|---|---|---|
SPF passes; DMARC fails | Return-Path uses vendor domain | Use aligned custom bounce domain |
DKIM passes; DMARC fails | DKIM d= uses vendor domain | Enable aligned branded DKIM |
SPF or DKIM passes; DMARC fails | Strict alignment or different organizational domain | Compare identifiers and alignment mode |
DMARC missing | No applicable direct or inherited DMARC policy | Verify policy discovery and publish a valid record |
Several records | Duplicate DMARC TXT | Keep one record |
Forwarded mail | SPF path changes or DKIM is modified | Use aligned DKIM and trace changes |
Common DMARC failure causes
The fastest win is usually DKIM on the sending platform. Forwarding changes the IP checked by SPF. A shared sending pool can pass SPF when its sending IPs are authorized. DKIM stays with the message if the content and signed headers are not changed in a way that breaks the signature.
For deeper troubleshooting, compare header evidence with aggregate reports for the same receiver, sending route, and reporting period. If the results differ, check whether test messages used the same route as production campaigns. The sibling guide on DMARC failures goes further into root-cause checks.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Check SPF errors and DKIM signing
If authentication itself fails, repair the SPF record or DKIM signing setup for the affected source. A valid DMARC record cannot correct either problem.
- spf=fail: check the SPF record at the envelope sender domain shown by smtp.mailfrom and authorize the actual sending IP or provider. Adding a provider to your visible From domain does not change a vendor-owned Return-Path.
- spf=permerror: keep one TXT record beginning v=spf1 at that domain. RFC 7208 limits evaluation to 10 DNS-lookup-causing mechanisms and modifiers, including nested include and redirect terms. Remove obsolete entries and correct syntax errors.
- spf=temperror: investigate DNS timeouts or unavailable DNS servers, then repeat the test after resolution.
- For DKIM, read s= and d= in the message signature. Check the public key at <selector>._domainkey.<signing-domain>, following any CNAME. Confirm signing is enabled and the published public key matches the active private key.
Example SPF and DKIM DNS queriesBASH
dig TXT bounce.example.com +short dig TXT selector1._domainkey.example.com +short dig CNAME selector1._domainkey.example.com +short
Replace these example names with the envelope sender domain and DKIM selector/signing domain found in your message. Publishing a DKIM key is only part of setup; the sending system must sign messages. During key rotation, retain the previous selector until messages signed with it have cleared delivery queues. Google's DMARC troubleshooting documentation covers missing sender authorization and DKIM key problems.
Forwarding and message modification
Forwarding is a separate failure path because SPF checks the server that delivered the message to the final receiver. That server is usually not authorized by the original sender's SPF record. Aligned DKIM can preserve a DMARC pass through forwarding, but only while the signature remains valid.
- Confirm the original signature: The source should add a valid DKIM signature whose d= domain matches the visible From domain under the configured alignment mode.
- Trace message changes: Subject tags, footers, MIME re-encoding, and rewritten signed headers can invalidate DKIM.
- Check the intermediary: A forwarding service or mailing list should preserve signed content where practical and add ARC.
- Read ARC correctly: ARC does not change a DMARC fail into a pass. It gives the final receiver authenticated evidence about earlier handling. Delivery depends on whether the receiver trusts that ARC chain.
If you control only the original domain, you cannot repair a third-party forwarder's SPF path. Focus on aligned DKIM and test the actual forwarded route. If you control the intermediary, avoid modifying signed content and add a valid ARC chain so receivers can apply their local policy with more evidence.
When deliverability is actually affected
A DMARC record set to monitoring does not automatically hurt deliverability. Receivers are not told to quarantine or reject mail because of p=none. Delivery problems can still occur when receivers enforce their own authentication requirements or other spam filters.
Gmail uses 5.7.26 for several authentication-related failures. Save the full SMTP rejection text: a response stating that mail was rejected because of the domain's DMARC policy points to missing matching authentication, while other responses identify SPF or DKIM problems. Inspect the exact sending route and message results before changing DNS or policy. If you are the recipient, send the full rejection text to the sender's domain administrator so they can repair authentication for their domain.
Example internal DMARC triage bands
Apply these illustrative bands only to confirmed legitimate traffic. They are not protocol limits or mailbox-provider requirements, and critical low-volume mail still needs review.
Low failure
Under 1%
Investigate repeated legitimate failures and critical mail before raising policy.
Needs review
1-5%
Find each failing source and confirm whether it sends legitimate mail.
High failure
Over 5%
Pause enforcement changes until the main legitimate failing sources are fixed.
Policy matters too. At p=quarantine, failing mail can be placed in spam. At p=reject, failing mail can be refused. Raise policy only after reports show that the systems expected to send mail are passing.
Bulk sender authentication requirements
Bulk-sender requirements can require both SPF and DKIM, even though DMARC itself needs only one matching pass. Gmail bulk senders need SPF, DKIM, and a DMARC record, with at least one authenticated domain matching the visible From domain; p=none meets its minimum DMARC policy requirement. Fix a CRM that authenticates only as its own domain before scaling campaigns. Google's DMARC troubleshooting page documents common failure patterns.
Where Suped fits
Suped is our DMARC and email authentication platform. For this remediation workflow, Suped groups aggregate report data by source, flags SPF and DKIM alignment failures, and tracks whether legitimate traffic is ready for a stronger policy. Hosted SPF and Hosted DMARC can reduce repeated DNS edits when several teams manage sending systems.
Manual workflow
- Data parsing: You collect XML reports, group sources, and calculate pass rates yourself.
- DNS changes: You coordinate every record change with whoever controls DNS.
- Risk tracking: You track SPF limits, DKIM records, sender ownership, and policy readiness separately.
Suped workflow
- Issue detection: Suped flags failing sources and explains what needs to change.
- Hosted controls: Hosted SPF and Hosted DMARC reduce repeated DNS edits.
- Scale support: MSPs and agencies can manage many domains inside one dashboard.
When a marketing platform, internal server, or third-party sender starts failing, Suped shows the source, authentication result, affected volume, and recommended fix. Teams can confirm the evidence before changing policy and keep monitoring for new sending services after enforcement.
Views from the trenches
Best practices
Collect aggregate reports before policy changes so each real sender can be verified.
Confirm whether the issue is missing DMARC, monitoring mode, or a message-level fail.
Fix branded DKIM first when a platform authenticates mail only under its own domain.
Common pitfalls
Treating p=none as a protocol failure leads teams to change policy before evidence.
Assuming SPF pass is enough misses cases where the return-path domain does not match.
Testing one email path and applying the result to every CRM campaign hides failures.
Expert tips
Review the visible From domain first because DMARC evaluates the domain recipients see.
Fix critical low-volume failures first, then prioritize other sources by affected volume.
Keep monitoring after reject because new sending services can break authentication later.
Marketer view
Marketer from Email Geeks says a failing source should be identified through reports, then authenticated with SPF or DKIM under the sending domain.
2024-07-25 - Email Geeks
Marketer view
Marketer from Email Geeks says teams should first ask whether DMARC is missing, failing, or only published with a monitoring policy.
2024-07-25 - Email Geeks
Frequently asked questions
No. p=none expresses no handling preference for failed mail. With rua configured, it supports aggregate monitoring without asking receivers to block mail.
Yes. SPF can pass for a Return-Path domain that does not match the visible From domain. DMARC needs SPF or DKIM to pass with a domain matching the configured alignment mode.
No. Move to reject only after reports show that legitimate senders pass. Start with monitoring, fix sources, test real mail, then test each enforcement policy.
Fix any legitimate source that sends critical mail, even at low volume, then prioritize other failures by affected volume. Usually the repair is branded DKIM with a matching domain or a custom bounce domain on the sending platform.
RFC 9989 marks pct historic. Older implementations can still interpret it, but percentage handling varies, so avoid relying on it for staging. t=y requests policy testing under the current standard, but older receivers ignore t. Confirm legitimate mail passes before publishing a stronger policy.
DMARC helps receivers verify that mail using your domain is authorized. It does not replace list hygiene, complaint control, content quality, or sending reputation.
