Missing DKIM

SPF authorises servers. When a message is forwarded, the forwarding server is not on your list, so SPF fails — through no fault of yours and with nothing you can configure to prevent it.

Mailing lists have the same effect, and some of them modify the message as well, which breaks a signature too unless the list uses the mechanism designed for it.

DKIM survives the first case cleanly: the signature is in the message, and a forwarder that relays it unchanged relays a valid signature.

DMARC needs only one of SPF or DKIM to pass in alignment, so a domain with both has a path that works when forwarding breaks the other.

A domain with SPF and no DKIM therefore fails DMARC on every forwarded message, which is a predictable and permanent gap.

The public key is published at `<selector>._domainkey.<domain>` as a TXT record, and the signature in the message names which selector to look up.

That indirection is what allows several keys at once: one per sending service, each with its own selector, each independently rotatable.

So a domain sending through a mailbox provider, a transactional service and a marketing platform typically has three selectors, and each provider tells you which to publish.

There is no way to enumerate selectors from outside — you cannot list what exists under `_domainkey` — so checking DKIM externally means checking the selectors a provider is known to use, or reading the signature on a message that actually arrived.

This is why a DKIM check is less definitive than an SPF or DMARC check, and it is worth stating rather than glossing over.

RSA keys of 1024 bits are widely deployed and no longer considered adequate; 2048 bits is the current expectation for RSA.

Ed25519 is specified for DKIM and is much shorter, which sidesteps the DNS record-length awkwardness that 2048-bit RSA creates. Support among verifiers is not universal, so it is usually published alongside RSA rather than instead of it.

A 2048-bit RSA key exceeds the 255-character limit of a single DNS character string, so it must be split into several quoted strings within one TXT record. Getting that wrong produces a key that looks published and does not verify.

Keys should be rotated periodically, which is what selectors make practical: publish the new selector, switch signing to it, then remove the old record once nothing references it.

And a test key — a record with `t=y` — tells verifiers not to treat failures as meaningful. Left in place after testing, it quietly disables the benefit.

Send a message to an account you control elsewhere and open the original. The `DKIM-Signature` header names the domain (`d=`) and the selector (`s=`).

Then query that selector: `dig <selector>._domainkey.example.com TXT +short` should return a record containing `p=` followed by the key.

Read the `Authentication-Results` header on the received message: `dkim=pass header.d=example.com` confirms the signature verified and names the signing domain.

Check that `header.d` matches the domain in the visible From: address, since that is what DMARC alignment requires.

Repeat for each sending service. Each has its own selector and each can be broken independently.

Enable DKIM signing with every service that sends on your behalf. Each provider issues a selector and a record to publish; the work is per provider and each one is small.

Publish 2048-bit RSA keys, split correctly across strings in the TXT record, and verify each with a real message rather than by reading the panel.

Sign with your own domain rather than the provider's, or DMARC alignment will not count the pass. A message signed with `d=provider.example` passes DKIM and fails DMARC.

Remove `t=y` once testing is done.

Rotate keys on a schedule using new selectors, and remove old records once no mail references them.

`email.dkim.selectors` queries the selectors commonly used by known providers and reports the DKIM records found, with the key each publishes.

`email.spoofing_exposure` combines that with the SPF and DMARC state, which is where a missing DKIM shows its real consequence: a domain relying on SPF alone fails on every forwarded message.

`email.usage_context` reports whether the domain appears to send mail at all, which determines whether any of this is relevant to it.

Because selectors cannot be enumerated from DNS, an absent result means no record was found at the selectors checked — not that DKIM is absent. The report states that distinction rather than implying a verdict.