DKIM Explained: How Email Signatures Protect Your Domain

February 14, 20267 min read

SPF checks which servers are allowed to send email for your domain. DMARC tells receivers what to do when authentication fails. But there's a third protocol that ties everything together, and it's the one most people understand the least.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every email you send. It proves that the email actually came from your domain and that nobody tampered with it in transit. Without DKIM, you're relying entirely on IP-based checks, which break the moment your email is forwarded.

How DKIM works

DKIM uses public-key cryptography. When your mail server sends an email, it signs parts of the message (typically the headers and body) with a private key that only your server knows. It adds the signature to the email as a header called DKIM-Signature.

The receiving mail server looks up your public key, which you publish as a DNS TXT record, and uses it to verify the signature. If the signature checks out, the receiver knows two things: the email genuinely came from your domain, and the content wasn't altered after it was signed.

Unlike SPF, DKIM survives email forwarding. When someone forwards your email, the DKIM signature stays intact because it's attached to the message itself, not tied to the sending server's IP address.

Why DKIM matters for deliverability

Major email providers like Google, Microsoft, and Yahoo all factor DKIM into their spam filtering decisions. A valid DKIM signature is a strong positive signal. Without it, your emails are more likely to be flagged as suspicious, even if they're completely legitimate.

Google has required DKIM for bulk senders since February 2024. If you send more than 5,000 emails per day to Gmail addresses and don't have DKIM set up, your messages will increasingly be rejected or sent to spam.

DKIM is also a prerequisite for BIMI (Brand Indicators for Message Identification), which lets your brand logo appear next to your emails in supporting inboxes. No DKIM means no BIMI, and no visual trust signal for your recipients.

Setting up DKIM

DKIM setup involves two parts: configuring your mail server to sign outgoing emails, and publishing the public key in DNS.

Most email providers handle the signing part automatically. If you use Google Workspace, Microsoft 365, or any modern email platform, DKIM signing is built in. You just need to enable it and publish the DNS record they give you.

A typical DKIM DNS record is published at selector._domainkey.yourdomain.com as a TXT record. The selector is a label chosen by your email provider (like "google" or "selector1") that lets you have multiple DKIM keys for different services.

The tricky part is that each service that sends email on your behalf needs its own DKIM configuration. Your email provider, your marketing platform, your transactional email service, your helpdesk. Each one needs to sign emails with DKIM, and each one needs its own DNS record.

This is where most organizations fall behind. They set up DKIM for their primary email but forget about the other services sending as their domain.

DKIM and DMARC alignment

DKIM becomes especially important when you pair it with DMARC. For a message to pass DMARC, it needs to pass either SPF or DKIM, and the passing protocol must align with the From domain.

DKIM alignment means the domain in the DKIM signature (the d= value) must match the domain in the email's From header. If your email is from user@yourdomain.com, the DKIM signature should be signed with d=yourdomain.com.

Relaxed alignment (the default): the DKIM signing domain can be a subdomain of the From domain, or vice versa. So d=mail.yourdomain.com aligns with from@yourdomain.com.
Strict alignment: the domains must match exactly. d=mail.yourdomain.com would not align with from@yourdomain.com.

If your SPF record breaks due to forwarding or exceeding the 10-lookup limit, DKIM alignment is what keeps your emails passing DMARC. This is why having both SPF and DKIM configured is critical. They back each other up.

Common DKIM mistakes

We audit hundreds of domains, and these are the DKIM issues we see most often:

Using weak keys: RSA keys shorter than 2048 bits are considered weak. Some older setups still use 1024-bit keys, which are increasingly flagged by receivers. Generate new 2048-bit keys if yours are outdated.
Forgetting third-party senders: your primary email has DKIM, but your CRM, newsletter tool, or billing system sends unsigned emails. Each third-party sender needs its own DKIM setup.
Stale keys: DKIM keys should be rotated periodically. If your private key is compromised and you haven't rotated, an attacker could sign emails as your domain. Rotate keys at least annually.
Broken DNS records: DKIM public keys are often long and can get truncated or split incorrectly across DNS records. Always verify your DKIM record after publishing it.

Testing your DKIM setup

After setting up DKIM, verify it works. Send a test email and check the headers. Look for a "dkim=pass" result in the Authentication-Results header. If you see "dkim=fail" or no DKIM result at all, something is misconfigured.

MailShield checks DKIM automatically for every domain you monitor. We detect missing DKIM records, weak keys, alignment issues, and third-party senders that aren't signing properly. Your security score reflects the state of your DKIM configuration alongside SPF, DMARC, and other protocols.

If you're not sure where your DKIM setup stands, add your domain to MailShield. We'll show you exactly which services are signing with DKIM, which ones aren't, and what to fix first.