Introduction
DKIM is often called the more durable email authentication mechanism — and it is, compared to SPF. But DKIM alone has its own structural limits that prevent it from being a complete defense against spoofing. This article walks them and explains why the modern stack uses DKIM under DMARC, not in place of it.
Why this topic matters
A subset of teams skip SPF and DMARC, relying on DKIM as the sole authentication mechanism. The reasoning sounds plausible — DKIM is cryptographic, it survives forwarding, it binds to the message. In practice, three limits mean DKIM alone leaves your domain spoofable.
Limit 1: DKIM doesn't say who's supposed to sign
A DKIM signature proves a message was signed by someone with the private key. It doesn't say "only this entity should be signing for this domain."
An attacker can simply send mail without a DKIM signature. The receiver sees dkim=none — which, by itself, isn't a strong signal. Plenty of legitimate mail is unsigned in the wild. Without a policy layer saying "treat unsigned mail from this domain with suspicion," receivers can't act on the absence of a signature.
DMARC is what fills this. It declares: "For my domain, mail must be DKIM-signed (or SPF-aligned) — failures should be quarantined/rejected." That's the missing instruction.
Limit 2: DKIM doesn't enforce alignment by itself
A message can carry a valid DKIM signature where the signing domain (d=) doesn't match the visible From. Without DMARC's alignment check, receivers see "dkim=pass" and treat it as authenticated — even though the signing domain isn't yours.
This is exactly how SaaS senders with default DKIM (signing with their own domain) produce technically-valid signatures that don't protect your domain. DMARC's alignment requirement closes this.
Limit 3: DKIM doesn't tell receivers what to do with failures
DKIM has no policy framework. A DKIM failure is just data; what the receiver does with it depends on their own heuristics. Some receivers ignore DKIM failures; some downweight them; some quarantine.
DMARC publishes your preference: monitor, quarantine, or reject. Receivers can choose to ignore your DMARC policy too (rarely happens with major providers), but at least you've stated the intent. DKIM alone has no equivalent.
What SPF and DMARC add
The full stack covers each layer's gaps:
- DKIM signs and binds to message content. Survives forwarding.
- SPF lists allowed IPs. Backstops DKIM for senders that don't sign.
- DMARC publishes the alignment requirement and the policy. Closes the loops both leave open.
Together they produce a state where receivers know what to expect from your domain (DMARC), have two independent ways to authenticate (SPF and DKIM), and act predictably when authentication fails (the published policy).
Step-by-step approach to layering correctly
- Publish SPF for the IPs that send your transactional mail.
- Enable DKIM with custom signing at every sender. Each platform, distinct selector.
- Publish DMARC at
p=noneinitially. - Watch aggregate reports. Confirm both SPF and DKIM pass for legitimate senders.
- Tighten DMARC policy through quarantine to reject.
Each layer covers what the others can't.
Best practices
- Don't treat DKIM as a standalone control. It's necessary, not sufficient.
- Always pair DKIM with DMARC. The policy layer is what produces actionable enforcement.
- Use custom DKIM at every SaaS sender. Platform-default DKIM doesn't align with DMARC.
- Watch alignment in reports, not just raw DKIM pass. Aggregate reports show alignment-aware results.
- Rotate DKIM keys periodically. How to rotate DKIM keys safely.
Recommended next step
If you have DKIM but no DMARC, publish DMARC at p=none today. The monitoring data alone will show you which legitimate senders are aligned and which aren't — the foundation for moving to enforcement.
FAQ
Can DKIM be forged?
The signature can't be forged without the private key. But a message can be sent without a signature — which is what attackers do.
What does dkim=none mean?
The message had no DKIM signature. By itself this isn't conclusive; DMARC tells receivers how to interpret it.
Why isn't DKIM-pass enough?
Because DKIM-pass doesn't require the signing domain to match the visible From. DMARC's alignment requirement closes this.
Should I disable SPF if I have DKIM?
No. DMARC needs at least one to pass. Both add resilience.
What's the simplest fix if I have DKIM-only today?
Publish DMARC at p=none with reporting. The data will guide the next steps.
Final thoughts
DKIM is the cryptographic foundation of email authentication. It's structurally limited as a standalone control because it can't speak to policy or alignment. Pair DKIM with SPF and DMARC and you have a stack that produces real protection.
The right mental model: DKIM signs, SPF allows, DMARC commands. Drop any one and the others can't compensate.