SPF says which servers may send for your domain. DKIM proves that a message really comes from you and was not changed on the way. Gmail and Yahoo require it from bulk senders, Outlook.com from high-volume senders, and DMARC relies on it.

This guide explains what a DKIM record is, how to find the selector your mail service uses, what a healthy key looks like, and how to fix the problems we see most often.

How DKIM works

DKIM (DomainKeys Identified Mail, RFC 6376) uses a pair of keys:

  1. Your mail service keeps a private key and uses it to sign every message it sends: it adds a DKIM-Signature header computed from the message's body and main headers.
  2. You publish the matching public key in your DNS.
  3. The receiving server reads the signature, fetches your public key, and checks that the signature matches. If anyone changed the signed parts of the message on the way, the check fails.

A passing signature tells the receiver that the domain in the signature (d=) takes responsibility for the message. That is what builds reputation for your domain over time.

What a DKIM record looks like

A DKIM record is a TXT record at a special name:

<selector>._domainkey.<your domain>

For example, Google Workspace publishes its key at google._domainkey.example.com. The value looks like this (the key is shortened here):

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu8...IDAQAB
Tag Meaning
v=DKIM1 Version. Optional, but if present it must be first and must say DKIM1.
k=rsa Key type: rsa (the default) or ed25519.
p= The public key, base64-encoded. An empty p= means the key was revoked.
t=y Test mode: receivers may treat failures leniently. Remove it once DKIM works.
h= Hash algorithms allowed. If present, it must include sha256.

Some services, such as Microsoft 365 and many email platforms, ask you to create a CNAME instead of a TXT record. The CNAME points to a key they host, so they can rotate it for you. Receivers follow the CNAME, and so does our checker.

The selector: why "my DKIM record" is hard to find

Unlike SPF and DMARC, which live at fixed names, a DKIM key lives under a selector chosen by the service that signs your mail. A domain can have many selectors, one or more per sending service:

Service Usual selector(s)
Google Workspace google
Microsoft 365 selector1, selector2
Mailchimp k1
SendGrid s1, s2

There is no DNS query that lists every selector of a domain. That is why a DKIM checker either needs the selector, or tries a list of common ones.

How to find your selector

The surest way is to read it from a message you sent:

  1. Send an email from the domain to an address you can read (a Gmail account works well).
  2. Open it and show the original message: Show original in Gmail, View message source in Outlook.
  3. Find the DKIM-Signature header:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=google; ...

s= is the selector (google) and d= is the signing domain (example.com). Gmail's "Show original" page also says at the top whether DKIM passed.

If you send through several tools (your mailbox, a newsletter platform, a CRM), repeat this for each one: every tool that sends as your domain needs its own DKIM setup.

Check your DKIM record

Enter your domain in our free DKIM checker. Without a selector it tries about 30 common ones; with the selector from your header it checks that one directly. For each key it shows:

  • whether the record is a valid DKIM key,
  • the key type and, for RSA, its length in bits,
  • settings that weaken it: an empty (revoked) key, test mode, or SHA-1 only.

What a good DKIM key looks like

  • RSA, 2048 bits. RFC 8301 says signers should use keys of at least 2048 bits, and receivers must not accept signatures made with keys shorter than 1024 bits. A 1024-bit key still works, but plan to replace it.
  • SHA-256. SHA-1 signatures are no longer valid under RFC 8301. If your record has h=sha1, remove the tag or change it to h=sha256.
  • One record per selector. Two TXT records under the same name make the result unpredictable.
  • No test mode once everything works.

Ed25519 keys (RFC 8463) are shorter and modern, but not every receiver checks them yet. If you use one, sign with an RSA key as well.

Common DKIM problems and how to fix them

"No DKIM record found"

Either DKIM was never turned on at your mail service, or it uses a selector the checker did not try. Find the selector in a message header (see above) and check it directly. If there is no DKIM-Signature header at all, turn on DKIM in your mail service's settings: publishing a DNS record is only half the job, the service must also start signing.

The key is cut or broken

A 2048-bit key is longer than 255 characters, the maximum length of a single DNS text string. The record must then be split into several strings inside one TXT record. Most DNS providers do this for you; some editors, or a copy-paste that drops a character, break the key. If the checker says the key cannot be read, paste the value again from your mail service, without line breaks or quotes added by hand.

DKIM passes, but DMARC still fails

DMARC needs DKIM to be aligned: the d= domain in the signature must match the domain in the visible From address (or share the same main domain in relaxed mode). If your newsletter platform signs with its own domain (d=platform.com), DKIM passes but does not count for your DMARC. Set up a custom DKIM domain in that platform so it signs as your domain.

DKIM fails on forwarded or mailing-list mail

Plain forwarding usually keeps DKIM intact, which is why it matters more than SPF for forwarded mail. Mailing lists that add a footer or change the subject break the signature. This is expected, and it is one reason DMARC passes when either SPF or DKIM passes and is aligned.

Rotating a DKIM key without downtime

To move from a 1024-bit key to a 2048-bit one, or to rotate keys regularly:

  1. Create the new key in your mail service under a new selector and publish its DNS record.
  2. Check it with the DKIM checker, then switch signing to the new selector.
  3. Keep the old record for a few days so messages still in transit can be verified, then remove it.

Google Workspace and Microsoft 365 both offer 2048-bit keys; Microsoft 365 rotates between selector1 and selector2 for you.

DKIM is one part of deliverability

DKIM, SPF and DMARC prove who you are. They do not make a bad list good: messages to addresses that do not exist still bounce, and a high bounce rate still hurts the reputation your DKIM signature is building. Check your SPF and DMARC records too, follow the Gmail, Yahoo and Outlook sender requirements, and verify your list before you send.

Frequently asked questions

Can a domain have several DKIM records?

Yes, under different selectors: one per sending service, or two while you rotate keys. What it must not have is two records under the same selector.

Do I need DKIM if I already have SPF?

Yes. Gmail and Yahoo require both from bulk senders, and DKIM survives forwarding where SPF often fails.

How long do DKIM changes take to work?

Usually minutes to a few hours, depending on the record's TTL. The checker reads public DNS, so it shows what receiving servers see now.

Sources