How can I troubleshoot DMARC failures and identify the cause of authentication issues?
Published 5 May 2025
Updated 4 Oct 2026
12 min read
Summarize with
Updated on 4 Oct 2026: We refined the checks for subdomain failures, report fields, and verifying each sender fix.
Troubleshoot DMARC failures by separating two questions: is the domain's DMARC record valid, and which mail source is sending messages without an SPF or DKIM pass that aligns with the visible From domain? Start with DMARC aggregate reports, then confirm the failing source with message headers and DNS. If the pass rate drops only on certain days, the cause is usually a specific mail stream, campaign, workflow, or forwarded path rather than the DMARC record itself.
A proper DMARC monitoring setup turns raw receiver reports into source names, authentication results, trends, and fix priorities. Suped's product supports this workflow with source discovery, SPF and DKIM checks, failure alerts, and hosted records.
- Group failures by sending IP, provider, envelope domain, DKIM domain, and visible From domain to find the source.
- Check whether a passing SPF or DKIM domain has relaxed or strict alignment with the visible From domain.
- Fix each legitimate mail stream with the needed SPF authorization, DKIM setup, or aligned Return-Path; do not authorize an unknown source.
What DMARC failure means
DMARC does not simply ask whether SPF passed or DKIM passed. It asks whether at least one passing check used an authenticated domain that aligns with the visible From domain. Relaxed alignment accepts domains with the same organizational domain. Strict alignment requires an exact domain match. This explains cases where a mail provider reports SPF pass and DKIM pass, but DMARC still fails.
The published DMARC record lives in DNS for the domain, normally at _dmarc.example.com. You do not create a different DMARC policy inside every sending platform. Instead, every platform that sends with your domain has to authenticate in a way DMARC accepts.
|
|
|
|---|---|---|
SPF fail | No passing SPF result for the checked identity | Check IP authorization, DNS lookups, and the Return-Path |
DKIM fail | A checked DKIM signature did not validate | Check selector DNS, key rotation, and message changes |
DMARC fail | Neither SPF nor DKIM produced an aligned pass | Align the Return-Path or DKIM signing domain |
DMARC permerror | Policy evaluation has a persistent error | Check policy syntax and receiver details |
Unknown IP | Source is not cataloged | Identify the owner before authorizing it |
Compact DMARC failure map
A receiver dashboard pass rate is an aggregate symptom. It does not prove that your main marketing platform is broken. It counts mail using the domain that reached that receiver, including employee mail, transactional mail, billing notices, support tools, forwarded mail, and any source you forgot existed.
Follow this troubleshooting sequence
Use the same sequence every time because random DNS changes make DMARC harder to debug. First validate the policy, then use reports to identify the failing source, inspect headers for that exact source, and change the sender setup.
DMARC troubleshooting flowchart: validate the record, review reports, identify the source, check SPF and DKIM, then fix the sender.
- Confirm there is one DMARC TXT record, the syntax is valid, DNS changes have propagated, and aggregate reporting is authorized when rua uses an external domain.
- Group report rows by source IP and sending service, then look for volume spikes on the bad days.
- Use a failed sample to confirm what SPF, DKIM, DMARC, and ARC did for that message.
- Assign each failing source to an internal owner before changing DNS, because each platform has different setup steps.
- After the fix, send a test message through the same workflow and check its headers; then confirm recovery in the next aggregate reports, which often arrive the following day or later.
Before investigating every sender, run a broad check against the domain. Suped's domain health checker is a quick way to inspect DMARC, SPF, and DKIM basics before you ask engineering to change records.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
If the domain check is clean and the failure rate still drops, move to the reports. A clean record only proves the policy can be read. It does not prove that every source sending as your domain is configured correctly.
Read the reports before changing DNS
DMARC aggregate reports are the fastest way to find the source of authentication issues because receivers group messages by source IP, policy result, SPF result, DKIM result, and visible From domain. Raw XML is hard to read by hand, so a reporting platform should translate it into source names and trends. A source IP can belong to a forwarder, so confirm the original sender before changing authorization.
The most useful report view answers four questions: who sent the mail, how much did they send, which check failed, and whether the source is allowed to send for the domain. Under RFC 9990, the policy-evaluated SPF and DKIM values are alignment-aware, while the authentication-results fields contain the underlying raw checks. If you need a deeper breakdown, the page on DMARC reports covers sender identification and failure types.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
In Suped, filter failures by date, then open the source breakdown to find the rows that changed. Suped's issue detection links the failing source to its authentication and alignment results, which gives the source owner a specific configuration to verify instead of raw XML.
|
|
|---|---|
Source IP | Maps volume to a connecting sender or forwarder |
Header From | Confirms the domain DMARC protects |
Policy evaluated | Shows alignment-aware SPF and DKIM results |
Authentication results | Shows raw SPF and DKIM checks and their domains |
Disposition | Shows the reported policy action: none, pass, quarantine, or reject; it does not prove final delivery |
Reason | Explains policy overrides when the reporter supplies one |
Report fields worth checking first
Separate failures, evaluation errors, and policy overrides
A DMARC fail means evaluation completed and neither SPF nor DKIM produced an aligned pass. A permerror means evaluation hit a persistent problem, such as an invalid policy record. A temperror means a temporary problem, usually a DNS lookup failure, prevented a final result. Multiple DMARC records at one DNS name are discarded, which can leave a different policy or no policy to apply. These results need different fixes.
|
|
|
|---|---|---|
dmarc=fail | No aligned SPF or DKIM pass | Trace the source, Return-Path, DKIM d= domain, and From domain |
dmarc=permerror | Policy evaluation cannot recover without a change | Check policy syntax and receiver details |
dmarc=temperror | Evaluation hit a temporary DNS or retrieval error | Check authoritative DNS health, then test again |
DMARC fail, mail accepted | The receiver overrode or did not enforce the requested disposition | Inspect policy override reasons, ARC, forwarding, and local rules |
DMARC pass, mail filtered | Authentication passed, but another delivery signal caused filtering | Investigate content, reputation, recipient response, and receiver policy |
Result and disposition diagnostic map
Disposition is not the same as the DMARC authentication result. A receiver can accept a failing message because of a local policy, a trusted forwarding path, or a valid ARC chain. ARC preserves evidence about earlier authentication so the final receiver can make an override decision; it does not change the original DMARC fail into a pass.
Use headers to confirm the break
Reports tell you where to look. Headers tell you what happened on a real message. Ask the source owner for a raw message sample from the failing stream, or send a test message through the same workflow to a mailbox where you can view full headers.
The Authentication-Results header added by the receiving mailbox usually gives the clearest answer; earlier or copied headers can be forged. Do not stop when you see SPF pass or DKIM pass. Compare smtp.mailfrom and header.d against header.from, then inspect the Received chain and ARC headers when the path includes forwarding or a mailing list.
Header result that still fails DMARCtext
Authentication-Results: mx.example; dmarc=fail header.from=example.com; spf=pass smtp.mailfrom=bounces.vendor.example; dkim=pass header.d=vendor.example
In that example, SPF and DKIM pass, but neither authenticated domain aligns with example.com. The fix is not to loosen the DMARC policy. The sender needs to use an aligned Return-Path, sign with an aligned DKIM domain, or use a visible From address that matches its authenticated domain.
If the header shows spf=pass and dkim=pass but dmarc=fail, the problem is usually identifier alignment. The detailed guide on why SPF and DKIM pass but DMARC fails explains that case.
Common causes and fixes
The cause is usually clear once the source is known. Common patterns include a platform that was never authenticated, a rotated DKIM selector, an external envelope domain, an SPF DNS lookup error, or a forwarded path where SPF breaks and content changes invalidate DKIM.
Failure pattern
- A service is sending as the domain without being in the sender inventory.
- DKIM passes with a domain outside the visible From domain's alignment boundary.
- The SPF record exceeds the limit of 10 terms that trigger DNS lookups and returns a permanent error.
- A forwarding server changes the delivery path, so SPF no longer passes in alignment.
Practical fix
- Document the business owner, purpose, From domain, and sending volume for an unknown source.
- Publish the platform's selector records and confirm the DKIM d= domain aligns.
- Remove stale SPF includes, reduce lookups, or use Suped's hosted SPF when centralized management fits the domain.
- Keep DKIM valid through forwarding and inspect ARC before treating the path as unauthorized.
A valid DMARC record does not have to be complex. Start with reporting and a non-enforcing policy, then raise enforcement after known sources pass consistently. Under RFC 9989, the pct tag is obsolete. The t=y tag asks receivers not to apply the published assessment policy during testing; it does not request percentage-based enforcement. Use the DMARC checker to validate syntax before you assume the issue is with a sender.
Basic reporting recorddns
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:d@example.com"
If engineering changes DNS slowly or several teams share the domain, Hosted DMARC gives the team a controlled way to stage policy changes without repeated manual edits. In Suped, hosted DMARC connects the policy change to monitoring data and issue status, so enforcement moves only after known sources are verified.
Illustrative DMARC pass rate triage
These example bands help prioritize review; there is no universal safe pass rate, and a critical source can fail while the aggregate rate stays high.
Healthy
98-100%
Check critical sources even when the aggregate rate is high.
Investigate
90-97%
Compare failures with each source and its usual volume.
Urgent
Under 90%
Look for failed critical streams and unknown senders.
Troubleshoot subdomain failures
When failures use a visible From address such as alerts@news.example.com, check for a policy at _dmarc.news.example.com. If there is no applicable record there, the organizational domain policy applies: sp= for an existing subdomain, np= for a nonexistent subdomain, or p= when neither specific tag applies. A subdomain does not need a separate DMARC record to pass, and publishing one does not repair SPF or DKIM.
Filter reports by the subdomain in Header From and identify the sending service. Check whether its SPF envelope domain or DKIM d= domain both passes authentication and aligns with news.example.com. Under relaxed alignment, an authenticated parent-domain identity can align; strict alignment requires the exact From domain. Configure the sender to use an aligned identity, test the same mail stream, and check later aggregate reports. Publish a subdomain DMARC record when that subdomain needs its own policy or reporting address.
What to ask engineering to check
A useful engineering ticket should be specific. Asking for a general DMARC review often turns into checking the DNS record and stopping there. Ask the team to review every active mail source that uses the domain and confirm how each one authenticates.
Ticket template
- Review all systems sending with the visible From domain example.com.
- Check whether each source uses an aligned Return-Path domain and stays within the SPF limit of 10 DNS lookup terms.
- Check whether each source signs with an aligned DKIM domain and a current selector.
- Provide raw headers for one passing and one failing message from each source.
- Record the owner, use case, DNS records, setup URL, and risk rating in the sender inventory.
Keep the sender inventory close to the DMARC data. Product teams, finance tools, HR systems, support workflows, and other business systems add mail streams over time. A spreadsheet records known sources; Suped can alert the team when report data shows a new source that nobody documented.
|
|
|---|---|
Owner | Lifecycle team |
Purpose | Receipts |
From domain | example.com |
DKIM | Enabled |
Risk | High volume |
Sender inventory fields
Where Suped fits
For this troubleshooting workflow, Suped groups source discovery, issue diagnosis, sender ownership, DNS validation, alerts, and policy staging in one operational view. The aim is to move from a pass-rate change to the specific source and configuration that needs attention.
Suped connects DMARC report analysis with SPF and DKIM checks plus hosted records. Blocklist (blacklist) monitoring is available when the message passes authentication but reputation appears to be the delivery issue, which keeps that diagnosis separate from an alignment failure.
A practical Suped workflow is to add the domain, collect reports, filter the failure period, verify each known source, assign unexpected sources, record the fix, and watch subsequent reports for recovery. MSPs and agencies can keep client domains in separate workspaces while using the same process.
Views from the trenches
Best practices
Start with aggregate reports, then confirm every suspected source with real headers.
Keep a sender inventory with owner, purpose, DNS records, and current status noted.
Use DKIM with your domain for each major source so forwarding has less impact later.
Common pitfalls
Treating a valid DMARC record as proof that all sending platforms are configured.
Ignoring low-volume tools until a campaign or workflow turns them into a visible spike.
Checking SPF pass without checking whether the SPF domain matches the From domain.
Expert tips
Review failure dates against campaign calendars and system-triggered workflow logs.
Document every newly found sender immediately so the same source is not rediscovered.
Use alerts for new sources, because unknown mail streams are common on shared domains.
Marketer view
Marketer from Email Geeks says a DMARC reporting dashboard makes source discovery far easier than manually guessing which platform caused the failures.
2023-12-21 - Email Geeks
Marketer view
Marketer from Email Geeks says DMARC is published once in DNS, but every source using the domain needs correct authentication.
2023-12-21 - Email Geeks
Frequently asked questions
Yes. SPF can pass for an envelope domain that does not align with the visible From domain. DMARC still fails unless SPF or DKIM produces a passing, aligned identifier.
No. The domain publishes one applicable DMARC policy, with optional records for specific subdomains. Each sending platform needs SPF or DKIM configured so its authenticated domain aligns with the visible From domain.
Check aggregate reports by date and source. Look for a volume spike from one sender, then confirm that sender's SPF, DKIM, DMARC, and ARC results in a real message header.
Fail means neither SPF nor DKIM produced an aligned pass. Permerror means a persistent policy-evaluation problem, such as a malformed DMARC record. Duplicate records are discarded and can leave no applicable policy. Temperror means a temporary problem, usually DNS, prevented a final evaluation.
Do not loosen policy unless legitimate mail is being blocked and immediate containment is necessary. Find the source first, fix its authentication, verify recovery in later reports, and base enforcement changes on that evidence.
Suped turns aggregate reports into source-level views, separates authentication and alignment issues, alerts on new failures, and tracks whether sender or hosted-record changes improve later results.
