DKIM Configuration

What Is DKIM (DomainKeys Identified Mail) and How Does It Secure Your Email?

April 04, 2026 • By DMARCFlow Team • 9 min read

When an email arrives in your inbox claiming to be from your bank, your software vendor, or your CEO, how does the receiving server know it is genuine? SPF checks whether the sending IP is authorised by the domain owner. But SPF breaks when email is forwarded, and it only covers the envelope — not the message itself. DomainKeys Identified Mail, known as DKIM, takes a different and more robust approach: it uses cryptographic signatures to prove that specific parts of an email — the headers and body — were authorised by the owner of a particular domain and have not been modified in transit.

DKIM is one of the three pillars of modern email authentication alongside SPF and DMARC. Understanding how it works, what its failure modes mean, and how it interacts with DMARC is essential for any organisation that wants to protect its domain from spoofing and impersonation.

What Is DKIM?

DomainKeys Identified Mail is an email authentication standard defined in RFC 6376. It allows the sending mail server to attach a cryptographic signature to an email. The signature is computed over selected headers and the message body using a private key held by the sender. The corresponding public key is published in DNS under a special subdomain. When a receiving mail server gets the email, it retrieves the public key and uses it to verify the signature.

If the signature is valid, the receiving server knows two things:

1. The email was signed by someone who controls the private key for the signing domain.
2. The signed portions of the email — headers and body — have not been altered since signing.

Crucially, DKIM operates at the message level, not the envelope level like SPF. This means it survives email forwarding: when a forwarder passes the message on, the DKIM signature remains in the headers and can still be verified by the final recipient's mail server. This makes DKIM the more resilient of the two SPF/DKIM pair for indirect mail flows.

How DKIM Works – Signing and Verification

The DKIM process has two sides: signing at the sending server and verification at the receiving server.

Signing (outbound):

1. The sending mail server selects which headers to include in the signature — typically From, Subject, Date, To, and others — and canonicalises them according to a defined algorithm (simple or relaxed).
2. The server computes a hash of the message body and includes it in the signature.
3. It signs the combined data using the private key associated with a named selector for the domain.
4. The resulting signature is added to the email as a DKIM-Signature header.

Verification (inbound):

1. The receiving server reads the DKIM-Signature header and extracts the signing domain (d=) and selector (s=).
2. It performs a DNS TXT lookup at <selector>._domainkey.<domain> to retrieve the public key.
3. It re-computes the hash of the headers and body as described in the signature and verifies the signature against the public key.
4. If the signature matches and the body hash is correct, the result is pass. Any mismatch — modified headers, modified body, wrong key — results in fail or another non-pass result.

Anatomy of a DKIM-Signature Header

A DKIM-Signature header looks like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=mail2024;
  h=from:to:subject:date:message-id; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=abc123...base64encodedSignature...==

The key tags are:

The DNS record for the public key is published at <selector>._domainkey.<domain> as a TXT record, for example:

mail2024._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

DKIM Result Types: pass, fail, permerror, temperror, and more

The DKIM verification process can produce six distinct results. Understanding each is important because they have different implications for DMARC:

Only pass can satisfy DMARC DKIM — and only if the signing domain also aligns with the Header-From address.

DKIM and DMARC – Why Alignment Is the Key

A DKIM signature verifying successfully is necessary but not sufficient for DMARC. DMARC adds one more requirement: alignment. The signing domain in the d= tag of the DKIM-Signature must align with the domain in the visible Header-From address — the one your recipients see in their email client.

Two alignment modes are available, configured via the adkim tag in your DMARC record:

• Relaxed alignment (adkim=r, the default) — the organisational domains must match. A signature from mail.example.com aligns with example.com in the From address.
• Strict alignment (adkim=s) — the domains must be identical. mail.example.com does not align with example.com.

This distinction matters in practice. Many email service providers sign outgoing messages with their own domain in the d= tag rather than yours. The DKIM signature verifies — the message has not been tampered with — but the signing domain is mailchimp.com or sendgrid.net, not yourdomain.com. That means DMARC DKIM fails despite a cryptographically valid signature.

The solution is to configure DKIM signing with your own domain at each ESP. This typically involves generating a key pair, publishing the public key in your DNS, and authorising the ESP to use the corresponding private key when signing messages on your behalf.

How DMARCFlow Explains DKIM Alignment in DMARC Reports

DMARC aggregate reports include raw DKIM authentication results — domain, selector, and result — for every message batch from every sending source. DMARCFlow analyses this data record by record and maps each outcome to one of four clear DKIM insight scenarios:

For each record, DMARCFlow also surfaces the individual raw DKIM results — the signing domain, selector, and raw result (pass / fail / permerror / temperror / neutral / none) — alongside a plain-language explanation of what each result means and whether it can contribute to DMARC. This transforms opaque XML data into actionable intelligence.

DKIM vs. SPF – Complementary, Not Competing

SPF and DKIM solve related but different problems, and their weaknesses complement each other:

DMARC only requires that either SPF or DKIM passes and aligns. In practice, configuring both provides redundancy: if SPF breaks at a forwarder, DKIM can still satisfy DMARC. If DKIM is not set up at an ESP, SPF alignment may still save the day. The most resilient configuration has both properly aligned.

Common DKIM Problems and How to Fix Them

