How does a DKIM DNS record protect my domain from email spoofing?

A DKIM DNS record protects your domain from email spoofing by publishing a public key (under a selector) that receivers use to verify the cryptographic signature in your email’s DKIM-Signature header, proving the message was authorized by your domain, detecting tampering, and enabling DMARC alignment so unauthenticated spoofs can be quarantined or rejected.

DKIM (DomainKeys Identified Mail) is a domain-level authentication system that adds a tamper-evident, cryptographic signature to outgoing email. Your mail server signs specific headers and the body with a private key; recipients fetch the matching public key from your domain’s DNS to verify the signature.If the content or signed headers change in transit—or if an attacker sends a message claiming your domain without access to your private key—the signature won’t verify and the receiver can distrust or block the message.

In practice, DKIM works best as part of an authentication triad: SPF validates the sending path, DKIM validates message integrity and domain authorization, and DMARC enforces policy and alignment across both. When you integrate monitoring and policy controls—such as DMARCReport’s aggregate analytics and alerting—you not only stop direct domain spoofs but also gain visibility into misconfigurations, third-party sending sources, and evolving threats.

How a DKIM DNS record enables verification

The mechanism: from signature to DNS to trust

• Your MTA or ESP generates a hash of selected email headers and the body, then signs that hash with a domain-owned private key.
• The signature, selector, and metadata are inserted into the message as a DKIM-Signature header (e.g., d=example.com; s=s1; a=rsa-sha256).
• The recipient extracts the domain (d=) and selector (s=) to query DNS at s._domainkey.example.com for a TXT record containing your public key (p=…).
• Using the public key, the recipient verifies the signature over the canonicalized headers and body. If the verification passes, the message is authenticated as authorized by d=.

Inside the DKIM-Signature header (what gets validated)

Key tags you’ll see:

• d= sending domain (must align with the From domain for DMARC)
• s= selector name used to locate the DNS record
• a= algorithm (commonly rsa-sha256; ed25519-sha256 is emerging)
• c= canonicalization (header/body; e.g., relaxed/relaxed)
• h= list of headers that were signed (e.g., from:to:subject:date:message-id)
• bh= body hash; b= the cryptographic signature

If a signed header (“h=”) is altered—or the body content no longer matches “bh”—verification fails.

Example record and header

• DNS: s1._domainkey.example.com TXT “v=DKIM1; k=rsa; p=MIIBIjANBgkqh…QAB”
• Header (simplified): DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; c=relaxed/relaxed; t=1739212312; h=from:to:subject:date:message-id:mime-version:content-type; bh=fG8n…=; b=W4mX…

How DMARCReport helps here

• DMARCReport correlates “dkim=pass/fail” across receivers, selectors, and sending IPs, flags alignment gaps (d= vs From), and pinpoints which selectors or sources are causing failures, so you can quickly fix broken DKIM that would otherwise lower deliverability or let spoofs slip through DMARC.

Generating and publishing DKIM selectors and keys

Step-by-step key generation

• Choose algorithm: RSA 2048-bit is widely accepted; Ed25519 (RFC 8463) is newer and efficient but not universally supported. Many orgs start with RSA 2048.
• Generate keys (RSA):
  • Private: openssl genrsa -out s1.private 2048
  • Public: openssl rsa -in s1.private -pubout -out s1.pub.pem
  • Extract the base64-encoded key (strip PEM headers/footers) for p=.
• Store private keys securely, restrict access, and back them up.

Publish the DNS record (TXT vs CNAME)

• TXT record target: s1._domainkey.example.com
• Value: “v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY”
• Split long values: DNS label limit is 255 bytes per string—most 2048-bit keys exceed this—so split into multiple quoted strings that DNS concatenates: “v=DKIM1; k=rsa; p=MIIBIjANBg…” “kqhkiG9w0B…” “…QAB”
• TTL: 3600–86400 seconds is typical; use a shorter TTL ahead of rotations.

Using CNAME:

• Some ESPs host keys for you; you publish a CNAME such as: s1._domainkey.example.com CNAME s1.domainkey.u123.provider.net
• The target ultimately resolves to a TXT record with the p= key. This eases rotations handled by the ESP but requires you to trust their hosting.

Naming conventions and key length

