DKIM Record: What It Is and How to Set It Up

DKIM adds a cryptographic signature to every email you send. The receiving server checks that signature against a public key published in your DNS. If the signature verifies, the receiver knows two things: the message passed through infrastructure that holds the private key, and the signed headers and body were not modified in transit. That pair of guarantees is what makes DKIM the integrity layer of modern email authentication.

The public key lives in a DNS TXT record, and that record is what people mean when they say "DKIM record." It is not a single well-known location like an SPF record at the domain apex. Instead, each DKIM record sits at a selector-specific subdomain, which means a domain can publish multiple keys for different mail streams, different providers, or different stages of a key rotation. That flexibility is powerful, but it also means there is no way to discover all of a domain's DKIM keys without knowing which selectors are in use.

Quick check: Use DKIM Discovery to probe common selectors for your domain and see which public keys are currently published, or run the full Email Security Check for a combined SPF, DKIM, and DMARC audit.

How DKIM Works

The DKIM signing and verification process is a two-phase protocol split between the sending and receiving mail servers. Understanding both sides matters because misconfiguration on either side produces the same symptom: a failed verification that the domain owner may not notice until delivery problems surface in DMARC reports or recipient complaints.

Signing (Outbound)

When your mail server sends a message, it selects a set of headers to include in the signature, typically From, To, Subject, Date, and MIME-Version, though the exact set is configurable. The server canonicalizes those headers and the message body according to a defined algorithm (simple or relaxed), then computes a hash of each. It signs the combined hash with the domain's private key and attaches the result as a DKIM-Signature header at the top of the message.

The DKIM-Signature header contains everything a receiver needs to repeat the process: the signing domain (`d=`), the selector (`s=`), the algorithm (`a=`), the list of signed headers (`h=`), the body hash (`bh=`), and the signature itself (`b=`). A typical header looks like this:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
    c=relaxed/relaxed; q=dns/txt;
    h=from:to:subject:date:mime-version;
    bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
    b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk...

Verification (Inbound)

The receiving server reads the DKIM-Signature header and extracts two values: the selector (`s=`) and the domain (`d=`). It concatenates them into a DNS query: `selector1._domainkey.example.com`. The TXT record at that location contains the public key. The receiver uses that key to verify the signature in the `b=` tag against a fresh hash of the same headers and body listed in the signature. If the hash matches, the signature is valid. If any signed header was altered, if the body was modified beyond the scope of the canonicalization tolerance, or if the public key does not match the private key that signed the message, verification fails.

One detail that catches teams off guard: DKIM verification survives forwarding in most cases, unlike SPF. When a mailing list or forwarding service relays a message, the SPF check breaks because the relay's IP is not in the original domain's SPF record. But if the relay does not modify the signed headers or body, the DKIM signature still verifies. This is one of the main reasons DMARC was designed to accept either SPF or DKIM alignment, not both.

Anatomy of a DKIM Record

A DKIM record is a DNS TXT record published at `selector._domainkey.domain`. The record contains a semicolon-delimited set of tag-value pairs that describe the key and its constraints. Here is a representative example:

selector1._domainkey.example.com  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2N...truncated...IDAQAB"

Each tag in the record serves a specific role. The required tags are `v` and `p`. The others are optional but operationally relevant.

• `v=DKIM1` — Version identifier. Must be exactly DKIM1. Any other value causes the record to be ignored during verification.
• `k=rsa` — Key type. RSA is the default and most widely supported. Ed25519 (`k=ed25519`) is faster and produces shorter signatures, but receiver support is still inconsistent.
• `p=MIIBIjANBg...` — The public key, base64-encoded. This is the core of the record. If the tag is empty (`p=`), the key has been revoked and signatures using this selector will fail.
• `t=y` — Testing flag. Tells receivers the domain is testing DKIM and that verification failures should not affect delivery decisions. Remove this flag before relying on DKIM for DMARC enforcement.
• `t=s` — Strict alignment flag. Requires that the signing domain exactly match the domain in the From header, with no subdomain allowance.
• `h=sha256` — Acceptable hash algorithms. Limits which hash algorithms may be used with this key. Omitting the tag allows any algorithm the receiver supports.

