Google Provides Incorrect SPF Record Info for Use with Google Apps

by Scott Allen - March 19, 2009 
Filed Under Email, Google, Spam

If you’re using SPF Records with email powered by Google Apps, you most likely have a problem — a BIG one. Your email is likely getting flagged as spam, and not getting to important recipients. The (incorrect) SPF Record recommended by Google is:

v=spf1 include:aspmx.googlemail.com ~all

Unfortunately due to a problem with how Google is routing email internally, this WILL cause your outgoing emails to be flagged as spam, even when being read by another Google-based account. Great…thanks, Google!

From tests I’ve run, I can confirm that it happens when you are using POP and emailing through a client like Outlook, Thunderbird, etc. I haven’t tested it with IMAP. However, it doesn’t seem to flag anything as spam when the web interface is used.

According to the Google help forums, there is a workaround that will keep your emails from being flagged as spam. It recommends:

Instead of
v=spf1 include:aspmx.googlemail.com ~all
use
v=spf1 include:_spf.google.com ~all

However, in my opinion this isn’t a complete solution because it doesn’t allow mail sent from your webserver. I recommend using:

v=spf1 a mx include:aspmx.googlemail.com include:_spf.google.com ~all

This will allow mail from your webserver (for example if you have a contact form), and it also will keep you from having to change the SPF Record if Google ever fixes Google Apps to function the right way (as far as mx records are concerned). If you don’t have a dedicated IP on your server, or you don’t need to send mail from it, then you may want to delete the “a” between the “v=spf1″ and the “mx”.

In case you’re not familiar with SPF Records, they are a great tool to help prevent your company’s web domain from getting blacklisted when spammers try to send emails out with a fake the “From” address that seem to be coming from your web domain. SPF stands for “Sender Policy Framework” and basically establishes the rules by which your domain’s outgoing email can be used, including which servers are allowed to be sending mail. Email systems that check SPF Records will flag anything as spam that isn’t coming from one of the allowed servers.


hostgator web hosting affordable fast reliable servers: Google Provides Incorrect SPF Record Info for Use with Google Apps spam google email

sb 468x60: Google Provides Incorrect SPF Record Info for Use with Google Apps spam google email

Submit Your Site to Best of the Web!



Comments

