SPF, DKIM, DMARC: The 3-Record Setup That Stops Your Emails Landing in Spam

In February 2024 Gmail and Yahoo started enforcing email authentication for bulk senders. Within months, anyone sending more than a few thousand emails a day without SPF, DKIM, and DMARC saw deliverability collapse. If you're running cold outreach in 2026, these three records aren't optional — they're table stakes.

Here's what each one does and how to confirm yours are working.

SPF: who is allowed to send mail as you?

Sender Policy Framework is a TXT record on your domain that lists every server permitted to send mail using your domain name. When a receiver gets a message claiming to be from you, they look up your SPF record and reject the mail if it came from somewhere not on the list.

A typical SPF record looks like:

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

This says: "Google's servers and SendGrid's servers can send mail as us; anything else, soft-fail." The ~all at the end is the catch-all policy: ~ is soft fail (probably reject), - is hard fail (definitely reject), ? is neutral (don't care).

Common mistakes: more than 10 include: lookups (SPF lookup limit — receivers stop checking), +all (allow everything — defeats the point), or no SPF record at all.

DKIM: did this message actually come from you?

DomainKeys Identified Mail cryptographically signs outgoing emails. The receiver looks up your public key in DNS and verifies the signature. If the signature is valid, they know the message wasn't tampered with in transit and really did come from your infrastructure.

DKIM records live at selector._domainkey.yourdomain.com. The selector varies by provider — Google uses google, SendGrid uses s1 and s2, Mailgun uses k1, and so on. You usually get the value from your ESP's admin panel and paste it into DNS.

You can't enumerate DKIM selectors via DNS, which is why most DNS-check tools (including ours) try a list of common ones.

DMARC: what should receivers do when SPF or DKIM fails?

Domain-based Message Authentication, Reporting and Conformance is the policy layer. It tells receivers what to do when authentication fails, and where to send reports about failures.

A typical DMARC record:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100

Three policies:

• p=none — monitor only, deliver everything. Useful for the first 30 days while you fix issues.
• p=quarantine — send failing messages to spam.
• p=reject — bounce failing messages outright.

Start with none, watch the reports for two weeks, then move to quarantine, then reject once you're sure all legitimate senders are aligned.

How to check yours

Our free DNS health checker confirms SPF, DKIM, DMARC, and MX in one pass. Paste your domain — you'll see which records are missing or weak in under five seconds. If anything fails, fix it before you send your next bulk campaign.

And before you send to a fresh list, run it through bulk verification. Even with perfect authentication, high bounce rates tank sender reputation.