SecVaultAuditor
PL
Guide, updated 2026-11-05

What is DKIM and how to turn it on

DKIM is a digital signature attached to every message you send. The receiving server checks it with a public key from your DNS and learns that the message came from your domain and was not changed on the way. Without DKIM, large mailbox providers increasingly treat your mail as suspicious.

Check your domain for free

What DKIM does

The sending server computes a hash of the message body and selected headers, signs it with a private key and adds the result to the message as a DKIM-Signature header. The private key stays with your mail provider. You publish the public key in DNS as a TXT record. The receiving server reads the domain (the d= tag) and the selector (s=) from the header, fetches the key from DNS and verifies the signature. If the body or a signed header changes in transit, the signature no longer matches. The "From" header must be part of the signature (RFC 6376, section 5.4).

DKIM does not encrypt the message, and by itself it does not tell the recipient what to do with unsigned mail. That decision belongs to DMARC.

Where the key lives and what the record looks like

DKIM keys live under the _domainkey subdomain. The full record name is <selector>._domainkey.<domain>, for example mail2026._domainkey.yourcompany.com. The record type is TXT (some providers use a CNAME that points to a record on their side). An example with the key shortened for readability:

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

  • v=DKIM1 is the version. If present, it must be the first tag in the record.
  • k= is the key type. The default is rsa; for Ed25519 keys you write k=ed25519 (RFC 8463).
  • p= is the public key in base64. An empty value means the key has been revoked.
  • t=y (optional) means the domain is only testing DKIM and the recipient should not treat such mail differently from unsigned mail. Remove the tag when testing is over.

The selector, and why an external scan may not find it

The selector is any name chosen by your provider or by you. It lets a domain keep several keys at once: one for company mail, one for the newsletter, one for the shop. The recipient knows the selector because it sits in the s= tag of the message. DNS offers no list of subdomains, though, so a tool that only knows your domain cannot look it up. It can only try the most common names. If your provider uses an unusual selector, the scan will not find the key even though your mail is signed. The Auditor then says it found no key under the common selectors, not that DKIM is missing. When that happens, check the headers of a real message (below) or enter the selector shown in your provider's panel.

Key length and algorithms

  • RFC 8301 requires signers to use RSA keys of at least 1024 bits and recommends at least 2048 bits. The rsa-sha1 algorithm is forbidden, and rsa-sha1 signatures count as failed. Use rsa-sha256.
  • Google requires a key of at least 1024 bits when sending to Gmail accounts and recommends 2048 bits if your domain provider supports it. Yahoo also requires at least 1024 bits.
  • A 2048-bit key in base64 is longer than 255 characters, and a single string in a TXT record is limited to 255. The record is therefore split into several strings, which the recipient joins with no spaces in between (RFC 6376, section 3.6.2.2). DNS panels handle this differently, which is the source of a common mistake described below.
  • 4096-bit keys may not fit in a 512-byte UDP response packet (RFC 6376, section 3.3.3), so there is usually no reason to use them.
  • RFC 8463 adds the Ed25519-SHA256 algorithm with a short key (44 base64 characters). Not every recipient supports it, so for a small company RSA with 2048 bits remains the simpler choice.

Key rotation

A key that never changes is a bigger risk if it ever leaks. A safe order: publish the new key under a new selector, switch signing to the new key, and keep the old record for a reasonable time so that mail already in transit can still be verified. Only then remove the old record or set its p= to an empty value. With managed services (Google Workspace, Microsoft 365) rotation is done in the provider's panel. RFC 6376 does not set a rotation interval.

DKIM, SPF and DMARC

SPF checks the sending server, DKIM checks the message signature, and DMARC ties them to the address in the "From" field. A message passes DMARC through DKIM when the signature is valid and the domain in the d= tag matches the domain in "From" (in the default mode the same organizational domain is enough). This has practical consequences:

  • A valid signature made with the provider's domain (for example d=mail-provider.com) passes DKIM but is not aligned for DMARC. The mail then passes DMARC only through SPF, which easily breaks when a message is forwarded. Forwarded messages usually keep their DKIM signature, as long as nobody changes the content.
  • For that reason, enable signing with your own domain in every outside service (newsletter, shop, CRM) instead of the provider's default domain.

