SPF, DKIM, and DMARC Explained for Non-Technical Founders

You bought a domain. You set up Google Workspace. You wrote your cold emails. You hit send on 100 emails.

Three days later, you discover 80 of them went to spam. Your open rate is 8%. You have no idea why.

The answer is almost always one of three acronyms: SPF, DKIM, or DMARC. If any one of them is missing or misconfigured, receiving email servers can't verify your emails are legitimate — so they default to "probably spam."

In 2026, Google, Yahoo, and Microsoft all actively enforce these authentication checks. Sending cold email without them isn't risky — it's guaranteed failure. Here's what each one does, in plain English, and exactly how to set them up.

The Airport Security Analogy

Think of email authentication like airport security:

• SPF = Your boarding pass. It proves you're allowed to fly from this gate (send from this domain).
• DKIM = The security seal on your luggage. It proves nobody tampered with your bag (email) after you checked it.
• DMARC = The airport security policy. It tells security what to do if your boarding pass or luggage seal fails inspection.

If any one of these checks fails, you don't board the plane — or in email terms, you land in spam.

SPF: Who Can Send From My Domain?

Plain English: SPF is a list you publish in your DNS that says "these specific mail servers are authorized to send email from my domain. Anyone else claiming to be me is lying."

What it actually does: When a receiving server gets an email from you@yourdomain.com, it looks up your SPF record. It checks whether the server that sent the email is on your authorized list. If it is: SPF PASS. If it isn't: SPF FAIL. If there's no SPF record at all: SPF NONE — which is treated the same as FAIL for deliverability purposes.

What an SPF record looks like:

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

Let's decode this: v=spf1 — this is an SPF record. include:_spf.google.com — Google's mail servers are authorized. ~all — if a server not on this list tries to send from my domain, mark it as suspicious but don't reject it yet (softfail).

How to Add an SPF Record (Step by Step)

1. Go to your domain's DNS provider (Cloudflare, Namecheap, GoDaddy — wherever you bought your domain)
2. Find the DNS management section (usually called "DNS Settings" or "Manage DNS")
3. Add a new TXT record
4. For the Name/Host field, use "@" (meaning the root domain)
5. For the Value field, paste your SPF record
6. Save. Wait 5-10 minutes for propagation.

SPF templates by provider:

• Google Workspace only: v=spf1 include:_spf.google.com ~all
• Microsoft 365 only: v=spf1 include:spf.protection.outlook.com ~all
• Google + SendGrid: v=spf1 include:_spf.google.com include:sendgrid.net ~all

Critical rules: Only ONE SPF record per domain. If you need multiple services, merge them into a single record — don't create separate TXT records. Stay under 10 DNS lookups (each include: counts as one). Exceed 10 lookups and SPF breaks entirely — emails from authorized servers get rejected.

DKIM: Prove This Email Wasn't Tampered With

Plain English: DKIM is a digital signature added to every email you send. Your DNS publishes the key to verify that signature. It proves two things: the email actually came from your domain, and nobody changed the content after you sent it.

What it actually does: When you send an email, your email provider signs it with a private key that only they have. The receiving server looks up your DKIM public key (published in DNS) and uses it to verify the signature. If the signature matches: DKIM PASS — the email is authentic and untampered. If it doesn't match or doesn't exist: DKIM FAIL.

How to Set Up DKIM for Google Workspace

1. Go to Google Admin Console (admin.google.com)
2. Navigate: Apps > Google Workspace > Gmail > Authenticate email
3. Select your domain from the dropdown
4. Click "Generate new record"
5. Choose 2048-bit key length (1024-bit is deprecated in 2026)
6. Copy the generated DNS TXT value
7. In your DNS provider, add a TXT record with hostname: google._domainkey.yourdomain.com
8. Paste the value Google provided
9. Return to Admin Console and click "Start Authentication" to enable DKIM signing

Verification: Send an email to a Gmail address. Open it, click the three dots > Show original. Look for "DKIM: PASS with domain yourdomain.com." If it says FAIL or DKIM isn't mentioned, it's not set up correctly.

DKIM for Microsoft 365

1. Go to Microsoft 365 Defender portal (security.microsoft.com)
2. Navigate: Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM
3. Select your domain and toggle DKIM signing to "Enabled"
4. Microsoft auto-generates two CNAME records — add them both to your DNS
5. Wait 24-48 hours for full propagation

DMARC: The Policy That Ties It All Together

Plain English: DMARC is the instruction manual you give to receiving servers: "Here's what I want you to do when SPF or DKIM fails — send it to spam, reject it, or let it through. Also, send me reports about who's using my domain."

What it actually does: DMARC defines three policy levels:

• p=none: Monitor only. Don't take any action on failed emails — just send me reports. This is where you start.
• p=quarantine: Send failed emails to the spam folder. This is your middle ground — you're enforcing, but not rejecting outright.
• p=reject: Don't deliver failed emails at all. This is full enforcement — the gold standard, but don't jump here on day one.

How to Set Up DMARC

1. In your DNS provider, add a TXT record
2. Host/Name: _dmarc
3. Value: v=DMARC1; p=none; rua=mailto:you@yourdomain.com
4. The rua= address receives aggregate reports — you'll get weekly emails showing who's sending from your domain

Recommended DMARC progression:

• Weeks 1-4: p=none (monitor, identify issues, fix alignment problems)
• Weeks 5-8: p=quarantine (route failures to spam — soft enforcement)
• Week 9+: p=reject (full enforcement — blocks unauthenticated emails)

A p=none policy that never progresses to quarantine or reject signals to providers that you're collecting data but not acting on it. In 2026, this hurts your reputation almost as much as having no DMARC at all.

How to Verify All Three Are Working

1. MXToolbox Deliverability Test: Go to mxtoolbox.com/deliverability, enter your domain. It checks SPF, DKIM, and DMARC in one scan. Green = good. Red = fix before sending.
2. Google Admin Toolbox Check MX: Go to toolbox.googleapps.com/apps/checkmx, enter your domain. Google-specific diagnostic that shows deliverability from Google's perspective.
3. Send a test email to a Gmail address: Open the email, click the three dots > Show original. You should see: SPF: PASS, DKIM: PASS, DMARC: PASS. If any say FAIL or are missing, something is broken.
4. Google Postmaster Tools: After sending some volume, check postmaster.google.com. Your domain reputation should show "High." If it shows "Medium" or "Low," your authentication setup needs attention.

What Happens If You Skip These

• No SPF: Receiving servers can't verify your email actually came from your domain. Treated as spoofed/spam by default.
• No DKIM: No proof your email content hasn't been altered. Gmail and Outlook both weight DKIM heavily — missing DKIM is a major negative spam score factor.
• No DMARC: Providers apply their own policies to unauthenticated email from your domain. Google defaults to quarantine. You've given up control of your deliverability.
• All three missing: Your emails are going to spam. Not might go — are going. In 2026, sending cold email without SPF, DKIM, and DMARC is like driving without a license plate. You might get away with it for a day, but eventually you get pulled over.

The 2026 Reality

Google's bulk sender requirements (enforced since February 2024, strengthened November 2025), Yahoo's authentication mandates (June 2024), and Microsoft's DMARC enforcement (May 2025) have made SPF, DKIM, and DMARC table stakes. Not best practices — minimum requirements.

XSendFlow's preflight deliverability checker automatically verifies all three DNS records before your first campaign sends. It checks each record against MXToolbox, Google's Admin Toolbox, and 6 DNS blacklists — then shows you exactly which records pass, which fail, and what to fix. No command line. No DNS jargon. Just a green checkmark for "ready" or a clear fix instruction for "not ready."