• No DKIM signature at all. Many organisations add SPF but never configure DKIM signing, leaving them entirely dependent on SPF for DMARC. Any ESP that does not support DKIM — or where DKIM has not been enabled — will produce messages with no DKIM result. Fix: enable DKIM signing at every sending platform and publish the corresponding public key in DNS.
• Signing with the ESP's domain, not yours. The most common cause of "pass but not aligned": your ESP signs with its own domain by default. Fix: configure a custom DKIM identity at the ESP. This typically means generating a key pair in the ESP's control panel, adding a DNS TXT record for the provided selector, and activating domain-aligned signing.
• Body modification breaking the signature. Mailing lists, forwarding services, or security gateways that add footers, modify Subject lines, or alter headers can invalidate DKIM signatures. Using relaxed canonicalisation (c=relaxed/relaxed) tolerates minor whitespace changes but cannot survive structural modifications. Consider using DKIM with only the most stable headers in h=, or coordinate with list managers to use ARC (Authenticated Received Chain).
• Expired or revoked keys. If a private key is compromised or you revoke the DNS public key record before the TTL expires, in-flight messages may fail DKIM. Plan key rotation carefully (see below) and keep old key records live for the duration of any messages that may still be in transit.
• permerror on every message. A permanent error usually means the DKIM-Signature header is malformed, required tags are missing, or the DNS public key record is invalid or absent. Verify the record at <selector>._domainkey.<domain> with a DNS lookup tool and compare it to what your ESP published.
• temperror intermittently. Transient DNS failures during key retrieval cause temperror. These are not cryptographic failures and should resolve on retry. If they are persistent, investigate DNS health at your registrar or consider a secondary DNS provider.
• Wrong selector in DNS. If the selector in the DKIM-Signature header does not match any published DNS record, verification will fail. Ensure the selector name configured in your signing platform exactly matches the subdomain you published the key under.

DKIM Key Rotation – Why and How

DKIM private keys are long-lived secrets. Unlike SPF records, which are public, the private key must be kept confidential. If it is ever leaked or compromised, an attacker can sign messages with your domain's identity. Key rotation — periodically replacing old key pairs with new ones — limits the damage window of a compromised key.

Best-practice rotation looks like this:

1. Generate a new key pair for a new selector (e.g. mail2026).
2. Publish the new public key in DNS at the new selector subdomain.
3. Wait for DNS propagation — typically a few minutes to an hour depending on TTL.
4. Switch your signing platform to use the new private key and selector.
5. Keep the old DNS record live for at least 48–72 hours (or longer if messages may be delayed) to allow in-flight messages signed with the old key to still verify successfully.
6. Remove the old DNS record after the grace period.

Many organisations rotate annually. Security-conscious organisations rotate every 3–6 months. If you suspect a key compromise, rotate immediately following the steps above but compress the timeline.

How DMARCFlow Turns DKIM Complexity Into Clarity

Managing DKIM across multiple ESPs, domains, and selectors — while monitoring for failures, tracking alignment, and knowing when to rotate keys — is a significant operational burden. DMARCFlow is built to absorb that complexity and give you a clear, actionable view of your DKIM posture.

Here is what DMARCFlow brings to DKIM specifically:

• Per-record DKIM insight analysis. Every record in every DMARC aggregate report is individually analysed. For each record, DMARCFlow identifies all raw DKIM results (domain, selector, result), determines which of the four DMARC DKIM scenarios applies, and explains the outcome in plain language. You see exactly which signing domain and selector satisfied DMARC DKIM — or exactly why it failed.
• Alignment mode awareness. DMARCFlow reads the adkim tag from your actual DMARC policy and evaluates every DKIM result against the correct alignment mode — relaxed or strict. The analysis always reflects your real configuration, not a generic assumption.
• Multiple-signature support. An email can carry more than one DKIM signature — for example, one from your domain and one from the ESP. DMARCFlow evaluates all of them and correctly determines whether at least one provides an aligned pass, which is what DMARC requires.
• Authentication failure analysis. When DKIM failures appear across many records, DMARCFlow groups them, calculates failure rates by sending source, and surfaces the top failing IP addresses — so you know where to investigate first.
• Security score with DKIM component. DMARCFlow calculates a security score out of 100 for your domain. The breakdown shows exactly how your DKIM posture contributes to the overall score alongside SPF, policy enforcement, coverage, and reporting. A domain without DKIM alignment will be held back from a high score, and the breakdown tells you why.
• Maturity level tracking. Domains without any DKIM alignment are capped at lower maturity levels. DMARCFlow's maturity model shows you precisely what is blocking progression and what configuring DKIM alignment would unlock.
• Recommendations engine. If DKIM is failing due to an unaligned signing domain at a specific ESP, DMARCFlow tells you what to fix and how — including guidance on publishing a custom selector for that platform.
• GDPR-compliant, EU-hosted. All report data is processed and stored exclusively in the European Union. No personal data is retained. Essential for GDPR-regulated organisations.

Conclusion

DKIM is a powerful and resilient email authentication mechanism. By attaching a cryptographic signature to your outgoing messages, it proves that specific parts of the email were authorised by a holder of your domain's private key and have not been altered in transit. Unlike SPF, DKIM survives email forwarding — making it indispensable for organisations that rely on mailing lists, forwarders, or indirect sending paths.

But a DKIM pass alone is not enough for DMARC. The signing domain must align with the Header-From address under your configured alignment mode. The four DKIM insight scenarios — from an aligned signature pass to no DKIM results at all — represent the full spectrum of what you will encounter in DMARC reports. Knowing which scenario applies to each of your sending sources is what enables you to take the right corrective action.

DMARCFlow makes that diagnosis fast and accurate. It analyses every DKIM result in every DMARC report, maps it to a clear scenario, and gives you the recommendations to act on it — whether that means publishing a custom selector at an ESP, rotating a key, or investigating a persistent permerror. Pair that with the security score, maturity tracking, and EU-compliant data handling, and you have a platform designed to take you from "DKIM exists somewhere" to "DKIM is fully aligned and actively protecting my domain."