DKIM (DomainKeys Identified Mail) is an email authentication standard that adds a cryptographic signature to each message, so the receiving server can confirm which domain took responsibility for it and that the signed parts weren't changed on the way. The signature travels in a message header, and the public key that checks it is published in your DNS.

Most teams set it up once, see a green tick in their email platform and never look at it again. That's fine for the mailbox provider their people use. The trouble starts with everything else that sends as the company: the marketing platform, the support desk, the billing tool, the cold email domains. Each one signs separately, and when one of them signs with its own domain instead of yours, DKIM still reports a pass while DMARC reports a fail.

So the useful questions about DKIM are less about what the acronym stands for and more about who is signing as you, with which key, under which domain.

TL;DR

• A DKIM signature proves which domain vouched for a message and that the signed headers and body arrived unchanged. It doesn't encrypt anything, and it doesn't decide whether you land in the inbox.

• The DKIM-Signature header names the signing domain (d=) and a selector (s=). The receiver fetches the public key from a DNS record at selector._domainkey.yourdomain and checks the signature against it.

• Selectors let every sending tool hold its own key on the same domain. Microsoft 365 publishes two CNAME selectors and rotates keys by switching between them, and we keep a register of which selector belongs to which tool.

• Use 2048-bit RSA keys. RFC 8301 sets 1024 bits as the minimum and 2048 as the recommendation, Google recommends 2048 unless your DNS host can't store it, and rsa-sha1 is no longer allowed at all.

• DMARC checks alignment, not just a pass. The d= domain has to match your From domain, or share its organizational domain in relaxed mode, so a tool that signs with its own domain passes DKIM and still fails DMARC.

• Broken DKIM never throws an error in your sending tool. Look up the selector in DNS, send a test to an outside inbox, read the d= value in the Authentication-Results header, and watch your DMARC aggregate reports.

• A pass settles who you are and nothing more. Reputation, list quality and engagement still decide where a signed message lands.

What a DKIM signature proves, and what it leaves alone

The standard itself, RFC 6376, describes DKIM as a way for a person, role or organization to claim some responsibility for a message. In practice that means a domain. When a receiver verifies the signature, it learns two things: the domain named in the signature really did sign this message, and the parts it signed (the body and a chosen list of headers) haven't changed since.

That covers impersonation of the signing domain and tampering in transit, two things email was originally built with no way to check.

What it doesn't cover is just as worth knowing. The RFC says plainly that no attempt is made to include encryption, so anyone who can read the message in transit still can. A valid signature also says nothing about whether the mail is wanted. A spammer with their own domain can sign perfectly well, which is why receivers treat DKIM as an identity check and then judge the sender on domain reputation and behavior.

And DKIM alone doesn't stop someone putting your name in the From line. An attacker simply sends unsigned mail, or mail signed by a domain they own. Telling receivers to reject that is DMARC's job, which is why DKIM is one of three DNS authentication records rather than a fix on its own.

Reading a DKIM-Signature header, tag by tag

The quickest way to understand DKIM is to open a signed message ("Show original" in Gmail) and find a header like this one, shortened here: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yourcompany.com; s=google; h=from:to:subject:date; bh=…; b=…

The sending server hashes the body into bh, then signs that hash together with the listed headers using a private key only it holds. The receiver reads d= and s=, looks up the TXT record at the selector under a _domainkey subdomain (google._domainkey.yourcompany.com in this example), and checks the signature with the public key it finds there. If the two match, the result is dkim=pass.

The c= tag matters more than it looks. RFC 6376 defines a simple mode that tolerates almost no modification and a relaxed mode that tolerates common changes like rewrapped whitespace. Relaxed/relaxed is the sensible choice for mail that passes through gateways before it arrives.

DKIM selectors let several tools sign for one domain

Selectors exist so a domain can publish several public keys at once. All DKIM keys live under the _domainkey subdomain, and the selector picks one of them. Without selectors, two services couldn't sign for the same domain.

A typical B2B company sends from more places than it thinks: the mailbox provider, the CRM or marketing platform, a support desk, an invoicing tool. Each should sign under your domain with its own selector. Google Workspace uses google as its default selector. Microsoft 365 asks for two CNAME records, selector1._domainkey and selector2._domainkey, that point at keys Microsoft hosts for you.

Those two Microsoft selectors also show how key rotation works. Microsoft's DKIM documentation explains that only one selector is active at a time, and the second is used only after a rotation, once the first is switched off. Mail never goes out unsigned during the change. Where a platform hosts the key behind a CNAME, it can rotate without anyone touching DNS. With a plain TXT record, rotation means publishing a new selector, moving the signer over, and removing the old record once mail signed with it has had time to arrive.

We keep a short register for every client domain: the selector, the tool that owns it, the key length and the date it went live. It sounds like paperwork until a vendor is dropped and its selector is still published, because then a private key outside your control can still produce valid signatures for your domain.

Key length: why 2048 bits is the one to ask for

RFC 8301 updated DKIM's cryptography. Signers must use RSA keys of at least 1024 bits and should use at least 2048, and verifiers must not accept signatures made with anything shorter than 1024. The same document took rsa-sha1 out of use for both signing and verifying.

Google's Workspace setup guide recommends 2048-bit keys and keeps 1024 as a fallback for domain hosts that can't store the longer record. The catch is length. Google notes that most DKIM TXT records hold up to 255 characters per string, and a 2048-bit key is longer than that, so it has to be split into several quoted strings inside one TXT record. Most DNS hosts do this for you. Some don't, and the key ends up truncated or split across two separate records, and both of those fail verification.