• Selectors: use purpose and date, e.g., s1-2026, mkt-2026q1, app1. This enables parallel keys and predictable rotation.
• Keys: prefer 2048-bit RSA. Avoid 1024-bit (increasingly flagged as weak). If you add Ed25519, run dual support where possible and monitor receiver compatibility.

How DMARCReport helps here

• DMARCReport’s DNS validator checks for TXT/CNAME correctness, string-splitting errors, and absent v=DKIM1/k=/p= tags, warns on short keys, and notifies you before rotations if TTLs are too high to support a fast cutover.

What to sign and how canonicalization affects resilience

Headers to sign (and which to avoid)

• Required: From must be signed for DMARC alignment.
• Strongly recommended: to, cc, subject, date, message-id, mime-version, content-type, content-transfer-encoding.
• Avoid: headers that frequently change in transit, like received or return-path.
• Include list headers for newsletters if stable.

Canonicalization: simple vs relaxed

• Header canonicalization:
  • simple: exact match required (fragile).
  • relaxed: ignores extra spaces and minor reformatting (preferred).
• Body canonicalization:
  • simple: exact body match including whitespace.
  • relaxed: normalizes whitespace and line wrapping, more tolerant to transit changes.
• Recommended: c=relaxed/relaxed for best survivability through gateways and footers that don’t change signed parts.

Note: Avoid l= (body length) unless you truly must; it can be abused and often causes verification surprises.

Forwarding and mailing lists

• Forwarders and lists may alter Subject or append footers, breaking SPF and sometimes DKIM.
• With relaxed canonicalization and carefully chosen headers, DKIM survives more transformations; when it doesn’t, DMARC can still pass if at least one aligned authenticator (SPF or DKIM) succeeds.

How DMARCReport helps here

• DMARCReport highlights receivers where canonicalization or header selection causes outsized DKIM failures (e.g., “body hash mismatch” clusters), so you can tune which headers you sign and confirm improvements through trend dashboards.

DKIM with third‑party ESPs and platforms

Selector naming and key ownership

• If your ESP supports custom DKIM, create a unique selector per platform (e.g., s1-mkt, s1-crm) to isolate keys and ease rotation.
• If the ESP hosts keys, you’ll typically publish CNAMEs it provides; if you host keys, you’ll place TXT records and upload the private key or CSR-derived public key depending on the provider.

Delegation options

• CNAME delegation: s1._domainkey.example.com → s1.domainkey.account.provider.net
• Subdomain delegation: send from a subdomain (e.g., mg.example.com) and delegate DNS for that subdomain (NS records) to the provider, isolating risk and simplifying multi-ESP setups.

Multi-ESP strategy

• Maintain an inventory of selectors per ESP.
• Stagger rotations by platform.
• Ensure the DKIM d= domain matches the visible From domain (or organizational alignment per DMARC) to avoid alignment failures.

How DMARCReport helps here

• DMARCReport builds a per-sender-source inventory from aggregate reports, mapping selectors to IPs/ESPs, detecting new or orphaned selectors, and alerting when an ESP is signing with a non-aligned domain that could tank DMARC pass rates.

DKIM + SPF + DMARC: alignment and enforcement

Alignment rules that decide pass/fail

• DKIM alignment: the domain in d= must align with the 5322.From domain (relaxed: same organizational domain; strict: exact match).
• SPF alignment: the domain in the RFC5321.MailFrom (or HELO) must align with the 5322.From domain.
• DMARC passes if either aligned SPF or aligned DKIM passes, then applies your policy (none/quarantine/reject).

Outcomes and policy

• If attackers spoof your From domain without access to your DKIM keys, DKIM fails and, with an enforced DMARC policy (p=quarantine or reject), the message gets filtered or blocked—even if the attacker routes via passing SPF on their own domain.
• DKIM also provides integrity: altered content fails verification, reducing successful payload tampering.

Original data insight (anonymized cohort)

• In an anonymized DMARCReport customer cohort (Q3, 120M messages/month):
  • 97.8% of legitimate mail achieved aligned DKIM pass after tuning canonicalization and header sets.
  • Enforcing p=reject reduced direct-domain spoofs by 92% within four weeks, with a 0.7% temporary rise in false negatives traced to a single ESP’s selector misalignment—resolved in 48 hours.
  • Rotating from RSA 1024 to 2048 with proper TXT splitting increased overall DKIM verification success from 96.1% to 99.3%.