The most common mistake in DKIM records is a malformed public key in the `p=` tag. DNS providers that split TXT records across multiple strings sometimes introduce whitespace or line breaks inside the base64-encoded key, which causes decoding to fail on the receiver side. Always verify the published record by querying it from an external resolver and checking that the base64 decodes cleanly.

Setting Up DKIM

The setup process varies by provider, but the core pattern is always the same: generate a keypair, configure the sending system to sign with the private key, and publish the public key as a DNS TXT record at the correct selector subdomain. The differences are in where the keypair is generated and how the DNS record is published.

Google Workspace

Google generates the DKIM keypair for you. In the Google Admin console, navigate to Apps, then Google Workspace, then Gmail, then Authenticate Email. Select your domain and click Generate New Record. Google will display a TXT record value and a selector, which defaults to `google` but can be customized. Copy the TXT value and create a DNS record at `google._domainkey.yourdomain.com` (or whatever selector you chose). After DNS propagation, return to the admin console and click Start Authentication. Google will verify the record and begin signing outbound mail.

Google supports both 1024-bit and 2048-bit RSA keys. Choose 2048-bit unless your DNS provider cannot handle TXT records longer than 255 bytes in a single string, which is rare with modern providers. The 2048-bit key will be split across two DNS strings automatically.

Microsoft 365

Microsoft 365 uses CNAME records instead of publishing the public key directly as a TXT record. This lets Microsoft rotate keys on their side without requiring you to update your DNS. You create two CNAME records that point to Microsoft's key infrastructure:

selector1._domainkey.yourdomain.com  CNAME  selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com
selector2._domainkey.yourdomain.com  CNAME  selector2-yourdomain-com._domainkey.yourtenant.onmicrosoft.com

Replace `yourdomain-com` with your domain name using hyphens instead of dots, and `yourtenant` with your Microsoft 365 tenant name. After adding both CNAME records, enable DKIM signing in the Microsoft 365 Defender portal under Email & Collaboration, then Policies & Rules, then Threat Policies, then Email Authentication Settings. Microsoft will start signing with `selector1` and uses `selector2` for automatic key rotation.

Custom Setup (OpenSSL + MTA)

For self-hosted mail servers or any MTA that supports DKIM natively (Postfix with OpenDKIM, Exim, Haraka, etc.), you generate the keypair yourself. The following commands produce a 2048-bit RSA private key and extract the public key in the format DNS expects:

# Generate a 2048-bit RSA private key
openssl genrsa -out dkim_private.pem 2048

# Extract the public key in DER format, base64-encoded
openssl rsa -in dkim_private.pem -pubout -outform DER | openssl base64 -A

# Output is the value for the p= tag in your DNS record

Take the base64 output and publish it as a TXT record at `yourselector._domainkey.yourdomain.com` with the full record value `v=DKIM1; k=rsa; p=<base64-public-key>`. Configure your MTA to sign outbound mail using the private key file and the same selector. The exact configuration syntax depends on the MTA, but every implementation needs three values: the path to the private key, the selector string, and the signing domain.

After publishing, verify the record resolves correctly by querying it from an external DNS resolver. The DKIM Discovery tool will show you exactly what receivers see when they look up your selector.

DKIM Selectors

A selector is the prefix that makes each DKIM key addressable in DNS. When a receiver reads `s=selector1` from a DKIM-Signature header, it knows to query `selector1._domainkey.example.com` for the public key. This indirection is what allows a single domain to maintain multiple active signing keys at the same time, each published under a different selector.

Common selectors follow provider conventions. Google Workspace uses `google` by default. Microsoft 365 uses `selector1` and `selector2`. Mailchimp uses `k1`. SendGrid uses `s1` and `s2`. Amazon SES generates a unique selector per configuration set. These conventions are useful to know because they help you inventory which providers are signing on behalf of your domain, but they also mean an attacker or investigator can guess likely selectors to discover your DKIM configuration.

The operational reasons for multiple selectors go beyond multi-provider setups:

• Key rotation: publish a new key under a new selector, switch signing, then revoke the old selector. Both keys are valid during the transition.
• Environment separation: use different selectors for production, staging, and development so a compromised dev key cannot sign production mail.
• Vendor isolation: each third-party sender gets its own selector, so revoking one vendor's key does not affect the others.
• Algorithm migration: publish an Ed25519 key under a new selector while keeping the RSA key active for receivers that do not yet support Ed25519.

