Why are some SFMC emails failing DKIM and causing DMARC rejections?
Some SFMC emails fail DKIM and cause DMARC rejections because those messages leave one sending path without a DKIM-Signature header, or with a DKIM domain that does not match the visible From domain closely enough for DMARC. If SPF is also not aligned, DMARC has no passing aligned identifier. With p=reject, receivers that enforce your policy reject or soft bounce those messages.
When the failures are a small percentage and cluster around Comcast, sbcglobal, bellsouth, or a few source IPs, I would treat this as a specific SFMC routing or sender authentication issue, not a general DNS problem. The key clue is DKIM not signed. A missing signature is different from a bad DKIM key, a DNS lookup failure, or a body hash mismatch.
- Root cause: One SFMC send path, business unit, send classification, or IP pool is not applying aligned DKIM.
- DMARC trigger: SPF is passing in the envelope domain but not matching the visible From domain used by DMARC.
- Receiver behavior: Some providers reject the failed messages immediately while others accept, defer, or classify them differently.
- Practical fix: Segment DMARC reports by source IP, DKIM domain, SPF domain, receiver, and SFMC job metadata, then fix the path that is unsigned.
A domain at p=reject should not depend on only one identifier if a major mailstream still has uncertain signing. DKIM should pass with the From domain, and SPF should use a bounce domain that also aligns wherever the sender supports it.
What is actually failing
DMARC passes when at least one of these is true: DKIM passes and its signing domain aligns with the visible From domain, or SPF passes and the envelope sender domain aligns with the visible From domain. It does not require both. That is why a small DKIM gap can be invisible for months when SPF aligns, then become painful when SPF is unaligned and the DMARC policy is strict.
Typical receiver resulttext
Authentication-Results: mx.receiver.example; dkim=none header.d=example.com; spf=pass smtp.mailfrom=bounce.sfmc.example.net; dmarc=fail header.from=example.com
In that example, SPF passes, but it does not help DMARC unless the envelope sender domain has the same organizational domain as the visible From address. DKIM is none, so DMARC fails. A DMARC checker can validate the record syntax, but it will not prove whether every SFMC path is signing. For that, you need report data and message samples.
Flowchart showing how DKIM and SPF alignment determine the DMARC result.
Why only some SFMC sends fail
Intermittent DKIM failures in Salesforce Marketing Cloud Engagement usually point to inconsistent paths. If 7 of 10 IPs sign properly and 3 do not, the issue is not the public DKIM TXT record by itself. A missing DNS record would affect every message using that selector. A small, repeatable slice points to routing, account configuration, or a send path that bypasses the expected authentication setup.
|
|
|
|---|---|---|
DKIM none | Unsigned path | IP pool |
One BU | Config drift | MID |
One receiver | Strict policy | Headers |
One template | Encoding | MIME |
Random pool | Fallback route | SFMC case |
Use the pattern of failures to narrow the cause.
Salesforce Marketing Cloud Engagement screen showing send configuration fields that affect authentication.
DKIM is absent
- Meaning: The message reached the receiver without a DKIM-Signature header.
- Likely area: SFMC routing, sender profile, business unit setup, or an unexpected non-SFMC source.
- DNS impact: Changing the DKIM TXT record will not fix a message that was never signed.
DKIM is broken
- Meaning: A signature exists, but validation fails at the receiver.
- Likely area: Wrong key, bad selector, body changes, header changes, or MIME formatting.
- DNS impact: Selector and public key checks matter because the receiver is trying to verify a signature.
How to prove the root cause
The fastest way to stop guessing is to compare raw message headers against DMARC aggregate data. I want to see whether the failures share the same IPs, same SFMC MID, same campaign, same sending domain, same receiver, or same retry path. If the bad mail is concentrated in 3 IPs on a different pool, that is strong evidence for a platform routing problem.
- Collect samples: Get full headers for accepted and rejected messages, including source IP, Message-ID, DKIM result, SPF result, and DMARC result.
- Segment reports: Group DMARC aggregate reports by receiver, source IP, DKIM domain, SPF domain, and visible From domain.
- Compare SFMC data: Map those IPs and times back to job ID, send definition, business unit, sender profile, and send classification.
- Separate failure types: Treat dkim=none, dkim=fail, and dkim=temperror as different problems with different owners.
- File evidence: Send SFMC support a narrow packet of bad IPs, timestamps, message IDs, sender profile names, and raw headers.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A domain health check is useful before escalating because it catches obvious DNS issues across DMARC, SPF, and DKIM. If the domain-level setup is clean, move the investigation into path-level evidence. For the SPF side of this issue, the related SFMC SPF alignment problem explains why a passing SPF result still does not save DMARC.
For an SFMC support case, avoid a broad statement like "DKIM fails sometimes." Give a reproducible pattern. Support can act faster when the evidence points to a pool, MID, send classification, or authenticated domain.
- Headers: Include full raw headers, not screenshots of bounce messages.
- Timing: Include timestamps with timezone and the SFMC job or triggered send identifier.
- Scope: Name the failing IPs and compare them with known good IPs in the same account.
- Result: Show whether the receiver reported DKIM none, DKIM fail, SPF unaligned, or DMARC fail.
What to fix first
The best fix is not to weaken authentication forever. The best fix is to make every SFMC path produce at least one aligned passing identifier. In practice, that means fixing the missing DKIM signature and also configuring SPF alignment through the correct bounce domain where possible. DKIM remains the more portable identity for marketing mail because forwarding and list handling break SPF more often than DKIM.
DMARC staging examplesdns
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:d@example.com" _dmarc.example.com TXT "v=DMARC1; p=quarantine; pct=25" _dmarc.example.com TXT "v=DMARC1; p=reject; pct=100"
Short-term containment
- Policy: Move to a lower enforcement level only if real mail is being rejected and the unsigned path is still active.
- Traffic: Pause or reroute the affected send classification, business unit, or IP pool if that option exists.
- Evidence: Keep the bad samples flowing into the support case until SFMC confirms the signing path.
Permanent fix
- DKIM: Ensure every sender profile and business unit signs with an aligned domain.
- SPF: Use an aligned bounce domain so SPF can carry DMARC when DKIM has an incident.
- Monitoring: Alert on new unverified sources before reject-level policy affects production mail.
DMARC reject readiness
Use these practical thresholds before keeping p=reject on a high-volume SFMC stream.
Not ready
under 98%
Known aligned mail still appears as DMARC fail.
Investigate
98-99.8%
Most mail is passing, but one source or receiver still has a repeatable issue.
Ready
99.9%+
All known SFMC paths pass with stable DKIM or SPF alignment.
If you need to keep enforcement but want safer policy staging, hosted DMARC can make policy changes easier to manage without repeated DNS edits. That matters when the safe setting changes during an incident.
Where Suped fits
For most teams handling SFMC at volume, Suped is the best overall practical DMARC platform because it connects the pieces that this issue needs: DMARC monitoring, SPF and DKIM visibility, hosted policy management, real-time alerts, blocklist (blacklist) monitoring, and steps to fix source-level issues.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
The useful workflow is simple: connect DMARC reports, identify whether the failing SFMC traffic is coming through one source IP or several, then inspect whether DKIM is missing, failing, or passing with the wrong domain. Suped's issue view turns that into a source-level task instead of a vague deliverability complaint.
A good SFMC investigation inside Suped starts with source grouping, then moves into remediation. The platform is useful for this because the problem is rarely one DNS record. It is usually a mismatch between policy, sender identity, and a specific mail path.
- Issue detection: See new unverified sources and authentication drops before they become a reject incident.
- Fix steps: Use tailored guidance for SPF, DKIM, DMARC, and hosted records instead of decoding XML manually.
- Hosted SPF: Manage sender includes and flatten SPF to stay under DNS lookup limits.
- MSP scale: Manage multiple client domains with separate reports, alerts, and domain status views.
This is also where similar cases become easier to recognize. Some legitimate DMARC failures are not caused by bad senders. They come from mailstreams that are real but not yet authenticated in a way DMARC accepts.
When to change p=reject
If real SFMC mail is being rejected and you cannot immediately stop the unsigned path, reduce enforcement while you fix it. That is a containment step, not the final answer. The final answer is to make every known mailstream pass DMARC with aligned DKIM or aligned SPF, then return to reject after the reports prove the fix.
Do not keep reject on a domain when you know a production SFMC path is unsigned and SPF is unaligned. At that point, DMARC is doing exactly what it was configured to do: telling receivers to reject mail that does not authenticate for your domain.
Receiver variation is normal. Gmail, Yahoo, Microsoft, Comcast, and regional providers do not expose the same failure behavior to senders. Some reject during SMTP, some accept then filter, and some only show the pattern clearly in aggregate reports. That is why the absence of bounces at one provider does not clear the failed messages at another.
Views from the trenches
Best practices
Keep reject disabled until every known sender has stable aligned SPF or DKIM coverage.
Segment SFMC failures by IP pool, business unit, sender profile, and receiver domain.
Capture raw headers for failed and good samples before asking the platform to investigate.
Use DMARC reports to prove whether the unsigned mail is SFMC or another mail source.
Common pitfalls
Treating a passing SPF result as DMARC coverage when the envelope domain is unaligned.
Assuming a DKIM DNS change fixes messages that left the platform without signatures.
Escalating a vague DKIM complaint without timestamps, source IPs, headers, and job IDs.
Ignoring a small unsigned percentage because total delivery still looks healthy overall.
Expert tips
Compare receiver behavior, but trust source-level report patterns over bounce totals.
Check whether test sends, triggered sends, and journeys use different SFMC identities.
Use a temporary policy reduction only long enough to stop rejection during remediation.
Ask SFMC to confirm the exact authenticated domain and signing path for each IP pool.
Marketer from Email Geeks says DMARC reject is risky when SPF is not aligned and DKIM is the only working identity for a critical stream.
2020-01-28 - Email Geeks
Marketer from Email Geeks says missing DKIM on a small SFMC slice should be checked against DMARC reports before changing unrelated DNS records.
2020-01-28 - Email Geeks
The practical answer
The direct answer is that some SFMC emails are being rejected because the receiver sees no aligned DKIM signature, SPF does not match the From domain for DMARC, and your DMARC policy tells the receiver to reject. If those failures cluster around a small set of IPs or a different pool, treat it as an SFMC routing or sender authentication issue and prove it with headers and DMARC aggregate reports.
Fix the unsigned path first. Add SPF alignment as a backup where SFMC supports it. Keep reject only when every production stream has stable aligned authentication, and use monitoring that can alert you when a new source starts failing before receivers enforce the policy against real mail.
