Checking SPF, DKIM and DMARC

Without correctly configured email records, anyone can send a message that appears to come from your domain. An invoice with an altered bank account, a request to your bookkeeper, a password reset from nowhere. It is unrelated to how well your website is secured, it is fixed with DNS records, and it is structurally overlooked.

Lees deze pagina in het Nederlands

Run free audit

Three records that work together

The three mechanisms each do something different, and only together do they close the door:

  • SPF declares which servers may send on behalf of your domain. Absent it, everyone may.
  • DKIM puts a cryptographic signature on your outgoing mail, so the recipient can verify nothing was altered in transit.
  • DMARC tells receiving mail servers what to do when SPF or DKIM fails — and sends you reports about attempted abuse.

The common misconfigurations

It is rare for all three to be missing. What we see more often is that they exist but enforce nothing:

  • SPF ending in +all — that literally permits any server, and is worse than no SPF, because it creates the impression the matter is handled
  • SPF ending in ?all (neutral), which gives receivers nothing to act on
  • DMARC at p=none, the monitoring setting: you get reports but nothing is stopped
  • DMARC without a rua address, so you do not even receive those reports
  • A DKIM key that has been revoked — the record still exists, but with an empty public key, so every signature fails

What this check cannot know for certain

One honest caveat about DKIM. A DKIM record lives on a self-chosen selector, and there is no way to read from the outside which selectors a domain uses. We query a list of selectors commonly used by the known mail providers.

So finding nothing does not establish with certainty that you have no DKIM — you may simply use a selector name of your own. The report therefore phrases that finding as 'not found on the usual selectors' rather than 'missing'. SPF and DMARC are different: they sit at a fixed location and can be determined conclusively.

A sensible order to switch this on

Never set DMARC straight to reject. You risk blocking your own newsletter, your invoicing system or your CRM, because those often send on behalf of your domain without anyone still thinking about it.

Start at p=none with a rua address, and read the reports for a few weeks. They show you which systems mail on your behalf. Make sure all of them are in your SPF and are DKIM-signed, then move to quarantine and eventually reject. That path takes weeks, not an afternoon — but it is the only order in which you break nothing.

Frequently asked questions

I send no mail at all from this domain. Do I still need to do something?
Especially then. A domain that does not mail is the easiest target, because there is nothing to break. Set SPF to -all with no permitted servers and DMARC straight to p=reject.
Does this help against phishing aimed at my staff?
Against mail impersonating your domain, yes. Against mail from a lookalike domain somebody just registered, no — that is technically entirely legitimate. Only alertness and a process agreement about bank details help there.
How long before a change takes effect?
DNS changes have usually propagated everywhere within a few hours, depending on the TTL on your records.

Curious what is on your own site? Paste a URL and you have a report within a minute.

Run free audit