University of Email by Pankaj Kumar
    Facebook Twitter Instagram
    Facebook Twitter Instagram
    University of Email by Pankaj Kumar
    Subscribe
    • CDP
    • Deliverability
      • Deliverability Issues
      • Email Bounce Error
    • Emarketing
    • Industry updates
    • Solutions
    • About
    University of Email by Pankaj Kumar
    Deliverability

    Deliverability Blog Post 5: Sender Policy Framework – SPF

    Pankaj KumarBy Pankaj KumarJanuary 19, 2018Updated:January 23, 2018No Comments6 Mins Read

    SPF stands for Sender Policy Framework. Don’t go with its name like other terminology where you’ll find written something like ‘as its name suggest’. Because its name won’t suggest you anything for the first time 🙂

    It is an Email Authentication technique where the sender can make a stamp on their “Envelope” MAIL FROM (sending domain). It designates for a particular set of mail servers.

    In simple word you are telling to internet world that you are going to have an “Envelope” MAIL FROM (sending domain), which will send some amount of emails from a fixed number of mail servers. Now the question is how? Basically, this is done using a TEXT information (also called TXT record) which is stored or published in domain’s DNS zone. The TEXT information is written using a particular syntax so that computer can understand it. This record has all the required details about the mail server. I’ll discuss below how it looks like and how to set up this. But before going into that area let’s see the history of SPF and why actually we needed.

    It describes a method of verifying whether a sender is valid when accepting mail from a remote mail server or email client. An SPF check involves verifying the email address the sender is using to send from, and the IP address they connect to the SMTP service with. SPF uses the sender’s domain to retrieve a TXT DNS record (basically a small text snippet) that describes which IP addresses the domain sends on. The retrieved record is then compared to the connecting IP address. And if it matches then the sender is determined to be valid; otherwise, it indicates that the sender is impersonating the sending domain.

    In other words, Sender Policy Framework is a method of detecting when an email sender is forging their sender address. It does this by confirming with the sender’s alleged domain (via DNS lookups) as to whether the connecting IP address or other details are valid. For example, if a spammer was sending emails as loot_lo_offer@aol.com, a lookup is done for SPF details against the AOL.com domain. Information returned from this lookup could determine that since the IP address of the spammer is not an AOL IP address then it is likely to be spam. Email can then be marked as likely spam, or not accepted. An SPF record can also be more complicated than just a list of IP addresses, in order to give more flexibility.

    Sender Policy Framework

    History of SPF

    The idea of verifying SMTP “Envelope” MAIL FROM has a long history that goes back to 1997. During that time multiple people proposed their own technique which all were almost similar. These were submitted independently at various times. But, the first serious development of this took place in 2003 when the email based communication took a high jump on the internet.

    The first draft was submitted by Gordon Fecyk in 2003 and called “Designated Senders Protocol” which then later known as SPF. Originally SPF stood for Sender Permitted From and was sometimes also called SMTP+SPF, but its name was changed to Sender Policy Framework in February 2004. In July 2005, this version of the specification was approved by the IESG as an IETF experiment, inviting the community to observe SPF during the two years following publication. On April 28, 2006, the SPF RFC was published as experimental RFC 4408.

    Why we needed the SPF?

    If you read the first two lines of this article you must realize why we needed it actually. You SPF is one of the email authentication technique. Using this we mail server can identify that the said email is coming from the original sender? or someone is trying to spoof the sender reputation. If you open your spam folder of your mailbox you can see there are some emails who are claiming themselves as TATA, Honda, Vodafone or other brands and by using their names they want to steal some information from you or they want to do something wrong with you. Don’t worry and you really don’t need to think because this is the reason why they are in your spam folder. So just leave it or delete it.

    SPF in details.

    To explain further first assume that we have few things as listed below:
    Email Sending Domain: mail.universityofemail.com
    IPs: 198.10.10.2, 198.10.10.3

    Example: How an SPF record looks like –

    v=spf1 ip4:198.10.10.2 ip4:198.10.10.3 -all [This is a text (TXT) record which must be populated in sending domain’s DNS Zone ie mail.universityofemail.com]

    SPF may looks like –

  • v=spf1 ip4:198.10.10.2 ip4:198.10.10.3 -all OR
  • v=spf1 ip4:198.10.10.2 ip4:198.10.10.3 ~all OR
  • v=spf1 ip4:198.10.10.2 ip4:198.10.10.3 +all OR
  • v=spf1 ip4:198.10.10.2 ip4:198.10.10.3 ?all
  • Note- These are just a few examples of how SPF looks like so don’t get confused if you see some complex SPF. There are many ways to create SPF.

    v=spf1 is the version indicator
    198.10.10.[2-3] is the allowed sending IPs
    -all: means only allow mail that matches one of the parameters (IPv4, MX, etc) in the record.
    ~all: means recipients may accept mail from another server as well, but it should be viewed with suspicion.
    +all: means allow all mail
    ?all: No policy statement

    Note- "~", "-", "+", "?" these are four mechanisms used in SPF. Meanings explained above, still if you have any doubt just make a comment.

    Of course, as said above there are other ways to define authorized IP addresses. Using v=spf1 mx -all authorizes any IP that is also an MX for the sending domain. or v=spf1 a -all for A record of the domain and etc.

    mail.universityofemail.com TXT "v=spf1 a -all
    This record tells us that the only host that can announce itself as mail.universityofemail.com is mail.universityofemail.com (indicated by the “a”)

    universityofemail.com. TXT "v=spf1 a:mail.universityofemail.com -all
    This record indicates that there is only one server that is allowed to send mail using the universityofemail.com domain, and that is mail.universityofemail.com. Now that we know that, we look up the IP address of the mail.universityofemail.com host.

    mail.universityofemail.com TXT "v=spf1 mx:mail.universityofemail.com -all
    Specifying mx:mail.universityofemail.com is generally incorrect unless you truly want SPF validation to look up all the hosts that accept mail for the “mail.universityofemail.com” domain. Usually, there will not be any such hosts, because mail.universityofemail.com is itself a host, not a domain. This will not show up as a syntax error, however, it will simply not match anything.

    The correct usage for validating against the MX records for universityofemail.com is mx:universityofemail.com, or if you want to specify a particular mail server’s hostname or IP, a:mailserver.universityofemail.com or ip4:198.10.10.2. Finally, note that when your SPF rule is stored as a DNS record associated with universityofemail.com, then universityofemail.com is the default domain for the rule. So mx on its own (with no explicit domain specified) is sufficient to check the sender IP against all the MX mail hosts listed for universityofemail.com, in that context.

    Other SPF records can be included using the include: command; for instance, include:_spf.google.com includes Google’s SPF record. IPs can be in either IPv4 space or IPv6 space by using either the ip4 or ip6 qualifiers: v=spf1 ip4:198.10.10.2 ip6:2001:db8:8:4::2 -all. SPF records can also contain IP ranges in the form v=spf1 ip4:198.10.10.2/25 -all.

    Post Views: 613
    deliverability Sender Policy Framework SPF
    Pankaj Kumar
    • Website
    • Facebook
    • Twitter
    • LinkedIn

    Pankaj Kumar is a senior professional holding 10+ years of experience in CRM, Email Deliverability & Marketing Analytics, Deliverability Onboarding, Implementation, Deliverability Automations He has worked with a broad range of clients to provide strategic, data-driven guidance to increase email delivery, subscriber engagement and revenue. He also helps marketers through this blogs in preparing strategies, data analytics, deliverability, and CRM with a passion for helping email marketers exceed subscriber expectations. You may connect with him on LinkedIn at https://www.linkedin.com/in/kumarpankaj793/

    Related Posts

    Orange.fr Email Delivery Guidelines: 2025 Update for Senders

    June 12, 2025

    What Should You Know About Email Blacklisting?

    June 22, 2024

    How To Solve Deliverability Problem With Orange.fr / Wanadoo.fr Domains

    June 15, 2024

    Leave A Reply Cancel Reply

    Subscribe to University of Email

    * indicates required

    Most Viewed Posts
    1. Yahoo/AOL/Verizon Postmaster tool for Email Deliverability (131,979)
    2. What you should ask to your next Email Service Provider? Revealed (125,028)
    3. Transfer your email from Yahoo to Gmail (15,201)
    4. £183m GDPR Fine Levied against British Airways (11,648)
    5. What Should You Know About Email Blacklisting? (9,077)
    Total posts
    • 106posts
    Search UOE
    Things to do here
    • About
    • Questions
      • Activities
      • Ask a question
      • Categories
      • Profile
      • Tags
    Pankaj Kumar
    Pankaj Kumar
    Pankaj Kumar, Author at University of Email
    Facebook Twitter Instagram LinkedIn
    © 2025 University of Email. Designed by BirdServer Technologies.

    Type above and press Enter to search. Press Esc to cancel.

    Please wait...

    Subscribe to our newsletter

    Want to be notified when our article is published? Enter your email address and name below to be the first to know.
    SIGN UP FOR NEWSLETTER NOW