What Is DKIM (DomainKeys Identified Mail)?

DKIM (DomainKeys Identified Mail) is an email authentication protocol that lets receiving servers verify that a message was actually sent by the domain it claims to come from, and that the content wasn’t changed in transit. It works by attaching a cryptographic signature to every outgoing email, which the receiving server checks against a public key published in your domain’s DNS. 

This guide covers what a DKIM record looks like, how the signing and verification process works step by step, how to read an actual DKIM-Signature header, and how to troubleshoot the failures that come up most often.

What Is a DKIM Record?

A DKIM record is a set of instructions published as a TXT record in your domain’s DNS. It holds the public key that corresponds to the private key your mail server uses to sign outgoing email. When a receiving server wants to check a signature, it looks up this record, retrieves the public key, and uses it to confirm the message hasn’t been altered and genuinely originated from your domain.

DKIM was originally formed in 2004 by merging Yahoo’s DomainKeys and Cisco’s Identified Internet Mail, and it’s since become one of the most widely adopted email authentication standards.

DKIM Record Format and Naming Convention

A DKIM record isn’t published at your root domain. It lives at a specific subdomain built from a selector and the fixed label _domainkey. The naming convention is:

[selector]._domainkey.[domain]

So a record signed with the selector google for yourdomain.com would be published at:

google._domainkey.yourdomain.com

The value of that TXT record looks like this:

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

Each tag has a specific role:

You can generate a valid record with our DKIM generator and confirm it’s published correctly with our DKIM checker tool.

What Is a DKIM Selector?

