June 9, 2026

SPF, DKIM, and DMARC: a plain-English guide for small business owners

Your invoices are landing in spam. Your sales replies never get read. And somewhere, someone might be sending emails that look like they came from your domain — to your customers. If any of that sounds familiar, the fix usually comes down to three acronyms most small business owners have never been told they need: SPF, DKIM, and DMARC.

This post explains what each one does, how to check what you already have, and what a working setup actually looks like. No jargon, no fluff.

Why your email is landing in spam (or worse, getting spoofed)

Email was invented in the 1970s, back when nobody imagined people would lie about who they were. By default, anyone with a mail server can send a message claiming to be you@yourcompany.com. Gmail, Outlook, and Yahoo know this, so they've spent the last decade getting much stricter about which senders they trust.

If your domain doesn't publish proof of who's allowed to send mail on your behalf, two things happen:

Your legitimate email gets filtered. Quotes, invoices, appointment confirmations, marketing — all of it lands in spam or never arrives at all. You lose deals and look unprofessional.
Spoofers can impersonate you. Scammers can send fake invoices "from" your domain to your clients, and there's nothing stopping them. Your customers get phished, and your brand takes the hit.

As of February 2024, Google and Yahoo started rejecting bulk email from any domain that doesn't have proper authentication. They're not bluffing. If you've noticed your deliverability sliding over the last 18 months, this is almost certainly why.

The fix is three DNS records. Let's go through them.

SPF in three sentences

SPF (Sender Policy Framework) is a list of servers allowed to send email for your domain. You publish it as a TXT record in your DNS, and receiving mail servers check it before they decide whether your message is real. If the sending server isn't on the list, the receiver treats it as suspicious.

Here's what a real SPF record looks like for a business using Google Workspace and Mailchimp:

v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

A few things to know:

The include: entries are "trust whoever this provider trusts." Google Workspace, Microsoft 365, SendGrid, Mailchimp, Klaviyo, HubSpot — each one has its own include string you add.
~all means "anyone else is probably fake, soft-fail them." -all is the stricter version ("reject anyone else outright"). Start with ~all and tighten later.
You can only have one SPF record per domain. If you add a second, both break. Everything goes into the one record.
SPF has a hard limit of 10 DNS lookups. If you stack too many providers, it silently breaks. This is one of the most common reasons SPF "works" in some tools but fails in practice.

DKIM in three sentences

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every email you send, proving the message actually came from your domain and wasn't tampered with in transit. Your email provider creates the signing key; you publish the matching public key as a DNS record so receivers can verify it. If the signature checks out, the email is trusted. If it's missing or broken, it gets flagged.

A DKIM record uses a "selector" — basically a label — so you can have multiple keys for different services. Here's what one from Google Workspace looks like in your DNS:

Name:  google._domainkey.yourcompany.com
Type:  TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

The google part is the selector. Mailchimp uses k1 and k2. SendGrid uses s1 and s2. Every sending service needs its own DKIM record, which is why you'll often end up with three or four of them in your DNS — one per platform.

The most common mistake I see: someone enables DKIM in Google Workspace but never actually publishes the DNS record, so signing is "on" but nothing is being verified. Always confirm both sides.

DMARC in three sentences

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy that ties SPF and DKIM together and tells receivers what to do when a message fails. It also sends you reports showing every server sending email as your domain — including ones you didn't know about. Without DMARC, SPF and DKIM are checked but nothing enforces them.

A starter DMARC record looks like this:

Name:  _dmarc.yourcompany.com
Type:  TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.com; pct=100

The important part is p=, the policy. It has three settings, and you walk up the ladder:

p=none — Monitor only. Receivers do nothing differently, but they send you reports. This is where you start. Run it for two to four weeks and look at the reports to find every legitimate sender you forgot about (your CRM, your payroll system, your invoicing tool, that contractor who sends quotes through Gmail).
p=quarantine — Failed messages go to spam. Move here once your reports are clean.
p=reject — Failed messages are rejected outright. This is the goal. At p=reject, nobody can spoof your domain.

Most small businesses I see are either at p=none forever (no protection, just reports nobody reads) or have no DMARC record at all. The whole point of the ladder is to actually climb it.

How to check what you have right now

You can audit your current setup in about five minutes. Three free tools:

1. MXToolbox. Go to mxtoolbox.com and run the SuperTool. Type your domain and check SPF, DKIM, and DMARC one at a time. It'll tell you if records exist, if they're syntactically valid, and if SPF is exceeding the 10-lookup limit.

2. Google Postmaster Tools. If you send any meaningful volume to Gmail addresses, set up postmaster.google.com for your domain. It shows you spam rate, authentication pass rate, and IP reputation as Gmail sees them. This is ground truth — what Google actually thinks of your email.

3. The command line, if you're comfortable. On Mac or Linux:

dig TXT yourcompany.com +short
dig TXT _dmarc.yourcompany.com +short
dig TXT google._domainkey.yourcompany.com +short

That'll dump your SPF, DMARC, and DKIM records directly. On Windows, nslookup -type=TXT yourcompany.com does the same thing.

What you're looking for:

An SPF record that includes every service that sends mail for you
A DKIM record for each sending service, with the right selector
A DMARC record — and check whether p= says none, quarantine, or reject

If any of those are missing, that's where the work starts.

What a proper, finished setup looks like

For a small business running Google Workspace plus one marketing platform, a complete configuration looks something like this:

SPF:

v=spf1 include:_spf.google.com include:servers.mcsv.net -all

DKIM (one record per sending service, with the provider's selector):

google._domainkey      TXT  v=DKIM1; k=rsa; p=MIIBIjANBgk...
k1._domainkey          TXT  v=DKIM1; k=rsa; p=MIIBIjANBgk...

DMARC (after the monitoring phase):

_dmarc  TXT  v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com; pct=100; adkim=s; aspf=s

That's the finish line: SPF locked down, DKIM signing every message from every platform, DMARC at p=reject so nobody can spoof you. Spam folder problems mostly disappear, and your domain becomes useless for phishing.

Why this is worth doing properly

I'll be honest about what this isn't: it's not a magic fix for bad email content. If you're sending mass emails to scraped lists with broken unsubscribe links, no amount of DNS configuration will save you. Authentication gets you trusted as a sender. The content is on you.

But for the average small business that just wants invoices to arrive, sales replies to be read, and customers to be safe from impersonation, getting these three records right is one of the highest-leverage hours of work you can do for your business. The records cost nothing to publish. The damage from not having them — lost revenue from missed emails, plus brand damage if you get spoofed — adds up quickly.

If you'd rather not stare at DNS records and DMARC reports for the next month, I do this as a productized service: $297, flat. I audit your current setup, find every legitimate sender (including the ones you forgot about), publish clean SPF/DKIM/DMARC records, monitor reports for two weeks, then walk you up the ladder to p=reject. You get a one-page summary at the end showing exactly what changed and why.

Details and signup are at thewizrdz.io/#security. If you want me to just take a look at what you have first, the contact form is at the bottom of thewizrdz.io — send me your domain and I'll tell you honestly whether you need help or whether you're already set.