DKIM checker

What a DKIM record does

DKIM (DomainKeys Identified Mail, RFC 6376) lets your mail provider sign each outgoing message with a private key. The matching public key is published in your DNS. A receiving server reads the signature, fetches the public key, and checks two things: that the message was signed by your domain, and that the signed parts (the body and the important headers) weren’t changed on the way.

Unlike SPF, a DKIM signature travels with the message, so it usually survives forwarding. That makes it the more dependable half of DMARC, which needs at least one of SPF or DKIM to pass and align with your From domain.

Selectors: why you may need to type one

A domain can have several DKIM keys at once, one for each service that sends as it, plus spares during key rotation. Each key sits under a name called a selector, at selector._domainkey.yourdomain. The selector is written into every signature (the s= value in the DKIM-Signature header), so receivers know which key to fetch. Nothing in DNS lists your selectors, so a checker can only test names it already knows or that you give it.

When you leave the selector empty, this checker tries the fixed names that well-known providers document:

• google: Google Workspace’s default (Google)
• selector1, selector2: Microsoft 365 (Microsoft)
• s1, s2: SendGrid automated security (Twilio SendGrid)
• k2, k3: Mailchimp
• mte1, mte2: Mailchimp Transactional, formerly Mandrill (Mailchimp)
• fm1, fm2, fm3: Fastmail (Fastmail)

Many services generate a selector unique to your domain instead. Amazon SES’s Easy DKIM uses randomly generated names (AWS), Postmark uses a date-based name ending in pm (Postmark), and Zoho lets the admin choose. For those, find the selector in the provider’s DNS settings or in the header of a message you sent, and enter it above.

How to read the results

For each selector, the checker fetches the TXT record (following a CNAME if your provider hosts the key), parses its tags, decodes the public key and reports its type and size:

• Pass: a valid RSA key of 2048 bits or more, or a valid Ed25519 key.
• Warning: a 1024-bit RSA key, a key marked as testing (t=y), more than one key record at the same selector, only Ed25519 keys, or no key found at the common selectors.
• Fail: no key at a selector you entered, an empty key (p=, meaning revoked), a key that doesn’t decode, an RSA key under 1024 bits, a record that limits hashing to SHA-1, or an unsupported key type.

An empty p= is reported differently on domains with no mail servers. There, a revoked key is deliberate: it makes every forged signature fail.

Key type and length

RFC 8301 updated DKIM’s cryptography. Signers must use RSA keys of at least 1024 bits and should use at least 2048. Receivers must not accept signatures from keys under 1024 bits, and the old rsa-sha1 algorithm must not be used for signing or verifying. Google also asks for at least 1024 bits and recommends 2048 if your DNS host supports it.

A 2048-bit public key is longer than a single 255-character DNS string, so it’s published as several strings in one TXT record. Most DNS panels handle this for you. If yours doesn’t, the key gets cut off, and the checker reports that it can’t be read.

Ed25519 keys (RFC 8463) are much shorter and are published with k=ed25519. Receivers are required to verify them, but RFC 8463 expects senders to add an RSA signature alongside while support spreads, so an Ed25519 key on its own gets a warning.

What a good record looks like

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

The v=DKIM1 tag is optional, but when present it must come first. k=rsa is the default. p= holds the base64-encoded public key, and that’s the only part that must be exact. Many providers instead ask you to add a CNAME that points your selector, such as s1._domainkey, at a name they host, so they can rotate keys without you touching DNS. That’s fine: the checker follows it.

Common mistakes, and how to fix each

• DKIM set up in DNS but not switched on. Some providers, including Google Workspace, only start signing after you click “Start authentication” once the record is live. Publishing the key isn’t enough.
• Host entered with the domain twice. Many DNS panels append your domain automatically, so s1._domainkey.acme.com becomes s1._domainkey.acme.com.acme.com. Enter just s1._domainkey.
• A key pasted with a missing character or extra quote marks. The key won’t decode. Copy it again from the provider, as one value.
• An old 1024-bit key. It works, but rotate to 2048 bits when your provider supports it.
• A key left in testing mode. t=y asks receivers to treat your signatures as experimental. Remove it once mail is flowing.
• Signing with a domain that doesn’t match your From address. Some services sign with their own domain until you set up a custom one. DKIM passes, but it doesn’t align, so it doesn’t help DMARC. Set up domain authentication so the d= in the signature is your domain.

Why DKIM matters for support email

Gmail requires SPF or DKIM from every sender and both from senders of more than 5,000 messages a day, with a key of at least 1024 bits (Gmail sender guidelines). Yahoo’s requirements match, and it recommends a 1024-bit minimum (Yahoo best practices). Outlook.com requires DKIM to pass for domains sending over 5,000 a day (Microsoft).

Support conversations are often forwarded: a customer forwards your reply to a colleague, or a shared mailbox relays it. SPF breaks when mail is forwarded, because the forwarding server isn’t on your list. DKIM usually survives, so a properly aligned DKIM signature is what keeps your replies passing DMARC after they leave the first inbox.