A DKIM selector is a unique identifier that tells the receiving server which key pair was used to sign a given message. It’s the alphanumeric string defined in the s= tag of the DKIM-Signature header, and it lets a domain manage multiple keys at once (for example, one selector for your mail platform and a different one for a marketing service. Each vendor you send through should use its own distinguishable selector.

For example, Google Workspace uses “google” as its default selector, so the full DNS lookup for a Google-signed message would be google._domainkey.yourdomain.com. If your record name were s1._domainkey.yourdomain.com, then s1 is your selector.

Learn more about selectors and how to find them in our detailed DKIM selector guide. 

DKIM Record vs. DKIM Signature: What’s the Difference?

These two terms get confused constantly, so it’s worth stating plainly. The DKIM record is the static TXT entry in your DNS that holds the public key, and you publish it once, and it sits there. The DKIM signature is the DKIM-Signature header added to each individual email as it’s sent, generated with your private key. One is a fixed DNS entry; the other is created fresh for every message. The record is what verifies the signature. We’ll break the signature header down field by field further below.

You can learn more about the latter in our complete guide to DKIM signatures. 

How Does DKIM Work?

DKIM authentication runs in four steps, from generating the keys through to the final pass/fail decision on the receiving end.

Step 1: Key Pair Generation

Your email provider or you generate a cryptographic key pair: a private key that stays secret on the sending mail server, and a public key that gets published to DNS as the DKIM record described above. The two are mathematically linked, so anything signed with the private key can only be verified with its matching public key.

Step 2: Signing the Outgoing Email

When you send a message, the sending server (the Mail Transfer Agent) uses the private key to compute a hash of specific parts of the email (the headers listed in the signature’s h= tag, plus the message body) and attaches the result as a DKIM-Signature header on the outgoing message.

Step 3: DNS Lookup by the Receiving Server

The receiving server reads the DKIM-Signature header, pulls out the selector (s=) and the signing domain (d=), and queries DNS for the public key at [selector]._domainkey.[domain], exactly the naming convention covered in the DKIM Record section above. This is where the per-message signature and the static DNS record meet.

Step 4: Verification

Using the retrieved public key, the receiving server verifies the signature and independently recalculates the hash from the message it actually received. It then compares the two. If they match, DKIM passes: the message is intact and authorized by the signing domain. If they don’t, DKIM fails, and the message may be flagged, quarantined, or rejected depending on the domain’s DMARC policy. 

You can confirm your own setup any time with our free DKIM checker tool linked above.

Inside a DKIM-Signature Header 

Here’s what an actual DKIM-Signature header looks like on a received email:

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=google;
c=relaxed/relaxed; h=from:to:subject:date:message-id;
bh=abc123...; b=xyz789...

Every field carries part of the information the receiver needs to verify the message:

The two fields that do the actual work are bh (the body hash) and b (the cryptographic signature). The d= field is the one that matters most for DMARC: if it doesn’t align with the visible From domain, DKIM can pass, and DMARC can still fail.

What Does “Canonicalization” Mean? (relaxed vs. strict)

The c= tag defines how forgiving the signature is about minor formatting changes made in transit. 

Relaxed mode (the common, recommended choice) tolerates small whitespace and header-case differences, which are almost inevitable as mail passes through servers. 

Strict mode (also called simple) demands a byte-for-byte match and breaks at the slightest change. This matters because mailing lists and forwarding servers frequently make tiny modifications (an added footer, a rewritten line) that would break strict canonicalization but survive relaxed. The value looks like c=relaxed/relaxed, where the first part applies to headers and the second to the body.

Why Does DKIM Matter?

Verifies Email Integrity (Prevents Tampering)

The signature is a tamper seal. If a message is intercepted and altered in transit, the receiver’s recalculated hash won’t match the signed hash, verification fails, and the email is rejected or flagged. This is DKIM’s core job: guaranteeing the content that arrives is the content that was sent.

Protects Sender Reputation and Deliverability

Properly signed emails earn trust from mailbox providers. A verified, consistently authenticated sending domain builds a stronger reputation with ISPs, which means your legitimate messages are more likely to reach the inbox instead of the spam folder, a direct benefit for marketing and transactional email alike.

Survives Email Forwarding (Unlike SPF)

This is the single most important practical distinction between the two protocols, and it’s easy to miss. Because a DKIM signature travels with the message, it keeps verifying even after the email is forwarded. SPF, by contrast, checks the sending server’s IP against the original domain’s SPF record, so when a message is forwarded, the forwarding server’s IP isn’t on that list and SPF breaks. That’s why DKIM is the more reliable of the two for maintaining DMARC alignment on forwarded and indirect mail flows.

Required by Google, Yahoo, and Microsoft for Bulk Senders

DKIM stopped being optional for high-volume senders. Under Google and Yahoo’s requirements that took effect in February 2024, and Microsoft’s equivalent rules rolling out from May 2025, any domain sending roughly 5,000 or more messages per day to those providers must authenticate with DKIM (alongside SPF and DMARC), or risk having your email rejected or filtered to spam. Even below that threshold, DKIM is now the baseline expectation for good deliverability.

DKIM vs. SPF vs. DMARC: How They Work Together

DKIM is one of three email authentication standards that are designed to be used together, not in isolation. Here’s how they divide the work:

In plain terms: SPF checks the sending server, DKIM checks the message integrity, and DMARC ties both back to the domain your recipients actually see in the From field, then adds a policy telling receivers what to do when a check fails. DKIM and SPF do the authenticating; DMARC does the aligning and enforcing. You want all three.

Common DKIM Failures and How to Fix Them

None of the top-ranking “what is DKIM” pages walks through what actually goes wrong. Here are the four failures you’ll run into most, and how to fix each. 

DKIM Signature Not Found

What this means: This error indicates that the receiving server found no DKIM signature. Usually, this means DKIM isn’t configured for the sending service you used, or the DNS record was never published. 

How to fix it: enable DKIM signing on every service that sends email as your domain, and confirm the record exists in DNS.

DKIM Signature Verification Failed

What this means: A signature was present but didn’t verify, meaning the body or signed headers were modified after signing. The most common cause is a mailing list or forwarding server adding a footer, rewriting the subject, or stripping headers. 

How to fix it: Relaxed canonicalization reduces this, and ARC (Authenticated Received Chain) exists specifically to preserve authentication results across forwarding hops. However, ARC is being deprecated soon, and DKIM2, once rolled out, will significantly reduce forwarding issues. 

Public Key Not Found in DNS

What this means: The receiver looked up the public key and came back empty. This is typically a selector or domain mismatch between the DKIM-Signature header and the actual DNS record name, a DNS propagation delay after a recent change, or a simple typo in the record name, most often a missing underscore in _domainkey.

How to fix it: Run your domain through a DKIM checker tool to review all errors and fix them one by one. 

Key Too Short / Weak Key

What this means: Many older email platforms and hosting panels still generate 1024-bit keys by default. RFC 8301 treats 1024-bit as the bare minimum but recommends at least 2048-bit for signing, and NIST classifies 1024-bit RSA as legacy-use only. Major receivers like Google still accept 1024-bit as a minimum, but recommend 2048-bit, so a 1024-bit key isn’t an outright failure today; it’s simply below the current standard, and its security margin keeps shrinking.

How to fix it: use a 2048-bit RSA key with rsa-sha256 as your default. Two things to watch when you upgrade: a 2048-bit public key is too long for a single 255-byte DNS TXT string, so it must be split into multiple quoted strings in the same record, and you should rotate keys every 6 to 12 months. 

DKIM Best Practices

• Use 2048-bit keys, not 1024-bit: Longer keys are stronger and increasingly required by major providers.
• Rotate keys at least once a year: Publish the new key in DNS before deactivating the old one so there’s no verification gap during the switch.
• Sign all outgoing email sources: Every third-party service (CRM, email marketing platform, help desk) needs its own DKIM signing configured under its own selector.
• Monitor pass/fail rates: Review your DMARC aggregate reports so you catch a broken selector or an unsigned sender before it hurts deliverability.

Limitations of DKIM

DKIM is essential, but it isn’t complete on its own. Given below are a few honest limitations:

DKIM doesn’t stop From-address spoofing by itself

DKIM authenticates the domain in the signature’s d= tag and confirms the message wasn’t altered, but it doesn’t check that d= matches the From address the recipient sees. That alignment check is DMARC’s job. And if an attacker gains access to a legitimate account or server, they can send a validly signed email.

DKIM depends on correct DNS publication

A misconfigured record, a propagation delay, or a wrong selector will cause DKIM to fail even for legitimate emails.

DKIM enforces no policy on its own

DKIM only produces a pass/fail result and doesn’t tell receivers what to do with a failure. Pairing it with DMARC, which uses DKIM (and/or SPF) results to apply a quarantine or reject policy, is what turns authentication into actual protection.

Key management adds operational complexity

Managing keys across multiple sending services, rotating them safely, and keeping every third-party sender aligned takes ongoing attention and regular monitoring. Manually doing this for multiple domains is not only time-consuming but also resource-intensive.

Enable DKIM with PowerDMARC

PowerDMARC lets domain owners set up DKIM alongside SPF and DMARC, with hands-on monitoring and reporting so you can track authentication results and catch errors as they happen without manual intervention. 

The platform handles multiple domains and high email volumes, and pairs hosted DKIM with the other authentication protocols for full-stack protection against email fraud. You can get DKIM and DMARC configured in minutes rather than wrestling with DNS by hand.

With PowerDMARC’s Hosted DKIM, you get:

• One-time CNAME setup, zero DNS edits after that: Connect your domain once, then manage every selector and key change from a single cloud dashboard instead of touching DNS for each update.
• Rotate keys without DNS access: Schedule and apply key rotation instantly from the dashboard, with no propagation delays or manual record edits, so there’s no downtime and no room for a syntax slip.
• Full key-length flexibility: Choose 1024, 2048, or 4096-bit keys and upgrade key strength without breaking authentication.
• A dedicated DKIM Analytics dashboard: Track email volume, DKIM pass rates, and per-selector performance in real time for fast visibility and troubleshooting.
• Multi-domain and MSP-ready control: Manage DKIM across hundreds of domains and subdomains from one place, with a multi-tenant view built for enterprises and service providers.
• A complete authentication stack in one platform: DKIM sits alongside DMARC, SPF, MTA-STS, and BIMI, and integrates with providers like Google Workspace and Microsoft 365.

Frequently Asked Questions

1. What does DKIM stand for?

DKIM stands for DomainKeys Identified Mail. It’s an email authentication protocol that uses a cryptographic signature to verify that a message came from the claimed domain and wasn’t altered in transit.

2. What is DKIM in simple terms?

You can think of DKIM as a tamper-proof seal on your email. Your server signs each message with a private key, and the receiving server checks that seal against a public key in your DNS. If the seal is intact, the email is genuine and unmodified.

3. How do I set up DKIM for my domain?

To set up DKIM, you need to generate a key pair (via your email provider or our DKIM generator), configure your sending server to sign outgoing email with the private key, and publish the public key as a TXT record at selector._domainkey.yourdomain.com. You can view our full set up DKIM guide for step-by-step instructions.

4. Is DKIM enough on its own?

No. DKIM verifies message integrity but doesn’t check the visible From address or enforce a policy. You need to pair it with SPF and DMARC for complete protection against spoofing.

5. What’s the difference between DKIM and SPF?

SPF authorizes which servers may send email for your domain (verifying the path), while DKIM verifies the message content wasn’t altered and was signed by the domain (verifying integrity and origin). DKIM signatures often survive forwarding, while SPF usually breaks when email is forwarded.

6. How do I check if DKIM is set up correctly?

To check if your DKIM record is set up correctly, use PowerDMARC’s free DKIM checker. Simply enter your domain and selector, and it queries DNS to confirm your record is published, well-formed, and retrievable.

7. What happens if DKIM fails?

A DKIM failure means the message was either tampered with or not properly signed. Receivers may flag it as spam, and if a DMARC policy is in place and SPF doesn’t pass either, the message may be quarantined or rejected outright.

8. How often should DKIM keys be rotated?

DKIM keys should be rotated at least once a year. Always publish the new key in DNS before deactivating the old one, so there’s no gap where email can’t be verified.

9. Can DKIM prevent phishing?

DKIM alone cannot prevent phishing. DKIM makes forging your email harder and stops content tampering, but it doesn’t block spoofing of the visible From address; only DMARC alignment does that. DKIM is one necessary layer of an anti-phishing setup, not the whole solution.

10. Does DKIM affect email deliverability?

DKIM has a positive impact on your email deliverability. A properly signed email builds sender reputation with ISPs, improving inbox placement, and with Google, Yahoo, and Microsoft now requiring DKIM for bulk senders, missing it can send your email to spam or get it rejected.