Free DKIM Record Checker

What is DKIM?

DomainKeys Identified Mail (DKIM) is an email authentication standard that lets a sending mail server cryptographically sign outgoing messages. The receiving server uses a public key published in DNS to verify the signature, confirming two things: the message came from a server authorized by the domain owner, and the message content was not altered in transit.

The signing process works like this. Your mail server takes specific headers and the message body, runs them through a hashing function, and encrypts the result with a private key that only your server holds. This signature is added to the outgoing message as a DKIM-Signature header. The receiving server fetches the corresponding public key from DNS—stored at selector._domainkey.yourdomain.com—and uses it to decrypt and verify the signature.

Unlike SPF, which only checks the IP of the sending server, DKIM travels with the message. That means DKIM survives email forwarding, where a relay server changes the sending IP and breaks SPF, but leaves the DKIM signature intact. For DMARC to pass via DKIM alignment, the domain in the DKIM signature's d= tag must match the From header domain. This is why DKIM alignment is the more reliable path to DMARC compliance compared to SPF alignment.

Common DKIM failures

Selector mismatch

The most common failure. The s= tag in the DKIM-Signature header of a signed email must exactly match a selector published in DNS. If you check a selector that does not exist—because you typed it wrong, or your provider uses a different one—you will get a "record not found" result. To find the correct selector, open a sent email in its raw header view and look for the DKIM-Signature header. The s= tag is your selector.

Empty p= tag (revoked key)

An empty p= tag—written p=; in the record—means the key has been intentionally revoked. Any signature made with that selector will now fail verification. This is typically done during key rotation: the old selector is emptied to invalidate old signatures before the DNS record is eventually deleted. If you see an empty p= and mail is still being signed with that selector, your sending server is using a retired key. Update it to the new selector immediately.

DNS propagation delay

After publishing a new DKIM record, DNS changes take time to propagate—anywhere from a few minutes to 48 hours depending on TTL settings and resolver caching. Testing immediately after adding the record will show a failure even if the record is correct. Wait for propagation before concluding there is a problem.

Intermediate relay modifying the message

DKIM signs specific headers and the body. If a relay server—a mailing list manager, a forwarding service, or a spam filter—adds to or rewrites the signed content, the signature becomes invalid. This is expected behavior when you use services that intentionally rewrite messages such as mailing list software. The fix is to configure those services to re-sign messages with their own DKIM key, or to use a signing configuration that only signs headers resistant to modification.

How to set up DKIM on Amazon SES

Amazon SES offers two DKIM signing methods. For most senders, Easy DKIM is the right choice.

Method 1: Easy DKIM (recommended)

Easy DKIM lets SES manage the key pair for you. SES generates a 2048-bit RSA private key, stores it internally, and gives you three CNAME records to publish in DNS. Using three records adds redundancy—SES rotates between them automatically, so key rotation happens without any action on your part.

To set it up: in the SES console, open your verified identity and navigate to the "DKIM" section. Choose "Easy DKIM" and select RSA_2048 as the key length. SES will display three CNAME records in the format token._domainkey.yourdomain.com → token.dkim.amazonses.com. Add all three to your DNS zone. Once they propagate, SES will begin signing outgoing mail automatically.

Method 2: BYODKIM (Bring Your Own DKIM)

BYODKIM lets you supply your own key pair, which is useful if you need to use the same DKIM key across multiple sending services or have a compliance requirement to control your private keys.

Generate a 2048-bit RSA key pair using openssl or a key management tool. Paste the private key into SES under the BYODKIM option. Then publish a single TXT record in DNS at your chosen selector under _domainkey.yourdomain.com. The record value must include v=DKIM1; k=rsa; p= followed by your base64-encoded public key. With BYODKIM, key rotation is your responsibility—set a calendar reminder to rotate annually.

After either method, use this checker to confirm the record is live and the p= tag is non-empty. If SES shows DKIM status as pending for more than 48 hours, check that the CNAME records are published on your actual DNS zone and not a subdomain zone, which is a common mistake when the domain uses split DNS.

How to read a DKIM record

A typical DKIM record looks like: v=DKIM1; k=rsa; p=MIGfMA0GCSqG.... Each semicolon-separated tag has a specific meaning:

v=

Version. Must be DKIM1. Always the first tag. If absent, some receivers reject the record entirely.

k=

Key type. rsa is the default if this tag is omitted. ed25519 is also supported and offers smaller signatures, though not all receivers verify it yet.

p=

Public key, base64-encoded. This is the key receivers use to verify signatures. An empty value (p=;) means the key has been revoked.

h=

Acceptable hash algorithms. Rarely specified explicitly; defaults to allowing both sha1 and sha256. Specifying h=sha256 disallows the weaker sha1.

s=

Service type. Specifies which services may use this key. Default is * (all services). Setting s=email limits the key to email only.

t=

Flags. t=y means the domain is in testing mode—receivers should not reject based on DKIM failures. t=s means the i= tag in signatures must match the d= domain exactly (no subdomain delegation). Remove t=y once DKIM is working correctly.