DKIM (DomainKeys Identified Mail)

DKIM (DomainKeys Identified Mail) is an email authentication standard that lets a sending domain cryptographically sign outgoing messages so recipients can verify the message genuinely came from that domain and was not altered in transit. The sending mail server attaches a digital signature to each message header; the receiving server fetches the matching public key from the sender's DNS and validates the signature. DKIM is one of the three pillars of modern email authentication, alongside SPF and DMARC.

Why DKIM matters

Without authentication, anyone can forge the From: address on an email. DKIM raises the cost of spoofing your domain in phishing and business-email-compromise (BEC) attacks, because an attacker cannot produce a valid signature without your private key. Just as important, DKIM is a prerequisite for DMARC enforcement: DMARC only reaches a reject or quarantine policy when SPF or DKIM passes and aligns with the visible sender domain. Major mailbox providers now require DKIM for bulk senders, so a missing or broken record also hurts deliverability.

How DKIM works

1. The sender generates a public/private key pair. The private key stays on the mail server; the public key is published in DNS as a TXT record at selector._domainkey.yourdomain.com.
2. When sending, the server hashes selected headers and the body, signs the hash with the private key, and adds a DKIM-Signature: header naming the selector and domain (the s= and d= tags).
3. The receiver reads those tags, looks up the public key in DNS, and verifies the signature. A valid signature means the signed content was not tampered with and originated from a holder of the private key.

A concrete example

A message from billing@yourdomain.com carries DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail2025; .... The receiver queries mail2025._domainkey.yourdomain.com, retrieves a key like v=DKIM1; k=rsa; p=MIGfMA0..., and confirms the signature. If you rotate keys, you publish a new selector and retire the old one once mail signed with it has cleared.

How DKIM shows up on your external attack surface

DKIM lives entirely in public DNS, which makes it part of your externally observable posture. Common, real-signal issues an attacker or auditor can spot include:

• No DKIM record for a domain that sends mail, leaving DMARC unable to reach enforcement.
• Weak keys (512- or 768-bit RSA) that are feasible to factor, or records left in test mode (t=y).
• Stale selectors from a decommissioned email provider that were never removed, expanding the surface you have to reason about.
• Syntax errors that cause signatures to silently fail validation.

How FortWatch helps

FortWatch's DNS monitoring scanner inspects DKIM, SPF, and DMARC records across your domains as part of broader DNS-hygiene checks, flags missing, weak, or misconfigured records with a severity and AI-written remediation, and re-checks continuously so a record that breaks during a provider migration is caught quickly. For a fast manual check you can run the DMARC & SPF checker, and the wider DNS security checklist covers how email authentication fits into your overall external attack surface.