Microsoft 365 deserves a check of its own. Its PowerShell command for creating a DKIM configuration uses 1024 bits unless you ask for 2048, and a change of key size only takes effect at the next rotation. If a domain was connected to Microsoft 365 a few years ago and nobody has rotated since, look at the key length before you assume it's current.

DKIM alignment: the check DMARC actually runs

DMARC doesn't ask whether DKIM passed. It asks whether a passing signature was made by the domain in the visible From address. The DMARC standard, republished in May 2026 as RFC 9989 to replace RFC 7489, calls this identifier alignment. It's also the version of DKIM that Gmail and Yahoo expect from bulk senders, and since those rules already get a full treatment under email deliverability, we'll skip them here.

Alignment comes in two modes, set with the adkim tag in your DMARC record. Relaxed, the default, accepts a signing domain that shares the organizational domain with the From address, so a signature from mail.yourcompany.com aligns with a From of yourcompany.com. Strict wants an exact match.

The classic failure goes like this. You send from you@yourcompany.com through a tool nobody connected to your DNS. The tool signs anyway, with d=sendingtool.io. The receiver verifies that signature, DKIM passes, and DMARC still fails on the DKIM side because sendingtool.io isn't your domain. In DMARC aggregate reports it shows up as one sending source with DKIM passing and alignment failing. The fix sits in that tool's settings, where you add its DKIM record to your DNS so it signs as you.

DMARC passes when either SPF or DKIM aligns, so why insist on both? Because the Sender Policy Framework checks the server that handed over the message, and forwarding changes that server. A DKIM signature sits inside the message, so an aligned signature usually survives a forward that breaks SPF, as long as nothing rewrites the content on the way.

Where signatures break once real mail starts flowing

A broken signature doesn't show up as an error in your sending tool. Mail goes out, some of it fails verification at the other end, and the first sign is usually a dip in replies a week later. These are the causes we run into most when we look at a client's domain:

• A tool nobody connected. It signs with its own domain or not at all. The usual suspects are tools another team added: billing, support, a webinar platform.

• A record pasted wrong. A missing semicolon, a stray space, smart quotes copied in from a document, or a long key published as two TXT records instead of one.

• A Workspace key published but never switched on. Google's setup has a separate Start Authentication step, and the key in DNS does nothing until someone clicks it.

• A message changed after signing. RFC 6376 points out that mailing lists commonly add trailers, and security gateways that rewrite links or add disclaimers do the same. Once the body changes, the body hash no longer matches.

• An old key nobody owns. A vendor you stopped paying still has a published selector. Revoke it by emptying its p= value or delete the record.

• A short key on an old setup. A 1024-bit key still validates, but it sits below what RFC 8301 and Google recommend.

These are also the first items on the list in an outbound deliverability audit, because they're cheap to find and they make every other fix pointless until they're sorted.

Checking a DKIM record, and reading the result

Start with DNS. A TXT lookup on your selector, for example google._domainkey.yourcompany.com, should return a single record that starts with v=DKIM1 and carries a full p= value. RFC 6376 treats an empty p= as a revoked key, so if that's what comes back for a selector you still use, the signer is pointing at a dead key.

Then send a real message to an inbox outside your organization. Google says you can't confirm Workspace DKIM by sending a test to yourself, so use a personal Gmail address and open the original. The Authentication-Results header will show something like dkim=pass header.d=yourcompany.com. Read the domain, not just the word pass, because a pass for the wrong domain is the alignment problem from the section above.

A failure that mentions the body hash means the message changed after it was signed, so look at footers, link rewriting and gateways. A result saying no key was found points at DNS: the wrong selector, a missing record, or a change that hasn't spread yet. Google says a new key can take up to 48 hours to start working.

For ongoing monitoring, DMARC aggregate reports are the best source, since they cover every service sending as your domain at every receiver that reports back. Google's Postmaster Tools adds authentication data for mail to personal Gmail accounts, though Google warns it can be missing at low daily volume, which is common for outbound spread across many inboxes. We re-run these checks after any change to the stack, such as a new tool or a DNS migration.

What a passing DKIM check is worth for deliverability

A signed, aligned message gets judged on its merits. An unsigned or misaligned one starts with a question mark over who sent it. That's the full extent of DKIM's effect on placement. Once identity is settled, providers look at sender reputation, complaints, bounces and how recipients engage, and a perfectly signed email sent to a bad list still lands in spam.

For outbound teams, that makes DKIM one line on a longer list. It belongs in your sending infrastructure next to SPF, DMARC, a warmed domain, verified lists and sensible volume per inbox. In cold email infrastructure, each secondary domain needs its own key in its own sending tool, set up before warmup starts, so the reputation you build sits on a domain that authenticates from the first message.

The same signature protects mail nobody thinks of as deliverability work, like form confirmations and replies to inbound leads, which go to your warmest contacts. Our email deliverability guide walks through the rest of the setup in order.

Recap

DKIM comes down to two tags. The d= value says who signed, the selector says where to find the key, and the receiver checks both against what you've published in DNS. Almost every practical question, from alignment to rotation to a failed test, traces back to one of them.

The first setup is the easy part. The ongoing work is knowing who signs as you as tools come and go, making sure each one signs under your own domain so DMARC sees alignment, and keeping keys long enough and current enough that a former vendor or an attacker can't use them.

When we build outbound or inbound systems for a client, the DKIM keys, selectors and DMARC reporting go into the client's own DNS and sending accounts, with a written register of which key belongs to which tool. When the project ends, all of it stays with the client, along with the notes on how to change it.

Frequently asked questions