SPF, DKIM and DMARC: a checklist before you send anything

Most authentication problems come from the same handful of mistakes. Work through these in order before a new domain or server sends its first message.

1. One SPF record, under ten lookups

Look up the TXT records on your domain. There should be exactly one that starts with v=spf1. Two records make SPF fail outright. Then count the DNS lookups the record causes: every include, a, mx and redirect counts, including the ones inside the records you include. Ten is the limit. If you are over, remove services you no longer use or replace includes with ip4 entries for addresses you control.

2. A DKIM key of at least 2048 bits

Publish the public key at <selector>._domainkey.<domain> and check that the key parses. 1024-bit keys still work but are weak, and some providers warn about them. Generate keys somewhere you trust and keep the private key off machines that don't need it.

3. A DMARC record that reports

Publish _dmarc.<domain> with at least p=none and a rua address. Reports tell you who is sending as your domain, including sources you forgot about. Move to quarantine and then reject once the legitimate sources all pass.

4. Alignment, not just passing

DMARC needs SPF or DKIM to pass and the domain that passed to match the visible From domain. A message can pass SPF for a provider's bounce domain and still fail DMARC. Send a test message and check the authentication results header for dmarc=pass.

5. Reverse DNS that matches

The sending IP should have a PTR record, the name should resolve back to the same IP, and the server should greet with that name. Mismatches are an easy way to look like a throwaway server.

Check it

The free DNS check runs the DNS parts of this list and shows the exact record to publish for anything that fails.