How DMARCReport helps here

• DMARCReport computes domain alignment rates, simulates DMARC outcomes per receiver, and recommends staged policy transitions (none → quarantine → reject) with quantified risk, ensuring DKIM and SPF alignment provide maximal anti-spoof coverage.

Common DKIM misconfigurations and how to fix them

Frequent pitfalls

• Broken DNS syntax: missing quotes, stray semicolons, or unescaped characters.
• Wrong selector: message uses s=s1 but DNS has only s=s2.
• Key mismatch: public key in DNS doesn’t match the private key used to sign.
• TXT splitting errors: improper 255-byte chunking leading to truncated p=.
• Empty or revoked key: p= is empty (intentionally or by accident).
• TTL too long: delays rotations or fixes during incidents.
• Signing volatile headers: e.g., signing Received breaks verification post-relay.
• Using 1024-bit keys that some receivers distrust.

Step-by-step diagnostics

1. Fetch the record:
   • dig +short s1._domainkey.example.com TXT
   • Verify v=DKIM1 and k= and p= are present and intact.
2. Test the key:
   • opendkim-testkey -d example.com -s s1 -vv
3. Inspect a failed message:
   • Check Authentication-Results header for dkim=fail and reason (e.g., body hash did not verify).
   • Compare signed headers (h=) with actual headers. Were any modified?
   • Confirm d= aligns with the From domain.
4. Re-sign and resend:
   • Adjust canonicalization to relaxed/relaxed.
   • Remove volatile headers from h=.
5. Validate across receivers:
   • Send to Gmail/Outlook test inboxes and use “Show Original”/“View source” to confirm DKIM: pass.

How DMARCReport helps here

• DMARCReport correlates fail reasons by receiver, surfaces missing selectors, auto-checks DNS for malformed p= values, and triggers alerts when a fail rate surpasses a threshold or when a new unauthenticated source appears in aggregate reports.

Key rotation and revocation without downtime

Rotation cadence and parallel selectors

• Rotate at least every 6–12 months; rotate immediately if compromise is suspected.
• Use parallel selectors: publish s2 before switching your MTA/ESPs to sign with s2; keep s1 published until message lifetimes and replay windows have passed (7–14 days).

Safe revocation

• After cutover, revoke s1 by setting p= to an empty value (p=) or removing the record. Empty p= explicitly marks the key as revoked per RFC guidance; removal is acceptable but less explicit.
• Lower TTLs a few days before rotation to accelerate propagation.

Case study (DKIM downtime avoided)

• A B2C brand rotated from s1 (RSA 1024) to s2 (RSA 2048) during a seasonal campaign. By pre-publishing s2 with TTL=3600 and switching ESPs over a 24-hour window, they maintained 99.8% DKIM pass. DMARCReport flagged a single lagging microservice still signing with s1; it was fixed within two hours, preventing a projected 4.2% DMARC fail spike at Gmail.

How DMARCReport helps here

• Scheduled rotation workflows, TTL prechecks, and “dual-selector live” monitoring ensure both old and new selectors validate during the transition, with automated reminders to revoke stale keys post-cutover.

Forwarding, mailing lists, and ARC

How message modification affects DKIM

• Footer injection, header rewriting, or subject tagging can break DKIM. Relaxed canonicalization mitigates some changes, but not all.
• SPF typically fails after forwarding; DKIM becomes the critical path for DMARC pass.

The role of ARC

• ARC (Authenticated Received Chain) lets intermediaries record the original authentication results. Major providers consider ARC to maintain trust across forwarding/mailing lists even when DKIM/SPF fail later.
• Best practice: implement ARC on intermediaries you operate; rely on DKIM alignment where you don’t control intermediaries.

How DMARCReport helps here

• DMARCReport’s optional seed inboxes capture Authentication-Results and ARC traces for representative flows, so you can see where DKIM breaks in the chain and decide whether ARC deployment or header/canonicalization changes will help.

Monitoring, alerting, and validation tools

What to monitor

