Let’s first explain what SPF does and what it does not:
Does:
SPF authorizes the sending IPv4/IPv6 addresses.
SPF protects the header of the email, that is not visible to the end-user, often called several names such as: Return-Path or MAIL FROM or Envelope-From or Bounce address. If this header is missing, the SPF check will be done on the EHLO/HELO address.
Does not:
SPF does not require any alignment between the FROM domain and the above mentioned Return-Path address that it actually checks. Meaning the two don't have to match from an SPF perspective.
SPF does not provide any reporting functionality, meaning the receiver of the email won't send back any reports to the sender, containing results of the email authentication.
SPF does not survive auto-forwarding and indirect mail-flows.
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:
Instantly test your SPF configuration
OnDMARC’s free tool Investigate lets you verify your SPF set up to ensure they actually authenticate your emails correctly.