SPF, DKIM, and DMARC Explained: How to Check and Fix Email Authentication

SPF, DKIM, and DMARC are three DNS-based standards that together stop attackers from sending email that appears to come from your domain. SPF declares which servers are allowed to send your mail, DKIM cryptographically signs each message, and DMARC tells receiving servers what to do when a message fails both checks — and asks them to send you reports. To check your setup, look up three DNS records (SPF and DMARC are TXT records; DKIM lives at a selector subdomain), or run an automated checker. To fix the common gaps, publish a valid SPF record ending in ~all or -all, enable DKIM signing at your mail provider, and move DMARC from p=none to p=quarantine or p=reject.

This guide explains what each record does, how to check yours, and how to close the gaps that leave a domain spoofable.

Why do SPF, DKIM, and DMARC matter?

Plain SMTP has no built-in way to prove who sent a message — the "From" address is just text an attacker can type. That is what makes phishing and business-email-compromise work: a fraudster sends mail that looks like it came from your domain, and the receiving server has no reason to doubt it. SPF, DKIM, and DMARC are the layers that close that hole.

There is also a hard deliverability reason. Since 2024, Google and Yahoo's bulk-sender requirements require senders of roughly 5,000+ messages a day to authenticate with SPF, DKIM, and a published DMARC record. Get this wrong and your legitimate mail lands in spam — or is rejected outright.

What is SPF?

SPF (Sender Policy Framework) is a DNS TXT record that lists which mail servers are authorized to send email for your domain. When a receiving server gets a message claiming to be from you@yourdomain.com, it looks up your SPF record and checks whether the sending server's IP is on the list.

A record looks like this:

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

The include: mechanisms pull in the sending infrastructure of providers like Google Workspace or SendGrid. The ending mechanism is the critical part:

SPF is defined in RFC 7208. Two gotchas that catch people out: you may publish only one SPF record per domain, and the whole chain (including everything pulled in by include:) must resolve in 10 or fewer DNS lookups — exceed that and SPF returns a permerror, which counts as a failure. SteelSuit flags both the lookup count and a +all policy as findings.

What is DKIM?

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing message. Your mail server signs the message with a private key; you publish the matching public key in DNS at a selector subdomain like selector1._domainkey.yourdomain.com. The receiver fetches that public key and verifies the signature.

If the signature validates and the signed headers and body were not altered in transit, DKIM passes. That proves two things: the message genuinely came from a server holding your private key, and nobody tampered with it on the way. DKIM is defined in RFC 6376.

Unlike SPF, you usually don't write the DKIM record by hand — your email provider generates the key pair and gives you the DNS record (or sets it up for you) when you enable DKIM signing. The selector name varies by provider, which is why checking DKIM requires knowing the selector your mail flows through.

What is DMARC, and why is p=none dangerous?

DMARC (Domain-based Message Authentication, Reporting & Conformance) is the policy layer that ties SPF and DKIM together. It does two jobs: it tells receivers what to do with mail that fails authentication, and it asks them to send you reports so you can see who is sending mail as your domain. It is published as a TXT record at _dmarc.yourdomain.com and defined in RFC 7489.

A typical record:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com

The p= tag is the policy, and it is where most domains fall short:

The danger is getting stuck at p=none. It is the correct starting point — it lets you collect reports and confirm your legitimate mail aligns before you start blocking. But p=none takes no action on spoofed mail; phishing that fails SPF and DKIM is still delivered. A domain sitting on p=none for months has reports but no protection. SteelSuit reports p=none as a finding precisely because it is so often mistaken for "DMARC is set up." The goal is to progress to p=quarantine, then p=reject.

Two related traps SteelSuit also checks: a subdomain policy (sp=none) weaker than the domain policy lets attackers spoof your subdomains, and a pct= value below 100 means the policy only applies to a fraction of your mail.

SPF vs DKIM vs DMARC: a side-by-side

You need all three. They answer different questions, and DMARC only works because the other two exist.

How do I check my SPF, DKIM, and DMARC records?

You can verify all three yourself with DNS lookups:

1. SPF — query the TXT record at your domain and look for the line starting v=spf1:

   dig +short TXT yourdomain.com
   

2. DMARC — query the TXT record at the _dmarc subdomain:

   dig +short TXT _dmarc.yourdomain.com
   

3. DKIM — query the selector your provider uses (Google Workspace defaults to google, others vary):

   dig +short TXT selector1._domainkey.yourdomain.com
   

Reading the raw records correctly — counting SPF lookups, spotting a weak sp=, confirming the DKIM key parses — is fiddly. The faster path is an automated checker. SteelSuit uses the RFC-compliant checkdmarc library to validate SPF, DKIM, DMARC, and MX in one pass, then turns each gap into a concrete finding: a missing or invalid record, a +all or ?all ending, an SPF chain over the 10-lookup limit, a p=none policy, a weak subdomain policy, and more. There is a free standalone email-security checker at SteelSuit that runs exactly this with no signup.

How do I fix the common gaps?

The findings almost always fall into a handful of buckets:

• No SPF record. Publish one TXT record listing your senders and ending in ~all or -all, e.g. v=spf1 include:_spf.google.com ~all.
• SPF ends in +all or ?all. Change it to ~all (softfail) or -all (hardfail). +all lets anyone send as you and makes SPF worthless.
• SPF over 10 DNS lookups. Drop includes you no longer use, or flatten the record so the full chain resolves in 10 lookups or fewer, or it will permerror.
• No DKIM. Enable DKIM signing in your mail provider's admin console and publish the selector record they give you.
• No DMARC. Start with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com, read the reports, then tighten.
• DMARC stuck at p=none. Once reports confirm your real mail passes, move to p=quarantine, then to p=reject. Match sp= to your domain policy so subdomains aren't a soft spot.

Email authentication is one item on a larger surface — it sits alongside TLS, headers, and exposed secrets in our pre-launch web application security checklist. And because DNS records get edited and occasionally broken, it pays to re-check on a schedule rather than once; see continuous security monitoring for that pattern.

Check your domain in one scan

You don't have to read three DNS records by hand. Run the free DKIM/SPF/DMARC checker on your domain — no signup — and it validates all three via checkdmarc and tells you exactly what to fix.

For the full picture, a SteelSuit fast scan (~30 seconds, free) checks email authentication alongside TLS, security headers, exposed secrets, and sensitive paths, and returns prioritized findings with fix advice; a deep scan (5–6 minutes, after DNS-TXT verification) adds port scanning, content discovery, and subdomain enumeration. To understand how those findings are scored and prioritized, see your vulnerability scan report explained.

SPF, DKIM, and DMARC aren't exotic — they're three DNS records and one policy decision. Get them right once, then re-check them so a stray edit never quietly reopens your domain to spoofing.