What Is DKIM and Why Does DMARC Depend on It?

Introduction

DKIM — DomainKeys Identified Mail — is the cryptographic half of email authentication. Where SPF lists which IPs can send for your domain, DKIM proves that a specific message was sent and signed by an authorized server. It's the more durable of the two mechanisms: DKIM signatures survive forwarding, mailing lists, and most other transit complications that break SPF.

This article explains how DKIM actually works, why DMARC depends on it, and what to do to deploy it cleanly.

Why this topic matters

If you're going to bet your domain protection on one of SPF or DKIM, bet on DKIM. It survives more transit scenarios, proves more about each message, and aligns more naturally with the visible From domain. Why SPF alone is not enough is one side of that argument; DKIM as the load-bearing layer is the other.

How DKIM actually works

When a sending server sends a message:

1. It hashes the message (headers + body) and signs the hash with a private key.
2. The signature is added to the email as a DKIM-Signature header.
3. The header includes the signing domain (d=) and a selector (s=).

When a receiving server gets the message:

1. It looks up the public key at <selector>._domainkey.<signing-domain> in DNS.
2. It verifies the signature against the message and the public key.
3. Result: pass or fail.

If the signature verifies, the receiver knows the message originated from a server holding the signing domain's private key — strong evidence of authenticity.

How DKIM feeds DMARC

DMARC requires that DKIM pass AND that the d= domain align with the visible From header. Two senders illustrate the alignment piece:

• Sender A signs with d=yourdomain.com. From header is [email protected]. DKIM aligns. DMARC pass via DKIM.
• Sender B signs with d=mailchimp.com. From header is [email protected]. DKIM technically passes (the signature is valid), but the signing domain doesn't align with From. DMARC fails on the DKIM side.

This is why custom DKIM matters. SaaS senders that sign with their own domain by default produce technically-valid signatures that don't satisfy DMARC. Enabling custom DKIM at the platform makes them sign with your domain instead.

Why DKIM survives where SPF breaks

DKIM doesn't depend on the connecting IP. The signature is embedded in the message; as long as the message reaches the receiver intact, the signature can be verified. This means:

• Forwarded mail still passes DKIM because the signature travels with the message.
• Mailing-list mail can pass DKIM if the list software re-signs the message (modern list software handles this).
• Cross-region routing doesn't affect DKIM because no IP is involved.

Why DKIM alone is not enough covers the inverse — DKIM has its own limits — but for forwarding survival, DKIM wins decisively.

Step-by-step approach to setting up DKIM

1. Identify your sending platform. Microsoft 365, Google Workspace, Mailchimp, etc.
2. Enable DKIM at the platform. Each has a documented "DKIM setup" path.
3. Publish the public key in your DNS. The platform gives you a TXT record value; you publish it at <selector>._domainkey.<your-domain>.
4. Verify the DKIM signature. Send a test message; check the DKIM-Signature header.
5. Confirm via DMARC reports. Aggregate reports show DKIM pass rate per sender.

For multi-sender environments, repeat per platform with a distinct selector each.

Best practices

• Always use custom DKIM for senders that support it. Default platform DKIM (using their domain) doesn't align with DMARC.
• Use distinct selectors per sender. marketing._domainkey.yourdomain.com, transactional._domainkey.yourdomain.com. Makes rotation easier.
• Rotate keys periodically. Annual rotation is reasonable. How to rotate DKIM keys safely covers the procedure.
• Use 2048-bit keys minimum. 1024-bit is breakable; 2048 is the modern minimum.
• Don't share private keys. Each sending platform should have its own key.

Recommended next step

If you have any senders not yet using custom DKIM, enable it now. Each one is a future DMARC alignment failure. The platform-specific guides cover the major SaaS senders: Microsoft 365, Google Workspace, Mailchimp, SendGrid.

FAQ

What's a DKIM selector?

A label that lets you have multiple DKIM keys for the same domain. The receiver uses it to find the right public key. DKIM selector explained has the detail.

Why does my DKIM signature have d=mailchimp.com instead of my domain?

You haven't enabled custom DKIM at Mailchimp. By default, SaaS senders sign with their own domain. Switch to custom DKIM to sign with yours.

Can DKIM be forged?

The cryptographic signature can't be forged without the private key. But a message can be sent without a DKIM signature, in which case it just fails DKIM. The point is that the receiver can distinguish — they know a missing signature is suspicious.

Do small businesses need DKIM?

Yes. Every legitimate sender should be signing. Microsoft 365 and Google Workspace make this near-automatic; SaaS senders require explicit setup per platform.

How do I know if my DKIM is working?

Send a test message to a Gmail account; view the original. Look for DKIM-Signature and dkim=pass in the authentication results.

Final thoughts

DKIM is the more durable half of email authentication. SPF tells receivers which IPs are allowed; DKIM proves the message itself is legitimate. For a domain serious about DMARC, custom DKIM on every sender is the goal — and once achieved, the rest of the rollout becomes substantially easier.

The pattern that scales: SPF as the IP backstop, DKIM as the primary authentication mechanism, DMARC tying them together. Each layer does what the others can't.