BLOG

Authenticating with SPF: -all or ~all

What is SPF?

Sender policy framework (SPF, RFC 7208) is an authentication process that ties the 5321.from (also known as the mail from, envelope from or return path) to authorized sending IP addresses. This authorization is published in a TXT record in DNS. Receivers can check SPF at the beginning of a SMTP transaction, compare the 5321.from domain to the connecting IP address and determine if that IP is authorized to transmit mail.

What does a SPF record look like?

At its simplest, the SPF TXT record contains a version indicator, allowed IPs and an authorization type.

In the example "v=spf1 ip4:198.51.100.26 -all":

  • v=spf1 is the version indicator
  • 198.51.100.26 is the allowed sending IP
  • -all means only this IP is authorized to send mail for the domain.

Of course, there are other ways to define authorized IP addresses. Using "v=spf1 mx -all" authorizes any IP that is also a MX for the sending domain. 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.51.100.26 ip6:2001:db8:8:4::2 -all". SPF records can also contain IP ranges in the form "v=spf1 ip4:198.51.100.128/25 -all".

Domain owners are also allowed to publish different types of authorization.

Statement Result Meaning
+all pass Allow all mail
-all fail Only allow mail that matches one of the parameters (IPv4, MX, etc) in the record
~all softfail Allow mail whether or not it matches the parameters in the record
?all neutral No policy statement

What’s the difference between ~all and -all

Given many receivers are not actively bouncing mail based on SPF pass/fail, there isn’t a strong argument for either -all or ~all in SPF records. For a while, Hotmail was advising that senders who published a -all record would have better delivery. This led to -all became a de-facto standard for a lot of ESPs and bulk senders. More recently, there does not seem to be any benefit to publishing -all even at Hotmail (Outlook.com, live.com, etc).

What should I publish?

I generally recommend publishing ~all records for my clients. There’s not a huge benefit to publishing -all and sometimes mail gets forwarded around. The one time I recommend a -all record is when a domain is getting forged into spam. Domain forgery can cause a lot of bounces. The amount of bounces can be bad enough to take down a mail server, particularly those with a small userbase. Many ISPs will check SPF before sending back a bounce and so a -all record can decrease the amount of blowback the domain owner has to deal with.

Do I have to publish SPF records?

No, there is no requirement for publishing SPF in order to send mail. You don’t even need to publish SPF to get inbox delivery. Gmail will even do a “best guess SPF” for domains not publishing SPF and authenticate off that. However, large volume senders should be publishing SPF records on principle.

Want to check your SPF record?

We provide a SPF checker on our Tools page.

