DKIM Signing Explained

Published 27 April 2026

DomainKeys Identified Mail (DKIM) attaches a cryptographic signature to every outgoing message, generated using a private key controlled by your domain. Receivers verify the signature against your public key, published in DNS. If the signature checks out, the receiver knows two things: the message genuinely came from someone with access to your DKIM private key, and the message hasn't been modified in transit.

Where SPF only checks "did this connection come from an authorised IP", DKIM checks the message itself. That makes it the only email authentication mechanism that survives forwarding, mailing lists, and most aliasing — because the signature lives in the message headers and travels with the message no matter how many hops it takes.

What DKIM Looks Like

An outgoing email signed with DKIM has a header like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=example.com; s=20260427;
    h=From:To:Subject:Date:Message-ID;
    bh=lOhX7Cv5i8cCerGv4LU6ngDd7A=;
    b=W3hYj2kP9LZxQ/...long base64 signature.../+pNsNmE0XtNz=

Reading the key tags:

v=1 — DKIM version.
a=rsa-sha256 — algorithm. RSA with SHA-256 is the modern default. Older messages used SHA-1; deprecated.
c=relaxed/relaxed — canonicalization. How the message is normalised before signing. "relaxed" forgives whitespace changes; "simple" doesn't.
d=example.com — the signing domain.
s=20260427 — selector (more on this below).
h=From:To:Subject:Date:Message-ID — list of headers covered by the signature.
bh=... — body hash (proves body integrity).
b=... — the actual signature.

Selectors

The selector is a label that tells the receiver where to find your public key. Combined with your domain, it forms a DNS query:

{selector}._domainkey.{domain}

So s=20260427 on domain example.com means the receiver looks up 20260427._domainkey.example.com for the public key.

You can have multiple selectors active at once. Common patterns:

One selector per provider. Google Workspace's selector might be google, SendGrid's might be s1, Mailgun's might be k1. Each provider publishes its own selector and key.
Date-based selectors for rotation. 20260427, 20261101, etc. Lets you roll keys without breaking in-flight messages — old keys stay published until any signed mail still in transit has been delivered.
Generic selectors like default, mail, k1. Common but harder to manage if you rotate.

How Signing Works

Your sending server holds a DKIM private key.
Outgoing message: server computes a hash of the relevant message body and headers, signs that hash with the private key, attaches the signature as a DKIM-Signature header.
Receiver: looks up {selector}._domainkey.{domain} to retrieve the public key, recomputes the hash, verifies the signature using the public key.
Match → DKIM passes. Mismatch → DKIM fails.

The signing happens automatically once configured. The configuration is the harder part.

How to Set Up DKIM

Setup depends on who's doing the sending:

Google Workspace / Microsoft 365

Both generate a DKIM keypair for you in the admin console. You publish the resulting public key as a TXT record on a specific selector (e.g. google._domainkey.yourdomain.com). Then enable signing in the admin panel. The provider handles signing every outbound message automatically.

Transactional senders (SendGrid, Mailgun, Postmark, AWS SES)

Each provider has a DKIM setup wizard that gives you a CNAME or TXT record to publish in DNS. Once published, the provider verifies the records and starts signing all outbound mail through their service. Some providers use multiple selectors (e.g. SendGrid uses s1._domainkey and s2._domainkey) so you'll be publishing two records.

Self-hosted (Postfix, Exim, etc.)

Generate a 2048-bit RSA keypair locally:

openssl genrsa -out dkim-private.pem 2048
openssl rsa -in dkim-private.pem -pubout -out dkim-public.pem

Configure your MTA's DKIM milter (e.g. opendkim) with the private key and selector. Publish the public key as a TXT record:

{selector}._domainkey.example.com  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq...long base64 public key..."

Test by sending a message to a Gmail account; check the Authentication-Results header for dkim=pass.

Key Sizes and Algorithms

The current minimum acceptable key size is 1024 bits, but 2048 is now the recommended default. Some receivers (Google in particular) flag 1024-bit DKIM as "weak" and may not give it full credit even when it verifies. Use 2048.

4096 bits is occasionally seen but not standard — older receivers may have buffer issues, and the security improvement is marginal. 2048 is the sweet spot for both compatibility and security.

For algorithms, RSA with SHA-256 (rsa-sha256) is current. SHA-1 is deprecated. ED25519 signatures are defined in RFC 8463 but receiver support is still patchy in 2026; use only as a secondary signature alongside RSA, not as a replacement.

DKIM Key Rotation

You should rotate DKIM keys periodically — every 6–12 months for active rotation, or at minimum after any incident where the private key may have been exposed. The rotation procedure:

Generate a new keypair with a new selector (e.g. 20260427 instead of 20251015).
Publish the new public key at {new-selector}._domainkey.example.com.
Wait for DNS propagation. Verify with dig from a remote network.
Configure the MTA to sign with the new selector. The old selector is left in place.
Wait at least 7 days. Any in-flight messages signed with the old key need time to be delivered before the old public key disappears.
Remove the old public key from DNS.
Decommission the old private key.

The 7-day overlap is critical. Removing the old public key before all old-signed messages have been verified means those messages will fail DKIM, which under a strict DMARC policy means they get rejected — even though they were legitimately sent.

Why DKIM Survives Forwarding

SPF authenticates the connection. When mail is forwarded, the connection IP changes — the forwarder is now the sender, and unless they're listed in the original domain's SPF, SPF fails.

DKIM authenticates the message. The signature is in the headers; it travels with the message. As long as the forwarder doesn't modify the signed headers or body in ways that break the canonicalization rules, the signature remains valid through any number of hops.

This is why DMARC requires either SPF or DKIM to pass with alignment — DKIM is the one that gets you through forwarders, mailing lists, and aliases.

Where DKIM Can Still Fail

Mailing lists that modify subject lines. "[List Name] Original subject" rewrites the Subject header, breaking the signature unless the list sends a fresh signature on the rewritten message (most modern lists do).
Mailing lists that rewrite the body. Footers added to messages break the body hash. Lists need to either resign or set up ARC (Authenticated Received Chain) to preserve auth state.
Antivirus gateways that modify content. Some corporate gateways add disclaimers or headers, breaking the signature. Modern gateways resign with their own DKIM after modification.
Long-cached public keys. If a receiver caches the public key for hours and you remove it from DNS too quickly, signature verification can fail until the cache expires.
Provider mismatches. If a third-party tool sends from [email protected] but doesn't have your DKIM key, it can't sign on your behalf — you'll get DKIM fails.

Verifying DKIM Is Working

Send a message to a test inbox at Gmail, Outlook, or Yahoo. Look at the message source for the Authentication-Results header:

Authentication-Results: mx.google.com;
    dkim=pass [email protected] header.s=20260427

dkim=pass means the signature verified. The header.i shows the signing domain, and header.s shows the selector that was used.

For ongoing verification, run your domain through DMARC Dashboard — the report covers DKIM publication and lets you spot missing or misconfigured records before email starts failing.

The DKIM Checklist

☐ Every system sending email on your domain has a DKIM key configured.
☐ Each provider has its own selector — don't share selectors across senders.
☐ Keys are 2048 bits, signed with rsa-sha256.
☐ Test message from each source verifies as dkim=pass.
☐ Public keys are published as TXT records on the right selector subdomain.
☐ Key rotation procedure documented and scheduled.
☐ DMARC policy aligned with DKIM (covered in our DMARC progression guide).

Once DKIM is working across every legitimate sender, DMARC has the foundation it needs to start rejecting spoofed mail with confidence.