What is a DKIM Record?
DKIM adds a cryptographic signature to your outgoing email and publishes the matching key in DNS. Here's how the signing works, what the record looks like, and how to set it up.
Quick Answer
DKIM (DomainKeys Identified Mail) is an email authentication method that adds a digital signature to every message you send. Your mail server signs outgoing email with a private key, and the matching public key is published as a DNS TXT record at selector._domainkey.yourdomain.com. Receiving servers fetch that public key, verify the signature, and confirm the message really came from your domain and wasn't altered on the way. DKIM works alongside SPF and DMARC.
What is DKIM?
DKIM stands for DomainKeys Identified Mail. It's a way to prove two things about an email: that it genuinely came from your domain, and that nobody changed the content between your server and the recipient's. It does this with public-key cryptography.
When your mail server sends a message, it signs parts of that message with a private key that only it holds. It attaches the signature to the email as a DKIM-Signature header. The matching public key lives in your DNS as a TXT record. Any receiving server can fetch that public key and check the signature.
If the signature checks out, the receiver knows the message is authentic and unmodified. If someone forged the sender or tampered with the body, the signature fails. DKIM is one of the three pillars of email authentication, alongside SPF and DMARC.
How DKIM Signing Works
1. Your server signs the message
When you send an email, your mail server hashes selected headers and the body, then encrypts that hash with its private key. The result is attached as a DKIM-Signature header, which also names the domain and the selector to use.
2. The receiver reads the header
The receiving server reads the DKIM-Signature header to find the signing domain (the d= tag) and the selector (the s= tag). Together these tell it exactly where to look for the public key.
3. It fetches your public key from DNS
The receiver queries selector._domainkey.yourdomain.com for a TXT record. That record holds your public key.
4. It verifies the signature
Using the public key, the receiver checks the signature against the message it received. If they match, the email is authentic and unchanged. If not, DKIM fails and DMARC decides what happens next.
The private key never leaves your mail provider, and the public key can only verify signatures, not create them. That asymmetry is what makes forging a signed message impractical.
What a DKIM Record Looks Like
A DKIM record is a TXT record at a selector subdomain. Here's a typical one:
The value breaks down into a few tags:
| Tag | Meaning |
|---|---|
| v=DKIM1 | Version. Always DKIM1 and must come first. |
| k=rsa | Key type. RSA is standard; some providers now offer Ed25519. |
| p=... | The public key itself, base64 encoded. This is the long part. |
| t=y | Optional. Testing mode, which tells receivers not to act on failures yet. |
An empty p= value means the key has been revoked. If you see that on a selector you still use, your signing is broken.
DKIM Selectors
The selector is the label in front of ._domainkey. It exists so a single domain can hold several DKIM keys at once. Each signed email names its selector in the header, so the receiver always knows which key to fetch.
Selectors are why you can do two important things without downtime. First, key rotation: publish a new key under a new selector, switch signing to it, then remove the old one once no in-flight mail relies on it. Second, multiple senders: your mailbox provider and your marketing platform each sign with their own selector, so both pass DKIM for the same domain.
Tip: selectors are chosen by whoever generates the key, so you rarely pick them yourself. Google Workspace uses google, and many platforms use names like s1, k1, or a dated label.
SPF vs DKIM vs DMARC
The three work together. Each answers a different question, and DMARC needs at least one of the other two to pass.
| Method | Question it answers |
|---|---|
| SPF | Is this server allowed to send mail for the domain? |
| DKIM | Did the message really come from the domain, unaltered? |
| DMARC | What should happen when SPF or DKIM fails, and do the domains align? |
DKIM has one advantage over SPF: it survives forwarding. When a message is forwarded, the sending server changes and SPF often breaks, but the DKIM signature travels with the message and still validates. That's why DMARC accepts a pass from either one.
How to Set Up and Verify DKIM
1. Generate the key at your provider
In your email provider's admin console, turn on DKIM for your domain. Google Workspace, Microsoft 365, and platforms like SendGrid or Mailchimp generate the key pair and show you the exact record to publish, including the selector.
2. Publish the TXT record
Add the TXT record at your DNS host, using the full name the provider gives you (for example google._domainkey). Paste the value exactly as shown.
3. Wait for propagation, then verify
Give the record time to propagate, then confirm it resolves. Look up the selector subdomain as a TXT record and check that the value matches. Send a test email to a mailbox you control and view the headers to confirm DKIM passes.
4. Enable signing
Once the record is live, switch on DKIM signing in the provider console. From then on, every message you send carries a valid signature.
To confirm the record is visible everywhere, look up the TXT record for your selector across global servers with DNSFly's TXT Record Lookup. Enter the full name, such as google._domainkey.yourdomain.com. Or confirm the public key by selector with the DKIM Checker.
Common DKIM Problems
The key got split or truncated
A 2048-bit public key is longer than the 255-character limit for a single TXT string, so it must be split into multiple quoted strings that DNS joins back together. If your host mangled this, the key is invalid. Re-paste it exactly, or use a 1024-bit key if your host can't handle long values.
The selector doesn't match
The selector in your published record must match the one your server signs with. If the provider signs as s1 but you published under default, receivers look in the wrong place and DKIM fails.
Signing was never enabled
Publishing the record is only half the job. If you forget to switch on signing in the provider console, your mail goes out unsigned even though the DNS record is correct.
Stuck in testing mode
A t=y tag marks the key as testing, so receivers may ignore failures. That's fine while you set up, but remove it once you trust the signing.
Verify Your DKIM Record
After publishing your DKIM key, confirm it resolves everywhere by looking up the selector TXT record across 21 global servers. Enter the full name, like google._domainkey.yourdomain.com.