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
there is one exception discussed later when an a can be used to compress an spf record
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 firstname.lastname@example.org 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 example.com states
v=spf1 ip4:22.214.171.124/25 include:_spf.google.com -all
this is equivalent to a sender ID mail envelope from policy
v=spf2.0/mfrom ip4:126.96.36.199/25 include:_spf.google.com -all
but to avoid it causing mailing list mail to fail you can define a non failing pra policy
v=spf2.0/pra ip4:188.8.131.52/25 include:_spf.google.com ?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
or the tempting option to make all sender-id users filtering fail (but i wouldn't advise it)
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 termsLast 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.