SPF, DKIM & DMARC in Plain English

You send an email to a customer. They never get it.

Or they find it a week later sitting in their spam folder. Or worse, you start getting a flood of bounce-back messages for emails you never sent, because someone out there is pretending to be you.

If any of that sounds familiar, there’s a good chance your domain is missing three things: SPF, DKIM and DMARC.

I know. Those sound like something only an IT department should worry about. But they’re just three text records in your domain’s DNS settings, and once they’re in place, you rarely have to touch them again. Together, they’re what’s known as email authentication. Let me explain them in plain English.

Why this matters more than it used to

For years, you could get away without these records. Not anymore.

Starting in 2024, Google and Yahoo began requiring email authentication from anyone sending in volume, and Microsoft followed with similar rules for Outlook and Hotmail addresses. Even if you only send a handful of emails a day, inboxes are increasingly suspicious of mail from domains that don’t have this set up.

Think of it this way. These records are how your domain proves to the world, “Yes, this email really came from me.”

SPF: who’s allowed to send for you

SPF (Sender Policy Framework) is a list of the services allowed to send email using your domain name.

Your business probably sends email from more places than you think: your regular mailbox (Google Workspace or Microsoft 365), your newsletter service, your website’s contact forms, maybe your invoicing software. SPF tells the world all of those are legit.

An SPF record looks something like this:

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

That says: “Google and SendGrid can send for this domain. Treat anything else as suspicious.”

A few things trip people up:

• You can only have one SPF record. If you add a new service, you add it to the existing record. You don’t create a second one. Two SPF records will break both.
• There’s a limit of 10 lookups. Every include: counts, and some services use several behind the scenes. Pile on too many and SPF quietly fails.
• The ending matters. ~all means “soft fail” (be suspicious), and -all means “hard fail” (reject). Most people start with ~all.

DKIM: a signature on every message

DKIM (DomainKeys Identified Mail) adds a digital signature to every email you send. The receiving server checks that signature against a key published in your DNS. If it matches, they know the message really came from you and wasn’t changed along the way.

The good news is you don’t build DKIM yourself. Each service you send through, like Google Workspace, Microsoft 365 or your newsletter platform, gives you the record to add. Usually it’s a TXT or CNAME record with a name like google._domainkey.

The part people miss: every service that sends for you needs its own DKIM set up. Having DKIM on your mailbox doesn’t cover your newsletter service.

DMARC: the rules, and the reports

DMARC ties SPF and DKIM together. It tells receiving servers what to do when an email claims to be from you but fails those checks, and it sends you reports about who’s sending email using your domain.

A starting DMARC record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

That p= part is the policy, and there are three levels:

1. p=none: Just watch and send me reports. Don’t block anything yet.
2. p=quarantine: Send failing mail to the spam folder.
3. p=reject: Refuse failing mail entirely.

Here’s something I’ve been running into a lot lately. For years, the standard advice was to start at p=none and leave it there while you watched the reports. Today, a lot of systems don’t see p=none as good enough. Tools like MXToolbox flag it as a problem, and I’ve had a number of clients whose mail started bouncing or getting filtered until we moved them to p=quarantine. To be fair, Gmail and the other big providers say p=none meets their minimum. But plenty of other mail systems treat a domain with no enforcement as less trustworthy, and those systems are the ones your customers are using.

DMARC is also what stops spoofing. Once you’re at quarantine or reject, scammers can’t easily send email pretending to be your domain, and you stop getting those mystery bounce-backs.

How to set up email authentication, step by step

1. Make a list of everything that sends email as your domain. Mailbox provider, newsletter service, website forms, CRM, invoicing, help desk. Don’t skip this step.
2. Log in to wherever your DNS is managed. That’s usually your domain registrar, your host, or Cloudflare.
3. Add or update your SPF record so it includes every sender on your list. Remember: one record only.
4. Set up DKIM for each sender. Look for “authenticate your domain” or “DKIM” in each service’s settings. They’ll give you the exact records.
5. Add a DMARC record with a reporting address. Start at p=none only while you test.
6. Test it. Send an email from each service to a Gmail address, open it, click the three dots and choose Show original. You want to see PASS next to SPF, DKIM and DMARC. You can also run your domain through MXToolbox to check your records.
7. Once everything passes, usually within a week or two, move to p=quarantine. Don’t leave it sitting at p=none.
8. When you’re confident nothing legitimate is failing, move to p=reject for full protection.

A few more things that help

• Send website email through a real email service, not your web server’s built-in mail function. WordPress contact forms are a common culprit here. An SMTP plugin connected to a proper sending service fixes most “my form emails go to spam” problems.
• Keep your mailing list clean. Sending to dead addresses hurts your reputation.
• Make unsubscribing easy. It’s now a requirement for bulk senders, and it beats being marked as spam.

The bottom line

SPF says who can send. DKIM proves the message is real. DMARC sets the rules and tells you what’s happening.

Set them up once, check your reports now and then, and your emails have a much better shot at landing where they belong: in the inbox.

If you’d rather have someone handle this for you, it’s something I set up for clients all the time at That One Web Guy.