The Plain-English Email Deliverability Checklist: SPF, DKIM, and DMARC

What Changed in 2024

Historically, the underlying protocol of email (SMTP) was built on trust. Anyone could configure a computer to send an email claiming to be from ceo@yourcompany.com, and recipient servers would usually deliver it.

To stop the deluge of spoofing and phishing scams, major inbox providers (Google Workspace, Microsoft 365, Yahoo, Apple Mail) now inspect three specific DNS verification records before allowing an email into the inbox.

If your domain is missing these records—or has syntax errors in them—your emails are immediately penalized with a high spam score.

SPF: The Guest List at the Door

SPF (Sender Policy Framework) is a simple TXT record published in your domain's DNS.

It acts like a bouncer's guest list at the door of your domain. It explicitly tells receiving servers: "These specific servers and IP addresses are authorized to send email on behalf of my domain. Anyone else is an impostor."

A standard SPF record looks like this:

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

• v=spf1: Identifies the record as SPF Version 1.
• include:_spf.google.com: Authorizes Google Workspace mail servers.
• ~all (SoftFail): Informs receiving servers that any sender not listed should be treated with suspicion.

DKIM: The Unbroken Wax Seal

While SPF verifies where the email came from, DKIM (DomainKeys Identified Mail) verifies that the email was not tampered with in transit.

Think of DKIM as an old-fashioned wax seal stamped with your royal signet ring:

1. When your mail server sends an email, it creates a cryptographic digital signature using your private key and attaches it to the email header.
2. The receiving server looks up your public key in your DNS records.
3. If the public key matches and verifies the digital signature, the receiver knows with mathematical certainty that neither the body text nor the attachments were altered by a bad actor between departure and arrival.

DMARC: The Police Policy

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the master orchestrator that ties SPF and DKIM together.

Even if you have SPF and DKIM configured, receiving servers need to know: "What should I do if an email claiming to be from this domain fails SPF or DKIM?"

DMARC provides three policy levels (p=):

1. p=none (Monitoring Mode): "Deliver the email normally, but send me a daily forensic report about who is sending email using my domain name."
2. p=quarantine (Spam Folder): "If authentication fails, do not deliver to the primary inbox. Quarantine it in the recipient's spam/junk folder."
3. p=reject (Hard Rejection): "If authentication fails, reject and bounce the email completely. Never let it reach the recipient."

The Step-by-Step DNS Playbook

Here is the exact setup routine to lock down your business domain:

Step 1: Configure SPF

Log into your DNS provider (Cloudflare, GoDaddy, Namecheap, Squarespace) and add a TXT record for your root domain (@):

• If using Google Workspace:

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

• If using Microsoft 365:

  v=spf1 include:spf.protection.outlook.com ~all
  

• If sending via both Google and a service like Mailchimp or Stripe:

  v=spf1 include:_spf.google.com include:servers.mcsv.net ~all
  

Step 2: Generate and Publish DKIM

1. In your Google Workspace Admin Console or Microsoft 365 Defender portal, navigate to Email Authentication > DKIM.
2. Click Generate New Record (choose 2048-bit key size).
3. Copy the selector name (e.g., google._domainkey) and the long RSA public key string.
4. Add a new TXT record in your DNS with that selector name and paste the public key.
5. Return to your email admin console and click Start Authentication.

Step 3: Implement DMARC

Add a TXT record for _dmarc.yourdomain.com:

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@yourdomain.com

This policy tells receiving servers: "If an email claiming to come from our domain fails SPF and DKIM, quarantine it in spam 100% of the time, and email our aggregate report address."

3 Pitfalls That Break Deliverability

Watch out for these three common configuration mistakes:

1. Multiple SPF Records: A domain can only have exactly one SPF record. If you add one record for Google and a separate record for Mailchimp, receiving servers consider the SPF configuration invalid and fail both. You must merge them into a single record with multiple include: directives.
2. More Than 10 DNS Lookups: The SPF specification limits a record to 10 DNS lookups. Chaining too many services (Shopify + Zendesk + HubSpot + Google + SendGrid) will cause an automatic SPF PermError.
3. Neglecting Subdomains: Phishers love targeting unprotected subdomains (like mail.yourdomain.com or support.yourdomain.com). Ensure your DMARC record includes the sp=quarantine or sp=reject tag to protect subdomains automatically.