DomainKeys Identified Mail (DKIM) uses public-key cryptography to create a verifiable link between a sending domain and the email messages it sends. When your mail server sends an outgoing message, the DKIM signing process begins by selecting a set of message headers to sign — typically From, Subject, Date, To, and the message body — and computing a cryptographic hash of their content. The mail server then signs this hash using its DKIM private key, producing a digital signature that is encoded in Base64 and added to the message as a DKIM-Signature header before delivery.
On the receiving end, the receiving mail server extracts the DKIM-Signature header from the incoming message and reads the selector (s=) and domain (d=) values it contains. The server performs a DNS TXT record lookup at [selector]._domainkey.[domain] to retrieve the corresponding public key. Using this public key, it recomputes the hash of the signed headers and body as specified in the signature, and verifies that the signature in the DKIM-Signature header was produced by the corresponding private key. A successful verification proves that the message was signed by an entity controlling that domain's private key and that the signed portions of the message have not been modified since signing.
- Signing server: selects headers to sign, hashes them, signs the hash with the DKIM private key
- The resulting signature is encoded in Base64 and added as a DKIM-Signature header to the message
- Receiving server: extracts selector and domain from the signature, retrieves public key from DNS
- Verification: recomputes hash of signed content and verifies the signature using the public key
- A valid signature proves the message was signed by the domain and content was not modified in transit
The DKIM public key is published in DNS as a TXT record at a specific subdomain. The naming convention follows the format [selector]._domainkey.[domain]. For example, if your selector is named google and your domain is example.com, the public key TXT record is published at google._domainkey.example.com. The record contains several fields that describe the key: v=DKIM1 indicates the record version; k=rsa specifies the key algorithm (RSA is the standard, with Ed25519 gaining adoption); p= contains the Base64-encoded public key value.
A typical DKIM public key DNS record looks like: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA... where the long Base64 string after p= is the actual public key. The t=s tag can be used to indicate the domain in the DKIM-Signature must exactly match the From header domain (strict mode). The h=sha256 tag specifies the hash algorithm. An empty or missing p= field signals that the key has been revoked and messages signed with the corresponding private key should be rejected. Rotating a DKIM key involves publishing a new selector with the new public key before switching the signing server to use the new private key.
- Record location: TXT record at
[selector]._domainkey.[domain] v=DKIM1— required version tag identifying this as a DKIM public key recordk=rsa— specifies RSA key algorithm; use 2048-bit or 4096-bit keys for adequate securityp=— the Base64-encoded RSA public key value used by receivers to verify signatures- Empty
p=value signals key revocation — receiving servers should reject signatures from that key
The selector mechanism in DKIM serves two critical operational purposes. First, it enables an organization to use multiple signing keys simultaneously for different mail streams — a transactional mail server, a marketing platform, and a support ticketing system can each have their own unique DKIM key identified by distinct selectors. If one of these third-party services is compromised, only that service's key needs to be revoked, while the other mail streams continue to function without interruption.
Second, and equally important, selectors enable zero-disruption key rotation. To rotate a DKIM key, you first publish the new public key under a new selector in DNS and allow it to propagate globally. Only after the new key is published do you update your mail server to sign with the new private key. You then keep the old selector active in DNS for 48-72 hours after the switch to allow any messages signed with the old key that are still in delivery queues to be verified successfully by receiving servers. After this grace period, you can safely remove the old selector's TXT record or set its p= value to empty to signal revocation of the old key.
- Multiple selectors allow different mail streams to use different signing keys independently
- Selector-based rotation: publish new selector, switch signing, then retire old selector after 72 hours
- Retiring a key: set
p=to empty in the old selector's DNS record to signal revocation - Different marketing and transactional services should use distinct selectors for isolation
- Never reuse selector names for different keys — the old public key may be cached by receivers
The DKIM-Signature header added to signed messages contains multiple tag-value pairs that receiving servers use to perform verification. The d= tag specifies the signing domain — this is the domain whose DNS record will be queried for the public key. The s= tag specifies the selector. The h= tag lists the message headers that were included in the hash, such as from:subject:date:to. The bh= tag contains the Base64-encoded hash of the message body. The b= tag contains the actual Base64-encoded digital signature that receivers verify.
Additional tags control verification behavior. The a= tag specifies the signature algorithm, typically rsa-sha256. The c= tag specifies the canonicalization algorithm for headers and body, with options of simple or relaxed — relaxed canonicalization tolerates minor whitespace normalization that occurs during email transit, making signatures more robust. The t= tag contains the signing timestamp. The x= tag, when present, specifies a signature expiration timestamp. The headers listed in h= are the only headers that have integrity protection — headers not listed can be added or modified without invalidating the signature.
d=— signing domain; DNS query for the public key is made at[s]._domainkey.[d]s=— selector identifying which public key to retrieve from DNSh=— colon-separated list of header names included in the signed hashbh=— Base64 hash of the canonicalized message body, validated separately from headersb=— the Base64-encoded digital signature value that receivers verify against the public key
DKIM by itself does not prevent header spoofing — an attacker could sign a message with a DKIM key for a domain they control while using a different domain in the visible From header. DMARC's DKIM alignment requirement closes this gap. For DMARC's DKIM alignment check to pass, the domain in the DKIM-Signature's d= tag must match the domain in the message's From header. This alignment can be evaluated in two modes: relaxed alignment (adkim=r, the default) allows the organizational domain to match, so mail.example.com aligns with example.com. Strict alignment (adkim=s) requires an exact domain match.
DKIM alignment failure is a common source of DMARC failures that can be difficult to diagnose. The most frequent scenario involves a subdomain mismatch: marketing email sent from newsletter.example.com signed with a DKIM key for newsletter.example.com will pass DKIM relaxed alignment for a DMARC record published at example.com. However, if the DKIM signing domain is a completely different organizational domain — as happens with some email service providers that sign with their own domain rather than the customer's — DMARC alignment will fail regardless of relaxed mode. Always verify that your email service provider signs with your domain, not their own.
- DMARC DKIM alignment: the
d=domain in the DKIM-Signature must match the From header domain - Relaxed alignment (default): organizational domain match is sufficient —
mail.example.comaligns withexample.com - Strict alignment: requires exact domain match between DKIM
d=and From header domain - Third-party senders must sign with your domain (or a subdomain) for DMARC alignment to pass
- Check DMARC aggregate reports to identify sources failing DKIM alignment before enforcing policy
Security best practices recommend rotating DKIM keys at least annually, and more frequently for high-volume senders or organizations with elevated security requirements. All newly generated DKIM keys should use RSA with a minimum key size of 2048 bits — 1024-bit RSA keys are considered cryptographically insufficient by current standards and should be replaced immediately if still in use. Ed25519 keys, while not yet universally supported by all mail systems, offer strong security with much smaller key sizes and are gaining adoption. Google Workspace and several major ESPs now support Ed25519 DKIM signing.
The rotation procedure requires careful sequencing to avoid interrupting mail delivery. Generate the new key pair on your mail server or in a secrets management system. Publish the new public key as a new selector TXT record in DNS and wait for it to propagate — verify with dig TXT newsel._domainkey.example.com. Update your mail server configuration to sign with the new private key. Monitor mail delivery for 24-48 hours to confirm the new signature is verifying correctly. Only after this verification period should you retire the old selector. Testing tools like mail-tester.com and examining Gmail message headers (More options → Show original → view Authentication-Results) let you verify live DKIM signing behavior.
- Rotate DKIM keys at minimum annually; immediately replace any 1024-bit RSA keys still in use
- Use RSA-2048 or RSA-4096 as the current standard; Ed25519 is recommended where supported
- Publish new selector in DNS and verify propagation before switching signing to the new key
- Keep old selector active for 48-72 hours after switching to allow in-flight message verification
- Verify live DKIM signing with mail-tester.com or by inspecting Gmail message Authentication-Results headers