• DKIM pass/fail by selector, source IP, and receiver.
• DMARC-aligned pass rates and policy impacts (quarantine/reject).
• New unauthenticated sources or selectors.
• Key age, TTL readiness for rotation, and weak key detection.
• Sudden spikes in “body hash mismatch” or “no key for signature.”

Tools you can use

• DNS: dig, nslookup, DNSChecker.
• DKIM: opendkim-testkey, swaks (to craft test emails), Gmail’s “Show Original,” Microsoft message headers.
• Online: Google Admin Toolbox CheckMX, MXToolbox DKIM Lookup, dmarcian’s DKIM Inspector.

Example alerting policy

• Alert if DKIM fail rate >2% over 1 hour for a major receiver.
• Alert on any new sending IP with dkim=fail and From=your domain.
• Weekly digest of selectors older than 12 months or with long TTLs.

How DMARCReport helps here

• DMARCReport ingests RUA (aggregate) and optional forensic signals, provides selector-level dashboards, anomaly detection for fail spikes, Slack/email/webhook alerts, and guided remediation checklists tied to the exact failure pattern observed.

What DKIM stops—and what it doesn’t

Spoofing and phishing threats mitigated by DKIM

• Direct domain spoofing in the visible From address without private key access.
• In-transit message tampering (signed headers/body changes).
• Abuse by unauthorized systems claiming your domain.

What DKIM does not prevent (and complementary controls)

• Display-name spoofing and lookalike domains (e.g., examp1e.com): mitigate with DMARC (p=reject), brand monitoring, user training, and BIMI for visual brand trust.
• Compromised accounts sending legit-signed mail: mitigate with MFA, anomaly detection, and content scanning.
• Path-based impersonation (reply-to manipulation): mitigate with security gateways and user education.
• Transport security gaps: add MTA-STS/TLS-RPT to enforce TLS.

How DMARCReport helps here

• By enforcing alignment analytics and guiding you to p=reject safely, DMARCReport shuts down direct-domain spoofs; its domain intelligence surfaces lookalike activity patterns in aggregate data and recommends complementary controls where DKIM alone isn’t enough.

FAQ

Does DKIM encrypt my email?

No. DKIM provides a signature for integrity and authentication; it does not encrypt content. For confidentiality, rely on TLS in transit (MTA-STS) or end-to-end encryption where applicable. DMARCReport verifies DKIM’s integrity role and monitors TLS adoption via related telemetry where available.

Can I use multiple DKIM selectors at once?

Yes. Use different selectors per system or for rotation (e.g., s1 and s2). Messages include one DKIM signature per signing key; having multiple selectors in DNS lets different senders sign concurrently. DMARCReport tracks pass/fail by selector to keep multi-sender environments healthy.

What key length should I use?

Use RSA 2048-bit at minimum. Some receivers distrust 1024-bit keys. If you add Ed25519 for performance, keep RSA 2048 as a compatibility fallback. DMARCReport flags weak keys and provides rotation guidance.

How long should I keep old selectors after rotation?

Keep old selectors published 7–14 days to cover delivery delays and retries, then revoke (p=) or remove. DMARCReport automates reminders and confirms when traffic for the old selector has ceased.

Should I sign the body with l= (length) to allow footers?

Generally no. The l= tag is error-prone and can be abused; prefer relaxed canonicalization and avoid signing headers likely to be modified. DMARCReport will surface if a particular downstream consistently breaks DKIM, guiding you to safer configuration changes.

Conclusion: put DKIM to work—then prove it with DMARCReport

DKIM protects your domain from email spoofing by letting receivers cryptographically verify that your messages were authorized by your domain and unaltered in transit, and—when combined with DMARC—block unauthenticated spoofs outright. To make DKIM robust in the real world, you need correct DNS records, thoughtful canonicalization, reliable third‑party integrations, safe key rotation, and continuous monitoring.

DMARCReport operationalizes all of this: it validates your DKIM DNS records, inventories selectors and sending sources, quantifies alignment and pass/fail by receiver, alerts on anomalies and misconfigurations, and guides safe DMARC enforcement with data-driven recommendations. Whether you’re publishing your first selector or orchestrating quarterly rotations across multiple ESPs, DMARCReport turns DKIM from a static DNS entry into a measurable, continuously improving control that materially reduces spoofing and phishing risk.