dmarc vs spf

If you have not been following the whole debate of DMARC vs SPF, let’s understand what they are and how they can help you. In case you are new to email authentication, chances are that you have come across fleeting terms like DMARC and SPF and want to understand them better to decide which one suits you best.

Sender Policy Framework, aka SPF, allows you to cache a list of authorized IP addresses that are allowed to send emails to your customers on your behalf (RFC 4408). On the other hand, DMARC helps specify a policy for emails failing authentication, helping domain owners control the austerity of their implemented security protocols. Having said that, let’s elaborate on DMARC vs SPF. 

I have deployed SPF, do I still need DMARC?

SPF doesn’t provide domain owners with a mechanism to send reports of failed deliveries and impersonation attempts. This is where DMARC comes into play. If you enable DMARC reporting for your domains, you will be able to get notifications on your SPF authentication results, which includes but is not limited to failed delivery and spoofing attempts. This is an important feature that should be an indispensable addition to your email security suite even if you have only SPF deployed for your domains.

Monitoring your domains can be helpful in processing information about how your emails are performing and measuring the success rate of your email marketing campaigns. It also helps you respond to attacks faster and blacklist suspicious sender addresses. 

Can I deploy DMARC without DKIM?

Yes. It is possible to publish a DMARC record even without the presence of a DKIM record in your DNS. This is because, for your emails to be considered to be DMARC compliant, they need to pass either SPF or DKIM authentication and not both. If you don’t have a DKIM record in place, receiving MTAs only check for SPF alignment which determines the authenticity of the messages, while DKIM automatically fails for every message.

However, this isn’t an ideal situation. Let’s find out why:

The issue with email forwarding and mailing lists

In the case of forwarded emails, your message passes through an intermediary server before it can land in your receiver’s inbox. This server has a different IP address that might not be included in your domain’s SPF record. Hence the forwarded emails break SPF on the receiver’s side.

If you don’t have a DKIM record, failing SPF would essentially result in failing DMARC. For a policy set to reject, your legitimate emails sent through mailing lists wouldn’t reach your receivers at all. This is why having both SPF and DKIM implemented for your domain, and gaining complete DMARC compliance by aligning your emails against both protocols is a better way to ensure smooth deliverability.

DMARC Vs SPF: To Summarize

 

To sum up the discussion on DMARC vs SPF, our recommendation is to start by publishing a TXT record for SPF and a DMARC record keeping the policy at none while enabling aggregate reporting. This way you can keep a tab on the volume of emails that are being forwarded or sent via mailing lists. A none policy will not have any effect on the deliverability of your emails while allowing you to monitor your domains effectively.

However, to improve your defenses against impending phishing attacks and spoofing you need a more enforced policy (p=reject/quarantine) for DMARC. Solely implementing SPF does not offer any protection against email fraud, for which a DMARC policy is imperative.

Benefits of a DMARC software solution

We would recommend the use of PowerDMARC’s DMARC report analyzer to gain expert advice and make the most out of your email authentication standards today. This would help you:

  • Shift to a reject policy at the quickest market speed, without affecting your deliverability 
  • Gain 100% DMARC compliance on your outgoing emails
  • Monitor your email channels while on p=none to gain clarity on the volume of forwarded emails 
  • Make decisions about your protocol policy modes and configurations faster and enjoy a smooth roll-out of your implemented email authentication standards