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.
v=1; a=rsa-sha256; d=; s=; h=from:to:subject; bh=…; b=…
Change the selector and the name changes with it. Nothing in DNS lists which selectors exist, so a domain can rotate to a new key under a new selector and leave the old one in place until every in-flight message has been verified.
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.