DKIM for Email: What It Is and How to Check It

You hit send on a campaign, and it travels through several servers before it reaches a subscriber. How does the receiving server know the email came from you, and that nobody changed it along the way? 

That is the job DKIM was built to do.

DKIM (DomainKeys Identified Mail) is an email authentication method that adds a digital signature to the emails your domain sends. The signature proves your domain took responsibility for the message and that its content was not altered in transit.

Analytics platforms like Email Audit Engine can show when delivery or engagement starts to slide, and a failing signature is one of the quieter causes behind that kind of drop.

DKIM sounds technical, but the moving parts are few: a key pair, a selector, and a record in your DNS. Once you can find those three things, checking your setup takes a couple of minutes. The sections below cover each one, plus the failures that trip people up most often.

What Is DKIM in Email?

DKIM is a way of signing your emails so receiving servers can verify them. Each signed email carries a hidden signature in its header, and the receiving server checks that signature against a key you publish in your domain's DNS. If they match, the email passes.

The method relies on a key pair. The private key stays with the server that sends your email and is used to create the signature. The public key is published in DNS, where any receiving server can look it up and use it to check the signature.

For marketers, the payoff is trust. Mailbox providers use DKIM results as one of the signals they weigh when filtering email. A valid signature tells them your domain stands behind the message, which supports inbox placement and, over time, your email marketing success.

How Does DKIM Work When You Send an Email?

The easiest way to picture DKIM is as a tamper-proof seal on a package. Your sending server applies the seal, and the receiving server checks that it is intact. If someone opens the package and changes the contents, the seal no longer matches.

In technical terms, the process has three steps. First, your sending server uses the private key to sign selected parts of the email, including key headers and the body, and adds a DKIM-Signature header. 

Second, the receiving server reads that header to find two values: the signing domain (d=) and the selector (s=). Third, it uses those values to fetch your public key from DNS and verify the signature.

If the signature checks out, the email passes DKIM. If the content changed after signing, or the public key cannot be found, the email does not pass. Either way, the result is recorded in the email header, which you will check when testing your own setup.

What Does a DKIM Record Look Like?

A DKIM record lives at a specific address in your DNS that combines a selector, the label domainkey, and your domain. For example, a record with the selector "s1" would sit at s1.domainkey.yourdomain.com. Inside, the record looks something like this:

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

The v=DKIM1 tag identifies the record as DKIM. The k=rsa tag names the key type. The p= tag holds the public key itself, which is a long string of characters and is usually the part people paste incorrectly.

The selector is what lets one domain have several DKIM keys. Each service that sends email for you, such as your marketing platform and your support desk, can use its own selector and key. 

Some platforms ask you to add a CNAME record that points to a key they host, rather than a TXT record you manage yourself, so always follow the exact instructions your platform provides.

Key length matters too. Longer keys are harder to crack, and 2048-bit keys are widely recommended over older 1024-bit keys. If your DNS provider supports it, 2048-bit is the safer choice.

How Do You Check Your DKIM Record?

Unlike SPF, you cannot check DKIM with your domain name alone. You also need the selector, and the quickest place to find it is a real email. Once you have both, the rest is a lookup and a test email. 

Start by sending an email from your platform to a personal inbox. Open the full message header and find the DKIM-Signature line. The value after s= is your selector, and the value after d= is the signing domain.

Next, enter the domain and selector into a free online DKIM lookup tool. It will show whether a public key exists at that address and whether the record is formatted correctly. If you prefer the command line, dig TXT selector._domainkey.yourdomain.com returns the same record.

Finally, confirm the result in practice. In the same email header, look for the Authentication-Results line and check for dkim=pass. Also check that the d= domain is your own domain and not only your email platform's domain, because that detail matters for DMARC.

What Do DKIM Check Results Mean?

A DKIM check returns one of a few results, and each points you in a different direction. Knowing what they mean saves a lot of guesswork when something goes wrong. The result appears in the email header, so you can always see it for yourself.

A pass means the signature is valid and the content was not changed. A fail means the signature did not verify, either because the key did not match or because the email changed after signing. A neutral result means the signature could not be evaluated in a meaningful way, and none means the email was not signed at all.

There are also two error results. A temperror points to a temporary problem, such as a DNS lookup that timed out, so the check may pass on a retry. A PermError points to a lasting problem, such as a malformed key, and needs fixing.

