SPF, DKIM, and DMARC explained in plain English

When you send an email from your organization's domain, the receiving server — Gmail, Outlook, whoever — has no way to automatically know that email is real. Anyone can write "From: info@yourorg.org" in an email header. Spammers do it constantly.

SPF, DKIM, and DMARC are the three DNS records that give email providers a way to verify your messages are legitimate. Together they answer three distinct questions that happen automatically every time you send:

• SPF (Sender Policy Framework) — Was this sender authorized to send from this domain?
• DKIM (DomainKeys Identified Mail) — Was the message altered after it was sent?
• DMARC (Domain-based Message Authentication) — If SPF or DKIM fail, what should happen to the message?

You don't need to deeply understand the technical mechanics of any of these. You do need to know what each one does, why all three are necessary, and what the setup process looks like so you can get through it confidently.

SPF: the guest list

SPF is a DNS record that lists the servers and services authorized to send email from your domain. When a receiving server gets an email claiming to be from your organization, it checks your SPF record to see if the sender is on that list.

If your organization sends email through ActivistCentral, Google Workspace, or any other email service, those services need to be included in your SPF record. If they're not listed, receiving servers have less reason to trust the message.

Think of it this way: SPF is the guest list at the door. The bouncer checks whether the sender was invited before letting the message through.

An SPF record looks something like this in your DNS settings:

v=spf1 include:sendingservice.com include:accounts.google.com ~all

The services listed after include: are the ones authorized to send on your behalf. Your email provider will give you the exact value to add — you don't need to write it from scratch.

DKIM: the tamper-evident seal

DKIM adds a cryptographic signature to every email you send. When the message arrives, the receiving server checks that signature against a public key stored in your DNS records. If the signature matches, the server knows the message wasn't altered in transit. If it doesn't match, something went wrong — either the message was tampered with or the signature is invalid.

Think of it this way: DKIM is a tamper-evident seal on a package. If the seal is intact when it arrives, you know nobody opened it and changed what's inside.

Unlike SPF, you don't write this record yourself. Your email provider generates a DKIM key pair and gives you the DNS record to add to your domain. Once it's added, the signing happens automatically on every outgoing message.

DMARC: the policy and the paper trail

DMARC does two things. First, it tells receiving servers what to do when SPF or DKIM checks fail — monitor and report, send to spam, or reject the message outright. Second, it generates reports showing you which servers are sending email using your domain, which helps you spot unauthorized use.

Think of it this way: DMARC is the security policy posted at the door. It tells the staff what to do if someone isn't on the guest list — and keeps a log of everyone who tried to get in.

A basic DMARC record looks like this:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourorg.org

The p= value is the policy: none means monitor only, quarantine means send to spam, reject means block entirely. Most organizations start with quarantine or none while getting set up, then move to reject once everything is confirmed working.

Why you need all three — not just one or two

Each record covers a different part of the verification process. SPF alone doesn't prove the message content is intact. DKIM alone doesn't tell providers what to do when something fails. DMARC alone doesn't authorize any senders. They're designed to work together, and providers like Gmail increasingly treat all three as a baseline expectation — not an optional extra.

Starting in 2024, Google and Yahoo made SPF, DKIM, and DMARC mandatory for bulk senders — organizations sending more than 5,000 messages per day to Gmail or Yahoo addresses. If you're running any kind of real email program, you're likely in that category or will be soon.

What setup actually looks like

You configure all three records in the DNS settings for your domain — the same place you'd manage records for your website. If your domain is registered through GoDaddy, Namecheap, Cloudflare, or a similar provider, that's where you'll make these changes.

1. ActivistCentral's email setup guide provides the exact SPF and DKIM values to add for your account. You don't write these records from scratch — you copy and paste what the platform provides.

2. Log into your domain registrar and add the records to your DNS settings. Look for a section called "DNS Management," "DNS Records," or "Advanced DNS."

3. Add a DMARC record — start with p=quarantine if you're unsure. The ActivistCentral guide includes a recommended starting DMARC record you can use directly.

4. Wait for DNS propagation — typically a few minutes to a few hours. DNS changes don't take effect instantly. Most propagate within an hour but can take up to 48 hours in rare cases.

5. Verify the records are working using ActivistCentral's domain verification tool. The platform will confirm all three records are detected and configured correctly before you start sending.

Most organizations complete this in under 30 minutes. Once it's done, you generally won't touch these records again unless you change email providers or add a new sending service.

SPF, DKIM, and DMARC aren't complicated once you understand what each one is actually doing. They're the infrastructure that tells the internet your organization's emails are real, authorized, and trustworthy. Set them up before your first campaign, verify they're working, and then focus on what matters: the messages themselves.

Next up: Why campaign emails go to spam — even when you did everything right