π 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.

π― 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)
- The senderβs mail server signs selected headers (e.g.
From,Subject) and a hash of the body using its private key - This signature is added to the
DKIM-Signatureheader - The recipient retrieves the public key from DNS (
selector._domainkey.domain.com) - The recipient mail server uses this key to verify the signature
- 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
| Field | Meaning |
|---|---|
v=1 | DKIM 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
| Field | Meaning |
|---|---|
v=DKIM1 | DKIM version |
k=rsa | Key type |
p= | Public key (Base64-encoded) |
π οΈ How to Implement DKIM Safely
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
Publish the public key
- Add it as a TXT record under
selector._domainkey.yourdomain.com
- Add it as a TXT record under
Configure your mail server to sign messages
- Apply DKIM signing to all outbound email
- Sign at least
From,To,Subject, andDateheaders
Test DKIM
- Use tools like:
- DKIMCore: https://dkimcore.org/tools/keycheck.html
- MxToolbox DKIM Lookup: https://mxtoolbox.com/dkim.aspx
- Or:
dig selector1._domainkey.example.com TXT
- Use tools like:
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 brandedFrom: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 visibleFrom:address - Tells receiving mail servers how to handle failures
- Provides feedback via forensic and aggregate reports
| Protocol | What it Does | Weakness Alone |
|---|---|---|
| SPF | Authenticates sending server | Doesnβt sign content, can be bypassed via forwarders |
| DKIM | Signs headers + body for integrity and domain trust | Doesnβt protect βFromβ spoofing without DMARC |
| DMARC | Enforces policy + ensures domain alignment | Requires 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