14 Responses to “Google Provides Incorrect SPF Record Info for Use with Google Apps”

  1. Henry on April 28th, 2009 11:01 am

    Hi Scott, a big thank for the tip, I was having the same exact problem and wasn’t able to solve it via Google Apps Help Center. Really useful. Cheers from Italy.

  2. Scott Allen on April 29th, 2009 9:14 am

    @Henry: You’re welcome. :) Glad to help!

  3. Rich on May 19th, 2009 11:23 pm

    I’m having the same problem, so thanks very much for this. Not knowing the first thing about SPF I wouldn’t have known where to start either.

    Can I confirm, I should use a TXT type record, and the string provided goes in the Data part of the record?

    Thanks very much for posting the tip.

  4. Scott Allen on May 20th, 2009 6:05 pm

    @Rich: You’re welcome. Yes, SPF is a TXT record. Implementation will vary a bit by host, but the best place to start is the openspf.org website – they have all the info, and can help you with implementation info.

  5. Bill on May 22nd, 2009 11:16 pm

    Very helpful. Solved (I think) the problem we were having with recipients getting our ‘spam’. Our business guys were ready to pull up stakes with Google Apps today, but I think this will get them off the ledge.

    Google just joined Microsoft, Adobe and Sugar on my list of companies that qualify as torturers, btw.

  6. Al Terego on May 27th, 2009 1:58 pm

    The problem from this post is likely caused by hosts that do not follow SPF redirects. The SPF for aspmx.googlemail.com is a redirect to _spf.google.com. Using the end of the redirect allows hosts that don’t support redirects to resolve the records properly.

    The same messages will be displayed in the web UI as when using POP. POP just downloads messages in the Inbox, not the Gmail spam folder. If they end up in a spam folder in the email client, then it’s the client that is marking it as spam. I think your solution is valid for domains that [hard|soft]fail on SPF (not an issue when ~all is used), but your assessment of the problem appears to be wrong.

    If the email headers show an IP address that does not fall into the IP range in their help center, you should definitely let them know.

  7. Scott Allen on May 27th, 2009 2:18 pm

    @Al Terego (aka Alter Ego?):

    I can see from your IP address that you’re obviously a Google employee. You didn’t think I’d look? That’s a pretty lame attempt at reputation management – to simply deny the problem exists and pretend you don’t work for Google.

    Actually the assessment I’ve given in this post IS in fact, correct. I checked the headers of the emails I was testing in Gmail on the web and Google Apps on the web (as well as in email clients), and they marked the emails as a Fail when using the SPF instructions provided by Google. Whether soft fail or hard fail is irrelevant in testing this – it shouldn’t be marking them a fail at all if the SPF is working properly. The problem is obviously not with the email clients as you claim. There is a real issue with Google Apps and SPF, and it needs to be fixed, not denied.

    The help forums also acknowledged that it was a known issue, so I’m not sure what point there is in your trying to refute it.

  8. Scott Gingerich on May 28th, 2009 11:08 am

    Just the info I was looking for! Well written, easy to follow and best of all… the spf record I needed to use both the dedicated server and Google Apps. I had already failed using Google’s suggestion and my own attempts. Thanks again.

  9. Scott Allen on June 2nd, 2009 1:53 pm

    Apologies to any of you who might be offended if my response to “Al Terego” seems a little terse – it’s just that I have a real distaste for companies (or company employees) that act deceitfully when trying to manage their reputation. Especially when the facts are true. Pretending you’re not from the company is never a good practice. There was a scandal with several companies that were caught removing negative (but true) info from their Wikipedia pages. They were quickly discovered because they logged in from their company internet, and the IP address was attached to their company.

    @Scott: I’m glad that this was helpful for you. :) You’re welcome!

  10. T. Thumb on July 20th, 2009 7:55 am

    Hi! Thanks for this informaion! I’ve been pulling my hair out trying to get this corrected. The new hosting company that we just launched the website with didnt know how to fix it. :-)

  11. G. Abbott on July 28th, 2009 9:59 pm

    Thanks for the info. Just this evening I was moving my DNS and looked into adding a SPF record for my google apps account. I just use mine for personal use but thought it would be a good idea to implement this. Now not knowing a whole lot about SPF records, if google makes any changes on their end, should I be concerned about having to update the SPF record or risk getting emails I send marked as spam to others?

  12. Chris S. on September 10th, 2009 5:10 pm

    Thanks for the info. I’ve been scratching my head for a couple days and I hope this will resolve it.

  13. Bruce Clement on September 11th, 2009 5:27 pm

    Hi Scott,

    I manage the DNS for my own and a few friends and family’s domains using Google apps for their mail services and while I’ve been aware for a while the there was a problem I thought it was Google being misconfigured. Recently one of them had some mail blocked and this article proved invaluable for me to work out what happened. Thank you very much.

    Unfortunately it wasn’t a full solution, and I’m doubting that there ever will be one. Another Google page http://www.google.com/support/a/bin/answer.py?hl=en&answer=33786 adds the addresses ip4:207.126.144.0/20 ip4:64.18.0.0/20 ip4:74.125.148.0/22 to the required spf record. Even with these added it turns out that they are also using 209.85.220.228, a whois on that shows it’s a CIDR /17 block. I’m assuming that Google tweak things and don’t bother updating their published SPF records in sync with the changes.

    This has given me a required spf record of “v=spf1 ip4:64.18.0.0/20 ip4:74.125.148.0/22 ip4:207.126.144.0/20 ip4:209.85.128.0/17 a mx include:_spf.google.com include:aspmx.googlemail.com ~all”

    As I also want to send mail from my public server and my home PC via a dynamic DNS provider it’s ended up even uglier, but I’ll spare you that.

    Thanks again.

    Bruce

  14. Bruce Clement on September 11th, 2009 5:30 pm

    Oops,

    Sorry Scott, that was the same Google page you linked to in the main article.

Leave a Reply
If you have any questions about commenting, please see our Comment Policy.