SPF Sender Policy Framework Records Explained

spf logo medium SPF Sender Policy Framework Records ExplainedHopefully you’ve already heard of SPF records, one of the new ways to fight spam across the internet. When a mail server receives an email it can check the DNS zone of the sending domain for a SPF record. That will tell them if the email did indeed come from that domain name, using an authorised SPF address. This stops spammers forging mail headers, i.e. pretending that their email came from your domain when it didn’t. You can read more here.

Why do I need to know this?

SPF records are increasingly being used as a filter for email. That means that failing to put one on your domains (or that of your clients) can result in email being sent directly to the spam bin, bounced back or even deleted.

How does this connect to online marketing?

Well the obvious connection is email marketing. If our client mailouts never make it past the spam bin we have already impacted our conversion rate but this has wider implications. Not using a SPF record can hamper any email communication including support/sales follow-ups and forum/blog thread updates or other user notifications. This is a technical issue for server or domain administrators but many are yet to implement this standard. As the marketer you can suggest and push this good practice.

SPF records and Google/Gmail

gmail origional SPF Sender Policy Framework Records ExplainedGmail is quickly emerging as one of the main email providers, especially as they push us all towards the utopia of “cloud computing”. They are definitely taking note of SPF as a method to fight spam and have already implimented an SPF test for all incoming email. If you open any email there and click “Show original” from the right hand menu, you will probably see something like this among the blurb:

Received-SPF: neutral (domain.com: 238.38.32.00 is neither permitted nor denied by best guess record for domain of user@domain.com) client-ip=238.38.32.00;
Authentication-Results: mx.domain.com; spf=neutral (domain.com: 238.38.32.00 is neither permitted nor denied by best guess record for domain of user@domain.com) smtp.mail=user@domain.com

That means Google can’t get any positive authentication for this email, i.e. no SPF record exists. The best it can do is be neutral about the test, “neither permitted nor denied”. Now if we have an SPF record set up we get something a lot more positive:

Received-SPF: pass (domain.com: domain of mail@domain.com designates 238.38.32.00 as permitted sender) client-ip=238.38.32.00;
Authentication-Results: mx.domain.com; spf=pass (domain.com: domain of mail@domain.com designates 238.38.32.00 as permitted sender) smtp.mail=mail@domain.com

Much better, we’ve passed the SPF test at Gmail and our emails have improved chances of avoiding the spam folder.

How do I add SPF records?

Very easily as long as you have access to the DNS settings for the domain. SPF records can also be entered as text (TXT) records which are standard entries for DNS providers. Here is a handy wizard which will generate the SPF record for you. This will probably look something like this:

v=spf1 a mx ~all

So the record you would end up in with in your DNS zone will be similar to:

yourdomain.com. IN TXT "v=spf1 a mx ~all"

If you are using scripts to send out emails automatically (i.e. forum or blog) you may need to add settings for your server IP and the account it sends from. Again check the headers on these emails to see the sender details you need to authenticate (“Show original”).

To check if a domain currently has a record use this SPF validation tool. If you want to test a positive result, use this domain (nickwilsdon.com). Any questions, feel free to ask below.

Further References on SPF Records

SPF Project
Sender Policy Framework – Wikipedia
Google Apps Support – Understanding SPF and Create SPF records

Nick Wilsdon is the Head of Content and Media at iProspect UK, part of the Densu Aegis Network. He manages online campaigns for the UK's leading telecom, finance and FMCG brands.

10 Responses to SPF Sender Policy Framework Records Explained

  1. Great article — very useful.

    I’m looking into the SPF record for our domain (hubspot.com). Seems to show up correctly in the SPF testing tool, but GMail still shows messages from this domain as “neutral”.

    Any ideas as to why this would be?

  2. @Dharmesh

    Sorry I missed this comment, been working a little hard recently. The test tool shows hubspot.com has a valid SPF record so that should have worked.

    I see you have added some extra sending domains to the record, did that resolve the issue?

  3. Pingback: SPF | Spinor Info

  4. Pingback: Siddhesh Poyarekar: Net4 and the agony of Received-SPF | TuxWire : The Linux Blog

  5. Thanks. I figured that the problem really is poor support; they are simply not willing to admit that as a problem despite the evidence provided. I’ll simply have to change email providers since it seems like practically everyone at net4 is incompetent.

  6. A++ didn’t know what SPF records were until I Googled it and came across your article. Thanks for the explanation!

  7. What does this mean ‘Received-SPF: softfail (transitioning domain of liveoutthere.com does not designate 209.85.223.173 as permitted sender)’.
    What is softfail?

    • Hi Gina,

      Well using the validation tool, we can see your record is correct:

      Checking to see if there is a valid SPF record.

      Found v=spf1 record for liveoutthere.com:
      v=spf1 mx include:cmail1.com ~all

      evaluating…
      SPF record passed validation test with pySPF (Python SPF library)!

      OK, so that’s good. Let’s look at the error message: ‘Received-SPF: softfail (transitioning domain of liveoutthere.com does not designate 209.85.223.173 as permitted sender)’

      The soft/hard fail in the error message refers to the end of your rule. You can set a hard – (minus) all fail or a soft ~ (tilde) all fail on non matches. Using a soft rule (~all) is good for debugging your rule. Messages that fail your matching will still be accepted but tagged, as you see in your error message above. A hard rule (-all) indicates to the server that the mail should be rejected. Only use a hard fail is you have tested and are 100% sure of your SPF rule)

      So back to your error, 209.85.223.173 is not a permitted sender, as per the SPF rule you have set up. You have allowed for “cmail1.com” to send mail on your behalf – these two do not match. If I do an IP lookup on “cmail1.com”, the IP returned is 27.126.145.31. So you need to verify the URLs your mail server is using and update your rule with these (assuming that this error message has come from a legitimate piece of email and not spam). You can use an IP or range of IP addresses. I’d recommend giving your hosting provider a call/email to find out this information.

  8. I’m using Postfix to relay mail from my site to my mail server. Mail is received properly at my Gmail account – only Yahoo is the problem. The Yahoo mail headers state:

    Received-SPF: none (domain of mail.techmkt.co.in does not designate permitted sender hosts)

    In contrast, the Gmail headers state:

    Received-SPF: pass (google.com: domain of abuse@mail.techmkt.co.in designates 203.187.255.25 as permitted sender) client-ip=203.187.255.25;

    Does anyone have any suggestions as to what I can do to solve the Yahoo problem

  9. @Keshav

    Obvious first question – have you allowed 72hrs for the DNS records to propagate? This is the maximum TTL value that can be set, and many servers update faster than this but you have to clear 72hrs before you know something has gone wrong.

Click on a tab to select how you'd like to leave your comment

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>