You cannot configure DMARC to reject a message only because DKIM fails when SPF passes and the SPF domain matches the visible From domain. DMARC is an either-or test: a message passes DMARC when either DKIM passes with domain matching, or SPF passes with domain matching. If SPF already gives DMARC a pass, the domain's DMARC policy does not apply, 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 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.
- DMARC result: SPF pass with the right 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 used 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". The policy tags p and sp act after DMARC evaluates the combined result. They do not evaluate DKIM and SPF as separate rejection conditions.
A standard reject policy looks simple, but it does not mean every failed DKIM signature is rejected. It means the receiver is asked to reject mail that fails DMARC. A message with SPF pass and the right visible From domain has already passed DMARC.
A normal reject policytext
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com
That record asks receivers to reject messages that fail DMARC. It does not say "DKIM is required". The same is true if you add reporting tags, percentage rollout, or strict matching tags. Those tags change reporting and matching behavior, not the core pass rule.
Why SPF pass overrides DKIM failure in DMARC
DMARC checks the domain in the visible From header. Then it asks whether SPF or DKIM produced a pass that is tied back to that same domain, usually at the organizational-domain level unless strict matching is requested.
- SPF path: SPF passes, and the envelope sender domain matches the visible From domain enough for DMARC.
- DKIM path: At least one DKIM signature passes, and its d= domain matches the visible From domain enough for DMARC.
- Final result: If either path is true, DMARC passes. If both paths are false, the DMARC policy applies.
DMARC passes when either the SPF path or DKIM path matches the visible From domain.
This is why the answer to both SPF and DKIM is usually no. DMARC needs one passing, matching path, not both. Requiring both would break a large amount of legitimate mail, including forwarded messages, application mail, calendar mail, and senders where DKIM has not been configured correctly yet.
|
|
|
|
|---|---|---|---|
Pass + match | Fail | Pass | No reject |
Pass + mismatch | Fail | Fail | Policy applies |
Fail | Pass + match | Pass | No reject |
Fail | Fail | Fail | Policy applies |
The key case is the first row: DKIM fails, SPF passes, 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.
What DMARC can do
- Policy: Ask receivers to quarantine or reject 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 DMARC rejection.
Before changing DNS, validate syntax with the DMARC checker. Then test real messages from every source, because DNS syntax and live message authentication are different checks.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
The only ways to force DKIM as required
There are a few ways people try to make DKIM the decisive signal. Most are either outside DMARC or carry real delivery risk.
- Remove SPF: Do not do this for normal outbound mail. SPF is still useful for authorization, reporting, and receiver trust.
- 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/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 DKIM signature often means signed headers or body content changed. It can also mean the sender signed with the wrong domain, the DNS selector is wrong, the message was rewrapped, or the signing service has a bad key.
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 gives you stronger sender authentication without relying on a DMARC behavior that does not exist.
In Suped's product, DMARC monitoring helps identify sources where DMARC passes through SPF while DKIM fails. That is the exact workflow I want here: find the source, confirm whether it is legitimate, then fix DKIM at the sender rather than changing 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 under DNS lookup limits so it remains a reliable fallback.
- Failure review: Separate legitimate DKIM failures from unauthorized use, forwarders, and broken sender setups.
- Policy move: Move through none, quarantine, and reject once the legitimate traffic is stable.
Staged DMARC policy examplestext
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com
Suped's Hosted DMARC is useful when you want policy staging without repeatedly editing raw DNS. Hosted SPF and SPF flattening also help when the SPF record is close to lookup limits, while real-time alerts catch sudden DKIM failure from a sender change.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped is the best practical fit for most teams that need one place to monitor DMARC, SPF, DKIM, hosted records, blocklist (blacklist) signals, and multi-domain client work. The useful part for this problem is not a special override of DMARC. It is fast detection and clear remediation steps when DKIM fails on a legitimate source.
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 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 is a local receiver decision, so it protects your own users but does not tell the rest of the internet to behave the same way.
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 also help receivers evaluate forwarded mail by preserving earlier authentication results across trusted hops. It does not change your DMARC DNS policy, and it is not a replacement for fixing DKIM at the sender.
A decision path I use
I use a simple decision path. If DKIM fails on a source that SPF already covers, I do not try to make DMARC reject that message. I look at whether the source is legitimate, whether it should sign with the From domain, and whether the failure came from a sender setup or a later message change.
Reject policy readiness
Operational thresholds for moving a domain toward reject after sender fixes.
Not ready
< 98%
Legitimate sources still fail DMARC or have unknown DKIM behavior.
Investigate
98-99.5%
Most traffic passes, but exceptions need sender-by-sender review.
Ready
> 99.5%
Legitimate sources are identified and stable over recent reporting windows.
Those thresholds are not part of the DMARC standard. They are a practical operating model. A high pass rate does not remove the need to inspect business-critical senders, but it keeps the policy move grounded in evidence instead of guesswork.
If a business-critical sender passes DMARC only through SPF, keep it working while you fix DKIM. Do not block the mail just to satisfy a cleaner authentication model. The better target is both paths passing, with DMARC enforcement active once all legitimate flows are stable.
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 the real traffic, and move to p=reject only when legitimate mail is known and stable.
If your security requirement is specifically "reject when DKIM fails", apply that rule on the inbound systems you control. If your requirement is domain-wide protection against spoofing, DMARC reject is still the right destination, but it rejects DMARC failures, not every DKIM failure.
For most teams, Suped is the best practical choice for this workflow because it connects DMARC reports, SPF and DKIM diagnostics, hosted record management, real-time alerts, blocklist (blacklist) monitoring, and multi-tenant reporting in one platform. The value is seeing exactly which sender needs repair before a policy change affects real mail.
