How to configure DMARC to reject emails when DKIM fails but SPF passes?
Updated on 13 Oct 2026: We clarified DKIM failure diagnostics and safer DMARC policy testing.
You cannot configure DMARC to reject a message only because DKIM fails when SPF passes and the SPF-authenticated MAIL FROM domain, usually shown in Return-Path, matches the visible From domain under the selected alignment mode. DMARC is an either-or test: a message passes when either DKIM passes with identifier alignment or SPF passes with identifier alignment. If SPF gives DMARC an aligned pass, the DMARC failure disposition is not invoked, even when DKIM fails.
The practical answer is to fix DKIM, keep SPF working, and move the domain to p=reject only after legitimate sources and indirect mail are understood. If you need a local rule that says "DKIM must pass for this sender", that belongs in an inbound mail gateway or mailbox filter, not in the DMARC DNS record. A DMARC pass does not guarantee inbox placement because the receiver still applies its own filtering.
- DMARC result: SPF pass with the required domain match means DMARC pass, even if DKIM fails.
- DKIM tag: The adkim tag selects relaxed or strict DKIM domain matching; adkim=s requires an exact match. Neither setting makes DKIM mandatory.
- Reject policy: A p=reject policy is considered only when the whole DMARC check fails.
- Best fix: Repair DKIM per sending source, monitor failures, and use inbound rules for stricter local handling.
Why p=reject does not require DKIM
DMARC has no tag that means "reject when DKIM fails, even though SPF passes with alignment". The policy tags p and sp act after DMARC evaluates the combined result. They do not turn DKIM and SPF into separate rejection conditions.
A standard reject policy looks simple, but it does not mean every failed DKIM signature is rejected. It asks the receiver to apply a reject disposition to mail that fails DMARC. A message with SPF pass and the required match to the visible From domain has already passed DMARC.
A normal reject policytext
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com
For example.com, publish one DMARC TXT record at _dmarc.example.com and replace the example report address with your actual destination. That record requests rejection for messages that fail DMARC. It does not say "DKIM is required". Reporting tags, testing mode, and strict matching tags change reporting, rollout behavior, or identifier matching. They do not change the core pass rule.
What RFC 9989 changes
RFC 9989 became the current DMARC standard in May 2026 and replaced RFC 7489. It keeps the same message-level pass rule: one passing and matching SPF or DKIM identifier is enough. It also makes the operational expectation for enforced domains clearer.
- DKIM with reject: A domain publishing p=reject must not rely only on SPF and must apply valid DKIM signatures to legitimate mail. This improves resilience to forwarding, but it does not change the either-or evaluation of an individual message.
- Historic percentage tag: The pct tag is historic, so current rollout records should not depend on percentage sampling.
- Testing mode: The new t=y value requests one policy level below the published policy on receivers that implement it: quarantine becomes none and reject becomes quarantine for DMARC-failing messages.
- Receiver decision: The final disposition remains local. A receiver can accept a DMARC failure or filter a DMARC pass after considering other signals.
Receivers that do not implement t=y ignore it and can apply the full published policy. This follows the unknown-tag rule in RFC 7489. Treat p=reject; t=y as capable of full rejection, and validate legitimate senders before publishing it.
Alternative records for testing or enforcementtext
v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-reports@example.com v=DMARC1; p=reject; t=y; rua=mailto:dmarc-reports@example.com v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com
RFC 9989 advises domains whose users post to Internet mailing lists against publishing p=reject. Before an exception, collect aggregate reports with p=none for at least a month, then p=quarantine for an equally long period, and compare dispositions. Mailing lists can break SPF and DKIM alignment.
Why aligned SPF makes DMARC pass when DKIM fails
DMARC checks the domain in the visible From header. It then asks whether SPF or DKIM produced a pass tied to that domain. Relaxed alignment is the default and requires the same organizational domain; strict alignment requires an exact match. A raw SPF pass for an unrelated Return-Path domain does not satisfy DMARC.
- SPF path: SPF passes for the MAIL FROM or Return-Path domain, and that domain matches the visible From domain under the selected mode.
- DKIM path: At least one DKIM signature passes, and its d= domain matches the visible From domain under the selected mode.
- Final result: If either path is true, DMARC passes. If both paths are false, the DMARC policy is considered.
Flowchart showing that DMARC passes when SPF or DKIM passes with the required From-domain alignment.
This is why DMARC cannot require both SPF and DKIM for every message. DMARC needs one passing, matching path. Configuring both remains important because forwarding often breaks SPF, while message changes can break DKIM. With multiple DKIM signatures, one passing signature with the required domain match is enough, even when another signature fails.
|
|
|
|
|---|---|---|---|
Pass + match | Fail | Pass | No DMARC failure disposition |
Pass + mismatch | Fail | Fail | Policy considered |
Fail | Pass + match | Pass | No DMARC failure disposition |
Fail | Fail | Fail | Policy considered |
The key case is the first row: DKIM fails, SPF passes with alignment, and DMARC still passes.
Check Authentication-Results before changing policy
Inspect a delivered message's full headers, as recommended in Google's DMARC troubleshooting guidance. Use Authentication-Results added by your receiver or trusted gateway; RFC 8601 explains why untrusted fields cannot prove authentication.
SPF passes, DKIM fails, and DMARC passestext
From: Sender <sender@example.com> Return-Path: <bounce@bounce.example.com> Authentication-Results: mx.example.net; spf=pass smtp.mailfrom=bounce.example.com; dkim=fail (body hash did not verify) header.d=example.com header.s=selector1; dmarc=pass header.from=example.com
With default relaxed SPF alignment, bounce.example.com and example.com share an organizational domain, so SPF satisfies DMARC despite the DKIM failure. With aspf=s, that same SPF pass would not satisfy DMARC.
- Compare smtp.mailfrom with header.from to verify SPF domain alignment, rather than relying on spf=pass alone.
- Compare header.d with header.from for each passing DKIM signature. A vendor-domain signature can pass DKIM while failing DMARC alignment.
- Read header.s or s= in DKIM-Signature, then check selector1._domainkey.example.com for the public key in this example. Follow any CNAME to its TXT answer and compare the key with the sending system's configuration.
- Distinguish dkim=fail from dkim=none (unsigned mail), temperror (temporary verification failure), and permerror (unrecoverable verification error). A DNS outage needs different handling than a body-hash mismatch.
In aggregate XML, auth_results contains raw SPF and DKIM verification results, while policy_evaluated contains their DMARC alignment results. A reported DKIM alignment failure does not establish that the signature was invalid. RFC 9990 defines that distinction.
What strict DMARC alignment changes
You can tighten DKIM identifier alignment with adkim=s. A passing DKIM signature satisfies DMARC under this setting only when its signing domain exactly matches the visible From domain. It does not make DKIM required when SPF already passes with alignment.
What DMARC can do
- Policy: Request quarantine or rejection for messages that fail DMARC.
- Reports: Send aggregate data showing sources, volumes, and authentication outcomes.
- Matching: Use relaxed or strict domain matching for SPF and DKIM.
What DMARC cannot do
- DKIM-only: Require DKIM after SPF has already passed DMARC.
- Body changes: Prove that a body change was malicious rather than caused by a forwarder or footer.
- Inbound rules: Control how every receiver handles your mail beyond the DMARC result.
Strict SPF and DKIM domain matchingtext
v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:dmarc-reports@example.com
That record is stricter than the default, but only about domain matching. If a sender uses bounce.example.com as the SPF return-path domain and example.com as the visible From domain, strict SPF matching fails even if relaxed matching passes. If the exact From domain is used and SPF passes, DKIM can still fail without triggering a DMARC failure.
Before changing DNS, validate syntax with Suped's DMARC checker. Then inspect Authentication-Results and send live messages through every source, because a valid DNS record does not prove that SPF or DKIM passes with the required domain match.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
How to require DKIM on inbound mail
A DKIM requirement for selected inbound mail belongs in a receiving gateway or filter you control. Changing outbound SPF to make DKIM decisive for DMARC creates delivery risk and still does not add a DKIM-required policy tag.
- Remove SPF: Do not do this for normal outbound mail. SPF still provides source authorization and useful diagnostic data.
- Break matching: Using an unrelated Return-Path domain prevents its SPF pass from satisfying DMARC, even though SPF can still authenticate that domain. This removes the SPF fallback for DMARC.
- Inbound gateway: For selected inbound flows, require a valid DKIM signature with the expected signing domain, even when SPF passes.
- Sender repair: Configure DKIM correctly for each sender, including selectors, signing domain, and header or body handling. This repairs signing but does not change DMARC's pass rule.
Do not remove SPF or deliberately break its domain match to make DKIM carry DMARC for normal outbound mail. Making SPF unusable for DMARC removes a fallback; it does not erase raw SPF results from reports. Use inbound filtering for a scoped DKIM requirement.
If your concern is message modification after sending, DKIM is the right signal to investigate. A failed signature can mean signed headers or body content changed. It can also mean the public key is missing or incorrect, the signature expired, or signing produced an invalid signature. Signing with an unrelated domain can instead produce DKIM pass without DMARC alignment.
A safer configuration pattern
The safer pattern is to keep both authentication paths healthy, then treat DKIM failure on SPF-passing mail as an issue to repair. That supports forwarding and direct delivery without relying on a DMARC behavior that does not exist.
In Suped's product, DMARC monitoring groups reports by source so you can find mail that passes through SPF while DKIM fails. Confirm whether each source is legitimate, then fix custom DKIM signing at the sender instead of trying to change the DMARC pass rule.
- Inventory: List every service that sends mail using your domain, including transactional, marketing, billing, calendar, and support systems.
- DKIM repair: For each source, publish the DKIM TXT record or provider-supplied CNAME for its selector, confirm the signing domain, and send a live test message.
- SPF health: Keep SPF accurate and within DNS lookup limits so it remains a reliable authentication path.
- Failure review: Separate legitimate DKIM failures from unauthorized use, forwarders, and broken sender setups.
- Policy move: Move through p=none, p=quarantine, and p=reject after legitimate sources and indirect mail are understood. Do not rely on every receiver honoring t=y.
Staged DMARC policy examplestext
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com
Suped's Hosted DMARC can manage these policy stages without repeated raw DNS edits. Pair the policy workflow with source-level report review and alerts for sudden DKIM failure after a sender change.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
When message body changes are the concern
A DKIM body-hash mismatch indicates that the received body's hash does not match the signed bh= value after canonicalization. A message change is not automatically hostile, and an incorrect signature can also cause a mismatch. Mailing lists add footers, gateways rewrite links, security filters alter MIME structure, and forwarders can change headers. The fix depends on the hop that changed the message.
Common causes
- Footer edits: A list manager appends text after the sender has signed the body.
- Link rewriting: A security gateway changes URLs inside the signed content.
- Header changes: A gateway changes a header covered by the signature's h= list.
Better response
- Trace source: Inspect trusted Authentication-Results and Received headers to locate the system that changed the message or signed it again.
- Adjust signing: Use stable DKIM signing settings and the correct domain for each sender.
- Use local policy: Apply stricter DKIM rules only on inbound systems you control.
For inbound mail you control, the rule can be stricter than DMARC. For selected flows, reject or quarantine messages claiming to be from your domain when no valid DKIM signature has the expected signing domain, even if SPF passes. That local receiver decision does not tell other receivers to use the same rule.
Pseudocode for a scoped inbound DKIM requirementtext
if header.from_domain == "example.com" and flow.requires_dkim then if auth.any_dkim_pass_with_domain("example.com") then continue_normal_filtering() elseif auth.dkim_temporary_error_for_domain("example.com") then defer_for_retry("Temporary DKIM verification error") else quarantine_or_reject("Valid DKIM from example.com required") end end
The helpers use trusted gateway verification results and accept any valid signature with d=example.com. Limit enforcement to tested flows and review exceptions for forwarding or mailing lists.
ARC can help a receiver evaluate forwarded mail by preserving authentication results across trusted hops. It does not change your DMARC DNS policy, and it does not replace sender-side DKIM repair.
A practical decision path
When DKIM fails on a source that passes SPF with DMARC identifier alignment, do not try to make DMARC reject that message. Check whether the source is legitimate, whether it should sign with the visible From domain, and whether the failure came from sender setup or a later message change.
Reject policy readiness
Operational checks for moving a domain toward reject after sender fixes.
Not ready
Unknown sources
Legitimate sources remain unknown or fail DMARC.
Testing
Review indirect mail
Known sources pass, but indirect mail and policy effects still need review.
Ready
Stable traffic
Legitimate sources use stable authentication and policy testing is complete.
No universal pass-rate threshold makes a domain ready for reject. Readiness depends on verified sending sources, stable SPF and DKIM behavior, and review of business-critical and indirect mail.
If a business-critical sender passes DMARC only through SPF, keep it working while you fix DKIM. Do not block the mail just to produce a cleaner authentication result. The target is both paths working before DMARC enforcement is enabled.
Views from the trenches
Best practices
Keep SPF and DKIM healthy, then use DMARC reports to find sources with silent DKIM failure.
Treat DKIM failure on matching SPF mail as a sender repair task, not a DMARC policy gap.
Use strict DKIM domain matching only after every legitimate sender signs with the From domain.
Common pitfalls
Breaking SPF matching to force DKIM removes a fallback and risks legitimate delivery.
Assuming adkim=s makes DKIM mandatory leads to false confidence in reject behavior.
Moving straight to reject before checking forwarded and third-party mail blocks real messages.
Expert tips
Track DKIM failure by source, selector, and sending service before touching enforcement.
Use receiver-side rules when your own inboxes need stricter DKIM handling than DMARC.
Review body-modifying hops first, because footers and gateways often invalidate signatures.
Marketer view
Marketer from Email Geeks says DMARC passes when SPF authenticates and the envelope sender domain matches the visible From domain, even if DKIM fails.
2025-04-25 - Email Geeks
Expert view
Expert from Email Geeks says deliberately making SPF unavailable for DMARC can force DKIM to carry the result, but it is a poor default for normal outbound mail.
2025-04-25 - Email Geeks
Choose the right policy for DKIM failures
Publish a DMARC policy, keep SPF valid, configure DKIM for every sender, and monitor real traffic. Review quarantine outcomes before moving to p=reject. Testing mode is an additional signal for receivers that support it.
If your security requirement is specifically "reject when DKIM fails", apply that rule on the inbound systems you control. If your requirement is domain protection against direct spoofing, DMARC enforcement remains useful, but it acts on DMARC failures rather than every DKIM failure.
Frequently asked questions
No. If SPF passes and its MAIL FROM domain matches the visible From domain for DMARC, the message passes DMARC. A DMARC reject policy is not triggered.
No. It only makes DKIM domain matching strict. If SPF still passes with the required domain match, DMARC passes even when DKIM fails.
No. Keep SPF enabled for normal outbound mail. Removing it removes source authorization, while a domain mismatch removes SPF as a DMARC fallback. Repair DKIM instead.
Use a receiving gateway or filter to require at least one valid DKIM signature with the expected signing domain for selected inbound flows. Use trusted receiver-added Authentication-Results and handle temporary verification errors separately. This is independent of your public DMARC record.
Monitor aggregate reports, identify legitimate senders, fix authentication issues, and review indirect mail. Start with p=none, assess p=quarantine outcomes, then use p=reject when mail flow is stable. Receivers that ignore t=y can apply the full published policy.
No. A DMARC pass validates domain authorization; it does not verify the individual sender or establish that the content is safe. The receiver can still quarantine or reject the message under its local filtering rules.
