57

This is a canonical question about setting up SPF records.

I have an office with many computers that share a single external ip (I'm unsure if the address is static or dynamic). Each computer connects to our mail server via IMAP using outlook. Email is sent and received by those computers, and some users send and receive email on their mobile phones as well.

I am using http://wizard.easyspf.com/ to generate an SPF record and I'm unsure about some of the fields in the wizard, specifically:

  1. Enter any other domains who may send or relay mail for this domain
  2. Enter any IP addresses in CIDR format for netblocks that originate or relay mail for this domain
  3. Enter any other hosts which can send or relay mail for this domain
  4. How stringent should SPF-aware MTA's treat this?

the first few questions i'm fairly certain about... hope i have given enough info.

AlJo
  • 91
  • 8
vulgarbulgar
  • 729
  • 1
  • 7
  • 14

2 Answers2

77

SPF records detail which servers are allowed to send mail for your domain.

Questions 1-3 really summarise the whole point of SPF: You're supposed to be listing the addresses of all the servers that are authorised to send mail coming from your domain.
If you don't have an exhaustive list at this time, it's generally not a good idea to set up an SPF record. Also a domain can only have one SPF record, so you'll need to combine all the information into a single record.

The individual questions really just help break the list down for you.

  1. asks you for other domains whose mail servers may relay mail from you; if you have eg a secondary MX server at mail-relay.example.org, and that is the main mail server (MX record) for the domain example.org, then you should enter mx:example.org. Your SPF record should include your own domain's MX record under nearly all circumstances (mx).
  2. asks you for your ip netblocks. If you have colocated servers at 1.2.3.0/28, and your office address space is 6.7.8.0/22, enter ip4:1.2.3.0/28 ip4:6.7.8.0/22. IPv6 space should be added as eg ip6:2a01:9900:0:4::/64.
  3. if (eg) you also have a machine off in someone else's office that has to be allowed to send mail from your domain, enter that as well, with eg a:mail.remote.example.com.

Your mobile phone users are problematic. If they send email by connecting to your mail server using eg SMTP AUTH, and sending through that server, then you've dealt with them by listing the mail server's address in (2). If they send email by just connecting to whatever mail server the 3G/HSDPA provider's offering, then you can't do SPF meaningfully until you have rearchitected your email infrastructure so that you do control every point from which email purporting to be from you hits the internet.

Question 4 is a bit different, and asks what recipients should do with email that claims to be from your domain that doesn't come from one of the systems listed above. There are several legal responses, but the only interesting ones are ~all (soft fail) and -all (hard fail). ?all (no answer) is as useless as ~all (qv), and +all is an abomination.

~all is the simple choice; it tells people that you've listed a bunch of systems who are authorized to send mail from you, but that you're not committing to that list being exhaustive, so mail from your domain coming from other systems might still be legal. I urge you not to do that. Not only does it make SPF completely pointless, but some mail admins on SF deliberately configure their SPF receivers to treat ~all as the badge of a spammer. If you're not going to do -all, don't bother with SPF at all.

-all is the useful choice; it tells people that you've listed the systems that are allowed to send email from you, and that no other system is authorized to do so, so they are OK to reject emails from systems not listed in your SPF record. This is the point of SPF, but you have to be sure that you have listed all the hosts that are authorized to originate or relay mail from you before you activate it.

Google is known to advise that

Publishing an SPF record that uses -all instead of ~all may result in delivery problems.

well, yes, it may; that is the whole point of SPF. We cannot know for sure why google gives this advice, but I strongly suspect that it's to prevent sysadmins who don't know exactly whence their email originates from causing themselves delivery problems. If you don't know where all your email comes from, don't use SPF. If you're going use SPF, list all the places it comes from, and tell the world you're confident in that list, with -all.

Note that none of this is binding on a recipient's server; the fact that you advertise an SPF record in no way obliges anyone else to honour it. It is up to the admins of any given mail server what email they choose to accept or reject. What I think SPF does do is allow you to disclaim any further responsibility for email that claimed to be from your domain, but wasn't. Any mail admin coming to you complaining that your domain is sending them spam when they haven't bothered to check the SPF record you advertise that would have told them that the email should be rejected can fairly be sent away with a flea in their ear.

Since this answer has been canonicalised, I'd better say a few words about include and redirect. The latter is simpler; if your SPF record, say for example.com, says redirect=example.org, then example.org's SPF record replaces your own. example.org is also substituted for your domain in those look-ups (eg, if example.org's record includes the mx mechanism, the MX lookup should be done on example.org, not on your own domain).

include is widely misunderstood, and as the standard's authors note "the name 'include' was poorly chosen". If your SPF record includes example.org's record, then example.org's record should be examined by a recipient to see if it gives any reason (including +all) to accept your email. If it does, your mail should pass. If it doesn't, the recipient should continue to process your SPF record until landing on your all mechanism. Thus, -all, or indeed any other use of all except +all, in an included record, has no effect on the result of processing.

For more information on SPF records http://www.openspf.org is an excellent resource.

Please don't take this the wrong way, but if you get an SPF record wrong, you can stop a significant fraction of the internet from receiving email from you until you fix it. Your questions suggest you might not be completely au fait with what you're doing, and if that's the case, then you might want to consider getting professional assistance before you do something that stops you sending email to an awful lot of people.

Edit: thank you for your kind words, they're much appreciated.

SPF is primarily a technique to prevent joe-jobbing, but some people seem to have started to use it to try to detect spam. Some of those may indeed attach a negative value to your having no SPF record at all, or an overbroad record (eg a:3.4.5.6/2 a:77.5.6.7/2 a:133.56.67.78/2 a:203.54.32.1/2, which rather sneakily equates to +all), but that's up to them and there's not much you can do about it.

I personally think SPF is a good thing, and you should advertise a record if your current mail structure permits it, but it's very difficult to give an authoritative answer, valid for the entire internet, about how people are using a DNS record designed for a specific purpose, when they decide to use it for a different purpose. All I can say with certainty is that if you do advertise an SPF record with a policy of -all, and you get it wrong, a lot of people will never see your mail.

Edit 2: deleted pursuant to comments, and to keep the answer up-to-date.

mehov
  • 568
  • 1
  • 5
  • 14
MadHatter
  • 78,442
  • 20
  • 178
  • 229
  • appreciate the thorough, and plain-english answer (which i obviously needed). you are correct in noting that i am mostly in the dark, and have no business wearing a postmaster's hat. a followup question: since we are talking about a very small operation (about 10-15 email accounts in total)- and don't send out large volumes of mail- is this something we can survive without for the time being, or will likely end up in a lot of spam folders out there? when we do mass-mailing, we use services such as mailchimp, etc – vulgarbulgar Mar 14 '12 at 07:57
  • The ~all is good for two things: `1.` That "not completely _au fait_" scenario you described. It lets you do all the setup in a real way, including real testing, before pulling the final trigger. `2.` Spam scores. If you really can't control all your mail exit points, ~all can help spam scores for those systems that match your record (of course: they can also hurt the score for those systems that soft-fail). – Joel Coel Jun 10 '13 at 22:09
  • They can also hurt the score with recipient systems whose admins regard `~all` as a spam indicator on the whole domain, of which there is at least one on SF. – MadHatter Jun 11 '13 at 13:44
  • 2
    @MadHatter A comment to Edit2 specifically: The [current SPF spec](http://tools.ietf.org/html/rfc4408#section-3.1.1) says you must use either `TXT` or `SPF` but that you should use both (identical), the proposed [upcoming SPF spec](http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-21#section-3.1) abandons `SPF` as the uptake has been less than expected and mostly just causes interoperability problems. With that in mind it seems ill advised to only look up `SPF`. – Håkan Lindqvist Apr 25 '14 at 21:01
  • Hakan (apologies for not having all the right characters on my keyboard), I entirely agree that it's ill-advised to only check `SPF`, I merely note that we're starting to see problems here on SF caused by systems that do it anyway. – MadHatter Apr 25 '14 at 21:10
  • @MadHatter Yeah, if it came across as disputing the point you were making then that was not my intention. My intention was essentially to 1) point out that what you recommended is not only your recommendation but also what the current SPF spec says to do, 2) that I don't think it should be seen as a movement towards `SPF`-only even though I'm sure it's correct that some are only looking up `SPF` (just like I'm sure some are only looking up `TXT`). (The latter is not something you stated but I think that could be one way of interpreting it.) – Håkan Lindqvist Apr 25 '14 at 21:47
  • Hakan, no apology is needed, and thanks for your clarification and your original point - which is a good one. – MadHatter Apr 26 '14 at 05:17
  • Note that one place to get some information on, among other things, your SPF records is at https://mxtoolbox.com/spf.aspx – Anti-weakpasswords Feb 21 '16 at 05:39
  • [rfc7208](https://tools.ietf.org/html/rfc7208#section-3.1) (April 2014) standardized TXT as the only acceptable the DNS RR type. This is not to say there aren't server which are not standards compliant, but rather that use of the SPF RR type is strongly discouraged. – 84104 Apr 16 '16 at 03:31
  • @84104 thanks for that, I have deleted edit 2 accordingly. – MadHatter Apr 16 '16 at 05:23
  • 3
    Thanks for the truth and I laughed out loud at " +all is an abomination." – jerclarke May 11 '16 at 20:40
  • @jeremyclarke you're welcome, and I'm glad SPF contains *something* amusing! – MadHatter May 11 '16 at 20:42
  • Instead of just saying that ~all and ?all are useless and +all is an abomination, could you please explain what those actually mean? – Brian Minton Apr 18 '18 at 16:00
  • @BrianMinton I explain `~all` above, in some detail. That said, this answer is not intended to be an alternative to reading the protocol, but as an aid to making choices after absorbing all the factual information therein. – MadHatter Apr 19 '18 at 06:02
  • @MadHatter If you type `@h` then you'll get HåkanLindqvist presented, so you don't need å on your keyboard. The same goes for people with names using Greek characters, where there is a correspondence something like r will get you ρ (rho). – Andrew Morton Oct 16 '20 at 12:08
  • I find the part about the MX record and whether including it into the SPF record confusing. MX records tells other which servers to contact if they have mail for this domain. SPF tells other which servers are allowed to send mails out for this domain. But servers receiving and servers sending email may not be the same. MX must not necessarily be part of an SPF record. – Cybot Oct 28 '20 at 11:27
  • @Cybot if you're sure that your MX never sends out bounce messages, I agree. Most of them do, though. – MadHatter Oct 28 '20 at 11:54
  • @MadHatter, good point, will double check this. But servers who bounces and are missing in SPF are more likely the calendar servers (of google) - at least from my past reports. – Cybot Oct 29 '20 at 12:11
  • I'm having trouble seeing the utility of SPF. It's essentially useless without -all, but -all will pretty much never actually work since it does not handle recipients redirecting their email from one service to another, nor does it handle mailing lists (though I guess that is old school these days). If a user, for example, has a hotmail account redirected to gmail, hotmail will validate the SPF, and then it will resent the email to gmail which will promptly reject it. Is there any solution to this? – Peter N Lewis Aug 18 '22 at 08:00
  • @PeterNLewis you're right that it needs `-all`, and I hope my answer is clear about that. It doesn't affect mailing lists, because it's only applied to the envelope-From (not the header-From), and proper mailing lists regenerate that. It does break simple forwarding, and sadly SRS doesn't seem to have caught on, so as a mail admin you have to decide which you want more: inbound SPF checking, or reception of simply-forwarded email. Your call. – MadHatter Aug 18 '22 at 08:19
5

What's important for your setup is the configuration of the server which finally sends the email to the internet. You say that you send emails via SMTP. So in terms of IP address what matters is the configuration of your SMTP server ( question 2 )

If you are using a third-party, such as gmail, to send your emails, you have to include their spf records like this: include:_spf.google.com ( the ajax wizard does not seem to know about this ).

For the "How Stringent", leave the "soft fail" ( ~all ) if you're unsure, but else "reject" ( -all ) is the way to go once your configuration is clean.

Jacob Evans
  • 7,636
  • 3
  • 25
  • 55
Olivier S
  • 2,719
  • 1
  • 12
  • 14