30 comments

  1. Jose Argudo says

    As always very useful and interesting content, thanks!

  2. Steevo says

    What are the tabs at the top of the spf checker page supposed to do? They don’t seem to do anything now.

    1. steve says

      There are still some javascript bugs with the tools.wordtothewise.com pages. Working on ’em.

  3. Al says

    One thing that I’d like to add here. If you keep your SPF record in a Word document, when you copy it out, the dash changes from an “en dash” to an “em dash”. And that just doesn’t work. Tough to see the difference between: -all and –all

  4. Steevo says

    I used an online tool to make the spf record I published,
    http://www.spfwizard.net/
    but I have some evidence that it’s not *exactly* right.

    Your tool for example says it’s not there as SPF, but it is returned by your dns TXT tool as TXT.

    That’s the problem with trusting something you find online. You have to trust that it gives the correct output. You have to have faith.

    With some checkers saying it’s fine, and some saying it’s not, well, thanks for the article. I didn’t learn enough to fix it for sure, but I learned something.

  5. Saurav Nayak says

    Hey! Is the IP address for the email address same as that of the Website’s IP address? if no which one is to be used in an SPF record?

  6. Cómo crear una Newsletter con Mailrelay - Blogpocket says

    […] Aquí hay una explicación que justifica el uso del parámetro “~all”, en lugar del “-all”: Authenticating with SPF: -all or ~all. […]

  7. Jondi Gumba says

    Hi, Im a newbie in SPF, may I ask what IP should I put in the ip4: ? Where will I get that IP…?

    Thanks in advance.

  8. Anders says

    In my opinion there is a huge difference between ~all and -all.
    ~all is “softfail” which has the intended action “accept”, in my world this makes SPF useless since no one will take any action on a “softfail”. In that case you might as well not configure a SPF-record at all.
    -all is “fail” which has the intended action “reject”. If you have control over the servers sending emails for your domain I see no reason not to use -all.

    If all domain owner used SPF with -all there would be a lot less spam- and phishing-emails.

  9. Manuel says

    I generally recommend publishing ~all records for my clients.

    I would never ever recommend that. SPF’s point is to block all not matching IP’s so why would i ever use that except for testing?

  10. Tim says

    I see it this way: The only reason to not use -all is if you are unsure that you have properly listed all the sending IPs associated with your domain. If your IT dept can’t keep track of all the legitimate senders at your domain, then I don’t trust your incompetent IT dept. Since SPF is for the recipient and the recipient is the one that chooses whether to trust the incoming email, I treat ~all as -all. I use -all for my own domains. If the sending IP is not listed or included in the record, the mail is coming from an illegitimate source.

    ~all is for testing and nullifies the purpose of SPF. Don’t use it.

  11. Huey says

    ” If your IT dept can’t keep track of all the legitimate senders at your domain, then I don’t trust your incompetent IT dept.”

    If your IT dept CAN keep track of all of the legitimate senders at your domain, then you obviously work for a much smaller company than than a lot of other people do.

  12. Kim says

    Google recommends ~all to their Apps admins.

    v=spf1 include:_spf.google.com ~all

  13. SPF_guy says

    question can incldude both ?all and -all in one SPF entry? I have two domains i need to list in record:

    example below
    v=spf1 include:spf.protection.outlook.com -all ip4:xx.xxx.xxx.xx include:mail.somecompany.com ?all

    1. laura says

      That is an invalid SPF record, you can only have one “all” statement in the record. You seem to be trying to say “mail can only come from protection.outlook.com” unless it comes from these other places. You can use one -all or you can use ~all (never use ?).

  14. SPF_guy says

    so only following entry is correct?

    v=spf1 include:spf.protection.outlook.com ip4:xx.xx.xxx.xx include:mail.othercompany.com -all

    1. laura says

      Yup. That’s a correct SPF record. You can use our SPF checker (http://tools.wordtothewise.com/authentication) to get feedback on the correctness of your record and an (approximate) list of IPs that you are allowing to send mail.

  15. brandon says

    Hi Laura,

    i have been working at this for over a month and i still get email spoof. i finally learned how to make a spf record. and it works when you test it. our domain is optimasystems.ca but we still get the same amount of email spoofing. it never stopped even a tiny bit. even though the spf records passes the test of being set up properly, is there something i am missing that is allowing these spoof emails to come through? here is my record Host record: @ TXT Value: v=spf1 mx a ip4:MYSHAREDIPADDRESSHERE?all

  16. brandon says

    Actually i just noticed something i used your SPF Checker and entered my domain and it said this:

    This is an approximate list of the IP addresses that the domain optimasystems.ca allows email to be sent from according to their SPF record.

    then it showed a complete list of IPS. all of those IPS are where all the spoof emails are coming from according to the email headers of those spoofed emails (mostly from netherlands and Germany)? how is that possible that it says “ALLOWS” where can i typically erase those IPS so they are NOT allowed? thank you so much for helping me out in advance!

    1. laura says

      If you go to the DNS tab on the authentication page, it shows you what all the lookups are. Most of the IPs in the record belong to “mx.spamexperts.com.”

      If you’re only sending from one IP address, take out the “MX” and “A” from your SPF record. That should remove all the unexpected IPs from your SPF record.

  17. Damian Walker says

    Could someone let me know if I include: an SPF record has soft-fail (~all) to my SPF record that has hard-fail (-all) what will happen? Will it soft-fail the included servers only, and hard our own?
    Thanks in advance.

  18. Developer Chris says

    The fact that major mail handlers like google use ~all IS one of the reasons spf is a total and absolute utter disaster. This is a debug setting and should only be used during testing and initial configuration setup. to recommend it is the same as saying don’t bother using spf.

    The reason why google does do it by the way is because it sends a large amount of mail on behalf of others and those others are unable or do not understand how to create a suitable spf record.

    Personally I don’t think that’s a valid excuse.

    The other reason is, I am seeing a huge increase in spf validated email from all the new tld’s.

    I am now considering filtering all email from the new tld’s as spam. or at least giving them a higher spam score.

  19. Nithin says

    can i use mx record of my server in the +include option????? in the SPF , i have included my ip address , but i’m using a cnetralized mx record for all of my servers , so i think i have to include those too.

    +include:mx_record_name

  20. Andrew says

    I am currently in the process of working through all the 3rd parties that are sending as my domain. I have created a sub domain email.domain.com. The plan is to use a separate SPF record, some of the 3rd parties have advised to add their spf record to our own spf by a way of an Include. Whilst I am happy to do that within reason, I noticed their SPF record in some instances ends in a “~all” is that a problem?

    Regarding the Include record. Some instances suggest to add a ? in front of it:
    ?include:spf.3rdparty.com

    I have seen some instances with:
    +include: ?include:spf.3rdparty.com

    Can anyone explain what is the best approach to this?

    1. laura says

      include records only pull the IP addresses, they don’t pull the recommendation, so it doesn’t matter if it’s – or ~. I don’t think the ? in front of the include record is necessary or useful. So I’d suggest leaving it out.

  21. Andrew says

    That 2nd example should be:
    +Include:spf.3rdparty.com

  22. acil kredi says

    Its must be like; v=spf1 +a +mx +ip4:xxx.xxx.xxx.xxx ~all

  23. bunny E says

    https://tools.ietf.org/html/rfc7208
    This document obsoletes RFC 4408.

    Are their any frightening differences? Your site only lists 4408.

  24. David Jones says

    SPF is a failing system as long as people are allowed to use ~all. This goes, especially, for large organisations who complain about having no control over their list of sending IPs. This is not an acceptable argument. If the big players can’t “up their game” and sort their sender IP management out SPF will, in time, die and spam will have won, yet again.

  25. MikeH says

    The reason for google using the soft fail is because of the following record:

    _dmarc.google.com. 300 IN TXT “v=DMARC1\; p=reject\; rua=mailto:mailauth-reports@google.com”

    SPF is no longer good enough security by itself. If you are serious about protecting your brand from spoofing, then you MUST implement DMARC as well.

Comment:

Your email address will not be published. Required fields are marked *

  • Blogging

    It's been a wild week here in the US. I have to admit, the current political climate is affecting my ability to blog about email. I've always said email is not life or death. And how can I focus on the minutia of deliverability when things are in such turmoil and uncertainty? There are many things I want to write about, including some resources for those of us who are struggling with the current administration and changes in the US. What we can do. What we must do.  It just takes work and focus I don't have right now.    1 Comment


  • Email trends for 2017

    Freshmail has published a list of email marketing trends for 2017 from some of their favorite experts. I am honored to be included. Go check it out!No Comments


  • AOL FBL change

    Reminder for folks, AOL is changing their FBL from address starting on Jan 17th. AOLlogoForBlogThe (in)famous scomp@aol.net is going away to be replaced by fbl-no-reply @ postmaster.aol.com. These messages will be signed with the d= mx.postmaster.aol.com. Time to update your scripts!No Comments


Archives