SPF, DKIM, and DMARC in plain English

If you've ever sent a perfectly normal email from your business address and watched it land in a customer's spam folder, the cause is almost always one of three DNS records: SPF, DKIM, or DMARC.

These three records are how Gmail, Outlook, Yahoo, and every other mail provider answer one question before they show your email to a human: was this email actually sent by the people who own the domain it claims to come from?

When the answer is "we can't tell," the email goes to spam. When the answer is "definitely not," the email gets dropped completely. As of February 2024, Google and Yahoo enforce all three for any sender pushing more than 5,000 messages a day, and they're aggressive about filtering smaller senders who fail too.

Here's what each record actually does, in the order you should think about them.

SPF: who is allowed to send for you

SPF stands for Sender Policy Framework. It's a single line of text published in your DNS that lists every server and service allowed to send email as your domain.

A typical SPF record looks like this:

v=spf1 include:_spf.google.com include:spf.mailgun.org ~all

Translated: "Google's mail servers and Mailgun's servers are allowed to send for us. Anyone else, treat as suspicious."

When Gmail receives an email claiming to be from you@yourcompany.com, it looks up your SPF record, checks the sending server's IP address, and asks: is this server on the list? If yes, SPF passes. If no, SPF fails.

The two most common SPF problems we see on scans:

1. No SPF record at all. Every legitimate sender appears to Gmail as if it could be spoofed. This is the single biggest cause of "why does my email always go to spam."
2. Too many include: statements. SPF has a hard limit of 10 DNS lookups per record. Once you cross that, the entire record fails and Gmail treats you as if you had none. This usually happens after a company has signed up for Google Workspace, Mailchimp, HubSpot, Klaviyo, and three CRMs over the years, never cleaning up the SPF.

If your SPF record is over the lookup limit, the fix is to flatten or split it, not to add more include: lines.

DKIM: a cryptographic signature on every email

DKIM stands for DomainKeys Identified Mail. Where SPF authorizes the server, DKIM signs the email itself.

When your sending service (Google Workspace, Mailgun, etc.) sends a message, it adds a cryptographic signature to the email headers. That signature is generated using a private key only the sending service has. The matching public key is published in your DNS at a specific path, like selector1._domainkey.yourcompany.com.

Gmail reads the signature, fetches the public key from your DNS, and verifies the email hasn't been tampered with in transit. If the signature matches, DKIM passes. If it doesn't match (or no DKIM signature is present), DKIM fails.

Why this matters: SPF only verifies the server. DKIM verifies the message contents. A determined attacker could potentially relay through an authorized server, but they can't forge a DKIM signature without your private key.

Common DKIM problems:

1. Missing DKIM entirely. Many small businesses set up SPF correctly because Google Workspace tells them to, but forget DKIM, which is configured separately.
2. Wrong selector. Google Workspace uses google._domainkey. Mailgun uses k1._domainkey and k2._domainkey. Klaviyo uses something different again. Each service publishes the exact records you need: copy them carefully.
3. Old DKIM keys still published after switching providers. Harmless but messy.

DMARC: tell Gmail what to do when SPF or DKIM fails

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It's the policy layer.

Without DMARC, when Gmail sees an email that fails SPF or DKIM, it has to guess what you'd want it to do. Block it? Send to spam? Show it anyway with a warning?

DMARC removes the guessing. Your DMARC record tells receiving mail servers exactly what to do:

v=DMARC1; p=reject; rua=mailto:reports@yourcompany.com; pct=100;

The important part is p=, which has three possible values:

• p=none means "monitor only, don't enforce." You still get reports about who's sending email as you, but nothing gets blocked. This is where you start.
• p=quarantine means "if SPF and DKIM both fail, send the message to spam."
• p=reject means "if SPF and DKIM both fail, bounce the message back. Don't deliver it at all."

The path most companies take: start with p=none, watch the DMARC reports for two to four weeks to confirm all your legitimate senders pass, then move to p=quarantine, then to p=reject.

Why this matters more than you'd think: if you don't have a DMARC record at all, anyone can send phishing emails that look like they came from your domain. Customers, employees, and partners all get spoofed messages with your branding on them. Once you publish p=reject, those phishing campaigns stop working. It's the single most effective anti-phishing control you can apply to your brand.

How they fit together

A simple mental model: SPF answers "who is allowed to send," DKIM answers "did this specific message come from them untampered," and DMARC answers "what should happen when one of those checks fails."

You need all three. Gmail and Yahoo's bulk-sender rules now require all three explicitly. Microsoft is moving the same direction. A site we scanned last month had perfect SPF and DKIM but no DMARC: their domain was being used to send phishing emails to their own customers, and they had no idea until one of those customers called.

What to do next

Scan your domain. AcuityScan checks all three records, validates the syntax, counts your SPF DNS lookups, looks up DKIM across 16 common selectors, and tells you exactly what's missing.

If your SPF passes, your DKIM passes, and your DMARC is set to at least p=quarantine, you're in better shape than roughly 70% of the small business sites we've scanned.

If any of those three are missing, you have a measurable, fixable reason your email isn't reaching the inbox.