SPF vs DMARC — Understanding the Difference

SPF and DMARC are both email authentication protocols, but they work at different levels. SPF checks whether the sending server is allowed to send email for your domain. DMARC checks whether that SPF result aligns with the address recipients actually see, and then tells the receiving server what to do about it.

Many domain owners set up SPF and assume they are covered. They are not. SPF has real limitations that leave your domain open to spoofing and give you zero visibility into who is sending email as you. This guide explains what SPF does, where it falls short, and what DMARC adds to close those gaps. For the full picture of how all three protocols work together, see our email authentication guide.

What SPF Does on Its Own

SPF stands for Sender Policy Framework. It is a DNS TXT record that lists every server authorized to send email on behalf of your domain. A typical SPF record looks like this:

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

When a mail server receives a message, it checks the envelope sender (the Return-Path address, not the visible "From" header) and looks up the SPF record for that domain. If the sending server's IP address matches one of the authorized sources, SPF passes. If it does not, SPF fails.

SPF is straightforward to set up and it catches a basic category of abuse — someone trying to send email from an unauthorized server using your domain as the envelope sender. It was one of the first email authentication standards and remains a foundational part of email security.

You can create an SPF record for your domain at spfcreator.com.

SPF's Limitations

SPF solves one problem, but it has several well-known weaknesses that limit how much it can protect your domain.

It Does Not Check the "From" Header

This is the biggest gap. SPF verifies the envelope sender (Return-Path), which is a technical address used for bounce handling. It does not verify the "From" header — the address your recipients actually see in their inbox. A spammer can set their own domain as the envelope sender (passing SPF for their domain) and put your domain in the "From" header. The email arrives looking like it came from you, and SPF never raises a flag.

It Breaks During Forwarding

When someone forwards your email — through a mailing list, an office redirect, or a personal forwarding rule — the forwarding server relays the message from its own IP address. That IP is not in your SPF record, so SPF fails. This is a known, structural limitation of SPF. There is no workaround within the SPF specification itself.

The 10-Lookup Limit

SPF records can reference other records using include: statements. Each include triggers a DNS lookup, and SPF has a hard limit of 10 DNS lookups per evaluation. If your SPF record exceeds this limit (which happens fast when you use multiple email services), the entire SPF check returns a permerror and is treated as a failure. This limit catches many organizations off guard as they add new services over time.

No Reporting Mechanism

SPF does not send you reports. If someone is spoofing your domain and SPF is failing, you have no way of knowing unless a recipient tells you. You are operating blind, with no data about who is sending email as your domain or whether your legitimate messages are passing authentication.

No Policy Enforcement

SPF can indicate that unauthorized senders should be rejected (the -all mechanism), but this only applies to the envelope sender check. There is no way for SPF to instruct receiving servers about what to do with messages that fail based on the visible "From" address. The receiving server makes its own judgment call.

What DMARC Adds on Top

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It does not replace SPF — it builds on it (and on DKIM) to fill the gaps listed above.

Alignment with the "From" Header

DMARC introduces the concept of alignment. When DMARC evaluates a message, it checks whether the domain in the SPF check (the envelope sender) matches the domain in the "From" header that the recipient sees. If your envelope sender is bounce@yourdomain.com and the "From" address is hello@yourdomain.com, the domains align and DMARC passes on the SPF side.

If a spammer passes SPF using their own domain but spoofs your domain in the "From" header, SPF alignment fails because the two domains do not match. This is the check SPF cannot do on its own.

DMARC supports relaxed alignment (organizational domains must match, so mail.yourdomain.com aligns with yourdomain.com) and strict alignment (exact domain match required). Most organizations use relaxed alignment. For a deeper dive into how alignment modes work, see DMARC alignment explained.

Policy Enforcement

DMARC lets you publish a policy telling receiving servers exactly what to do with messages that fail authentication:

• p=none — Deliver the message normally, but send me a report.
• p=quarantine — Send the message to the spam or junk folder.
• p=reject — Block the message entirely.

This gives you control that SPF alone cannot provide. Instead of leaving enforcement up to each receiving server, you set a global policy for your domain.

Aggregate Reporting

When you add a rua address to your DMARC record, mail providers send you regular aggregate reports in XML format. These reports show you which IP addresses sent email as your domain, whether those messages passed or failed SPF and DKIM, and what action was taken. This data is essential for identifying misconfigured services, unauthorized senders, and spoofing attempts.

Side-by-Side Comparison

Why SPF Alone Is Not Enough

If you have only SPF and no DMARC, your domain is exposed in several ways:

Spoofing is still possible. Attackers can send phishing emails that display your domain in the "From" header. SPF might pass on the attacker's infrastructure, and the recipient has no idea the message is fraudulent. Without DMARC, there is no alignment check to catch this.

You have no visibility. You do not know who is sending email as your domain, whether your legitimate messages are passing SPF, or whether your domain is being spoofed. DMARC reports are the only standardized way to get this information.

Forwarded email is unprotected. When SPF fails on forwarded messages, there is no fallback. With DMARC and DKIM in place, forwarded messages can still pass DMARC through DKIM alignment even when SPF fails.

Deliverability suffers. Google, Yahoo, and Microsoft use DMARC as a positive signal when making inbox placement decisions. Since early 2024, Google and Yahoo require DMARC for bulk senders. Even low-volume senders benefit from having a published DMARC record. Learn more about how DMARC improves email deliverability.

The Bottom Line

SPF is a necessary foundation, but it was never designed to be a complete solution. It checks the wrong address (envelope sender, not "From" header), it breaks during forwarding, it has a hard lookup limit, and it gives you no reports.

DMARC fills every one of those gaps. It adds alignment checking to verify the "From" header, policy enforcement to tell receivers what to do, and reporting to give you visibility into your email ecosystem.

Set up SPF first at spfcreator.com, add DKIM for message integrity at dkimcreator.com, then publish a DMARC record to tie it all together. Agencies managing multiple client domains will find this layered approach especially important. You can verify your current setup at dmarcrecordchecker.com.

Monitor Your Email Authentication

You've set up your email authentication — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.