◈ DomainGuard

← Blog

DMARC, SPF, DKIM: Stop Email Spoofing

2026-10-13 · 7 min read · By the DomainGuard team

The short version

SPF, DKIM, and DMARC are three DNS-based protocols that together stop attackers from sending email as your domain. SPF lists which servers may send for you. DKIM cryptographically signs your messages so tampering is detectable. DMARC ties them together: it says what receivers should do with mail that fails the checks, and, critically, it sends you reports showing who's sending as your domain, legitimate or not. Since February 2024, Gmail and Yahoo require bulk senders (5,000+ messages/day) to publish SPF, DKIM, and at least a p=none DMARC record; Microsoft's Outlook added equivalent rules in May 2025. If your domain lacks these records, you're both easier to impersonate and increasingly likely to hit spam folders.

What each protocol does, in plain terms

SPF (Sender Policy Framework) is a DNS TXT record that lists the IP addresses and services allowed to send mail for your domain. When a receiving server gets mail claiming to be from you, it checks the sending IP against your SPF record. Match: pass. No match: fail. Simple, and limited, because SPF only checks the envelope sender (the Return-Path), not the From address your recipients actually see.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each message's headers, signed with a private key whose public half lives in your DNS. Receivers verify the signature: if the message was altered in transit, verification fails. DKIM survives forwarding better than SPF (forwarders change the sending IP, breaking SPF, but the signature usually survives), which is why you want both.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy layer. It says: for mail claiming to be from my domain, require SPF or DKIM to pass and align with the visible From domain, and if neither does, do this: p=none (deliver anyway, just report), p=quarantine (send to spam), or p=reject (bounce it). DMARC without a policy is just monitoring; DMARC at p=reject is enforcement.

Alignment is the detail that makes DMARC work. SPF might pass for your marketing platform's domain and DKIM for your mail provider, but DMARC requires at least one of them to align with the domain in the From header the user sees. Without alignment, an attacker can pass SPF with their own domain in the envelope while displaying your domain in the From line. Alignment closes that gap.

The mailbox-provider rules that made this mandatory

For years these were "best practices" that many senders ignored. Then the providers turned them into delivery requirements:

The practical consequence: even if you never send bulk mail, publishing SPF, DKIM, and DMARC now improves your deliverability baseline everywhere, because every major provider treats authenticated domains as more trustworthy by default. And from the security side, a domain with p=reject is a domain attackers can't spoof directly — which pushes them toward lookalike domains instead (a threat we cover in our BEC playbook).

The rollout that doesn't break your email

The reason many companies sit at no-DMARC for years is fear: flip to p=reject on day one and you might bounce legitimate mail from a SaaS tool someone forgot to inventory. The safe rollout has four stages:

Stage 1, inventory. List every service that sends as your domain: your mail host, marketing platform, CRM, support desk, invoicing tool, that HR system nobody remembers. Check each one's docs for their required SPF include and DKIM setup. Miss one and you'll be debugging it later.

Stage 2, publish SPF and DKIM. A typical SPF record:

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:mailgun.org ~all"

Watch the 10-DNS-lookup limit: SPF allows at most 10 DNS lookups during evaluation (nested includes count). Exceed it and SPF returns a permanent error, effectively a fail. Audit your includes; flattened or consolidated records beat long include chains. DKIM goes in as TXT records at <selector>._domainkey.example.com with the public key your provider gives you.

Stage 3, DMARC at p=none with reporting.

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1;"

p=none changes nothing about delivery — it just turns on the reports. The rua address receives aggregate XML reports from every major receiver, typically daily. Run at p=none for two to four weeks and read the reports: they show every IP and service sending as your domain, pass/fail per message, and, the gold, any unauthorized senders you didn't know about.

Stage 4, tighten to quarantine, then reject. Once the reports show all legitimate mail passing with alignment, move to p=quarantine (a small percentage first via pct= if you're cautious), watch for another cycle, then p=reject. Keep the rua reporting on permanently, it's your ongoing spoofing radar.

Reading your DMARC reports: what to look for

Aggregate (rua) reports are XML, and raw XML is miserable, use a parser or a report-analysis service. What you're looking for in the parsed view:

Forensic (ruf) reports, per-message failure samples, are far less widely supported by receivers and often redacted for privacy. Don't build your program around them; the aggregate reports carry the program.

What these protocols can't do

Three honest limits. First, as covered in our BEC playbook: none of this stops lookalike domains. SPF/DKIM/DMARC authenticate your domain; the attacker's cousin-domain authenticates itself just fine. Second, DMARC only works if receivers check it, the major providers do, but the long tail is uneven. Third, authentication says nothing about content: a perfectly authenticated email can still be a scam written by the legitimate account holder (or by someone who compromised it). Authentication proves who sent it, not whether to trust it.

FAQ

Do I need DMARC if I barely send email?

Yes, arguably more so. A domain that sends little legitimate mail but has no DMARC is the ideal spoofing target: receivers have no baseline of your real mail to compare against. A p=reject policy on a quiet domain is cheap and nearly risk-free.

What's the difference between ~all and -all in SPF?

~all is a softfail (mail from unlisted servers is marked suspicious but usually delivered); -all is a hard fail (receivers should reject). Start with ~all during rollout, move to -all once DMARC reports confirm your inventory is complete.

Why do my SPF lookups keep failing with "too many DNS lookups"?

SPF permits a maximum of 10 DNS-querying mechanisms per evaluation, and nested includes multiply fast, one vendor's include can hide five more. Consolidate includes, remove dead vendors, and consider SPF flattening (replacing includes with their resolved IPs), accepting that flattened records need maintenance when vendors change infrastructure.

Does p=none actually do anything?

It does the most important thing first: it turns on aggregate reporting without affecting delivery. You can't safely enforce what you can't see. Every competent DMARC deployment spends weeks at p=none reading reports before tightening.

Check your SPF, DKIM, and DMARC posture free — right now.

Run my free report