SPF vs DKIM vs DMARC: What Each One Does and Why You Need All Three

If you've ever looked into why your company's emails land in spam — or how scammers send mail that looks like it's from your domain — you've run into the same three acronyms: SPF, DKIM, and DMARC.

They're often lumped together, but they do three different jobs. Missing any one of them leaves a specific hole. Here's what each record does, in plain language.

SPF: who's allowed to send for your domain

SPF (Sender Policy Framework) is a DNS TXT record that lists the servers authorized to send email for your domain. When a receiving mail server gets a message claiming to be from you@yourcompany.com, it checks your SPF record to see whether the sending server is on your list.

A typical SPF record looks like this:

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

That says: Google and SendGrid may send for this domain, and everyone else should be rejected (-all).

Two things trip people up:

• The 10-lookup limit. SPF checks may not require more than 10 DNS lookups. Every include: costs at least one, and popular services often chain several. Blow past ten and SPF checks can fail even though your record looks right.
• A soft ending. Records ending in ~all (softfail) ask receivers to be lenient with unlisted senders. That's a reasonable setting while testing, but it's weaker than -all — spoofed mail is merely marked suspicious rather than refused outright.

SPF alone has a blind spot: it checks the hidden "envelope" sender, not the From address a human actually sees. A scammer can pass SPF using their own domain while displaying yours in the From line. That's where the other two records come in.

DKIM: proof the message wasn't forged or altered

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every message you send. Your mail server signs outgoing mail with a private key; the matching public key is published in your DNS at a special address (selector._domainkey.yourdomain.com). Receivers use the public key to verify two things: the message genuinely came from a server holding your key, and the content wasn't modified in transit.

DKIM survives forwarding better than SPF does, and it gives receiving providers a durable signal of authenticity. Without it, you're relying entirely on IP-based trust — and any change in your sending infrastructure can wreck your deliverability overnight.

Setup is service-specific: Google Workspace, Microsoft 365, and every reputable email provider will hand you a DKIM record to publish. If you've never done that step, your mail is probably going out unsigned.

DMARC: the policy that ties it together

SPF and DKIM each verify something, but neither tells receivers what to do when verification fails — and neither, on its own, protects the From address people actually read. That's DMARC's job.

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a TXT record at _dmarc.yourdomain.com that does three things:

1. Alignment. It requires that the domain that passed SPF or DKIM matches the domain in the visible From header. This is what actually stops display-name spoofing of your domain.
2. Policy. It tells receivers what to do with mail that fails: p=none (deliver it, just report), p=quarantine (send it to spam), or p=reject (refuse it).
3. Reporting. With a rua tag, receivers send you aggregate reports showing who is sending mail as your domain — including senders you didn't know about.

A starter DMARC record looks like:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

p=none is the sensible starting point: it changes nothing about delivery but starts the flow of reports so you can find every legitimate sender before tightening. The end goal is p=quarantine and ultimately p=reject — a domain at p=none forever is still spoofable, because failing mail is delivered anyway.

Why you need all three

• SPF only: spoofers can still put your domain in the visible From line.
• DKIM only: receivers can verify signed mail, but there's no rule about unsigned mail claiming to be you.
• SPF + DKIM without DMARC: verification happens, but failures carry no consequences and you get no visibility.
• All three, with DMARC at p=quarantine or p=reject: unauthorized mail claiming to be your domain gets filtered or refused, and you get reports showing every source sending as you.

There's a deliverability payoff too: major mailbox providers, including Gmail and Yahoo, now require bulk senders to authenticate with SPF, DKIM, and DMARC. Missing records don't just enable spoofing — they push your legitimate mail toward spam.

Check your domain in 10 seconds

You don't need to read your DNS zone by hand. Our free scanner checks your SPF, DKIM, DMARC, and MX records straight from live DNS and grades your domain A through F, with a fix plan for anything missing or misconfigured. No signup, nothing installed — the lookups run right in your browser.