DKIM Records Explained: Improve Your Email Authentication and Deliverability

What is a DKIM record

A DKIM record is a DNS TXT entry that stores a public key, letting email servers confirm that a message actually came from the domain it claims to be from and wasn’t tampered with along the way. It works alongside SPF and DMARC as one of the three pillars of email authentication. Together, they’re what stops spammers from spoofing your domain and what determines whether your emails land in the inbox or the spam folder.

Before going further, a few terms worth knowing:

• •

  DKIM record: the DNS TXT entry that holds the public key receiving servers look up

• •

  DKIM signature: the cryptographic header attached to each outgoing email, generated with a private key

• •

  Selector: a label pointing receiving servers to the right public key in your DNS

The record and the signature often get confused, but they’re not the same thing. The record sits quietly in your DNS. The signature travels with every email you send.

How DKIM email authentication works

DKIM runs on a pair of cryptographic keys, one private and one public. Here’s how they work together, in order.

The private key and digital signature

When your mail server sends a message, it generates a unique digital signature using a private key and attaches it as a hidden header called DKIM-Signature. That signature typically covers the message headers and body. The private key never leaves your server, which is exactly the point.

The public key and DNS lookup

The receiving server reads the s= (selector) and d= (domain) values from that signature header, then queries DNS for the matching public key. This is where your DKIM record comes in. Without it, there’s nothing for the receiving server to check against.

The verification and authentication check

The public key decrypts the signature, and the server compares it to a freshly computed version of the message. If they match, DKIM passes. If even one character changed in transit, it fails, and that failure gets logged for DMARC reporting.

DKIM record syntax and example

A DKIM record has two parts: the record name and the record content. Once you know the pattern, spotting a broken one gets a lot easier.

Record name and selector format

DKIM records don’t sit under your plain domain name. They follow this format instead:

selector._domainkey.yourdomain.com

So a selector of google on acme.com becomes google._domainkey.acme.com.

Record content and public key

The value follows a tag-value format. v=DKIM1 tells the server this is a DKIM record, and everything after p= is the public key itself. If p= is empty, the key has been revoked on purpose, and the record is effectively switched off.

Record type and TTL

Technically, a DKIM record is just a DNS TXT record, the same type used to store all kinds of domain-related text. Most DNS providers default to a TTL of 3600 seconds (one hour), and that’s usually fine for DKIM.

What is a DKIM selector and how to find yours

Selectors exist because one domain often sends email through several services, and each one needs its own key. That’s why it’s common to see multiple DKIM records under a single domain, one per sending source.

Where to find your selector in email headers

Send yourself a test email to a Gmail account, open it, and choose “Show original.” Look for dkim=pass in the Authentication-Results header, or check the DKIM-Signature header directly for the s= tag. That value is your selector.

Common selectors by email provider

You won’t always need to dig through headers. Most providers default to a known selector:

• •

  Google Workspace: google

• •

  Microsoft 365: selector1, selector2

• •

  Mailchimp: k1

• •

  SendGrid: s1, s2

If you use an outreach tool like lemlist alongside your main provider, it typically publishes its own selector too.

How to set up a DKIM record step by step

The exact steps can vary slightly by provider, but the general process looks like this.

1. 1.

   List every domain and service that sends on your behalf, including your email provider, CRM, and any outreach tools.

2. 2.

   Generate a DKIM key pair. Most providers do this for you inside their admin console.

3. 3.

   Create the DNS record using the naming format covered above, then paste in the public key.

4. 4.

   Add the record through your DNS provider (Cloudflare, GoDaddy, Namecheap, and similar).

5. 5.

   Enable DKIM signing on your server. Some providers activate this automatically once the record verifies; others require a manual toggle.

6. 6.

   Test the setup with a real email and a DKIM checker.

Propagation and signing activation can take a little time, so don’t panic if it doesn’t pass on the first try.

TXT vs. CNAME records for DKIM

Not every provider asks for the same record type, and the difference comes down to who controls the key.

When to use a TXT record

A TXT record stores the full public key directly in your DNS, and you control when it changes. This is the standard approach, and it’s what the official DKIM specification describes.

When to use a CNAME record

Microsoft 365, for instance, uses CNAME records that point to Microsoft’s own DKIM infrastructure. That hands key management to the provider, letting them rotate keys without you ever touching DNS. SendGrid follows a similar model. Either approach works, so it’s worth checking what your provider recommends before assuming TXT is the only option.

How to check and verify your DKIM record

Once the record is live, confirming it actually works only takes your domain name and selector. Free tools like MxToolbox, EasyDMARC, or Google Admin Toolbox handle the lookup for you.

• •

  Pass: the tool returns the public key and confirms correct formatting

• •

  Fail: record not found, syntax error, or a mismatched selector

Running this check once after setup is useful. Running it across every mailbox manually, though, gets tedious fast, which is where lemlist’s Deliverability Hub comes in. It monitors DKIM and other authentication records across all your sending domains from a single dashboard.

Common DKIM record mistakes and how to fix them

Most DKIM failures trace back to one of a handful of predictable errors.

Incorrect selector or record name

A typo in the selector, or a missing ._domainkey. in the hostname, makes the record invisible to receiving servers. It’s worth comparing the full record name against your provider’s instructions, character by character.

Missing or malformed public key

Longer keys sometimes get split into multiple strings, and if your DNS provider truncates the value along the way, the key breaks silently. Checking that the entire base64 string is intact can save a lot of confusion later.

Using a weak key size

1024-bit keys were the default for years, but they’re now considered marginal against modern cryptanalysis. Google, Microsoft, Yahoo, and Amazon SES have all shifted their guidance toward 2048-bit as the minimum.

Forgetting to enable DKIM signing on the server

The DNS record only tells receiving servers where to look. If your sending server isn’t actually attaching a signature to outgoing mail, the record does nothing on its own, which is an easy step to overlook with third-party tools.

How DKIM works with SPF and DMARC

DKIM rarely works alone. It’s one layer in a three-part authentication stack:

• •

  SPF: confirms the sending server’s IP is authorized by the domain’s DNS

• •

  DKIM: confirms the message wasn’t altered and the signature matches the domain’s public key

• •

  DMARC: tells receiving servers what to do when SPF or DKIM fails, and requires at least one of them to pass with domain alignment

DKIM signatures also survive email forwarding, which SPF often doesn’t, making DKIM the more resilient piece for DMARC alignment. That’s why having both configured, rather than relying on just one, gives you the strongest protection.

Why DKIM matters for cold email deliverability

For anyone running outbound campaigns, DKIM isn’t optional anymore. Google and Yahoo now require bulk senders to authenticate with both SPF and DKIM, along with a DMARC record in place, and non-compliant emails face rejection. Beyond compliance, DKIM also feeds into how ISPs build domain reputation over time, alongside low spam complaints and healthy engagement.

Proper setup is just the starting point, though. Authentication needs monitoring, and new domains still need to warm up gradually. lemlist’s Deliverability Hub gives you per-mailbox DKIM monitoring with alerts when something breaks, and every seat includes lemwarm, which builds sender reputation on top of a correctly authenticated domain by exchanging real emails at a controlled pace.