DKIM Explained

6 Mins read

πŸ” DKIM β€” DomainKeys Identified Mail

DomainKeys Identified Mail (DKIM) is an email authentication method that uses digital signatures to prove that an email was:

  • Authorised by the owner of the sending domain
  • Not altered in transit

DKIM uses public-key cryptography: the sender’s mail server signs parts of the message with a private key, and the recipient verifies the signature using a public key published in the sender’s DNS.


DKIM

🎯 Purpose of DKIM

  • Verifies message integrity
  • Confirms that the email was sent by a trusted domain
  • Enables DMARC alignment
  • Helps reduce spoofing and increases deliverability
  • Used by major providers (e.g. Google, Microsoft, Yahoo) to score email trustworthiness

πŸ”‘ How DKIM Works (Conceptually)

  1. The sender’s mail server signs selected headers (e.g. From, Subject) and a hash of the body using its private key
  2. This signature is added to the DKIM-Signature header
  3. The recipient retrieves the public key from DNS (selector._domainkey.domain.com)
  4. The recipient mail server uses this key to verify the signature
  5. If valid, the email is trusted to be from the claimed domain and untampered

🧬 Anatomy of a DKIM Signature

DKIM adds a DKIM-Signature: header to the message.

πŸ“₯ Example

DKIM-Signature: v=1; a=rsa-sha256; d=example.com;
 s=selector1; c=relaxed/relaxed;
 h=from:to:subject:date;
 bh=base64_body_hash;
 b=base64_signature_data;

πŸ“– Field Breakdown

FieldMeaning
v=1DKIM version
a=Signing algorithm (usually rsa-sha256)
d=Domain signing the message
s=Selector used to locate public key in DNS
c=Canonicalisation rules (for header/body formatting)
h=Headers included in the signature
bh=Base64-encoded body hash
b=Actual DKIM signature of the headers + body hash

🧷 Publishing the DKIM Public Key (DNS Record)

The public key is published in a DNS TXT record at:

selector1._domainkey.example.com

πŸ“₯ Example DNS TXT Record

Name: selector1._domainkey.example.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkq...AQAB
FieldMeaning
v=DKIM1DKIM version
k=rsaKey type
p=Public key (Base64-encoded)

πŸ› οΈ How to Implement DKIM Safely

  1. Generate a key pair

    • Use a secure tool to generate a 1024- or 2048-bit RSA key pair
    • Keep the private key secure on your sending infrastructure
  2. Publish the public key

    • Add it as a TXT record under selector._domainkey.yourdomain.com
  3. Configure your mail server to sign messages

    • Apply DKIM signing to all outbound email
    • Sign at least From, To, Subject, and Date headers
  4. Test DKIM

  5. Rotate keys periodically

    • Best practice: rotate selectors every 6–12 months
    • Use new selectors (e.g. selector2) to allow overlapping validation during transitions

⚠️ Common Pitfalls

  • ❌ No DKIM record in DNS, or wrong selector
  • ❌ DNS TXT record too long (>255 chars per string) β€” split it into quoted segments
  • ⚠️ Private key exposed or improperly stored
  • ❌ Signing a domain that differs from the visible From: domain β€” breaks DMARC alignment
  • ⚠️ Failing to rotate keys or remove old ones

Real-World Gotchas β€” Where DKIM Can Fail Unexpectedly

Even with correct DKIM setup, organisations can run into unexpected failures caused by overlooked services, improper integrations, or alignment issues that affect DMARC.

1. Web Form Autoresponders

Many websites send autoresponse emails from forms or booking systems. These often use your domain in the From: address (e.g. [email protected]), but are sent via:

  • The web server’s local mail system (e.g. sendmail, phpmail())
  • CMS plugins (e.g. WordPress contact forms)
  • An SMTP relay without DKIM signing

Risk:
The message may not be DKIM-signed at all, or may sign with a d= domain that doesn’t align with the From: domain β€” causing DMARC failures.

Mitigation:

  • Route all email through a DKIM-enabled mail relay (e.g. Microsoft 365, SendGrid, Mailgun)
  • Avoid letting unauthenticated services send mail directly
  • Ensure the DKIM d= domain aligns with your branded From: domain

2. Third-Party Platforms Not Properly Configured

CRMs, marketing platforms, or SaaS tools (e.g. Mailchimp, Salesforce, HubSpot) often send emails on your behalf. These tools may not use your domain by default, or require manual DKIM setup.

Risk:
Emails pass DKIM (signed by the vendor), but the d= domain is not yours β€” breaking DMARC alignment.

Mitigation:

  • Configure custom DKIM selectors provided by each platform
  • Publish the required DNS TXT records under your domain
  • Test messages to confirm that:
    • d= matches your domain
    • DKIM passes
    • DMARC aligns

3. Forgotten Subdomains or Legacy Services

Legacy systems or forgotten services often send unsigned or misaligned email:

  • Ticketing platforms ([email protected])
  • Alerting systems (IoT, printers, fax/email gateways)
  • Internal tools sending through unverified SMTP relays

Risk:
These systems send email from your domain without valid DKIM signatures, leading to delivery issues or DMARC failures.

Mitigation:

  • Audit all outbound email sources
  • Centralise mail delivery via trusted, signed SMTP relays
  • Configure subdomain-specific DKIM and DMARC records as needed (e.g. _domainkey.helpdesk.yourdomain.com)

4. Mail Forwarding or Mailing Lists

Forwarded emails often get modified in transit (e.g. headers changed, footers added), especially through:

  • University or ISP forwarding services
  • Google Groups or mailing lists

Risk:
Even if the original message had a valid DKIM signature, it may fail after modification due to body hash or header changes.

Mitigation:

  • Use relaxed canonicalisation (c=relaxed/relaxed) in DKIM configs
  • Combine SPF, DKIM, and DMARC for resilience
  • For complex environments, consider supporting ARC (Authenticated Received Chain)

5. Stale or Conflicting DKIM Selectors

Some providers or developers may reuse generic selectors like selector1, which clashes with your existing mail infrastructure.

Risk:
DKIM signatures may:

  • Reference an old or invalid key
  • Create ambiguity in logs and DMARC reports
  • Unintentionally pass with stale keys

Mitigation:

  • Assign unique selectors per provider (e.g. mc01, sf2024, o365)
  • Rotate keys regularly (every 6–12 months)
  • Remove deprecated TXT records when offboarding providers

🀝 DKIM in Context β€” SPF, DKIM, and DMARC

DKIM alone does not block spoofing. It must be used with DMARC, which:

  • Aligns the d= domain with the visible From: address
  • Tells receiving mail servers how to handle failures
  • Provides feedback via forensic and aggregate reports
ProtocolWhat it DoesWeakness Alone
SPFAuthenticates sending serverDoesn’t sign content, can be bypassed via forwarders
DKIMSigns headers + body for integrity and domain trustDoesn’t protect β€œFrom” spoofing without DMARC
DMARCEnforces policy + ensures domain alignmentRequires SPF and/or DKIM to pass with alignment

βœ… DKIM is essential for email integrity and trust, and critical for enabling DMARC to enforce protection.


βœ… TL;DR

  • DKIM uses public-key cryptography to verify an email is untampered and domain-authorised
  • The public key is published in DNS (selector._domainkey.domain.com)
  • DKIM is required for strong DMARC policy enforcement
  • Used properly, DKIM improves deliverability and protects against spoofing and tampering

πŸ”œ Next: πŸ“› DMARC β€” Domain-based Message Authentication, Reporting & Conformance