How to fix DKIM

Updated 17 October 2026, figures from the October 2026 census, snapshot 2026-10-12.

DKIM (DomainKeys Identified Mail) is the invisible tamper-proof seal on every email your business sends. It lets the receiving mail provider confirm the email came from you and arrived unchanged. Without it, your mail is easier to fake or alter, and far more likely to land in spam.

37,896,567 of the 76,563,365 domains where a DKIM selector could be looked for showed none: 49.5%.

Counted over the 76,563,365 domains with mail and a recognised provider, the only ones where a selector is discoverable from DNS (Domain Name System).

Without DKIM, the emails you send can be tampered with in transit, are easier for criminals to impersonate, and are more likely to be filtered into spam or rejected outright, which can cost you deals and payments.

Why DKIM matters

Email was never built to prove who sent it, and faking the sender is trivially easy. DKIM adds a cryptographic signature that the receiving provider checks automatically, confirming the message is from your domain and hasn't been altered on the way. It's one of the three things every modern mail provider looks for, it directly affects whether your email is trusted or junked, and the fix is free.

Fixing DKIM, in order

Turn on DKIM at your mail provider. Enable DKIM in your email platform; it generates a public key and a selector.
Publish the key in DNS. Add the CNAME (Canonical Name) or TXT (Text) record(s) your provider gives you, exactly as shown (Microsoft 365 uses two selector CNAMEs).
Enable signing. Switch on DKIM signing so outgoing mail is signed.
Cover every sender. Repeat for each tool that sends as you, so none break DMARC (Domain-based Message Authentication, Reporting and Conformance) alignment.
Verify it worked. Send a test and recheck to confirm the signature validates.

What DKIM is, in plain words

Every email your business sends travels through several hands before it reaches the inbox. By itself, an email carries no proof of who sent it or whether anyone changed it along the way: the “from” line is just text anyone can type.

DKIM fixes that. It puts an invisible, tamper-proof seal on each message your business sends. When the email arrives, the receiving mail provider checks the seal against a key you publish on your domain. If it matches, the provider knows two things for certain: the email came from your domain, and not a single character was changed in transit. If it doesn’t match (because the message was faked or altered), the seal fails, and the provider treats the mail with suspicion.

You don’t manage any of this by hand. Once it’s switched on, the signing and checking happen automatically on every email, forever.

What this can cost you

Here’s what a missing or weak DKIM seal looks like in practice for a small or medium business.

You email a customer an invoice. Somewhere between your server and theirs, an attacker intercepts it and swaps your bank details for their own. The email still appears to come from you, and the customer pays into the criminal’s account. Without DKIM, there’s nothing to flag that the message was tampered with. With it, the alteration breaks the seal and gets caught.
Your quotes, proposals and follow-ups keep slipping into customers’ junk folders. You never hear back and assume they weren’t interested. Unsigned mail is a strong spam signal, so your genuine business email simply wasn’t seen.
A bigger client’s procurement or security team checks your domain before signing and finds no DKIM key published. They hold the deal for weeks while you add one, or choose a supplier whose email passed.
A scammer sends convincing emails “from your company” to your customer base. Because nothing proves which messages are truly yours, the fakes look as legitimate as the real thing, and it’s your reputation that takes the hit when people get burned.
Banks, big mailbox providers and corporate filters increasingly distrust unsigned mail. Over time more of it is throttled, junked or bounced, until your everyday outreach stops reaching people.

How the seal works

DKIM stands for DomainKeys Identified Mail. Here’s how the seal works, without the jargon:

You publish a public key on your domain (in your DNS settings). Anyone can read it, and that’s the point.
Your mail provider holds the matching private key and uses it to sign every email you send, adding a hidden header.
When the email arrives, the recipient’s provider fetches your public key, checks the signature against the message, and confirms it’s genuine and unaltered.

A few terms you may hear from your IT person:

Selector. A label pointing to one specific key, e.g. selector1._domainkey.yourdomain. It lets you run and rotate multiple keys cleanly. Your provider sets this up.
Key strength. DKIM keys come in sizes. The modern baseline is 2048-bit RSA (Rivest-Shamir-Adleman); 4096-bit RSA or Ed25519 keys are stronger still. Older 1024-bit keys still function but are considered weak by today’s standards (NIST SP 800-131A / RFC 8301).

What “good” looks like: a valid DKIM key is published at a selector for your domain, your outgoing mail is being signed with it, and the key is 2048-bit or stronger. That’s the full pass.

A note on how this is scored. This check looks for a genuine, well-formed DKIM key published at the selectors mail providers commonly use. A published valid key is the positive signal. A third-party scanner can’t replay your live signatures, so the presence of a correct key is what’s measured. No key found fails the check (it’s a high-severity gap). A valid key that’s weak (1024-bit RSA) earns roughly half marks: it’s working but should be upgraded. A strong key (2048-bit RSA or better, or Ed25519) earns full marks. This is one of the email security checks that counts toward your grade, worth a meaningful share of it.

How to fix it (free, ~15 minutes)

This part is for whoever manages your email or domain. If that’s not you, hand them this section. The fix is free. If you want the exact steps for your own domain, in the safe order, the A-Grade Playbook sets them out.

The general shape is the same everywhere: switch on DKIM in your email provider, take the key it generates, publish it in your DNS, then confirm it’s live. The exact steps depend on who runs your email. Here are the common ones.

