# DKIM

Canonical: https://inetgeek.com/dns/dkim/

DKIM attaches a cryptographic signature to outgoing mail, verified against a public key published in your DNS.

## What DKIM is

DKIM, specified in RFC 6376, has the sending server sign parts of each message with a private key. The matching public key is published in DNS, so any receiver can verify the signature.
A valid signature shows that the signed content has not been altered in transit and that the signing domain took responsibility for the message.

## Selectors

The public key lives at a name built from a selector: selector._domainkey.example.com. The selector appears in the message's DKIM-Signature header, which is how a receiver knows which key to fetch.
Selectors let one domain publish several keys at once, which is what makes key rotation and multiple sending providers possible without a flag day.
Because the selector is chosen by the sender, there is no way to enumerate a domain's DKIM keys from DNS alone. A checker needs the selector, which is why "requires selector" is a normal result rather than an error.

(Interactive explainer on the canonical page — nothing to check live, this is reference text.)

## Why DKIM survives forwarding

DKIM signs the message rather than the connection, so the signature stays valid when a message is forwarded — unlike SPF, which fails once the message arrives from a server the original domain never authorised.
Modifications in transit do break it. Mailing lists that add a subject prefix or a footer invalidate the signature over those fields, which is part of why DMARC accepts either SPF or DKIM.

Check this on a live domain: https://inetgeek.com/tools/dmarc-checker/

## Related records

- [SPF](https://inetgeek.com/dns/spf/): Declares which servers may send mail using your domain.
- [DMARC](https://inetgeek.com/dns/dmarc/): Tells receivers what to do when SPF and DKIM fail.
- [TXT record](https://inetgeek.com/dns/txt-record/): Holds arbitrary text, used for verification and email policy.