10

SPF (Sender Policy Framework) seems like a good way to combat spammers/spoofing.

However, despite reading the explanations several times, I'm not quite understanding how to configure it correctly.


Let's say I have my server at a.x.com which hosts www.x.com and b.x.com and c.x.com and so on.

I also have a.co.uk b.net c.info and so on, each of these with an assortment of sub-domains, all hosted on x.com

For all of these domains and sub-domains, I want to permit mail to be sent from a.x.com

I would also like them all to permit mail sent from Gmail for all these domains.

How do I set this up with SPF?

Can I set one SPF record for x.com (or a.x.com) and then for everything else just have a simple include/pointer to x.com's record, or would it need to be done differently?

Can anyone provide some SPF records for the above example?


Note: The second part of my question has been answered (use "v=spf1 include:x.com -all" to include/point at x.com's record), but the key part of what to set on x.com remains unanswered...

Peter Boughton
  • 594
  • 2
  • 7
  • 19
  • Actually it's proved a hopelessly ineffective way of reducing spam. In fact, arguably, it's only really meant to address sender address spoofing anyway. – Christopher Edwards May 05 '09 at 00:57
  • 2
    "it's only really meant to address sender address spoofing" - exactly, to stop spammers from sending mail appearing to come from others' domains. – Peter Boughton May 05 '09 at 07:47
  • I'm confused and seeking clarity... If "Gmail sending" means adding a "Send mail as" profile to Gmail and using it to send email via a specified server, does Gmail need its own SPF permission for this? It would seem to be acting as an email CLIENT in this case, similar to Outlook or Thunderbird. Using Gmail for a Googe Workspace account, however, makes perfect sense to me on the SPF record because it would be the actual email server in that case. – Pup Jan 04 '23 at 22:48
  • In recent days, they won't even accept email from virtually hosted domains, even though the SPF is valid for the sender! So, my use-case is different but in my view the issue is that SPF doesn't apply to virtually hosted domains! THANKS for asking this question! – Richard T Mar 27 '23 at 04:08

5 Answers5

7

You can't avoid having to alter the zone files for the domains other than x.com, but you can save yourself a lot of trouble by defining common policies hosted on one domain and using the redirect SPF keyword on the other domains. Example:

  • In the zonefile for the x.com domain:
_policy1    IN    TXT     "v=spf1 a:a.x.com -all"
_policy2    IN    TXT     "v=spf1 include:_spf.google.com a:a.x.com -all"

_spf.google.com is the record holding the Gmail SPF record. Not sure whether it's documented. Theoretically you should include:gmail.com but that's a redirect to _spf.google.com and there has been at least one widely used SPF patch for qmail which didn't follow it properly (got fixed in August 2008 but might still be deployed.) The two policies are examples, of course - having more than one with various levels of strictness is extremely useful when debugging since you only have to alter a short name in the target domain instead of error-prone copypasting.

  • In the zonefiles for the other domains:
@                       IN    TXT    "v=spf1 redirect=_policy1.x.com"

or

@                       IN    TXT    "v=spf1 redirect=_policy2.x.com"

etc. I'm using redirect, not include, to cause the SPF check to completely replace the currently evaluated record with the one I'm redirecting to. include does not do that - for example, an -all at the end of an include does not cause evaluation to stop (include is a big misnomer.) You should avoid using include when you want to "alias" a SPF record from another domain, since it's quite brittle - if you accidentally forget the trailing -all you might render your entire SPF on that domain ineffective.

Edit: Please note, though, that you need to be on guard if you want to allow Gmail's servers as senders. The Gmail chaptcha has been cracked, which means that it's possible to automate account signups, which means Gmail can be (indirectly) used as an open relay (I'm getting tens of spambot signup requests per week for my company discussion forum, all using gmail.com email addresses - and those addresses are live, I've allowed a few to go through for checking purposes.) Additionally, anyone with a Gmail account can bypass SPF checking if familiar with the uwsername parts of the email addresses at your domains.

Mihai Limbăşan
  • 3,081
  • 23
  • 19
  • 1
    Thanks, this is a helpful answer. Last time I checked, Gmail requires email validation before you can send emails from other addresses - so once the inbox for that address is secure, things are ok? How important is/isn't also having 'www' lines as in bortzmeyer's answer? – Peter Boughton May 09 '09 at 15:11
  • 1
    True, but once a crack appears in the foudation I'm sure someone will find a way to squeeze half the river through :) Not saying you shouldn't, I'm just recommending to be on your toes and periodically check whether Gmail is being exploited, i.e. please don't abandon authority to Gmail indefinitely. I trust them more than I trust more online entities, but that's just a little trust versus no trust at all. – Mihai Limbăşan May 09 '09 at 18:47
  • I have no idea why bortzmeyer included the www entries. They are entirely useless unless you actually send mail from @www.x.com which (apart from not being used much) looks plain weird and induces confusion in less than technically savvy people. – Mihai Limbăşan May 09 '09 at 18:48
  • 2
    Additionally, I would NOT use SPF record types. I recommend you stick with TXT. The SPF record type is only supported by BIND 9.4 and higher, per RFC you *must* also maintain replicas of the TXT records i.e. you must copypaste stuff (bad) and you must maintain them in sync (hard). The gain is nonexistent since TXT will be the primary SPF delivery mechanism for the foreseeable future, quoth openspf.org. – Mihai Limbăşan May 09 '09 at 18:50
  • Thanks, all helpful and a good point about staying aware of Gmail's security/etc. – Peter Boughton May 09 '09 at 19:33
  • @mihai - no, the RFC says you SHOULD use both types, not that you MUST (see §3.1.1). – Alnitak May 14 '09 at 08:52
  • Thanks, Alnitak. I know. I was referring to bortzmeyer's example in particular, but I've seen a lot of people do that, and it's not a practice I'd recommend :) – Mihai Limbăşan May 14 '09 at 13:11
  • @Mihai: you defined two policies in the x.com zone file (_policy1 and _policy2). Which one of these SPF records does x.com use itself? Do you need an @ IN TXT "v=spf1 redirect=_policy1.x.com" in x.com as well as the other zone files? What is the best way to configure the x.com zone file? Thanks! – Tauren Mar 13 '10 at 05:03
  • 1
    @Mihai Limbasan: excellent answer, thanks for sharing. In case you think it's necessary to update your answer, Google seems to prefer `v=spf1 include:_spf.google.com ~all` in place of `-all`, supposing I understood properly, ref. http://www.google.com/support/a/bin/answer.py?answer=178723 – Marco Demaio Jul 22 '11 at 16:59
