How to configure DMARC to reject emails when DKIM fails but SPF passes?
Updated on 6 Aug 2026: We updated this guide for RFC 9989 testing mode, current rollout records, and clearer SPF alignment diagnostics.
You cannot configure DMARC to reject a message only because DKIM fails when SPF passes and the SPF-authenticated MAIL FROM or Return-Path domain matches the visible From domain. 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 tightens DKIM domain matching, but it does not make 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.
The direct answer
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
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, so quarantine is treated as none and reject is treated as quarantine while testing.
- Receiver decision: The final disposition remains local. A receiver can accept a DMARC failure or filter a DMARC pass after considering other signals.
Current testing and enforcement examplestext
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
Domains whose users post to Internet mailing lists need extra caution with p=reject. Review aggregate reports and indirect-mail behavior before enforcement because 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 same domain, usually at the organizational-domain level unless strict matching is requested. 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.
DMARC passes when either the SPF path or DKIM path matches the visible From domain.
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.
|
|
|
|
|---|---|---|---|
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.
What you can configure instead
The closest DNS-side setting is strict DKIM domain matching with adkim=s. This makes DMARC accept only DKIM signatures where the 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 the 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
The only ways to force DKIM as required
Several approaches can make DKIM the decisive signal. Most are outside DMARC or create delivery risk.
- Remove SPF: Do not do this for normal outbound mail. SPF still provides source authorization and useful diagnostic data.
- Break matching: Using a return-path domain that does not match the From domain makes SPF unavailable for DMARC. It is brittle and usually unnecessary.
- Inbound gateway: For mail you receive, a gateway can quarantine or reject messages where DKIM fails even though SPF passes.
- Sender repair: Configure DKIM correctly for each sender, including selectors, signing domain, and header or body handling.
Do not deliberately break SPF domain matching just to make DKIM carry DMARC. That hides useful authentication data and makes legitimate senders harder to diagnose. A DKIM-required rule belongs in inbound filtering when you control the receiving side.
If your concern is message modification after sending, DKIM is the right signal to investigate. A failed signature often means signed headers or body content changed. It can also mean the sender used the wrong signing domain, published the wrong selector key, rewrapped the message, or generated an invalid signature.
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 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 monitoring, testing, quarantine, and reject after legitimate traffic and mailing-list behavior are stable.
Staged DMARC policy examplestext
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-reports@example.com v=DMARC1; p=quarantine; 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
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
For this problem, Suped's product can separate sources that pass DMARC through SPF from sources with working DKIM. Use that breakdown to identify the sender, confirm its selector and signing domain, and verify the repair before changing policy.
When message body changes are the concern
A DKIM failure often means the signed message changed after signing. The change is not automatically hostile. 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.
- Wrong domain: The sender signs with a vendor domain instead of the visible From domain.
Better response
- Trace source: Inspect Authentication-Results and received headers to find the system that changed or resigned the message.
- 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. You can reject or quarantine messages claiming to be from your domain when DKIM fails, even if SPF passes. That local receiver decision protects your own users but does not tell the rest of the internet to use the same rule.
Example inbound logictext
if header.from_domain == "example.com" and auth.dkim != "pass" and auth.spf == "pass" then quarantine_or_reject("DKIM required for this flow") end
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 SPF already covers, 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
t=y
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 creates delivery risk and weaker source visibility.
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 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 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
The configuration that actually works
The correct configuration is not a hidden DMARC tag. Publish a normal DMARC policy, keep SPF valid, configure DKIM for every sender, monitor real traffic, test the next policy with t=y, and move to p=reject only when legitimate and indirect mail is understood.
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.
Suped's product supports this workflow by grouping aggregate reports by sender and showing whether each source passes through SPF, DKIM, or both. Use those results to repair the exact source before changing hosted policy, then watch alerts for authentication regressions after the change.
