Let’s first explain what SPF does and what it does not:
- SPF authenticates the sending server of the email based on the sending IPv4/IPv6 address.
- SPF focuses on a header that is not visible to the end-user (Return-Path, MAIL FROM, Envelope-From, Bounce address, HELO/EHLO).
- SPF does not require any alignment between the end-user's visible domain and the typically invisible Return-Path that it actually checks.
- SPF does not provide any reporting functionality for the receiver to send back to the sender with the results of the email authentication.
- SPF does not survive forwarding and indirect mail-flows.
- SPF does not tell the receiving server what it should do with an email that failed SPF. For example, senders can publish “-all” but this has never been honoured by receivers, as SPF breaks easily and this would cause legitimate emails to be rejected. This is the most commonly held misconception regarding SPF.
This prompted the introduction of an additional email authentication standard. This standard needed to address the shortcomings of the standalone SPF protocol by explicitly telling receivers what to do and provide authentication reports back. These reports enabled the sender to take the necessary actions to fix legitimate mail flows. This standard was finally formalized as the DMARC protocol.
DMARC makes use of SPF as one of its foundations but also adds additional features:
- Focuses on the "From" header which is visible to the end user (Header From).
- DMARC requires that the domain used by SPF aligns (either an exact match or subdomain) with the domain found in the visible "From" address of the email.
- DMARC ignores the nuances of soft fail and hard fail in your SPF configuration i.e. ~all and -all are treated equivalently as a SPF fail.
- DMARC provides the reporting functionality to send email authentication results back to the owner of the "From" domain so they can find out if their domain is being misused. It also helps with troubleshooting your deliverability as the reporting will aid in discovering any misconfiguration with your legitimate email senders.
- DMARC provides a policy which tells the receivers what to do with an email that fails email authentication. This policy is enforced by the receivers. There is no enforcement when SPF is used without DMARC.
Now that DMARC is here to provide the missing pieces, it is widely being adopted and used as an authentication requirement, that comes with the added bonus of improving email deliverability. Another protocol that DMARC relies on is DKIM which serves as a failsafe in cases where SPF breaks. To learn more about DKIM please click on the button below.
Mailbox providers have started using visual signs in their mail clients showing if an email is authenticated using DMARC (SPF/DKIM). For example, G Suite displays a question mark (?) for unauthenticated emails such as the one shown below:
Due to DMARC's extensive reporting and strict enforcement policies many organizations struggle to deploy it effectively. To learn more about DMARC in the real world take a look at what TransferWise have to say about implementing DMARC.
OnDMARC offers a simple solution to implementing DMARC. Try it out for yourself by accessing the free trial.