Why your emails are getting a 'DMARC verification failed' error
Published 10 Jul 2025
Updated 6 Nov 2026
16 min read
Summarize with
Updated on 6 Nov 2026: We added worked header examples and clarified how to diagnose DMARC failures under RFC 9989.
Your emails are getting a 'DMARC verification failed' error because the receiving mail server did not find a passing SPF or DKIM result that met the domain-matching rule for the visible From address. DMARC asks more than whether SPF or DKIM passed somewhere. It checks whether at least one passing result belongs to the domain the recipient sees in the From field, using the domain's relaxed or strict alignment setting.
The fastest fix is to identify which sending source produced the failure, read the original headers and Authentication-Results header, then make that source pass DKIM for your From domain or pass SPF with a Return-Path domain that aligns with your From domain. If the message is forwarded, DKIM becomes the safer path because forwarding often breaks SPF.
- Check the source: Find the platform, app, CRM, helpdesk, or mail server that sent the failing message.
- Check the domain match: Compare the visible From domain with the SPF Return-Path domain and the DKIM d= domain.
- Fix the authentication path: Publish the sender's DKIM records, authorize the sender in SPF, or move the From address to a domain the sender can authenticate.
- Watch the reports: Use aggregate reports to confirm the same source stops failing before tightening policy.
What a DMARC verification failure means
A DMARC verification failure means the receiver found a DMARC policy for the domain in the visible From address but did not find a passing SPF or DKIM result with identifier alignment. The policy can request none, quarantine, or reject handling. The receiver can still apply local policy, so quarantine does not always mean spam placement and reject does not guarantee the same response at every provider.
That distinction matters because an email can show SPF pass and DKIM pass in the raw headers, yet still fail DMARC. This happens when SPF passed for a sender-owned bounce domain, or DKIM passed for a sender-owned signing domain, while the visible From domain was your brand domain. In that case, message authentication passed for the wrong domain. The same pattern is covered in more detail for cases where SPF and DKIM pass but DMARC still fails.
DMARC verification failed flowchart showing visible From, SPF, DKIM, domain match, pass, and error results.
The pass that counts
DMARC only needs one good path, but that path must connect back to the visible From domain. A passing SPF result for a bounce domain that does not meet the configured domain-matching rule does not save DMARC. A passing DKIM result for a signing domain that does not meet that rule does not save DMARC either.
The error wording changes by provider. One system might say 'DMARC verification failed'. Another might say the sending domain does not pass DMARC verification, the message failed DMARC validation, or the message was rejected because of DMARC. The root question stays the same: which authenticated domain did the receiver trust, and did it meet the domain-matching rule for the visible From domain?
Do not treat every DMARC failure as a sender configuration problem. An unauthorized source using your From domain should fail. Investigate a source before authorizing it in SPF or adding DKIM records, and fix only systems that your organization recognizes.
A result of dmarc=none usually means no applicable DMARC policy was found. It is different from p=none, which is a published monitoring policy and still allows dmarc=pass or dmarc=fail results. A permerror indicates a permanent evaluation problem; a temperror indicates a transient problem such as an unavailable DNS server. Read the result attached to each method separately, because an SPF error does not prevent a valid, matching DKIM signature from passing DMARC.
A DMARC pass also does not guarantee inbox placement. Receivers still apply reputation, content, user, and local policy checks, so a message can pass DMARC and still land in spam or be blocked for another reason.
The fastest way to identify the cause
Start with the failed message or SMTP rejection text. The headers show which SPF domain was checked and which DKIM signatures were evaluated. If rejection prevented a mailbox copy, collect the bounce's Diagnostic-Code and sending logs, then ask the recipient's administrator for authentication results or a message trace. Guessing at DNS first wastes time because many domains have several legitimate senders.
- Find the From domain: Use the human-visible From address, not the Reply-To address or display name.
- Find SPF: Look for the SPF result and the checked Return-Path, envelope sender, or smtp.mailfrom domain.
- Find DKIM: Look for the DKIM result, selector, and signing domain shown after header.d= or d=.
- Compare domains: Under relaxed alignment, compare organizational domains. Under strict alignment, require an exact domain match.
- Read the DMARC result: Check header.from, the applied policy, disposition, and any stated reason for failure.
- Check the bounce code: Read the full response, not just 5.7.26 or another 5.7.x code. A code can cover several authentication problems; the accompanying text identifies whether DMARC caused the rejection.
- Send a clean test: Send a new message directly from the same source to avoid old headers or a forwarded copy.
Use the Authentication-Results header added by the receiving system you trust. Earlier copies can be inserted by other systems and do not necessarily describe the final receiver's evaluation.
If the DNS record itself is the unknown, run the domain through a DMARC checker before editing anything. Check for duplicate DMARC policy records and syntax problems. A missing reporting address is a visibility gap, not a DMARC authentication failure.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
For a domain that is not yet enforcing DMARC, monitoring mode lets you collect reports without requesting quarantine or rejection, although receivers still apply their own filtering rules. Keep an existing enforcement policy in place while fixing a sender unless you have deliberately chosen a temporary fallback.
Example TXT value at _dmarc.example.comdns
v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r
If rua reports go outside your organizational domain, make sure the destination authorizes report delivery. Otherwise the DMARC policy can remain valid while aggregate reports fail to arrive. Replace the example reporting address with a mailbox or reporting destination you control.
Once the failing source is fixed and report data confirms it, move gradually. A strict jump to reject while a major sender is still failing turns a diagnostic error into lost mail.
Read a failing Authentication-Results header
This illustrative header shows SPF and DKIM passing for a sending service while DMARC fails for the visible From domain. These are example domains, not live lookup results.
Example: authentication passes for the wrong domaintext
From: Billing <billing@example.com> Return-Path: <bounce@mailer.example.net> Authentication-Results: mx.receiver.example; spf=pass smtp.mailfrom=mailer.example.net; dkim=pass header.d=mailer.example.net header.s=mail; dmarc=fail header.from=example.com
- header.from identifies example.com as the domain DMARC checks.
- smtp.mailfrom shows SPF passed for mailer.example.net, which has a different organizational domain.
- header.d shows DKIM also passed for mailer.example.net, so that signature does not satisfy the From-domain matching rule.
- dmarc=fail follows because neither passing result meets that rule.
Configure the sender to sign DKIM with example.com, then send a fresh test. A successful result looks like this:
Example: DMARC passes after fixing DKIMtext
Authentication-Results: mx.receiver.example; spf=pass smtp.mailfrom=mailer.example.net; dkim=pass header.d=example.com header.s=mail; dmarc=pass header.from=example.com
SPF still passes for the service's domain, but the valid DKIM signature now matches the visible From domain exactly. If a message has several DKIM signatures, one valid signature with the required domain match is enough; a different signature failing does not cancel it.
Common causes and fixes
Most DMARC verification failures come back to a short list of causes. Fix the cause that matches the message source, not every authentication setting on the domain.
|
|
|
|---|---|---|
Third-party sender | Sender domain passes | Configure aligned DKIM |
Forwarding | SPF breaks | Preserve valid DKIM |
SPF lookup limit | SPF permerror | Reduce DNS lookups |
Wrong From domain | Brand mismatch | Use an aligned domain |
Strict alignment | Exact domain mismatch | Use exact domains |
Invalid DMARC DNS | Intended policy unavailable or ignored | Correct the TXT record |
DKIM signing or DNS setup | DKIM none or key lookup failure | Enable signing and verify selector DNS |
DKIM modification | Body hash fails | Stop content changes |
Common DMARC failure patterns and the practical fix.
Third-party senders are a common source. A marketing platform, billing app, ticketing system, review-invitation tool, or website plugin sends as your domain, but signs with its own domain or uses its own Return-Path. Publish the sender's DKIM TXT or CNAME records and enable signing in its settings. Where supported, configure a custom bounce domain for SPF as well.
If a sender cannot authenticate your custom From domain, use its default From domain and put your address in Reply-To. A dedicated subdomain still needs authentication that meets its From-domain matching rule; moving the address alone does not fix DMARC.
SPF-only sending
- Forwarding risk: Forwarded mail often fails SPF because the forwarding server is not listed in your SPF record.
- Return-Path dependency: DMARC only benefits when the SPF-checked domain aligns with the visible From domain.
- DNS pressure: SPF permits at most 10 DNS-querying terms during evaluation, including nested includes. Exceeding the limit produces permerror. Publish one SPF record per checked domain and merge authorized senders into that record.
DKIM-first sending
- Forwarding resilience: A valid DKIM signature usually survives forwarding if signed content is not changed.
- Source clarity: Each sender can use its own selector, which makes failures easier to trace.
- DMARC path: DMARC passes when the DKIM signing domain aligns with the visible From domain.
Publish one DMARC policy TXT record per _dmarc name, such as _dmarc.example.com. Under RFC 9989, duplicate policy records at one name are discarded, and policy discovery can continue at a parent. A missing or misplaced v=DMARC1 tag makes the record unusable. A malformed reporting URI affects reporting; it does not automatically make authentication fail.
For a DKIM key lookup failure, take the selector from s= and the signing domain from d=. Check the TXT or CNAME record at selector._domainkey.signing-domain against the sender's exact instructions. Confirm the key is published and signing is enabled; publishing DNS alone does not add a DKIM signature to outgoing mail.
When forwarding and mailing lists break DMARC
Forwarding changes the server that delivers the message, so SPF usually evaluates the forwarder's IP against the original envelope sender's policy and fails. DKIM can preserve a DMARC pass, but only while the signed headers and body remain valid. Mailing-list footers, subject prefixes, and other content changes can break that signature.
- Check the original DKIM result: If DKIM passed before the indirect hop and failed after it, compare the signed content with the delivered copy.
- Treat SRS correctly: Sender Rewriting Scheme can help a forwarder pass SPF, but the rewritten Return-Path normally is not aligned with the original visible From domain.
- Read ARC as context: Authenticated Received Chain can preserve earlier authentication results for a receiver that trusts the intermediary.
- Do not call ARC a DMARC pass: ARC does not change a failed DMARC result. A receiver can use a valid, trusted ARC chain when making its local delivery decision.
- Protect direct mail with DKIM: Sign with an aligned domain and avoid changes to signed content after signing.
If failures appear only after one gateway, forwarding route, or mailing list, collect headers from before and after that hop. Fix the intermediary when you control it. If you do not control it, preserve aligned DKIM where possible and expect the final receiver's ARC trust and local policy to affect delivery.
How SPF, DKIM, and DMARC interact
DMARC uses SPF and DKIM results. SPF checks the connecting server's IP against the SMTP MAIL FROM domain, normally shown in Return-Path. With an empty MAIL FROM, SPF uses the HELO domain instead. DKIM checks whether the message has a valid cryptographic signature for the domain in the d= tag. DMARC then checks whether either authenticated domain aligns with the visible From domain.
That is why a CRM can send a message that passes SPF for crm-vendor.example but fails DMARC for yourdomain.com. SPF passed, but not for the domain DMARC cares about. The same can happen with DKIM if the message is signed by the sender's domain instead of your domain.
A practical rule
If you control the sending source, prioritize DKIM for the visible From domain. Keep SPF clean as well, but do not rely on SPF alone for mail that might be forwarded, relayed, or processed by mailing lists.
- For direct mail: Configure both SPF and DKIM. DMARC needs at least one passing result that meets the From-domain matching rule.
- For forwarded mail: DKIM is the result most likely to preserve DMARC after the handoff.
- For bulk senders: Set up custom DKIM and custom bounce handling before sending at scale.
- For subdomains: Confirm whether the Author Domain record, parent policy, or subdomain policy controls the result.
Strict mode can expose domain differences that relaxed mode accepts. With relaxed alignment, mail from news.example.com can authenticate under example.com when both names have the same organizational domain. With strict alignment, the authenticated domain must exactly match the visible From domain. Relaxed alignment is the default for both SPF and DKIM. Use strict alignment only when your domain separation requirements call for an exact match; it rejects parent-domain or sibling-subdomain matches.
DMARC policy checks under RFC 9989
RFC 9989 is the current DMARC base specification and obsoletes RFCs 7489 and 9091. Aggregate reporting is covered by RFC 9990, while failure reporting is covered by RFC 9991. The day-to-day troubleshooting steps remain familiar: check the Author Domain in the visible From field, then check whether SPF or DKIM produced a passing result for an aligned domain.
RFC 9989 specifies a DNS Tree Walk for policy discovery and organizational-domain discovery. Do not assume every receiver has adopted it; confirm the policy evaluated by the receiver. For a sending subdomain, check its own _dmarc record and the organizational-domain policy. The psd tag describes public-suffix or organizational-domain boundaries; do not add it as a routine authentication fix.
The pct tag is historic, so do not use values such as pct=20 or pct=100 for a current staged rollout. The ri and rf tags are historic too, so do not depend on them for report timing or format control. Use monitoring mode, fix legitimate senders, then move policy deliberately.
Testing a quarantine policydns
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; t=y
In this example, t=y asks an RFC 9989 receiver to apply none instead of quarantine to failures. With p=reject, it requests quarantine instead. It does not affect reporting. An older receiver can ignore the unknown t tag and apply the stated quarantine or reject policy; use p=none when you need monitoring without requesting enforcement across receiver versions.
- Use p=none while you are still building a source inventory and reading daily reports.
- Use t=y with an enforcement policy only when you understand the testing behavior and the risk of receivers ignoring the tag.
- Keep rua reporting active so you can confirm whether receivers are applying the policy the way you expect.
- Use sp and np when existing and non-existent subdomains need separate policy control.
Provider-specific error patterns
Gmail and Google Workspace can return 550 5.7.26 when unauthenticated mail is rejected under a domain's DMARC policy, but that code also covers other authentication failures. Microsoft 365 uses 550 5.7.509 for a sending domain that fails DMARC with a reject policy. Amazon SES identity verification alone does not establish a DMARC pass; DKIM or custom MAIL FROM authentication must also meet the visible From-domain matching rule.
For Google-hosted mail, Google Workspace troubleshooting is useful when the receiver-side result needs to be checked against message headers. For a sender-side workflow, a deeper troubleshooting guide helps separate source discovery, DNS validation, and policy decisions.
- Google Workspace: Check whether the failing message was forwarded or altered by a group, routing rule, or gateway.
- Microsoft 365: Check the Authentication-Results header and bounce text for the domain Microsoft evaluated. If failures affect only one recipient organization, ask its administrator to trace the message and inspect connectors or mail-flow rules that redirect mail or add disclaimers.
- Amazon SES: Verify DKIM for the sending identity and configure a custom MAIL FROM domain if SPF should provide an aligned DMARC path.
- Helpdesk systems: Avoid sending customer-visible replies from a domain the helpdesk cannot sign with your DKIM.
- Website forms: Do not use the visitor's address as the From address. Use your own domain and put the visitor in Reply-To.
- Consumer or ISP domains: If the From domain is not yours, you cannot change its DMARC DNS. Send through the provider's approved SMTP settings or use a domain you control.
For WordPress or another website app, confirm which server actually sends the notification. Local PHP mail can use the host's Return-Path without DKIM for your From domain. Route notifications through an authenticated SMTP service that signs for your domain, and verify the actual From address in a fresh message.
How Suped fits into the fix
Suped is our DMARC reporting and email authentication platform. In this workflow, it turns a vague 'DMARC verification failed' symptom into source-specific evidence: which service sent the mail, whether SPF or DKIM passed, whether the authenticated domain aligned, and which configuration needs attention.
Suped's DMARC monitoring parses aggregate reports and groups results by sending source. Compare the source's results before and after a DNS change, then use alerts to catch later authentication drops. Aggregate-report alerts depend on when receivers send their reports; they are not per-message delivery alerts.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
- Automated issue detection: Suped groups failures by source and shows steps to fix the issue instead of leaving you to read XML reports manually.
- Report-based alerts: Teams get notified about authentication drops as new report data is processed. Use headers and sending logs when you need to diagnose a single message immediately.
- Hosted SPF: Sender changes can be managed without repeated DNS edits, and SPF flattening keeps the record below lookup limits.
- Hosted DMARC: Policy staging is easier when Hosted DMARC manages the record while reports confirm each step.
- MSP dashboard: Agencies and managed service providers can monitor many client domains without switching between separate reporting setups.
DMARC failures are rarely solved by one static record. Sender inventories change, vendors rotate infrastructure, staff add new SaaS tools, and domain policy gets stricter over time. Ongoing source monitoring makes those changes visible before legitimate mail starts failing enforcement.
Verify the fix before tightening DMARC policy
The right next step depends on whether you are seeing a one-off bounce, a steady stream of failures, or a policy rollout problem. Use the same order each time because it separates sender identity, DNS validity, and enforcement risk.
- Collect evidence: Keep the bounce, original headers, sending platform name, From address, approximate send time, and receiver timestamp when available.
- Validate DNS: Confirm there is only one valid DMARC record and that SPF stays within its DNS lookup limit.
- Identify the source: Use DMARC reports to map the IP or provider name to a real business system.
- Verify authorization: Confirm the source belongs to your organization before changing SPF or DKIM.
- Enable DKIM: Add sender-specific DKIM records for your domain wherever the platform supports it.
- Fix SPF carefully: Add only required senders and avoid broad mechanisms that authorize infrastructure you do not use.
- Stage enforcement: Move policy only after report data shows legitimate senders are passing DMARC.
If you need a broader view than the DMARC record alone, run a domain health check. That helps catch SPF, DKIM, DMARC, and related DNS issues that can produce authentication failures or hide the real sender problem.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Do not rush reject
A reject policy is the right endpoint for many domains, but it should be reached with report data. If a legitimate sender is still failing, reject turns a fixable configuration issue into blocked business mail.
After each change, send a fresh test and then review aggregate reports. Header checks are immediate, but reports show whether the change worked across normal mail flow, including routing paths and providers that handle your mail differently. Compare a direct test with the forwarding route that originally failed, and allow cached DNS answers to expire before assuming the change was ineffective.
Frequently asked questions
Yes. SPF can pass for the Return-Path domain while DMARC fails because that domain is not aligned with the visible From domain. DMARC needs SPF or DKIM to pass with an aligned domain.
Yes. DKIM can pass for a sender's signing domain while the message uses your domain in the From address. Configure the sender to sign with DKIM for an aligned domain.
Forwarding often breaks SPF because the forwarding server is not authorized by the original sender's SPF record. DKIM can preserve DMARC if signed content is not changed. ARC can preserve earlier results for a receiver that trusts the intermediary, but it does not turn DMARC fail into DMARC pass.
Use p=none when introducing DMARC monitoring, or as a deliberate temporary fallback while you fix legitimate senders. Changing policy does not repair SPF, DKIM, or the From-domain match. Receivers still apply local filtering. Return to enforcement after reports confirm your authorized sources pass.
A DNS change becomes available when the authoritative DNS publishes it, but resolvers can use cached data until the record's TTL expires. Send a fresh test after the change. Aggregate reports usually arrive on a later reporting cycle.
No. RFC 9989 marks pct as historic. Use monitoring mode, fix legitimate senders, read reports, then move to quarantine or reject with a clear rollback plan. RFC 9989 defines t=y for testing, but older receivers can ignore it and apply the stated enforcement policy; use p=none for monitoring across receiver versions.