Google Workspace (Gmail)

Admin Console → Apps → Google Workspace → Gmail → Authenticate email.
Select your domain and click Generate new record (choose the 2048-bit key length).
Google gives you a DNS record. Add it at your DNS host as a TXT record, host google._domainkey.yourdomain, with the value Google provided.
Wait for it to propagate (minutes to a few hours), then return to the same screen and click Start authentication.

Microsoft 365 (Outlook / Exchange Online)

Go to the Microsoft Defender portal → Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM.
Select your domain. Microsoft shows you two CNAME records to publish (selector1 and selector2).
Add both CNAME records at your DNS host exactly as shown.
Back in the DKIM screen, toggle DKIM signing to Enabled for the domain.

Zoho Mail

Control Panel → Email Authentication → DKIM.
Generate a key (use a selector like zoho), then add the provided TXT record at zoho._domainkey.yourdomain in your DNS.
Verify in the Zoho panel once the record is live.

Other providers / your own mail server The pattern is identical: the provider (or your mail software) generates a key pair, signs your outgoing mail with the private key, and gives you a public record to publish. It typically looks like:

Host: selector1._domainkey.yourdomain
Type: TXT (or CNAME, depending on provider)
Value: (the long key string your provider gives you)

Where DNS records are added: in your domain’s DNS settings, usually at your domain registrar or DNS host (e.g. Cloudflare, GoDaddy, your hosting control panel). If your email provider supplies a CNAME, it’s pointing to a record they host, so you never see the raw key. That’s normal and fine.

Confirm it works: send yourself a test email to a Gmail account, open it, choose Show original, and check that DKIM: PASS appears. Then re-check your domain here to confirm the key came through as 2048-bit or stronger rather than a weak 1024-bit one.

Common mistakes

Assuming a big provider has it on by default. Plenty of domains on Google or Microsoft still need DKIM switched on and a record published. “We use Microsoft 365” is not the same as “DKIM is enabled.”
Generating a weak 1024-bit key. Some providers still default to or offer 1024-bit. Choose 2048-bit when given the option. A weak key only earns half marks and is flagged by stricter receivers.
Publishing the record but never enabling signing. Adding the DNS record is only half the job. If you don’t switch on signing in the provider (the final toggle), your mail still goes out unsigned.
Mistyping or truncating the key. DKIM keys are long. A copy-paste that drops a character or splits the value wrongly produces a broken seal that fails on every email. Paste the value exactly as given.
Forgetting your other senders. If you send mail through a newsletter tool, CRM, invoicing app or e-commerce platform, each may need its own DKIM key and selector. Sign mail from all the services that send on your behalf, not just your mailbox.

A note on DKIM, SPF and DMARC

DKIM rarely works alone. It’s one of three settings that together make your email trustworthy:

SPF (Sender Policy Framework) says which servers are allowed to send mail for your domain.
DKIM (this page) is the tamper-proof seal proving a message is yours and unchanged.
DMARC is the instruction telling providers what to do with anything that fails, and it relies on DKIM and SPF to make that call.

If you’re fixing DKIM, it’s worth checking SPF and DMARC at the same time. Together they stop others impersonating your business and help your email reach the inbox.

Where the change goes, host by host

The click path for the providers people ask about most:

Common situations

Questions people ask

I'm not technical. Is this something I can sort out myself?

You don't need to understand the cryptography. In most cases it's a setting you switch on inside your email provider (Google Workspace, Microsoft 365, Zoho, etc.), which then gives you one or two records to add to your domain. Hand the 'How to fix it' section to whoever manages your email or domain. It's a quick, free job, usually around 15 minutes.

Will turning on DKIM risk breaking my email?

Adding DKIM correctly is safe. Your mail is sent exactly as before, with a signature added that recipients can verify. The one thing to get right is to publish the key your provider generates exactly as given, and to enable signing only after the record is live in DNS. Done in that order, there's no disruption to you or your customers.

We already use a big provider like Google or Microsoft. Aren't we covered automatically?

Not always. Big providers make DKIM easy, but for many domains it still has to be switched on and a record added to your DNS. It isn't always on by default. That's exactly why a domain on a major provider can still fail this check. It takes a few minutes to confirm and enable.

What's the difference between DKIM, SPF and DMARC? Do I need all three?

Think of them as a set. SPF lists which servers are allowed to send mail for you. DKIM is the tamper-proof seal that proves a message is yours and unchanged. DMARC is the instruction that tells providers to block anything failing those checks. They work best together. DMARC in particular leans on DKIM to do its job, so yes, you want all three.

My IT person says DKIM is 'on'. How do I know it's working and strong enough?

Two things matter: that a valid signature is being published at a selector for your domain, and that the key behind it is strong (2048-bit RSA or better). An older 1024-bit key still works but is considered weak by modern standards and is treated as a partial pass here. Re-running a check on your domain confirms both at once.

What is a 'selector' and why does it matter?

A selector is just a label that points to one specific DKIM key in your DNS. It lets you run more than one key at a time (for example, one for your mailbox and one for your newsletter tool) and rotate keys safely. You don't manage it by hand; your provider creates the selector and tells you the record to publish. It only matters here because the check looks for a valid key at the selectors mail providers commonly use.

Figures as of 12 October 2026, from the October 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.