SPF, DKIM, and DMARC in plain English - and how to tell if yours are right

Your donation confirmation went to spam again. You send the message a second time. A board member checks their junk folder. A donor texts to say “I think it came through but looked weird.”

This is almost never about what you wrote. It is usually about whether the servers receiving your email can prove you sent it.

That proof is handled by three text records attached to your domain - SPF, DKIM, and DMARC. Most small orgs have at least one of them missing, wrong, or set up to do nothing. Here is what each one is, how to check yours, and what to do next.

What are SPF, DKIM, and DMARC, and why do they matter?

They are three small text records attached to your domain that tell receiving email servers a message actually came from you, not a spammer. When any of them are missing or misconfigured, Gmail and Outlook get skeptical, and your email lands in spam or gets blocked outright.

SPF (Sender Policy Framework) lists the services allowed to send email from your domain. If you send newsletters through Mailchimp, Mailchimp’s servers need to be on that list. If you send event invites through Eventbrite, same thing. Anything sending email from your domain that isn’t on the list gets flagged on arrival.

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every message that leaves. The signature is created with a private key only your sending service has, and it’s verified against a public key published in your domain’s DNS. If the signature is missing or doesn’t match, the message is treated as unsigned - less trustworthy, more likely to be filtered.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy that ties the other two together. It tells receiving servers what to do when SPF or DKIM fails, and whether to send you a report about it. Without DMARC, you have no visibility into whether your records are actually working - you’re flying blind on your own email deliverability.

How do I check my records right now?

Go to MXToolbox and run three lookups on your domain:

1. SPF Record Lookup - confirm you have one, and that it includes every service you send through (Google Workspace, Mailchimp, Donorbox, whatever you use)
2. DKIM Lookup - this one needs a selector (usually google for Workspace, or one provided by your sending tool). Confirm the record exists.
3. DMARC Lookup - confirm a record exists and its policy is at least p=none (reporting only). p=quarantine or p=reject is stronger.

The tool returns a green check or a specific error. If any record is missing, the error will say “no record found.” If a record is present but misconfigured, the error will say what’s wrong (often “too many lookups” or “invalid syntax”).

Write the results down. The next step depends on what came back.

What do I do if something is wrong?

A few common fixes, in the order I see them most often.

SPF missing a service. Add the provider’s include string. Google Workspace is include:_spf.google.com. Mailchimp has historically used include:servers.mcsv.net, though their current documentation now emphasizes DKIM and DMARC over SPF - check Mailchimp’s authentication page before adding. Your other senders publish their own include strings in their deliverability docs. You only get one SPF record per domain, so merge the includes into a single record - don’t publish two.

DKIM not set up for your newsletter tool. Log into the sending tool and look for “authenticate your domain” in settings. It will give you a specific record to paste into DNS. Google Workspace has this in the Admin console under Apps → Google Workspace → Gmail → Authenticate email. Every major sending platform has the equivalent.

No DMARC at all. Start with a minimal policy that only reports, never blocks:

v=DMARC1; p=none; rua=mailto:you@yourdomain.org

That turns on reporting without affecting delivery. Read the reports for two or three weeks to see what’s actually happening on your domain. If the reports are clean, you can tighten to p=quarantine (spam box) or p=reject (bounce entirely).

The DNS changes themselves happen wherever your domain is registered - GoDaddy, Namecheap, Cloudflare, Squarespace, or whoever holds the domain for you. If you don’t know who that is, the registrar question is the first one to answer. Email deliverability comes after that.

None of this is complicated. It just sits in the gap between “IT” and “marketing” where nobody owns it.

What if I use Google Workspace and Mailchimp and that’s basically it?

Most small orgs land here, so it’s worth spelling out the exact setup.

1. SPF record - one record including Google’s sender. If Mailchimp still publishes an SPF include at the time you set this up, include it too: v=spf1 include:_spf.google.com include:servers.mcsv.net ~all. If Mailchimp has fully moved off SPF, just use Google’s.
2. DKIM for Google - set up in Google Workspace Admin, which publishes a record like google._domainkey
3. DKIM for Mailchimp - set up in Mailchimp’s domain authentication, which publishes two CNAME records
4. DMARC - the minimal reporting record above, with reports going to an inbox you actually monitor

Four pieces. Once they’re in place, they mostly take care of themselves. The only time they need attention is when you add a new service that also sends email from your domain.

---

If you’ve never heard of SPF records, you’re not behind. You just hadn’t needed to know yet. Now you do, and a 15-minute check is the difference between a donor receiving your thank-you and a donor wondering why you never acknowledged their gift.