As a DMARC services provider, we get asked this question a lot: “If DMARC just uses SPF and DKIM authentication, why should we bother with DMARC? Isn’t that just unnecessary?”

On the surface it might seem to make little difference, but the reality is very different. DMARC isn’t just a combination of SPF and DKIM technologies, it’s an entirely new protocol by itself. It has several features that make it one of the most advanced email authentication standards in the world, and an absolute necessity for businesses.

But wait a minute. We’ve not answered exactly why you need DMARC. What does it offer that SPF and DKIM don’t? Well, that’s a rather long answer; too long for just one blog post. So let’s split it up and talk about SPF first. In case you’re not familiar with it, here’s a quick intro.

Key Takeaways

DMARC is an essential email authentication protocol that provides features beyond what SPF and DKIM offer.
SPF records are limited by a maximum of 10 DNS lookups, which can hinder complex configurations.
SPF does not validate the From address, leaving opportunities for spoofing attacks via a fake Return Path.
Emails can be rejected if forwarded due to discrepancies between the sender’s IP and the SPF record.
DMARC improves security through reporting features that provide insights into authentication failures and spoofing attempts.

What is SPF?

SPF, or Sender Policy Framework, is an email authentication protocol that protects the email receiver from spoofed emails. It’s essentially a list of all IP addresses authorized to send email through your (the domain owner) channels. When the receiving server sees a message from your domain, it checks your SPF record that’s published on your DNS. If the sender’s IP is in this ‘list’, the email gets delivered. If not, the server rejects the email.

Simplify Security with PowerDMARC!

Start 15-day trial Book a demo

As you can see, SPF does a pretty good job keeping out a lot of unsavoury emails that could harm your device or compromise your organisation’s security systems. But SPF isn’t nearly as good as some people might think. That’s because it has some very major drawbacks. Let’s talk about some of these problems.

Limitations of SPF

SPF records don’t apply to the From address

Emails have multiple addresses to identify their sender: the From address that you normally see, and the Return Path address that’s hidden and require one or two clicks to view. With SPF enabled, the receiving email server looks at the Return Path and checks the SPF records of the domain from that address.

The problem here is that attackers can exploit this by using a fake domain in their Return Path address and a legitimate (or legitimate-looking) email address in the From section. Even if the receiver were to check the sender’s email ID, they’d see the From address first, and typically don’t bother to check the Return Path. In fact, most people aren’t even aware there is such a thing as Return Path address.

SPF can be quite easily circumvented by using this simple trick, and it leaves even domains secured with SPF largely vulnerable.

SPF records have a DNS lookup limit

SPF records contain a list of all the IP addresses authorized by the domain owner to send emails. However, they have a crucial drawback. The receiving server needs to check the record to see if the sender is authorized, and to reduce the load on the server, SPF records have a limit of 10 DNS lookups.

This means that if your organization uses multiple third party vendors who send emails through your domain, the SPF record can end up overshooting that limit. Unless properly optimized (which isn’t easy to do yourself), SPF records will have a very restrictive limit. When you exceed this limit, the SPF implementation is considered invalid and your email fails SPF. This could potentially harm your email delivery rates.

Learn more

SPF doesn’t always work when the email is forwarded

SPF has another critical failure point that can harm your email deliverability. When you’ve implemented SPF on your domain and someone forwards your email, the forwarded email can get rejected due to your SPF policy.

That’s because the forwarded message has changed the email’s recipient, but the email sender’s address stays the same. This becomes a problem because the message contains the original sender’s From address but the receiving server is seeing a different IP. The IP address of the forwarding email server isn’t included within the SPF record of original sender’s domain. This could result in the email being rejected by the receiving server.

How does DMARC solve these issues?

DMARC uses a combination of SPF and DKIM to authenticate email. An email needs to pass either SPF or DKIM to pass DMARC and be delivered successfully. And it also adds one key feature that makes it far more effective than SPF or DKIM alone: Reporting.

With DMARC reporting, you get daily feedback on the status of your email channels. This includes information about your DMARC alignment, data on emails that failed authentication, and details about potential spoofing attempts.

If you’re wondering about what you can do to not get spoofed, check out our handy guide on the top 5 ways to avoid email spoofing.

About
Latest Posts

Ahona Rudra

Domain & Email Security Expert at PowerDMARC

Ahona is the Marketing Manager at PowerDMARC, with 5+ years of experience in writing about cybersecurity topics, specializing in domain and email security. Ahona holds a post-graduation degree in Journalism and Communications, solidifying her career in the security sector since 2019.

Why SPF Isn’t Good Enough to Stop Spoofing