A receiving server asks three questions about your mail: was it sent from a machine allowed to send for this domain, has it been altered on the way, and what should be done if the answers are no. SPF, DKIM and DMARC are those three answers, and they are all DNS records.

SPF - who may send

v=spf1 ip4:203.0.113.10 include:_spf.google.com -all
  • One SPF record per domain. Two is a permanent error, not a merge - and it is the most common fault of the three.
  • Ten DNS lookups maximum. Every include counts, and the includes inside them count too. Over ten is a failure.
  • -all means reject; ~all means treat as suspicious. Start with ~all and tighten it once the reports are clean.

DKIM - has it been altered

dig +short selector1._domainkey.yourdomain.com TXT

Your server signs each message; the public key lives in DNS under a selector. If the record is missing or truncated - long keys are often pasted badly and get cut - every message fails the check.

DMARC - what to do about failures

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100

Start at p=none. It changes nothing about delivery and starts the reports arriving, which tell you who is sending as you. Move to quarantine and then reject once the reports are clean.

Test what you actually have

dig +short yourdomain.com TXT | grep spf1
dig +short _dmarc.yourdomain.com TXT
# then send a message to a checker and read the headers it returns

Alignment: the part that catches people

DMARC needs the visible From domain to match the domain that passed SPF or DKIM. Sending through a third party with their bounce domain passes SPF and still fails DMARC, because the alignment is wrong. Configure the sender with your own domain, or rely on DKIM signed by yours.

If mail is landing in spam despite all three passing, see mail goes to spam and reverse DNS for a mail server.