One message deserves special mention: "body hash did not verify." It means the body of the email changed between signing and delivery. Forwarding services, mailing lists that add footers, and some security gateways are common causes, so it is worth investigating where your email is being modified.

What Are Common DKIM Problems and How Do You Fix Them?

Most DKIM failures trace back to a short list of causes. Work through them in order, and you will usually find the culprit. Most of them are DNS edits rather than changes to your campaigns. 

The most common is a missing record. A new sending service gets added, but nobody publishes its DKIM key, so its emails go out unsigned or fail. Check every tool that sends email for your domain and make sure each one has a working key.

Next come record mistakes. A wrong selector, a record added under the wrong name, or a public key broken by extra spaces, line breaks, or a cut-off string will all cause failures. 

TXT records store text in strings of up to 255 characters, so a 2048-bit key often has to be split, and DNS editors handle that split differently. Paste carefully and verify the record with a lookup tool after saving. 

The last group is about strength and alignment. Short or old keys are weaker, so upgrade to 2048-bit where you can and rotate keys periodically. 

If your emails are signed only with your platform's shared domain rather than your own, DKIM may pass but fail to support DMARC, so set up domain authentication in your platform to sign with your own domain.

How Does DKIM Work With SPF and DMARC?

DKIM and SPF solve related problems in different ways. SPF checks which server sent the email, while DKIM checks whether the message itself is genuine and unchanged. Because the signature travels with the email, DKIM usually survives forwarding, which is one of the main situations where SPF breaks.

DMARC ties the two together. It tells receiving servers what to do when an email fails authentication, and it requires alignment. 

For DKIM to count toward DMARC, the signing domain in d= needs to align with the domain in your visible “From” address. By default, that means both share the same main domain, so mail.yourdomain.com aligns with yourdomain.com. 

That is why DKIM belongs on every email deliverability audit checklist. An audit that checks SPF alone can miss forwarded mail that only DKIM protects. Checking all three records together shows which messages are covered and which slip through. 

Frequently Asked Questions

What is DKIM in email?

DKIM stands for DomainKeys Identified Mail. It adds a digital signature to your emails that receiving servers verify with a public key in your DNS. A valid signature shows the email came from your domain and was not changed.

How do I find my DKIM selector?

Send yourself an email and open the full message header. Find the DKIM-Signature line and look for the s= value. That value is your selector.

How do I check if DKIM is working?

Look up your record with a DKIM lookup tool using your domain and selector. Then send a test email and check for dkim=pass in the Authentication-Results header. Confirm the d= value shows your own domain.

Why is my DKIM failing?

Common causes include a missing record, a wrong selector, or a public key that was pasted incorrectly. Content changes after sending, such as an added footer, can also break the signature. Check the header for the exact error to narrow it down.

What DKIM key length should I use?

A 2048-bit key is widely recommended. Older 1024-bit keys are shorter and easier to break, so they offer less protection. Use 2048-bit if your DNS provider supports it.

Do I need DKIM if I already have SPF?

Yes, because the two protect against different problems. SPF checks the sending server, while DKIM verifies the message itself and usually survives forwarding. DMARC works best when both are in place.

How often should DKIM keys be rotated?

There is no single required schedule, but rotating keys periodically limits the damage if a private key is ever exposed. Many organizations rotate on a fixed cycle as part of their security routine. At a minimum, replace any key that is short, old or possibly compromised.

Does DKIM stop email spoofing on its own?

No, DKIM alone does not stop spoofing. It proves a signed email is genuine, but it does not tell receivers what to do with unsigned or failing emails. DMARC adds that instruction.

What Should You Check Next?

A valid DKIM signature tells mailbox providers two things: the email came from your domain, and nobody changed it on the way. 

That is why a missing key, a mistyped record, or a footer added in transit can hurt campaigns that are otherwise sound. The checks that catch these problems are quick, from reading the selector in a header to confirming dkim=pass on a test email.

Keep DKIM on your list whenever your sending setup changes. A new tool, a DNS migration, or a key that has not been rotated in years are all moments to recheck it. 

Treat it as one part of a system with SPF and DMARC, and the three records will cover each other's gaps.

Once authentication is solid, the more interesting questions are about performance.

Mailchimp users can run a free email marketing audit in Email Audit Engine on their existing campaign data, which makes it easier to see whether engagement is moving in the same direction as deliverability. It is a useful next step after any authentication fix.