Guide
SPF, DKIM, DMARC and rDNS: what each one is for
The four DNS records behind a sending identity, what each one proves, and why a check says unknown rather than failed.
Four records stand between a message and an inbox. They answer different questions, and a domain that passes three of them still gets filtered.
SPF: which servers may send for this domain
SPF is a TXT record listing the servers allowed to use your domain in the envelope sender. It authenticates the envelope, not the From header a recipient sees -- so a relay that sends with its own bounce address is checked against the relay's record and never consults yours.
That surprises people, and it is the reason an SPF entry for every relay you use is usually the wrong instinct. Each lookup counts against a limit of ten, and a record stuffed with includes fails as a whole.
DKIM: this message was not altered
A private key at the relay signs the message; a public key in your DNS verifies it. DKIM is what survives forwarding, which SPF does not, and it is what carries alignment for DMARC.
Two relays can sign the same domain at once. The record names are deliberately different, so a migration does not need a cutover: a domain may carry many selectors, and DMARC passes if any aligned signature verifies.
DMARC: what to do when the other two fail
One record, and exactly one. Publishing two is the collision that matters, because policy discovery stops when it finds more than one record -- which means neither applies.
Start at p=none with a reporting address. It changes nothing about delivery and it tells you what is being sent as you before you ask anybody to reject it.
rDNS: the sending IP resolves back to a name
A PTR record on the sending IP. It is set by whoever owns the IP, so on a shared relay it is already done and is not yours to change; on a dedicated IP it is a support request to the provider.
Unknown is not failed
This product draws the two differently and always will. **Unknown** means the lookup did not answer -- we have not been able to check. **Failed** means we checked and the answer was wrong. Collapsing them would make a resolver hiccup look like a misconfiguration, and a real misconfiguration look routine.
Nothing here can be ticked by hand. An identity becomes ready when the checks confirm it, which is the only claim worth making about deliverability.