What is DKIM and why does my email need it?

DKIM is a digital signature that your email service adds to every email you send, which receivers check against a key published in your domain's DNS. It proves the email really came from your domain and wasn't changed on the way, and without a signature from your own domain, more of your email lands in junk.

DKIM stands for DomainKeys Identified Mail. Gmail and Yahoo require it from bulk senders, and Outlook from high-volume senders. Even if you only send a handful of invoices a day, a valid signature from your own domain is one of the clearest signals that your email is genuine.

How the signature works

DKIM uses a pair of keys.

• The private key stays with your email service, such as Microsoft 365. Nobody else sees it. The service uses it to sign each email as it goes out.
• The public key goes in your DNS, the public records for your domain. Anyone can look it up.

When your email arrives, the receiving server reads the signature, fetches your public key from DNS and checks that the two match. If someone changed the email on the way, or forged it without your private key, the check fails.

The signature sits in a hidden header called DKIM-Signature. You don't see it in Outlook unless you open the message headers, but every receiver reads it.

The two parts that matter: d= and s=

A DKIM-Signature header has many parts. Two matter most to you.

DKIM-Signature: v=1; a=rsa-sha256; d=yourbusiness.com.au; s=selector1; ...

• d= is the signing domain: who is vouching for this email. Here it's yourbusiness.com.au.
• s= is the selector: the name of the key that was used.

The receiver puts the two together to find the public key. With the example above, it looks up selector1._domainkey.yourbusiness.com.au. That's why every DKIM record you add has ._domainkey in its name.

Selectors: why you can have many DKIM records

A selector is just a label for one key. Because each key has its own label, one domain can have as many DKIM keys as it needs, side by side.

That's different from SPF, where you're allowed only one record. With DKIM:

• Microsoft 365 uses selector1 and selector2.
• Your newsletter tool might use names like s1 and s2.
• Xero or your website's email service will use its own names.

None of them clash, because each sits at a different selector.

Why each service needs its own key

The private key never leaves the service that holds it. Microsoft 365 can't sign email for Xero, and Xero can't sign with Microsoft's key. So every service that sends email as yourbusiness.com.au needs its own DKIM set up, inside that service, with its own record in your DNS.

Some services give you a TXT record that contains the public key itself, a long string of letters and numbers. Others, including Microsoft 365, give you CNAME records instead. A CNAME points your selector to a key the service hosts for you, so it can change the key later without you touching your DNS again.

Alignment: why the signer has to be you

Here's the catch. Many services sign every email by default, but with their own domain. The signature passes, yet it proves only that the service sent it, not that it came from you.

DMARC, the policy that tells receivers what to do with email that claims to be from your domain, only counts a DKIM signature when the d= domain matches the domain in your From address. That match is called alignment.

• d=yourbusiness.com.au on an email from accounts@yourbusiness.com.au: aligned.
• d=mail.yourbusiness.com.au: also aligned, because it's a subdomain of yours (unless your DMARC record asks for strict alignment).
• d= the service's own domain: DKIM passes, but it isn't aligned and doesn't help with DMARC.

This is a common reason for "DKIM passed, but my email still goes to junk". The fix is to set up DKIM for your own domain in that service. Services often call this "domain authentication" or "verify your domain".

DKIM matters so much because it survives forwarding better than SPF does, and many services can't make SPF pass for your domain at all. For DMARC, either SPF or DKIM must pass and align. DKIM is usually the easier one to get right.

Rotating keys

Like a password, a DKIM key is best changed now and then. Selectors make this painless: the service publishes a new key under a different selector, switches to it, and retires the old one. Email never goes unsigned in between.

Microsoft 365 does this with its two selectors. When you rotate keys in the Defender portal, Microsoft switches between selector1 and selector2, and the new key starts signing after about four days. Because both CNAME records are already in your DNS, you don't need to change anything there.

Key length matters too. Longer 2048-bit keys are harder to crack than 1024-bit ones. Not every service uses them by default. Microsoft's own PowerShell commands create 1024-bit keys unless you ask for 2048-bit, which you can choose when you rotate keys.

What breaks DKIM

• A missing or mistyped record. One wrong character and the receiver can't use the key.
• Something changing the email after it's signed. A footer, disclaimer, antivirus stamp or tracking link added by a mail filter or forwarding service breaks the signature.
• The wrong signer. The signature passes, but for the service's domain, not yours.

How to check yours

Send one email from each service you use to your free test address. Our report shows whether the email was signed, which domain signed it, whether the signature passed, and whether it counts for DMARC. If it doesn't, the report names the sending service where it can tell, and gives you the steps to set up DKIM for your domain in it.

Checked against: RFC 6376, DomainKeys Identified Mail (DKIM) Signatures · RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC) · Microsoft Learn, How to use DKIM for email in your custom domain.