SPF (Sender Policy Framework)

  • Overview

    • What is SPF?

    SPF or Sender Policy Framework (SPF) is an email authentication protocol that allows the owner of a domain to specify which email servers are permitted to send emails from their domain. As the email is being delivered, SPF allows the recipient email server to verify whether the email claiming to be from a specific sender is actually from an IP address that is authorized to send emails on the domain’s behalf. RFC 7208, issued April 2014, defines Sender Policy Framework as a “standard.”

    Messages sent from a company’s domain that does not have SPF configured are more likely to be flagged as spam by recipient mail servers. It is recommended to set up DKIM and DMARC in addition to SPF for improved domain security and smooth email deliverability.

  • History

    • History of SPF

    Let us understand the history of SPF through the following timeline:

    • 2000: In March, the need for DNS records of outgoing email servers was mentioned publically.
    • 2002: On June 1st, David Green presented his draft named Mail-Transmitter and RR  at an SPF-like specification on the IETF “namedroppers” mailing list which was followed the very next day by Paul Vixie’s draft “Repudiating MAIL FROM”.
    • 2003:
      • In June, Meng Weng Wong, a Singaporean computer entrepreneur, integrated the RMX and DMP specs.
      • In August, Wayne Schlitt proposed the “mx operator” option and David Saez proposed the “spf include” option.
      • In October, Paul Wouters proposed to use the new RR DNS type instead of TXT overload, which was later supported by Meng Weng Wong. SPF started to look somewhat like v=spf1.
    • 2004: In February, the name was modified to Sender Policy Framework. MARID, an IETF working group, was formed with the intent to propose email authentication standards.
    • 2005: The IESG, an organization responsible for the technical management of IETF activities, accepted this version of the SPF standard as an IETF experiment and allowed the community to observe SPF for two years after release.
    • 2006: On April 28, the SPF RFC was issued as an experimental RFC 4408.
    • 2014: In April, IETF published SPF as a “proposed standard” in RFC 7208.

  • Working

    • How does SPF work?

    • The domain admin configures policies that determine which mail servers are authorized to send emails on the domain’s behalf.

    • When the recipient mail server receives an email, it checks the domain of the Return-Path value included in the email’s header.

    • The server verifies if the source email server IP is authorized to send emails on the domain’s behalf.

    • The receiving mail server decides whether to accept, deny, or otherwise flag the email message as spam by verifying the TXT DNS entry in your domain, which includes a list of authorized IP addresses.

  • Why

    • Why do you need SPF?

    SPF has become increasingly important in determining whose sending infrastructure can transmit email on your behalf. Implementing SPF for email has several advantages:

    • It improves domain reputation and email deliverability.

    • It fights domain impersonation and email spoofing to protect your brand reputation.

    • It is one of the foundational methods of email authentication for DMARC.

    SPF Misconceptions

    • SPF protects your domain from being spoofed
      The sender’s address, which is accessible to the user, is not protected by SPF.  All SPF does is let the domain owner specify which email servers are permitted to send emails using that particular domain. To protect visible domain names, use DMARC.
    • SPF rejects emails that fail authorization
      SPF authorization does not have a significant impact on the delivery of emails. SPF protocols validate the sender’s IP address and confirm whether it is authorized to send emails on the domain’s behalf.
    • -all is safer than ?all or ~all.
      The -all policy has no effect on security but has a negative impact on message delivery. This tag tells the user to reject emails whenever there is a mismatch with the record.
    • It is sufficient to configure SPF for domains that are used to send emails
      SPF must be configured even on mail servers of domains that are not used to send emails. This is because attackers continuously look for authorized domains that can be abused. Additionally, it is a good idea to employ a blocking policy for MX, A, and wildcard records that are not used to send emails.

    • It is recommended to add a special SPF-type record to DNS instead of TXT
      According to the latest version of the SPF standard, SPF-type DNS records are deprecated and should no longer be used. TXT records must be used instead.

    • SPF is self-sufficient
      It is not! DKIM is required to forward email messages securely while DMARC is essential to prevent spoofing of the sender’s address. Additionally, DMARC allows you to receive reports on SPF policy violations.

    Ready to get started?

    Request demo