How DMARC works: DMARC guide. SPF: SPF guide.

What Gmail, Yahoo and Microsoft require

  • Google: every sender to Gmail accounts must set up SPF or DKIM. Senders of more than 5,000 messages per day to Gmail need SPF and DKIM and also DMARC (the policy can be none), and the domain in "From" must be aligned with the SPF or DKIM domain. The stricter rules for bulk senders apply from February 1, 2024.
  • Yahoo: the minimum is SPF or DKIM; bulk senders need both, plus a DMARC policy of at least p=none that passes. The Yahoo page gives no numeric threshold for a bulk sender.
  • Microsoft (Outlook.com, hotmail.com, live.com): from May 2025, domains sending more than 5,000 messages per day must pass SPF and DKIM and publish DMARC with a policy of at least p=none, aligned with SPF or DKIM. Non-compliant messages go to the Junk folder after May 5, 2025; Microsoft says they may later be rejected with error 550 5.7.515. No date for rejection has been given.

A small company usually sends fewer than 5,000 messages per day, but the signing rules still matter in practice, because missing DKIM lowers the trust that spam filters give your mail. More on mail landing in spam: emails going to spam.

How to check the signature in a message

Send a message to a Gmail account and use the menu option that shows the original message. Look for two headers.

DKIM-Signature: v=1; a=rsa-sha256; d=yourcompany.com; s=mail2026; h=from:to:subject:date; bh=...; b=...

  • d= is the signing domain and s= is the selector. The DNS record to look up is s._domainkey.d, here mail2026._domainkey.yourcompany.com.
  • a= is the algorithm; it should be rsa-sha256.
  • h= is the list of signed headers; it must include from.

The second header is Authentication-Results, added by the receiving server. Look for dkim=pass header.d=yourcompany.com. If you see fail, neutral or none instead of pass, the reason is often given next to it (for example body hash did not verify, key not found). If header.d shows the provider's domain instead of yours, the signature is not aligned with your "From" address.

The most common mistakes

  • Cloudflare proxy on a CNAME record. DKIM records in Cloudflare must be set to "DNS only" (grey cloud). With the proxy on, the recipient does not get the provider's record and the key is not found. See SPF, DKIM and DMARC with Cloudflare DNS.
  • A key cut off when pasting. A long TXT record pasted into a panel without splitting into strings, or with an extra space, line break or quote mark inside, produces "key not found" or "bad signature". Compare the record with the value you copied and do not edit the key by hand.
  • An old selector after changing provider. After a mail migration the old provider's records stay, while the new provider signs with a different selector that was never added to DNS. Remove the old records only after you confirm that the new signature passes.
  • Signing with the provider's domain instead of your own. DKIM passes, but DMARC does not accept it, because the d= domain does not match "From". Turn on signing with your own domain in the service's settings.
  • Two services sharing one selector. Two records under the same name with different keys cause random failures. Each service should have its own selector.
  • DKIM enabled only for company mail. The newsletter, shop invoices and the website form send separately, and each one has to be signed.

How to turn on DKIM

  1. In your mail provider's panel, find the DKIM signing settings and generate a key. Choose 2048 bits if the provider offers a choice.
  2. Add the record the panel shows in DNS (TXT or CNAME), with exactly the name and value given.
  3. After the DNS change, wait for propagation (usually minutes, sometimes a few hours), then enable signing in the panel.
  4. Send a message to a Gmail account and check for dkim=pass with your own domain in header.d.
  5. Repeat for every service that sends mail with your domain, then publish DMARC.

Step-by-step guides: Google Workspace, Microsoft 365, Cloudflare.

You can check the whole email setup of your domain in the free SecVault Auditor scan. The DMARC generator prepares a DMARC record, the SPF generator an SPF record, and the DMARC checker tests a published one.

Sources