SPF vs DMARC
SPF authorizes which servers may send for your domain; DMARC is a policy-and-reporting layer that uses SPF (and DKIM) results, checks alignment with the visible From domain, and tells receivers what to do on failure. DMARC builds on SPF - they aren't alternatives.
This guide is part of our guide to email authentication. Related: SPF vs DKIM and DKIM vs DMARC.
SPF authorizes which mail servers may send on behalf of your domain. DMARC is a policy-and-reporting layer that consumes SPF (and DKIM) results, checks that they align with the visible From domain, and tells receiving servers what to do when a message fails. DMARC builds directly on SPF — the two are not competing alternatives, they are complementary parts of the same authentication stack.
What SPF does
SPF (Sender Policy Framework) is a DNS TXT record that lists the servers and IP addresses permitted to send email for your domain. When a receiving server accepts a message, it reads the return-path (envelope sender) domain, looks up that domain’s SPF record, and checks whether the connecting IP is authorized. If it is, SPF passes; if not, SPF fails.
The record uses a compact syntax of mechanisms like ip4:, a, mx, and include:. Our guide to SPF record syntax walks through each one. The critical constraint is the 10-lookup limit: SPF permits a maximum of ten DNS lookups per evaluation, and every include:, a, mx, or redirect counts. Exceed it and the record returns PermError, which most receivers treat as no SPF at all. Use the SPF Checker to count your lookups and confirm the record resolves cleanly.
What DMARC does
DMARC (Domain-based Message Authentication, Reporting and Conformance) sits on top of SPF and DKIM and adds three things they lack on their own: alignment, policy, and reporting.
Alignment is the key concept. SPF and DKIM each validate a technical identifier — the return-path domain for SPF, the signing domain for DKIM — but neither guarantees a relationship to the address a human actually sees in the From header. DMARC requires that at least one of them both pass and align with the visible From domain.
Policy tells receivers what to do when nothing aligns: p=none (monitor only), p=quarantine (send to spam), or p=reject (block outright). Reporting sends you aggregate XML reports showing every source sending under your domain, so you can find legitimate senders before you tighten enforcement. Publish DMARC as a TXT record at _dmarc.yourdomain.com and validate it with the DMARC checker.
SPF vs DMARC at a glance
| Aspect | SPF | DMARC |
|---|---|---|
| Purpose | Authorize sending servers | Set policy and get reporting on top of SPF/DKIM |
| What it checks | Is the connecting IP allowed to send for the return-path domain? | Did SPF or DKIM pass and align with the visible From domain? |
| Where it’s published | TXT record on the domain root | TXT record at _dmarc.yourdomain.com |
| Produces reports? | No | Yes — aggregate and forensic reports |
| Enforces on the visible From? | No (checks the envelope return-path) | Yes (alignment is against the From header) |
Why SPF alone isn’t enough
SPF has two structural blind spots. First, it validates the envelope return-path, not the From address your recipients read. A spoofer can pass SPF for a throwaway domain in the return-path while forging your brand in the visible From header, and pure SPF never notices. Second, SPF breaks on forwarding: when a message is relayed, the forwarding server’s IP is usually not in your record, so SPF fails through no fault of the original sender.
DMARC closes both gaps. Its alignment requirement ties authentication back to the visible From domain, and DKIM (which survives forwarding) gives a second path to pass. There is also a failure mode that quietly undoes SPF entirely: a record that exceeds the 10-lookup limit returns PermError and is effectively ignored by receivers, silently disabling your SPF. AutoSPF flattens your includes into a compact, always-valid record that stays under the limit so SPF keeps working as your senders change.
Use them together
SPF and DMARC are not an either/or choice. The goal is a layered setup: a valid SPF record authorizing your senders, DKIM signing your outbound mail, and a DMARC policy of p=reject binding both to the visible From domain. Start SPF and DKIM, publish DMARC at p=none to gather reports, confirm every legitimate source aligns, then move to p=quarantine and finally p=reject. That progression gives you full spoofing protection without blocking your own mail along the way.
Frequently Asked Questions
What is the difference between SPF and DMARC?
SPF authorizes which servers may send for your domain by checking the envelope return-path against a DNS record. DMARC is a policy and reporting layer that uses SPF and DKIM results, requires them to align with the visible From address, and tells receivers whether to monitor, quarantine, or reject failing mail.
Can I use DMARC without SPF?
Technically DMARC can pass on DKIM alignment alone, but you should not rely on that. SPF and DKIM give DMARC two independent paths to authenticate a message, and forwarding often breaks one of them. Publishing both SPF and DKIM makes DMARC far more reliable and is the recommended configuration for every domain.
Does SPF alone stop spoofing?
No. SPF only validates the envelope return-path, not the From address recipients actually see. An attacker can pass SPF on an unrelated domain while forging your brand in the visible From header. Only DMARC, through its alignment requirement, ties authentication to the visible From domain and reliably blocks that kind of direct-domain spoofing.
Should I set up SPF or DMARC first?
Set up SPF (and DKIM) first, because DMARC depends on their results. Publish a valid SPF record under the 10-lookup limit, add DKIM signing, then publish DMARC at p=none to collect reports. Once you confirm your legitimate senders align, tighten the policy to quarantine and finally reject for full protection.