SPF, DKIM, and DMARC in Plain English

If I told you that right now, anyone in the world can send an email that appears to come from ceo@yourcompany.com—without hacking anything, without your password, without any access to your systems—you'd probably want to fix that.

That's not a hypothetical. It's how email was designed in the 1980s, and it's still how most email works today.

SPF, DKIM, and DMARC are the three controls that fix this. Here's what each one does.

SPF (Sender Policy Framework)

What it does: Tells the world which mail servers are allowed to send email for your domain.

Plain English: Think of it like a guest list. When your email server sends a message, it says: "I'm sending this from server 1.2.3.4." The receiving server checks: "Is 1.2.3.4 on the guest list for yourcompany.com?" Yes? Email passes. No? Email fails.

Real example: You use Microsoft 365 for email. Their servers send for you. Your SPF record says: v=spf1 include:spf.protection.outlook.com ~all. Any email claiming to be from @yourcompany.com that doesn't come from Microsoft's servers fails SPF.

What happens without it: Anyone can send email claiming to be from @yourcompany.com. The receiving server has no way to know if it's legitimate.

How to check yours: Go to MXToolbox.com, enter your domain, look at the SPF record.

DKIM (DomainKeys Identified Mail)

What it does: Adds a cryptographic signature to your emails that proves they weren't tampered with in transit.

Plain English: Think of it like a wax seal on a letter. When you send an email, your email provider stamps it with a digital signature using a private key. Receiving servers use your public key (published in your DNS) to verify: "Did this email actually come from yourcompany.com? Was it changed along the way?"

Real example: You send a contract to a customer. The email is signed with your DKIM key. Somewhere in transit, a man-in-the-middle tries to modify the contract terms. The signature no longer matches. Receiving server flags the email as potentially tampered with.

What happens without it: Emails can be modified in transit without detection. Attachments can be swapped. Bank account numbers can be changed. You have no cryptographic proof your emails weren't altered.

How to check yours: Most email providers enable this automatically. In Microsoft 365, check under Exchange Admin > Mail Flow > DKIM. In Google Workspace, check under Admin > Apps > Gmail > Authenticate Email.

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

What it does: Tells receiving mail servers what to do with emails that fail SPF and DKIM checks. Also sends you reports about who's sending email "from" your domain.

Plain English: SPF says "is this server on the guest list?" DKIM says "is this email signed properly?" DMARC says "what should we do if the answer is no?"

Real example: You set DMARC to p=reject. An attacker tries to send fake emails from ceo@yourcompany.com. The receiving server checks SPF and DKIM. Both fail. DMARC says "reject this email." The fake email bounces.

Three DMARC settings:

p=none (monitoring mode)

Do nothing to failing emails, just report them to you
Use this when you're first setting up SPF/DKIM
Lets you see what's failing before you start blocking

p=quarantine

Mark failing emails as spam instead of rejecting them
Users might miss some legitimate emails (false positives)
Safer than reject while you're still testing

p=reject

Block failing emails entirely
Most secure option
Only use after you've monitored for weeks and are confident nothing legitimate is failing

The reporting part: DMARC includes rua=mailto:your@email.com. This sends you XML reports showing every email that passed or failed authentication for your domain. These reports tell you:

Who's sending email "from" your domain
What's passing and what's failing
If attackers are trying to spoof you (they are)

Why You Need All Three

SPF checks which server sent the email. DKIM checks if the email was signed and not tampered with. DMARC ties them together and tells receivers what to do.

You need all three because they check different things:

Example attack SPF prevents: Someone sends email from their server claiming to be from your domain. Example attack DKIM prevents: Someone intercepts your email and modifies the bank account number before delivery. Example attack DMARC prevents: Someone sends email that fails both SPF and DKIM. DMARC tells receivers to reject it.

What Can Go Wrong

"SPF is too strict" You set up SPF and only include your main email server. But you forgot: your CRM also sends email "from" your domain. Your website form sends email "from" your domain. Now legitimate emails from those services fail SPF. Customers don't get their invoices.

"DMARC is too permissive" You set p=none and never change it. You get reports showing attackers are spoofing your domain, but you do nothing. The spoofed emails reach customers. One of them pays the fake invoice.

"You change providers and forget to update SPF" You switched from Google Workspace to Microsoft 365. You updated your MX records but forgot to update SPF. Now your legitimate new emails fail SPF because the record still points to Google's servers.

"You don't read the DMARC reports" The reports show someone in China is sending thousands of emails "from" your domain daily. You have no idea because you've never opened the reports. The spoofing continues.

What It Costs

Setup: $0

SPF: One DNS TXT record
DKIM: Built into Microsoft 365 and Google Workspace, one CNAME record
DMARC: One DNS TXT record

Monitoring:

Built-in reports: Free (XML files in your inbox)
Third-party DMARC monitoring: $0-$50/month (makes reports easier to read)

What happens if you don't do it:

Impersonation attacks succeed more often
Customers receive fake emails "from" your domain
Your reputation gets damaged
BEC scams are more likely to work

Minimum Viable Implementation

Check if you already have SPF/DKIM. Most Microsoft 365 and Google Workspace accounts have SPF set up automatically. DKIM may need to be enabled manually. Check your DNS records at DNSWatch or MXToolbox.
Enable DKIM if it's not already. In Microsoft 365: Exchange Admin > Mail Flow > DKIM. In Google Workspace: Admin > Apps > Gmail > Authenticate Email.
Create your DMARC record. Add a TXT record at _dmarc.yourcompany.com:
```
v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com
```
Create the dmarc@yourcompany.com address. This is where you'll receive reports.
Monitor for 4 weeks. Read the DMARC reports. Learn what's passing and what's failing. Find any legitimate senders you missed in SPF.
Fix legitimate failures. Add missing services to your SPF record.
Upgrade to p=quarantine. After 4 weeks of clean monitoring, change to p=quarantine.
Upgrade to p=reject. After another 4 weeks, change to p=reject if nothing legitimate is failing.

Vendor Questions (Copy/Paste)

"Is SPF/DKIM/DMARC set up automatically for our domain, or do we need to configure it?"
"Can you show us which services are currently authorized to send email from our domain?"
"We want to start receiving DMARC reports. What address should we use, and can you help us interpret them?"
"What happens if our email fails SPF or DKIM—do we get notified?"
"We're switching email providers. What's the process for updating our SPF record?"

When to Hire Help

DIY-friendly if:

Single email provider (Microsoft 365 or Google Workspace only)
No third-party services sending email from your domain
Basic DNS knowledge

Get professional help if:

Multiple domains with different email providers
Complex email routing
Previous impersonation attacks
Need to troubleshoot delivery issues
Don't have anyone who can interpret DMARC reports