SPF, DKIM, DMARC Explained for Small Business Owners

If you run a small business with a custom-domain email address, your outgoing mail is being judged by three DNS records you probably haven’t looked at: SPF, DKIM, and DMARC. Together they decide whether your invoices land in inboxes or spam folders, and whether spoofers can impersonate your brand. This article explains each in plain English, then tells you exactly what to check.

Why email needs authentication at all

Email was invented in the 1970s, and the protocol trusted anyone who claimed to be someone. Today you can send an email that claims to be from ceo@yourdomain.com to anyone in the world with zero authentication. SPF, DKIM, and DMARC exist to close that gap — they let receiving mail servers verify that a message claiming to be from your domain was actually sent by someone you authorized.

SPF: who is allowed to send from your domain

SPF (Sender Policy Framework) is a text record in your domain’s DNS that lists the IP addresses and services allowed to send mail using your domain name. A typical SPF record looks like:

v=spf1 include:_spf.google.com include:mailgun.org -all

This record says: Google Workspace and Mailgun are allowed to send mail for this domain. Anyone else is forbidden (-all = hard fail). When a mail server receives a message claiming to be from your domain, it checks your SPF record and either accepts or rejects based on the sending IP.

Check your SPF record with our free SPF Checker. It flags the three mistakes we see 90% of the time: missing -all, too many include: statements (SPF allows only 10 DNS lookups), and records that allow far too wide a sending range.

DKIM: proving the message wasn’t tampered with

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing email. The receiving server checks the signature against a public key you publish in DNS. If the signature checks out, the message wasn’t modified in transit and was signed by someone with your private key.

Google, Microsoft 365, and most major email services set up DKIM for you automatically — you just need to enable it in the admin console. The record lives at selector._domainkey.yourdomain.com where “selector” is a label your mail service picks (often google, k1, or s1). Check yours with our DKIM Checker.

DMARC: the policy that ties SPF and DKIM together

DMARC sits on top of SPF and DKIM and says: “If SPF and DKIM fail, here’s what to do with the message.” A DMARC record looks like:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

p=reject tells receiving servers to reject mail that fails both SPF and DKIM. rua= tells them where to send daily aggregate reports so you can see how much fake mail claims to come from your domain.

Three policy levels exist:

  • p=none — monitor-only. Receivers still deliver everything but send you reports. Good for your first month to discover all legitimate senders.
  • p=quarantine — unauthenticated mail goes to spam. Good intermediate step.
  • p=reject — unauthenticated mail is rejected at the gateway. Your production target.

Check yours with our DMARC Checker — it surfaces the most common mistakes and tells you what to change.

The 5-minute audit

Right now, for any domain you use for business email:

  1. Run our SPF Checker — verify you have a record and it ends in -all or ~all.
  2. Run our DKIM Checker — verify your mail provider’s selector is published and the key is at least 1024 bits (2048 recommended).
  3. Run our DMARC Checker — verify you have at minimum p=none with a rua= reporting address.
  4. If your email is via Google Workspace or Microsoft 365, enable DKIM in their admin console if it’s not on.
  5. Commit to moving DMARC from p=none → p=quarantine → p=reject over the next 90 days.

Why this matters for your business

Without DMARC at p=reject, anyone can send mail that looks like it’s from billing@yourcompany.com. That is how wire-fraud attacks start: a fake invoice to your customer saying to update the bank details. Our Business Email Compromise Checker covers the attack patterns in detail. DMARC at reject kills the entire category of attack before the phish reaches anyone.

FAQ

I use Gmail for business — do I still need these?

If you use Gmail at a Gmail.com address, SPF/DKIM/DMARC are handled entirely by Google. If you use Google Workspace with a custom domain (you@yourcompany.com), you do need to set these up yourself. Google’s admin console walks you through each one.

What’s the single most important thing to fix first?

Publish a DMARC record at p=none with an rua reporting address. That gets you daily aggregate reports showing exactly who is sending mail using your domain — both real senders you forgot about and spoofers. From there, you can tighten to quarantine and then reject.

Will tightening DMARC break legitimate mail?

It can, if you have senders you forgot about (a CRM, a support tool, a newsletter service). That’s why you start at p=none and review reports for 30-60 days before tightening. Every legitimate sender needs to be added to SPF or configured to sign with DKIM.