SPF, DKIM and DMARC explained without the jargon

Email has a trust problem that most small businesses never see. When a message arrives claiming to be from your domain, nothing in the original design of email proves it really is. Three records published in your DNS fix that, one layer at a time. They have forbidding names, but each one does a simple job.

SPF: the guest list

SPF is a list of the servers allowed to send mail for your domain. You publish it as a DNS record, and receiving mail servers check incoming mail against it. If a server on the list sends as you, it passes. If a server that is not on the list sends as you, receivers know something is off.

The catch is that the list has to be complete. Every service that sends mail on your behalf needs to be on it: your mail host, your newsletter tool, your invoicing system, the contact form on your website. Miss one, and its mail starts failing checks. That is why SPF problems usually show up as one particular kind of mail landing in spam while everything else works fine.

DKIM: the wax seal

DKIM is a signature, not a list. Your mail server signs each outgoing message with a private key, and receivers verify the signature against a public key published in your DNS. If the message is altered in transit, the signature no longer matches.

DKIM survives forwarding better than SPF, because it travels with the message itself rather than depending on which server delivered it. The usual failure mode is simpler: the signing key gets changed, or a provider rotates keys, and nobody updates the public record. Then every signed message fails verification at once.

DMARC: the policy that ties them together

DMARC is the record that says what receivers should do when mail claiming to be from your domain fails both checks, and where to send reports about it. Its policy setting matters: p=none means watch and report only, p=quarantine sends failing mail to spam, and p=reject refuses it outright.

DMARC also adds one rule the other two do not have: alignment. It is not enough for some check to pass — the passing check has to line up with your domain. That is what stops a stranger from passing SPF with their own domain and then putting your name in the From field.

The order to set them up

Start with SPF, listing every legitimate sender. Add DKIM signing next, and confirm signed mail verifies. Only then publish DMARC, and start it at p=none so you can read the reports and find any sender you forgot. Tighten to quarantine once your real mail passes consistently, and only consider reject after that. Doing it in the other order — policy first, records later — is how businesses end up blocking their own invoices.

Records also drift. DNS edits drop entries, providers change keys, and a host migration can quietly break alignment. A record that was correct last year is not necessarily correct today, which is why it is worth checking them regularly rather than assuming the original setup still holds.

See where your own records stand today: run a free health scan, or read what each check covers on the features page.