Why does DMARC authentication fail when SPF and DKIM pass, and how can it be fixed?
Published 23 Jun 2026
Updated 25 Oct 2026
24 min read
Summarize with
Updated on 25 Oct 2026: We clarified strict and relaxed alignment, corrected header troubleshooting, and replaced percentage-based enforcement thresholds with checks for legitimate sending paths.
DMARC fails when SPF and DKIM pass because DMARC also requires identifier alignment with the visible From domain. If SPF passes for an unrelated bounce domain and DKIM passes for a vendor domain, neither result authenticates the domain in the From header. This domain misalignment explains the DMARC failure.
The fix is to make either SPF or DKIM pass with alignment to the domain in the From header. Gmail bulk sender requirements apply at around 5,000 messages or more in 24 hours to personal Gmail accounts, counted across the same primary domain and its subdomains. Bulk senders must configure both SPF and DKIM as well as DMARC. Google's sender FAQ explains that threshold. Yahoo bulk sender requirements also require SPF and DKIM, plus a valid DMARC policy of at least p=none and a DMARC pass. Both providers accept a DMARC pass through either aligned method. In most production setups, fix DKIM alignment first because it survives forwarding better, then use SPF alignment as a second path when the sending service supports a custom Return-Path. Before a new platform sends production mail, confirm that it can authenticate the chosen From domain.
Do not treat a pass result as a content verdict. A compromised account, abused sender platform, or attacker-owned lookalike domain can authenticate cleanly. DMARC answers whether the visible From domain is aligned with an authenticated domain, not whether the message is honest or safe.
- Fast answer: A message can show SPF pass and DKIM pass, but DMARC fail, when neither passing domain meets the required alignment mode for the visible From domain.
- Best fix: Sign mail with DKIM using a domain that meets the required alignment mode, or configure the envelope sender so SPF passes with alignment.
- Common trigger: Default vendor signing or forwarding can leave both passing domains unaligned. Strict alignment can also reject a subdomain relationship that relaxed alignment accepts.
The direct reason DMARC fails
DMARC evaluates the domain in the visible From header, also called RFC5322.From. RFC 9989, published in May 2026, calls this the Author Domain. DMARC calls the passing SPF and DKIM domains Authenticated Identifiers. A raw SPF pass against RFC5321.MailFrom or a raw DKIM pass against d= is not enough. The pass must belong to a domain that has alignment with that Author Domain. Fix a missing, malformed, or repeated From header before troubleshooting alignment. Messages with multiple From domains are outside normal DMARC processing.
The Sender header can explain who sent a message on behalf of another party, but DMARC does not use it for policy. Fixing Sender alone will not repair a From-domain alignment failure.
For relaxed alignment, which is the default, the organizational domain must match. A message From email.example.com can match DKIM d=example.com. For strict alignment, the authenticated domain and the Author Domain must be identical. The adkim and aspf tags independently select DKIM and SPF alignment modes: r for relaxed or s for strict. Both default to relaxed when omitted. RFC 9989 uses a DNS Tree Walk to discover organizational domains. An explicit valid record at the Author Domain takes priority over an inherited policy.
|
|
|
|
|---|---|---|---|
news.example.com | news.example.com | Pass | Pass |
news.example.com | example.com | Pass | Fail |
news.example.com | bounce.example.com | Pass | Fail |
news.example.com | vendor.example.net | Fail | Fail |
These examples assume the authenticated method passes and example.com is the shared organizational domain where applicable.
The rule to remember
DMARC passes when SPF passes with alignment, or DKIM passes with alignment. It fails when neither passing domain meets the required alignment mode for the visible From domain. A pass or fail result is about Author Domain authorization, not a full safety decision.
DMARC alignment infographic comparing the visible From domain with the SPF domain, DKIM signing domain, and DMARC decision.
Check the receiver's DMARC result
Before fixing alignment, read the exact DMARC result in the final receiver's Authentication-Results header. A true dmarc=fail means an applicable DMARC policy record was found but no authenticated identifier aligned. Other result codes point to policy discovery or DNS problems, so changing the sender's SPF include or DKIM selector before identifying the code can send the investigation in the wrong direction.
Use the Authentication-Results header that your trusted receiving service added. Its authserv-id identifies the evaluator, but the name alone does not prove that the header is genuine. Compare SPF, DKIM, and DMARC results from that evaluation; earlier ARC-Authentication-Results describe a different hop. RFC 8601 explains this trust boundary.
If the same trusted receiver reports a passing method that meets the active alignment mode alongside dmarc=fail, check which DKIM signature passed and whether the results came from different processing stages. One passing aligned method is sufficient; DMARC does not require both methods to pass.
|
|
|
|---|---|---|
fail | A policy record exists, but no passing SPF or DKIM identifier aligned. | Compare header.from with smtp.mailfrom and each DKIM d= domain. |
none | No applicable DMARC policy record was discovered. | Check record placement and the DNS Tree Walk path. |
permerror | An unrecoverable policy lookup or record-format error occurred. | Check malformed policy syntax and permanent DNS errors; inspect duplicate records separately because they can be discarded during policy discovery. |
temperror | A temporary DNS or processing error prevented a result. | Retest authoritative DNS and resolver availability before editing authentication. |
Use the receiver's exact result before choosing a fix.
A disposition is not the result
The DMARC result describes validation. The reported disposition describes handling. A receiver can accept a message that failed DMARC or quarantine a message that passed because final delivery remains subject to local policy.
What passing SPF really means
SPF authenticates the envelope sender domain, not the visible From domain. In headers, that domain often appears as smtp.mailfrom or the Return-Path domain. Receivers can also evaluate SPF for HELO, but DMARC relies on SPF validation of the MAIL FROM identity. A standalone HELO SPF pass does not satisfy DMARC alignment when MAIL FROM contains a domain. For a bounce message with a null MAIL FROM path, SPF derives the MAIL FROM identity as postmaster@HELO-domain, so that HELO domain becomes the SPF domain DMARC can test for alignment.
If an ESP uses its own Return-Path, the receiver queries SPF for that ESP-owned MAIL FROM domain, not for the visible From domain's root SPF record. That means SPF can pass for the ESP while DMARC still fails for your visible From domain.
A branded Return-Path, also called a custom MAIL FROM domain, can provide SPF alignment. With news.example.com in the From header and bounce.example.com as the MAIL FROM domain, SPF can satisfy relaxed alignment if both share the same organizational domain. With aspf=s, those domains do not match exactly, so that SPF pass cannot satisfy DMARC.
The MAIL FROM domain is used for bounce handling. If several ESPs send for the same visible domain, each checked MAIL FROM hostname needs one valid SPF record. Adding a vendor SPF include to the brand's root SPF record does not repair alignment when the checked MAIL FROM domain remains vendor-owned. Configure the bounce domain in the sending service before editing its DNS.
Also check DNS at the exact MAIL FROM hostname. A valid CNAME chain is not an SPF error by itself. A CNAME must not coexist with a TXT record at the same name, and an alias loop or broken target needs correction. SPF alignment still uses the original MAIL FROM domain, not the CNAME target. RFC 1034 defines CNAME behavior. Multiple SPF records at the resolved name cause permerror. RFC 7208 also limits evaluation to 10 DNS-lookup-causing terms, including nested includes. A failing SPF path cannot authenticate a domain for DMARC, but an aligned DKIM pass can still make DMARC pass.
That distinction also explains a common receiver-dashboard mismatch. Message headers can show spf=pass for the Return-Path while aggregate authentication data looks weak because the receiver is grouping mail by the visible From domain and showing aligned DMARC outcomes across real traffic. If a setup check reports SPF missing while the header shows spf=pass, compare the checked hostname with smtp.mailfrom before editing the root SPF record.
A forwarder that uses SRS rewrites the envelope sender and sends the message onward. SPF can pass for the forwarder because its IP is authorized by its SPF record. That pass does not provide alignment when the forwarder's domain is unrelated to the original visible From domain; DMARC then needs a passing aligned DKIM signature.
Header pattern where SPF passes but does not help DMARCtext
Authentication-Results: mx.example.net; spf=pass smtp.mailfrom=bounces@forwarder.example; dkim=pass header.d=mailer.vendor.example; dmarc=fail header.from=news.brand.example
In that pattern, SPF passes for forwarder.example. The visible From domain is news.brand.example. Those domains do not match, so SPF does not satisfy DMARC.
- SPF pass: The connecting IP was allowed by the envelope sender domain's SPF record.
- SPF alignment: The envelope sender domain matches the visible From domain at the required alignment level.
- HELO limit: A standalone HELO SPF pass does not count when MAIL FROM has a domain; a null MAIL FROM path uses the HELO domain to derive the SPF identity.
- Return-Path fix: Configure a branded bounce domain that meets aspf, and verify SPF at that hostname. A separate bounce subdomain does not satisfy strict alignment.
- DMARC result: SPF only helps DMARC when both SPF pass and SPF alignment are true.
What passing DKIM really means
DKIM authenticates a cryptographic signature. The domain DMARC cares about is the DKIM d= domain, not the selector and not the domain in the return path. A message can carry multiple DKIM signatures. One can pass for a forwarding service, one can pass for a sending platform, and neither can match the visible From domain.
The DKIM DNS record follows the same identity. Receivers look for the public key at selector._domainkey under the d= domain, so a vendor-supplied selector belongs under the signing domain the sender actually uses. A setup checker can report DKIM missing while a live header shows dkim=pass if it looked for a different selector, a different signing domain, or a default sender setup that this message did not use. Query the exact selector._domainkey name from the DKIM-Signature header before changing DNS. If DKIM passes at one receiver and fails at another, test that selector on every authoritative nameserver before rotating keys. One stale nameserver, wildcard answer, broken CNAME, or DNS timeout can make a valid stream look receiver-specific. In a multi-ESP setup, each platform should get its own selector or provider CNAME. The selector can differ, but the d= domain still has to match the visible From domain for DMARC. For third-party services, that usually means enabling custom DKIM instead of relying on default vendor signing.
For subdomains, build the DKIM lookup from the live signature, not the DNS screen. If a message signs with d=mail.example.com and s=google, the receiver checks google._domainkey.mail.example.com. A key at google._domainkey.example.com does not help that message, and two TXT records at one selector can make DKIM fail before DMARC can use that path for alignment.
When troubleshooting this, find dkim=pass and then compare header.d with the visible From domain. If header.d is absent, read d= from the corresponding DKIM-Signature header. DMARC uses that signing domain, not header.i, which identifies the DKIM Agent or User Identifier. RFC 6376 defines these signature identities. A passing vendor signature does not satisfy your domain's DMARC policy unless its signing domain meets the required alignment mode. If the body hash did not verify, check content changes after signing, such as footer insertion or MIME reformatting. Subject tagging can break verification of signed headers instead. If no key is available or a DNS lookup failed, check selector DNS; a DKIM permerror also warrants checking signature syntax and supported algorithms. When the Return-Path is vendor-owned, aligned DKIM can provide DMARC authentication without changing the ESP's bounce-domain configuration.
An aligned DKIM pass from an unfamiliar IP can be legitimate forwarding: DKIM does not authenticate the final connecting IP. Confirm the route with the sending owner before treating the row as replay or compromised signing access. For suspicious messages, investigate account access and message content separately from DNS alignment.
DKIM passes
- Signature: The signed portions of the message verify under the signature's canonicalization rules.
- Domain: The signing domain can be a vendor, platform, forwarder, or brand domain.
- Limit: A valid signature does not automatically satisfy the brand's DMARC policy.
DKIM has alignment
- Identity: The DKIM signing domain matches the visible From domain.
- Default: Relaxed alignment accepts the same organizational domain.
- Outcome: A passing aligned DKIM signature is enough for DMARC to pass.
DKIM alignment is usually the most dependable fix because it survives forwarding better than SPF. A forwarder can change the envelope sender and break SPF alignment, but a DKIM signature continues to pass if the message content and signed headers are not modified.
How unaligned headers produce a DMARC fail
The header pattern behind this problem usually has several domains involved. One domain appears in the visible From address. Another appears in the SPF envelope sender. One or more domains appear in DKIM signatures. DMARC then checks whether any passing SPF or DKIM domain has alignment with the visible From domain.
|
|
|
|---|---|---|
Visible From | brand.test | The Author Domain being evaluated; the DMARC policy can be inherited from another domain. |
Sender header | service.test | Helpful context, not the DMARC policy identity. |
SPF | fwd.test | SPF passed for another domain. |
DKIM 1 | vendor.test | A platform signature passed. |
DKIM 2 | relay.test | A relay signature passed. |
DMARC | fail | No passing domain aligned. |
The exact names vary, but this is the structure to check.
An enforcement policy changes handling after authentication fails. If the organizational domain publishes sp=reject, it requests rejection of failing mail using existing subdomains that have no overriding DMARC record. The np tag can set a separate policy for non-existent subdomains. Neither tag changes the SPF or DKIM alignment test.
Do not relax policy first
Changing p=reject or sp=reject can change the requested handling, but it does not fix authentication. First prove which domain failed alignment, then decide whether policy staging is needed. The receiver still applies local policy to the final delivery decision.
How to fix DMARC alignment failures
The practical fix is to choose the domain that should identify the sender, then configure at least one authentication path to match it. For most marketing, product, and transactional mail, DKIM alignment comes first because it is more stable through forwarding and less dependent on the final connecting IP. For domains with multiple ESPs, start by mapping each platform to its DKIM d= domain and MAIL FROM domain before editing DNS. Classify each source as legitimate, unauthorized, or needing investigation before changing policy.
Do not create one DMARC record for each sending platform. Publish one DMARC policy record at each policy hostname, then give each legitimate sender an authentication path that meets the From domain's alignment requirements. Multiple DMARC records at one hostname are discarded during RFC 9989 discovery; this can change which inherited policy is found. If the domain has no DMARC record yet, start with a monitored p=none record; complete the sender alignment work before enforcement.
- Confirm: Read the visible From domain, identify the exact DMARC policy being applied, and check its adkim and aspf modes.
- Trace DMARC DNS: If record checks loop, time out, or alternate between answers, query each authoritative nameserver for _dmarc before editing policy tags.
- Compare: Check whether the SPF envelope sender domain matches the From domain.
- Trace SPF DNS: Confirm the exact Return-Path or bounce hostname and any CNAME target return one clean SPF answer.
- Inspect: Check every passing DKIM signature and compare each signing domain with the From domain.
- Trace DKIM DNS: Query the exact selector and DKIM domain from the header across every authoritative nameserver, and confirm the selector returns one active key.
- Assign: Map the failing source to a business owner so the DNS or sender-side change is made in the right system.
- Configure: Enable custom DKIM with a signing domain that meets adkim, or configure a custom MAIL FROM domain that meets aspf.
- Validate: After cached DNS answers expire, send a fresh message through each affected service to direct and forwarded test recipients. Confirm dmarc=pass with the expected identities in the trusted receiver's Authentication-Results header.
- Document: Record the owner, selector, Return-Path, DNS change, and rollback note so the same sender can be supported later.
Check record placement before changing policy. DMARC belongs at _dmarc for the visible From domain, DKIM belongs at the selector hostname under the d= signing domain, and SPF belongs at the Return-Path domain used in the SMTP MAIL FROM identity. If the Return-Path is ESP-owned, your root SPF record is not the active SPF record for that stream; request a branded bounce domain or rely on matching DKIM. For marketing and transactional platforms, check the authenticated domain or sender authentication setup for the bounce domain before editing unrelated SPF records. Copying every record to the root domain can still leave the failing mail stream misaligned.
If a DNS check reports a loop, distinguish a CNAME loop from a delegation or referral loop. Query the exact _dmarc hostname at each authoritative nameserver and follow any alias target. Fix the DNS path before changing policy tags.
Example DMARC record while testing alignmentdns
_dmarc.example.com. 3600 IN TXT ( "v=DMARC1; p=none; rua=mailto:dmarc@example.com; " "adkim=r; aspf=r" )
A p=none policy is valid monitoring, not an authentication failure. Use it to collect aggregate reports while you identify unaligned senders, then move to quarantine or reject only after legitimate traffic has aligned SPF or DKIM.
If the domain is already at reject, first check whether the failing stream lacks custom DKIM or uses an unrelated Return-Path. A temporary exception needs a named owner and a retest plan; reducing enforcement does not repair domain alignment.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
For a focused DNS check, use the DMARC checker to confirm the record syntax and policy tags before changing sender configuration.
When forwarding causes the failure
Forwarding creates a confusing version of this issue because the forwarded message can carry both old and new authentication signals. Without SRS, SPF often fails because the forwarder's IP is not authorized by the original MAIL FROM domain. With SRS, SPF can pass for the forwarder while losing alignment with the original From domain. DKIM can remain about the original sender, but only if the forwarder does not modify signed content. A failure report for the forwarded copy does not prove that all direct mail from the domain is failing. ARC can help receivers evaluate the earlier authentication state, but it does not turn a misaligned message into an aligned one by itself.
Flowchart showing why forwarded email can change SPF, preserve or break DKIM, and affect the DMARC result.
If you control the original sender, the best fix is still aligned DKIM. If you control the forwarder, preserve DKIM signatures by avoiding subject tagging, footer injection, and content rewriting. Mailing lists have the same failure shape when they add prefixes or footers, because the original DKIM signature can break while SPF belongs to the list server.
Some mailing lists rewrite the visible From address to the list domain so the list can authenticate as itself. That can reduce downstream DMARC failures for author domains with enforcement policies, but it changes the Author Domain that recipients and receivers evaluate.
If you control neither side, the receiver's local ARC handling and spam filtering decide the final outcome.
For deeper examples, the most useful next step is forwarded email analysis, because the apparent sender and the technical sender often diverge after forwarding.
How subdomain policy affects failed messages
Subdomain policy is another common reason the failure feels surprising. A parent domain can publish sp=reject, which requests rejection for failing mail using existing subdomains unless they publish their own DMARC records. The DMARC failure is still caused by the absence of a passing aligned method; the inherited policy determines the requested handling.
A subdomain does not inherit the root domain's DKIM selector record. If mail signs as d=email.example.com, the DKIM key has to live under that subdomain selector unless the sender is deliberately signing with the parent domain.
Policy-first reaction
- Change: Temporarily reduce the requested subdomain enforcement while fixing the sender.
- Risk: Misconfigured or spoofed subdomain mail gets less protection.
- Use case: Temporary staging while a known sender is being fixed.
Alignment-first fix
- Change: Configure aligned DKIM or SPF for the subdomain sender.
- Benefit: Correctly configured legitimate mail passes; unauthenticated use of the From domain remains subject to enforcement.
- Use case: Long-term production setup for brand and subdomain mail.
A temporary subdomain DMARC record can be reasonable while you stage a fix. For example, a specific sending subdomain can publish monitoring mode while the parent remains protected. Treat that as a short-lived exception with a clear owner, not as the final state.
Temporary subdomain monitoring recorddns
_dmarc.email.example.com. 3600 IN TXT ( "v=DMARC1; p=none; rua=mailto:dmarc@example.com" )
How to read the headers
When a failure report, receiver dashboard, setup check, or raw message looks inconsistent, reduce it to four questions. Do not start by changing DNS. First identify which authenticated identity DMARC used, which domains passed, and which one should have aligned. Treat Sender as context only, not as a DMARC pass/fail identity. A generic setup checker answers a DNS discovery question; the receiver header answers what happened to that exact message.
A DMARC failure report is a clue from one receiver about one delivery path, not proof that every message from the domain is broken. Start with the source IP and the final Authentication-Results header, then decide whether the source is a direct sender you control, a forwarder, a mailing list, a security relay, or an unknown system. Change DNS only after that classification is clear.
RFC 9990 defines DMARC aggregate reporting. If you are reading aggregate RUA reports instead of a raw header, compare policy_evaluated results with the auth_results block. The auth_results block can show raw SPF or DKIM pass for a vendor domain, while policy_evaluated.dkim or policy_evaluated.spf still shows fail because DMARC is recording the aligned result for the Author Domain.
Also check the reported disposition and any policy override reason. Local policy, trusted forwarding, mailing-list handling, or test mode can change the disposition without changing the underlying DMARC authentication result.
When one receiver shows DKIM pass and another shows DKIM fail for the same stream, compare the final Authentication-Results headers side by side. The same d= domain and s= selector with different result wording usually points to selector DNS consistency, resolver caching, timeouts, or message changes after signing. It does not make shared IP reputation the cause of the DKIM cryptographic failure.
Receiver dashboards add another layer because they aggregate many messages. SPF and DKIM can look steady while DMARC moves if the daily source mix changes, a small failing sender sends a larger batch, or the dashboard groups several subdomains under one view. Compare one high-success day with one low-success day, then group the aggregate report rows by source IP, MAIL FROM domain, DKIM d= domain, and Author Domain before changing DNS.
|
|
|
|---|---|---|
From? | header.from | Identify the Author Domain. |
SPF? | smtp.mailfrom | Use aligned bounce domain. |
DKIM? | header.d / DKIM-Signature d= | Use aligned signing domain. |
Policy? | adkim / aspf; p / sp / np | Stage only if needed. |
Use this compact checklist before editing DNS.
Suped's DMARC monitoring product groups aggregate reports by sending source. Find a failing source, compare raw SPF and DKIM results with their DMARC alignment results, then open the issue detail for the DNS or sender-side remediation steps.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
That matters when several teams and sending systems use the same domain. Suped groups aggregate reports by source, flags alignment issues, sends alerts, and keeps the remediation steps attached to the affected sender. The practical result is that each failure can be assigned to the team that controls the DKIM, Return-Path, or DNS change.
When reports show unknown senders
A low DMARC success rate does not always mean your legitimate mail is broken. Aggregate reports can include unauthorized traffic that used your domain or an invented subdomain in the visible From header. If known senders pass DMARC and unknown rows fail, the operational issue is enforcement and reporting interpretation, not adding more SPF includes to the root domain.
If a dashboard displays NXDOMAIN for an IP's reverse-DNS lookup, the queried PTR name does not exist. Aggregate XML reports do not have a standard "server name" field. Reverse DNS is useful context, but it does not determine DMARC alignment. A failed DMARC result still means no passing SPF or DKIM identifier satisfied the Author Domain's alignment requirements.
- Known source: Map the source IP, MAIL FROM domain, DKIM signing domain, and expected owner before changing DNS.
- Unknown source: Investigate the route and business owner before classifying an unfamiliar IP as spoofing. An aligned DKIM pass can survive legitimate forwarding; review replay or signing access if the route remains unexplained. Do not add the IP to SPF solely because it appears in a report.
- Random subdomain: A sender can place an invented subdomain in the visible From header without creating that DNS name.
- Policy response: Use sp and np only after legitimate subdomain mail has a confirmed aligned path.
- Metric: Track known-sender DMARC success separately from the blended global success rate.
Separate abuse from configuration
If a failing row maps to a sender or relay you use, verify its configuration and route. If investigation confirms unauthorized use of your domain, keep reporting enabled and apply the intended DMARC enforcement policy.
DMARC record changes that help
Record changes help when they make policy behavior explicit or reduce operational mistakes. They do not replace sender configuration. If SPF and DKIM pass for unrelated domains, no DMARC tag can make them match. Since RFC 9989 replaced RFC 7489 in May 2026, do not add older rollout tags such as pct to new records.
Adjacent controls have their own jobs. ARC can preserve prior authentication context, MTA-STS and TLS-RPT deal with inbound transport security and TLS reporting, and BIMI depends on DMARC enforcement for supported brand indicators. None of those controls makes a vendor DKIM domain or vendor Return-Path match the visible From domain, so fix the aligned SPF or DKIM path first.
- Use relaxed alignment: Keep adkim=r and aspf=r unless there is a clear security reason for strict alignment.
- Add reporting: Use rua so aggregate reports identify failing source and domain combinations. When the destination has a different organizational domain, its DNS owner must authorize external reporting; adding the destination address to rua alone does not grant authorization.
- Stage testing: RFC 9989 makes pct historic. Use t=y for test mode only after checking receiver support; do not build a new rollout around percentage sampling.
- Separate subdomains: Publish a subdomain DMARC record when one subdomain needs a different rollout path.
- Protect unused names: Use np when you need a policy for non-existent subdomains under the current DMARC rules.
- Handle failure reports carefully: Use ruf and fo only when there is a process for sensitive header data; RFC 9991 failure reports can expose message details, while rua reports are enough for most alignment work. Requesting failure reports does not guarantee that receivers will send them.
Before using p=reject on a domain that hosts human mailboxes, test mailing lists and forwarding paths. Choose enforcement based on verified legitimate flows and their impact; a high overall pass rate can hide a low-volume critical sender.
Reject policy with relaxed alignment for dedicated sending domainsdns
_dmarc.example.com. 3600 IN TXT ( "v=DMARC1; p=reject; sp=reject; np=reject; " "rua=mailto:dmarc@example.com; adkim=r; aspf=r" )
Under RFC 9989, t=y requests one level less enforcement: reject becomes quarantine, and quarantine becomes none. It has no effect on a none policy. Receivers that do not support the tag can still apply the declared policy, and local filtering still applies. Verify actual handling before relying on test mode, then remove the tag after validating legitimate traffic.
When building a new record, a DMARC record generator is useful for producing a valid TXT record, but the sender-side alignment still has to be configured in each mail platform.
Evidence for DMARC policy readiness
Base enforcement on verified legitimate sending paths. There is no universal pass-rate threshold for a safe rollout.
Monitor
Sender inventory incomplete
Map legitimate senders and investigate unexplained authentication failures.
Quarantine staging
Sender fixes under validation
Verify each configured sender and test important indirect delivery paths.
Reject readiness
Critical flows verified
Confirm critical legitimate flows pass, with reporting and an owner for any remaining exception.
Manage alignment across multiple sending services
The hard part is rarely the DMARC record itself. It is the inventory of legitimate senders and the hidden domain choices each sender makes. Marketing platforms, billing systems, support desks, product mailers, website forms, and internal servers can all send as the same brand while authenticating different technical domains.
Name an owner for sender intake and report review so a p=none monitoring setup turns into fixes instead of an unread report archive. A lightweight sender-intake checklist should capture the From domain, DKIM d= domain, selector, Return-Path, sending IP ownership, expected volume, and rollback owner.
If you bring in a DMARC professional, judge the engagement by the outputs they leave behind. You should receive a sender inventory, exact DNS changes, unresolved alignment issues, a policy-stage plan, rollback notes, and a handoff process for approving new senders.
Best practical order
- Inventory: List every service that sends mail using the domain.
- DKIM: Enable custom DKIM for every sender that supports it.
- SPF: Use branded bounce domains only where the sender supports custom return paths.
- Policy: Move toward quarantine and reject after reports show legitimate mail passing.
If you need a broad check across DMARC, SPF, and DKIM, the domain health checker gives a quick read before digging into mail headers and aggregate reports.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Views from the trenches
Best practices
Check the visible From domain before trusting any SPF or DKIM pass result in headers.
Prefer aligned DKIM for sender setup because it survives forwarding more reliably.
Use subdomain policy staging only with a named owner and a fixed review deadline.
Common pitfalls
Teams often treat any SPF pass as DMARC success, even when the bounce domain differs.
Multiple DKIM signatures can hide the fact that no signature matches the From domain.
Removing sp=reject can mask a sender problem instead of fixing the authentication path.
Expert tips
Read Authentication-Results from the final receiver, not only ARC or earlier relay results.
Map every sending source to its DKIM d= domain and envelope sender domain before policy changes.
Keep policy exceptions narrow so temporary DMARC staging does not become permanent.
Marketer view
Marketer from Email Geeks says DMARC can fail even when the header shows SPF and DKIM pass, because the passing domains can belong to relays or vendors instead of the From domain.
2018-05-24 - Email Geeks
Marketer view
Marketer from Email Geeks says forwarded mail should be checked against the final receiver's Authentication-Results header, since ARC results can describe an earlier authentication state.
2018-05-24 - Email Geeks
Frequently asked questions
Yes. Either method is enough if it passes and its authenticated domain meets the alignment mode for the visible From domain. SPF uses the MAIL FROM domain; DKIM uses d=. An unrelated vendor Return-Path does not qualify for SPF alignment. This DMARC rule is separate from Gmail and Yahoo bulk-sender requirements to configure both SPF and DKIM.
First check whether the receiver recorded dmarc=fail, none, permerror, or temperror. Headers show the result for one message, including the exact SPF and DKIM identities used. Aggregate reports and dashboards show traffic trends, while setup checkers can query a different selector, sender path, or policy name. Use the final Authentication-Results header to identify the result code, then verify the exact DNS names involved.
Receiver-specific DKIM failure usually points to inconsistent selector DNS, DNS timeout, stale resolver cache, or message changes after signing. Check the exact selector and DKIM domain on every authoritative nameserver, then compare the failing Authentication-Results wording with a message where DKIM passed.
Without SRS, forwarding often causes SPF failure because the connecting IP changes. With SRS, SPF can pass for the forwarder but lose alignment. DMARC still passes if an original aligned DKIM signature verifies; it fails only when neither method provides an aligned pass.
Remove or relax subdomain policy only as temporary staging. The better fix is to configure aligned DKIM or SPF for the subdomain sender.
Yes. A compromised account, abused sender platform, replayed signed message, or attacker-owned domain can pass SPF, DKIM, and DMARC. That result means the domain identity aligned, not that the content, links, source network, message ID, or sender intent are safe.