4

Yes, you can include the config from one of your domains in the SPF records for all the other domains. Setting the other domains' SPF record to the following should do the trick:

v=spf1 include:x.com -all
womble
  • 96,255
  • 29
  • 175
  • 230
  • Will this "just work", or does it require a _spf sub-domain, or similar? – Peter Boughton May 05 '09 at 19:51
  • I'm pretty sure that if you've got the SPF records defined directly on x.com initially, the include for the other domains can just point directly at x.com as well. If you define your SPF record in _spf.x.com route, then yeah, you'll need to change the include a bit to point to that FQDN as well. – womble May 06 '09 at 00:14
2

Have you tried using the web tool at http://www.openspf.org/? It might make it a bit easier for you to deal with this...

Just enter your domain in the top-right box and click the go button. From there, you should be able to set things up in a hurry.

Community
  • 1
Avery Payne
  • 14,536
  • 1
  • 51
  • 88
2

The standard, RFC 4408, provides some examples that are very close from what you want. Here is an extract of x.com's zonefile:

@     IN TXT  "v=spf1 a:a.x.com -all"
      IN SPF  "v=spf1 a:a.x.com -all"

www   IN TXT  "v=spf1 a:a.x.com -all"
      IN SPF  "v=spf1 a:a.x.com -all"

Notes:

  • I did not add Gmail email servers because I do not know them, ask Gmail people
  • 'a' is for 'address' (it is not a DNS A record, it includes IPv6)
  • I added SPF records, per the RFC, although almost all implementations use only the TXT record
bortzmeyer
  • 3,941
  • 1
  • 21
  • 24
1

Yes, you need to add the specific SPF record to each domain individually.

The reason for this is that the only (useful) aliasing type record in the DNS is the CNAME record. However the CNAME record causes aliasing to happen for ALL of the RRtypes in an RRset - there's no way to say "CNAME the SPF record but not the MX records"

Alnitak
  • 21,191
  • 3
  • 52
  • 82
  • I understand that I'll have to add *a* SPF record for each domain, but I was hoping to simply store a *simple* pointer to the main domain, where all the more complex commands can then live. Womble suggests I can use the include:{domain} for this, but I'm still unclear if this simply includes/points at the SPF records for the other domain, or if I need to host a _spf.x.com subdomain? – Peter Boughton May 05 '09 at 19:50
  • yes, see womble's answer – Alnitak May 05 '09 at 20:02