SPF vs DKIM vs DMARC: The Complete Email Authentication Guide

If your business email lands in spam, or you want to protect your domain from being spoofed by phishers, you need SPF, DKIM and DMARC. This guide explains what each does, in plain English, and shows you exactly what to paste into DNS for Gmail, Google Workspace, and Microsoft 365.

Table of Contents

• Why email authentication matters in 2026
• SPF — sender IP authorization
• DKIM — cryptographic signing
• DMARC — policy enforcement + reports
• How the three work together
• Setting up SPF for Google Workspace
• Setting up SPF for Microsoft 365
• Setting up DKIM for Google Workspace
• Setting up DKIM for Microsoft 365
• Publishing a starter DMARC policy
• Reading DMARC aggregate reports
• Common mistakes
• Troubleshooting
• FAQ

Why Email Authentication Matters in 2026

Gmail and Yahoo now reject unauthenticated mail from bulk senders. Microsoft 365 aggressively spam-folders it. Phishers spoof your domain to attack your customers. Publishing SPF, DKIM and DMARC solves all three problems and takes an afternoon.

SPF — Sender IP Authorization

SPF (Sender Policy Framework) is a DNS TXT record that lists which IP addresses and services are allowed to send email 'from' your domain. When a receiving server gets a message claiming to be from yourdomain.com, it looks up your SPF record and checks whether the sending server's IP is in the allow list.

Example: v=spf1 include:_spf.google.com ~all — allows Google, soft-fails everyone else.

DKIM — Cryptographic Signing

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outbound message. The receiver fetches your public key from a DNS TXT record (selector._domainkey.yourdomain.com) and verifies the signature.

If the signature matches, the receiver knows: (a) the mail really came from an entity that has your private key, and (b) nothing in the headers or body was altered in transit.

DMARC — Policy Enforcement + Reports

DMARC (Domain-based Message Authentication, Reporting and Conformance) sits on top of SPF and DKIM. It publishes two things: a policy for what receivers should do when SPF or DKIM fails, and an email address where receivers should send daily reports.

Policies: p=none (monitor only), p=quarantine (send to spam), p=reject (bounce).

Example: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1;

How the Three Work Together

A receiving server does this for every incoming message:

1. Look up SPF for the sending domain. Pass or fail?
2. Verify DKIM signature. Pass or fail?
3. Look up DMARC policy for the From: domain.
4. Check alignment: does SPF/DKIM pass on the same domain that appears in From:?
5. Apply the DMARC policy (none / quarantine / reject).
6. Send an aggregate report to the rua address in the DMARC record.

Setting Up SPF for Google Workspace

In your DNS (registrar or DNS provider), add one TXT record at the root of your domain (@):

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

If you also send from another service (Mailchimp, SendGrid, etc.), combine them: v=spf1 include:_spf.google.com include:sendgrid.net ~all. Never publish two separate SPF records.

Setting Up SPF for Microsoft 365

Add this TXT at the root of your domain: v=spf1 include:spf.protection.outlook.com -all. Note the -all (hard fail) that Microsoft recommends once you've confirmed everything works.

Setting Up DKIM for Google Workspace

1. Sign into admin.google.com.
2. Apps → Google Workspace → Gmail → Authenticate email.
3. Select your domain, click Generate new record (2048-bit).
4. Copy the generated TXT record.
5. In DNS, create a TXT record at google._domainkey.yourdomain.com with the copied value.
6. Back in the Admin console, click Start authentication.

Setting Up DKIM for Microsoft 365

1. In the Microsoft 365 admin center, go to security.microsoft.com → Email & collaboration → Policies & rules → DKIM.
2. Select your domain and click Create DKIM keys.
3. Microsoft gives you two CNAME records (selector1 and selector2). Add both to DNS.
4. Return to the DKIM page and switch DKIM signing to On.

Publishing a Starter DMARC Policy

Add a TXT record at _dmarc.yourdomain.com with value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1;. p=none is monitoring only — no risk to legitimate mail. Wait 4-6 weeks, verify all your senders pass, then move to p=quarantine and finally p=reject.

Reading DMARC Aggregate Reports

Reports arrive as XML attachments daily. They're unreadable raw — sign up for a free DMARC parser (Postmark, Dmarcian, ValiMail). They show which senders pass, which fail, and by what percentage — so you can find shadow senders (marketing platforms someone else set up) before you tighten the policy.

Common Mistakes

• Publishing two SPF records — causes PermError, DMARC fails on SPF for everything.
• Setting p=reject before monitoring — legitimate mail bounces to customers.
• Forgetting subdomains — DMARC alignment can fail if you send from mail.yourdomain.com but SPF is only at yourdomain.com.
• Using +all in SPF — allows the entire internet to send as you.
• Missing DKIM alignment — your ESP signs with their domain, not yours.

Troubleshooting

1. Mail rejected by Gmail? Check DMARC report — look for SPF/DKIM alignment failures.
2. Mail always going to spam at Microsoft? Verify SPF ends in -all, not ~all.
3. DKIM verification failing? DNS TXT record must be exactly one string (Microsoft uses CNAME instead).
4. No DMARC reports arriving? Confirm rua= mailbox exists and DNS is correct.