Discovering which selectors a domain uses is not straightforward because DNS does not support wildcard enumeration of TXT records under `_domainkey`. You need to either inspect DKIM-Signature headers from actual messages sent by the domain, check DMARC aggregate reports for selector references, or probe common selector names. The DKIM Discovery tool automates the probing approach by testing a curated list of known provider selectors against your domain.

Key Rotation

DKIM keys should be rotated periodically, even when there is no known compromise. The reasons are practical: a key that has been in use for years represents a longer window of exposure if it is ever exfiltrated, and algorithm upgrades require new keys regardless. Most security frameworks recommend rotating DKIM keys at least once per year. Some organizations rotate quarterly.

The rotation process must avoid a gap where neither old nor new key is valid. The safe sequence is:

1. Generate a new keypair and choose a new selector name (e.g., move from `s202601` to `s202610`).
2. Publish the new public key in DNS under the new selector. Wait for propagation, at least the TTL of the zone.
3. Update the signing configuration on the MTA to use the new private key and new selector.
4. Monitor DMARC reports for a full reporting cycle to confirm the new key is passing verification.
5. Revoke the old key by setting its DNS record to `v=DKIM1; p=` (empty p= tag), which signals that signatures from the old selector are no longer valid.
6. After another TTL period, remove the old DNS record entirely.

The critical step is the overlap period between publishing the new key and revoking the old one. Messages in transit or queued for retry may still carry signatures from the old selector. If you revoke the old key before those messages are delivered, their DKIM verification will fail. A 48-to-72-hour overlap is a reasonable minimum for most mail flows, though high-volume senders with long retry queues may need longer.

Microsoft 365 handles rotation automatically by alternating between `selector1` and `selector2`. Google Workspace requires manual rotation through the admin console. For custom setups, building rotation into a scheduled workflow prevents it from being perpetually deferred.

DKIM + SPF + DMARC

DKIM alone proves that a specific key signed a message and that the signed content was not altered. It does not, by itself, prevent spoofing. An attacker who controls any domain can generate a DKIM keypair, publish the public key in their own DNS, and sign messages with a valid DKIM signature. The signature will verify, but the `d=` domain in the signature will be the attacker's domain, not yours. Without something connecting the DKIM domain to the From header domain, a passing DKIM check says nothing about whether the visible sender identity is legitimate.

DMARC is the mechanism that closes that gap. When a receiver evaluates a message under DMARC, it checks whether the domain in the DKIM signature's `d=` tag aligns with the domain in the From header. Alignment can be strict (exact match) or relaxed (organizational domain match, meaning the d= domain and the From domain share the same registered domain). If DKIM passes and aligns, DMARC passes on the DKIM leg. If DKIM passes but the d= domain does not align with the From domain, the DKIM result is irrelevant to DMARC.

This alignment requirement is why third-party senders need to sign with your domain, not theirs. When you use a marketing platform or transactional email service, the provider must either sign with a key under your domain's selector namespace or the DKIM check will not contribute to DMARC alignment. Most providers support this through custom DKIM configuration, but it requires you to publish their public key in your DNS and configure the provider to sign with your domain in the `d=` tag.

SPF covers the gap that DKIM cannot: messages where the signature breaks in transit. Forwarding, mailing lists, and some content-modifying gateways can invalidate DKIM signatures by altering signed headers or the body. In those cases, SPF may still pass if the forwarding server is authorized. DMARC accepts either mechanism, so having both SPF and DKIM configured gives the domain two independent chances to pass authentication on each message.

The practical implication is that DKIM setup is never complete in isolation. A DKIM record without a DMARC policy is a lock without a door. Use the DMARC Builder to publish a policy that ties your DKIM and SPF results together, and use the SPF Builder to ensure your SPF record covers the same sending infrastructure.

Independent references: Review RFC 6376 for the full DKIM specification, and Google Sender Guidelines for current authentication requirements that apply to domains sending to Gmail users.

A DKIM record is a small DNS entry with outsized consequences. It is the foundation for message integrity, the prerequisite for DMARC alignment on the signing leg, and the most resilient part of the authentication stack when mail passes through intermediaries. Setting it up correctly is straightforward. Keeping it healthy over time requires knowing your selectors, rotating keys before they become liabilities, and treating the record as one part of a three-layer system rather than a standalone control.