DKIM – the seal that proves a message really came from you

DKIM signs your outgoing mail so recipients can prove it was not altered. Here is what the key record contains, why selectors cannot be guessed, and what each DKIM finding means.

DKIM is a wax seal. Your mail server signs every outgoing message with a private key that never leaves it, and publishes the matching public key in your DNS. A receiving server recovers the signature, fetches the public key and checks whether the two fit. If they do, two things are proven: the message really passed through a server that holds your key, and nobody changed the signed parts on the way.

That second half is what SPF cannot do. SPF only asks where a message came from, and it stops working the moment a message is forwarded – a mailing list, a redirect from an old address, a filtering service in front of a company mailbox. The DKIM signature survives all of that, because it travels inside the message.

What the record looks like

A DKIM key does not sit on your domain itself but under a selector name:

selector1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Two optional flags matter. t=y puts the key in test mode, which tells recipients to treat a failed signature as harmless. s=email limits the key to mail, which is good practice and does no harm.

Many providers do not publish the key as a TXT record at all but as a CNAME pointing into their own domain. Microsoft 365 does this, and so does IONOS. The effect is the same, and the check follows the reference.

Why "not found" is not the same as "not there"

DNS never says which selectors a domain uses. There is no index, no list, no way to ask. A receiving server does not need one: every signed message carries its selector in the header, so the server always knows where to look. Someone checking from the outside, with no message in hand, does not.

So this check does the only thing possible – it tries the selector names the common providers use, around fifty of them across five markets, and reports what it finds. If your provider uses an unusual name, or generates a random one, nothing is found and that says nothing at all about your DKIM setup.

There are two ways to turn a guess into a measurement, both in the check's form:

• Enter the selector, if you know it from your provider's DNS instructions.
• Paste the headers of a real message you sent. The DKIM-Signature line names the selector in its s= field. In most mail clients the headers are behind "Show original" or "View source".

These are the selectors the check tries for the providers common in this market:

How to set it up

DKIM is switched on at the system that sends the mail, not at the one that hosts your website. Every sending service needs its own key: the mailbox provider, the newsletter tool, the shop.

Step by step in Microsoft 365

1. Sign in to the Microsoft Defender portal at security.microsoft.com.
2. Open Email & collaboration, then Policies & rules, Threat policies, Email authentication settings, tab DKIM.
3. Select your domain. If DKIM has never been enabled, Microsoft shows two CNAME records for selector1._domainkey and selector2._domainkey.
4. Publish both records at your DNS host, exactly as shown, including the long tenant name.
5. Come back and switch Sign messages for this domain with DKIM signatures to on. If it refuses, the CNAMEs have not spread yet – wait an hour and try again.
6. Send yourself a message and check the header, or run this check with selector1 entered.

Google Workspace works the same way with one key: Admin console, Apps, Google Workspace, Gmail, Authenticate email, Generate new record, then publish the TXT record and press Start authentication. Choose 2048 bits, not 1024.

The findings in detail

No DKIM key found

We tried the selector names of the known providers and found no key under any of them.

This finding is deliberately cautious, because it can mean two very different things: DKIM is genuinely switched off, or your provider uses a selector we do not know. We cannot tell the two apart from outside, and neither can anyone else without a message from you.

What to do: first settle the question. Enter the selector in the form if you know it, or paste the headers of a real message – the s= field of the DKIM-Signature line names it. If it turns out nothing is signing, enable DKIM at your mailbox provider and at every sending service separately.

DKIM key revoked

A record exists under this selector, but its p= field is empty.

An empty key is the formal way to retire a selector after a key change: it tells recipients that anything still signed with it is no longer valid. As a step in a rotation this is entirely correct. Left standing for years, it is confusing rather than harmful.

What to do: if the change is finished and nothing signs with this selector any more, the record can be deleted. If you did not order a key change, ask your provider – a key that disappeared without notice deserves an explanation.

All DKIM keys found are revoked

Every selector we could find carries an empty key.

Nothing that we can see is signing. Outgoing mail then relies on SPF alone, which means a forwarded message loses its authentication entirely – and if you run DMARC, those messages fail it.

What to do: generate a new key at your mailbox provider and publish it. Then check that the new selector really is in use by looking at the header of a message you have just sent. Once the new key is signing, the old empty records can go.

DKIM key too short

The key under this selector is shorter than 1024 bits.

Keys of that size have not been considered secure for years, and several large providers no longer evaluate such signatures at all. The signature is then worth nothing to them, even though everything looks configured.

What to do: generate a new 2048-bit key at your provider, publish it under a new selector, wait until mail is signed with it, then remove the old record. Every current provider offers 2048 bits; if yours does not, that is worth a conversation.

DKIM key is 1024 bits

The key under this selector has 1024 bits.

Still accepted everywhere today, but no longer current practice – 2048 bits has been the standard for years. This is a finding to schedule, not to rush.

What to do: take it with the next key rotation. Generate the new key at 2048 bits, publish it under a new selector, and retire the old one once the new signature appears in your message headers.

DKIM in test mode (t=y)

The record carries the flag t=y.

Test mode tells recipients, explicitly, to treat a failed signature as if nothing had happened. It exists so that a new setup can be observed without breaking delivery. While it is set, DKIM provides no protection at all – the seal is there but recipients are told to ignore a broken one.

What to do: once you have seen signed mail arrive intact for a week or two, remove t=y from the record. Nothing else changes, and no key needs to be regenerated.

DKIM key unreadable

We found a record but could not parse the key in it.

Almost always a copy error: a line break inside the key, a space that crept in, a missing character at the end, or two chunks of a long record that the DNS panel reassembled in the wrong order. Recipients hit exactly the same wall and treat every signature as failed.

What to do: fetch the key from your provider again and paste it in one piece, with no spaces or line breaks inside the p= value. If your DNS panel breaks long values, most offer a field for long TXT records or accept the value split into quoted chunks – ask their support rather than trimming the key.

Frequently asked questions

Why can the check not simply find my selector?

Because DNS does not store that information anywhere. A DKIM key is only discoverable if you already know its name. Receiving servers read the name from the message header; a check run against a bare domain has no message and can only try known names.

How many selectors should my domain have?

As many as you have sending services, plus one during each key rotation. That is normal and causes no conflicts. What matters is that every service that sends in your name signs with a key of its own.

Does DKIM alone stop anyone forging my address?

No. A forger simply sends unsigned mail. Only DMARC turns a missing or broken signature into a consequence, and only DMARC checks that the signing domain matches the address the recipient sees.

How often should I change the key?

Once a year is a sensible rhythm, and any suspicion of a compromised server makes it urgent. Publish the new key first, let it sign for a while, and only then empty or delete the old record.