DKIM Validator

DKIM Under the Hood: Private & Public Key Cryptography

DKIM runs on **asymmetric cryptography**. This involves two mathematically linked keys: a **private key** and a **public key**:

1. Private Key Signing: When an email is sent, the outgoing mail server hashes specific headers and the message body, encrypts this hash using your domain's private key, and embeds the signature inside a header named DKIM-Signature. The private key remains secure on the sending server.
2. Public Key DNS Publishing: The domain administrator publishes the corresponding public key as a DNS TXT record at a specific host: [selector]._domainkey.yourdomain.com.
3. Public Key Verification: When the receiving mail server gets the message, it extracts the domain name and selector from the DKIM-Signature header. It queries DNS for the public key, decrypts the signature, and calculates the message hash. If the hashes match, the signature is verified, proving that the email came from your server and was not modified.

Understanding a DKIM TXT Record Syntax

A typical DKIM public key record published in DNS looks like this:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvX...

Here is what each tag represents:

• v=DKIM1: The version tag. It must be capital and placed first.
• k=rsa: Specifies the key type (RSA is the standard, though Ed25519 is also supported).
• p=...: The public key itself encoded in Base64 format. If empty or absent, it indicates the key is revoked.

DKIM Selectors & Canonicalization Explained

To support multiple sending services (such as Google Workspace for corporate email and SendGrid for transactional emails), domains use **selectors**. A selector is a string prefix that points to a specific key. This allows you to publish multiple DKIM public keys on a single domain.

Additionally, during transit, mail transfer agents sometimes modify headers (e.g. changing spacing or wrapping lines), which could break cryptographic signatures. To prevent false negatives, DKIM uses **canonicalization algorithms** (defined in the `c=` tag of the signature, such as `simple` or `relaxed`) to normalize spacing, casing, and carriage returns before calculations.

Best Practices for DKIM Key Rotation & Length

• Use 2048-Bit Keys: 512-bit and 1024-bit keys are vulnerable to offline brute-forcing. 2048-bit keys are standard and highly secure.
• Rotate Keys Regularly: Security best practices recommend rotating your DKIM private keys every 6 to 12 months to prevent compromise.
• Clean Up Old Records: When you stop using a sending service or rotate a key, delete the old selector DNS records to minimize attack surface.