Definition
DKIM (DomainKeys Identified Mail) is an email authentication specification that uses public-key cryptography to sign outgoing messages, enabling receiving mail servers to confirm that the email came from the domain it claims to originate from and that the message body and selected headers were not modified in transit. The signing domain publishes its public key in DNS; receiving servers retrieve that key and use it to verify the signature embedded in the DKIM-Signature email header.
DKIM was developed from two earlier, overlapping proposals — Yahoo’s DomainKeys and Cisco’s Identified Internet Mail — and was first published as IETF RFC 4871 in 2007. The current authoritative specification is RFC 6376, published in September 2011 and updated by RFC 8301 (2018) and RFC 8463 (2018) to mandate stronger cryptographic algorithms. DKIM is widely deployed across the email ecosystem and is a required component of a DMARC policy that provides meaningful protection.
How It Works
When an organisation’s mail server sends a message, the DKIM signing module (built into MTAs such as Postfix, Exim, and Microsoft Exchange, or provided as a service by transactional providers including SendGrid, Mailgun, Amazon SES, and Postmark) performs the following operations.
The signer selects a subset of headers to include in the signature — typically From, To, Subject, Date, and Content-Type — and canonicalises them using one of two defined algorithms: simple (minimal whitespace normalisation) or relaxed (more permissive, tolerating minor header rewrites during transit). The message body is similarly canonicalised and hashed using SHA-256 (the algorithm mandated since RFC 8301 deprecated the older SHA-1). The signer then computes an RSA or Ed25519 digital signature over the header hash plus a structured string of signing metadata, and inserts a DKIM-Signature header at the top of the message.
The DKIM-Signature header contains: v=1 (version), a=rsa-sha256 (algorithm), d=example.com (signing domain, known as the d= tag), s=selector1 (selector, used to look up the specific public key), h=from:to:subject (signed headers), bh=<body hash>, and b=<base64 signature>.
The domain owner publishes the corresponding public key at <selector>._domainkey.<domain> as a DNS TXT record. When Gmail, Outlook, Yahoo Mail, or any RFC 6376-compliant MTA receives the message, it queries DNS for that record, retrieves the public key, and verifies the cryptographic signature. A valid signature produces a DKIM result of pass. A missing or invalid signature, or any modification to the signed headers or body in transit, produces a fail or neutral result, which is then passed to the DMARC evaluation engine.
Selectors (s= tag) allow a domain to publish multiple DKIM keys simultaneously — useful for rotating keys without service interruption, or for isolating keys across different sending systems (e.g., marketing._domainkey.example.com versus transactional._domainkey.example.com).
Where You Encounter It
DKIM is a foundational deliverability requirement for any email-dependent service. Transactional email providers such as Amazon SES, SendGrid (part of Twilio), Mailgun (part of Sinch), Postmark, and SparkPost include DKIM signing as a mandatory configuration step during domain verification. The provider generates an RSA-2048 or Ed25519 keypair, displays the public key as a DNS TXT record, and prompts the domain owner to publish it before enabling sending from that domain.
For contest platforms that dispatch email confirmation votes, DKIM signing is especially important because confirmation emails must pass the authentication checks applied by major mailbox providers — Google Workspace / Gmail, Microsoft Outlook and Exchange Online Protection, Yahoo Mail, Apple iCloud Mail, and ProtonMail. Unsigned messages or messages whose signatures fail are far more likely to be delivered to spam or blocked entirely, preventing voters from confirming their submissions.
Email testing tools such as Mail-Tester, GlockApps, and MXToolbox DKIM Lookup allow senders to inspect and validate their DKIM configuration before production sending. Google Postmaster Tools and Microsoft SNDS provide aggregate-level deliverability data that reflects DKIM pass rates over time.
Practical Examples
A contest platform configured with a DKIM selector s=contest for the domain votes.example.com publishes the public key at contest._domainkey.votes.example.com. Every outbound confirmation email carries a DKIM-Signature header signed with the corresponding private key. When a voter’s Gmail account receives the message, Gmail’s inbound filter queries DNS, verifies the signature, records a pass, and forwards the result to its spam classifier. The confirmed DKIM pass, combined with SPF alignment, satisfies the conditions for DMARC compliance.
A contest administrator rotates from a 1024-bit RSA key (no longer considered cryptographically adequate) to a 2048-bit RSA key after reading RFC 8301. The old selector is kept active for seven days to cover any messages in transit, then removed from DNS. All new messages use the updated selector and key.
Related Concepts
DKIM works in concert with SPF Record — which authenticates the sending server’s IP address — and DMARC — which defines a policy action and reporting mechanism based on SPF and DKIM results. Both signals must be understood together; passing DKIM alone does not make a message DMARC-compliant if the d= domain does not align with the RFC5322.From domain. For the contest-operations context, the practical consequences of DKIM failures are explained in Email Confirmation Vote, where inbox placement of the confirmation message directly determines whether a cast vote is counted.
