Email authentication for small businesses: SPF, DKIM, and DMARC in plain terms

If your domain sends email and you have never touched SPF, DKIM, and DMARC, you are both easier to spoof and more likely to land in spam than you need to be. These three DNS records are the backbone of email authentication, and for a small business they are some of the highest-leverage security work you can do in an afternoon. Here is what each one actually does and the order to roll them out.

SPF: who is allowed to send

SPF — Sender Policy Framework — is a single DNS TXT record that lists the mail servers authorized to send email for your domain. When a receiving server gets a message claiming to be from you, it checks your SPF record and asks: did this actually come from an IP you approved? A record looks something like v=spf1 include:_spf.google.com include:servers.mcsv.net -all — your mail provider, any third-party senders (marketing tools, ticketing systems), and a policy at the end. The two common failure modes are forgetting a legitimate sender, which sends your own mail to spam, and the "too many DNS lookups" limit, which silently breaks SPF once you chain too many includes. The -all at the end is a hard fail; many start with ~all (soft fail) while testing.

DKIM: proof the message wasn't tampered with

SPF authorizes the server; DKIM authorizes the message. DomainKeys Identified Mail attaches a cryptographic signature to every outgoing email, using a private key your mail provider holds, and publishes the matching public key in your DNS. The receiver recomputes the signature and confirms two things: the mail came from your domain, and the headers and body were not altered in transit. Most providers generate the keys for you — you just paste a TXT (or CNAME) record at a selector like google._domainkey. The one habit worth keeping is rotating keys periodically, the same way you would any other secret.

DMARC: what to do when checks fail

SPF and DKIM each answer a question; DMARC decides what happens with the answer and tells you about it. A DMARC record sets a policy — none, quarantine, or reject — for mail that fails authentication, and crucially it can email you aggregate reports of who is sending under your domain. The correct rollout is gradual: start at p=none with reporting on, read the reports for a few weeks to find every legitimate sender you forgot, fix your SPF and DKIM until real mail passes cleanly, then tighten to quarantine and finally reject. Jumping straight to reject is how teams nuke their own invoices and password resets.

The order, and getting help

Roll them out in sequence: SPF first, then DKIM, then DMARC at p=none to observe, tightening over weeks. None of it costs anything but DNS edits and attention. If your business does not have someone who lives in DNS and would rather not learn the hard way which record breaks the CEO's email, this is exactly the kind of recurring, easy-to-get-wrong task a managed IT services provider handles as routine — set it up correctly once, monitor the DMARC reports, and keep the records current as you add and drop senders. Done right, the payoff is concrete: less of your mail in spam folders, and far less of your domain in the hands of whoever is impersonating it.