Alan Doherty [Rated By ICRA] Level Double-A conformance icon, W3C-WAI Web Content Accessibility Guidelines 1.0
Valid CSS! Valid HTML 4.01 Strict

Alan Doherty's things anyone setting up a sender policy framework record properly should know

or How Not to make the same mistakes everyone else keeps repeating

I'm a Network/IT Consultant based in Dublin and a regular contributer on the SPF help mailinglist.

I have seen a lot of bad SPF records in my time, and spf records seem to consistently be poorly written/understood

So if you are setting up a new SPF or checking up on your existing setup competency here are some tips

all do depend on you actually knowing how you do send ALL legitimate outbound mail

Do not make others perform unnecessary DNS lookups

Parsers of your spf record have limited resources, do not abuse them, here are some simple and common examples

use of 'mx'
Using 'mx' is telling people to lookup your mx records (1 wasted lookup) and inserting a:mx-host-1 a:mx-host-2 etc here, as you are the admin you already know this list of host-names so just put them in yourself and save everyone the hassle, more importantly you may notice that few of these hosts actually can't/shouldn't send outbound email and you may notice many of these listed can be further reduced by the next principle
use of 'a' not followed by :somename or use of 'a' followed by :somename-within-your-own-domain
Using 'a' with nothing following basically means where is the sender, thus telling people to lookup's ip(s) and substitute them here (normally the ip of your webserver), as you are you already know these ip(s) (and if they actually can send email) so just put them in yourself and save everyone the hassle, ditto for
there is one exception discussed later when an a can be used to compress an spf record
when to use mx
pretty much never, thus far no sensible use case has been seen
when to use a:somename-outside-your-domain
when the name referanced is a machine outside your control and thus it may be moved at anytime without notice by the 3rd party that operates it, though asking the provider for an appropriate include: SPF record to use instead is worthwhile
when to use a:somename-within-your-domain
when the name used references a large list of ips that signifigantly shortens your SPF txt record, maximum ips seems about 30 per A record
multiple hosts vs larger subnet
if you own/operate/trust* the subnet and if your firewalling/setup assures you that you trust all the machines not to send any forgeries potentially originating from this subnet, then allow the whole subnet so later moves/changes of equipment/address' dosn't cause issues, if there are untrusted systems within the subnet that aren't firewalled from connecting to port 25 outbound it is better to list only the trusted
count how many DNS lookups are required to parse your whole record (and all subrecords includes/redirects)
this is because once this number reaches 10 most parsers will correctly fail, as thats the normal upper limit
check any SPF include: suggested by a provider/3rd party/ESP
if an esp/3rd party/provider SPF designed to be included by customers has any components that are not ip4:/ip6: or include:further-record then worry about their potential to overload/break your spf record, and try to encourage them to fix
if your spf record is begining to look too long
its hard to define as the max length of a txt record response varies with the domain name length, but if you have more host address's than can fit in a single txt record you can chain records via include or redirect

spf is not just for envelope sender

setup SPF records for all HELO/EHLOs in use
if you own/operate any of the mailservers in use sending email secure their HELO/EHLO idenity names with SPF records also
setup SPF records for all non email names in your zone
all names not used in helo/ehlo and envelopes of emails should have null spf records, 'v=spf1 -all'

avoid conflicts with poeple who mistakenly still check sender-id

sender-id (a horrible failed microsoft experiment) abused SPF records as sender-id policies if an explicit sender-id record was not found, issue arose because sender-id checks both the envelope-sender and against the Resent-Sender/Resent-From/Sender/From: header(s) , so an email recieved via a mailinglist with a correct envelope of will have its ip checked against your SPF record erroneously if the from: is you@yourdomain to avoid having your SPF record mis-used this way you can define a complete sender-id policy or at least one thats permissive
if your spf record for states
v=spf1 ip4: -all
this is equivalent to a sender ID mail envelope from policy
v=spf2.0/mfrom ip4: -all
but to avoid it causing mailing list mail to fail you can define a non failing pra policy
v=spf2.0/pra ip4: ?all
in other words positive pass mail from your ips but treat as neutral mail from others
the other option is just have a open policy for people checking sender-id pra, and ignore other cases
v=spf2.0/pra ?all
or the tempting option to make all sender-id users filtering fail (but i wouldn't advise it)
v=spf2.0 +all
aka 'if checking sender-id just accept all forgeries from everyone'

* Trust : can extend beyond machines you own/operate if you trust the owner/operator. example you send via a smarthost(s) ip(s) in providernameX as you already trust the provider and must assume they will assist to stop their other customers from forging email sent as you via this/these same smarthost(s) it is equally safe to trust the providers server netblock (if provider suggests/says no others operate machines within it) as it gives them the ability to move/replace/expand, and gives you no greater attack surface in real terms

Last updated Mar. 2016 Alan Doherty

Yes its a test for people to donate money to me if any of the free software or advice given was worthwhile, but if just feeling generous feel free to give me money if you like.

Join the Blue Ribbon Online Free Speech Campaign Stop Spam Harvesters, Join Project Honey Pot block bad bots- [german site]