How to merge DA SPF with GoogleApps SPF?

ditto

Verified User
Joined
Apr 27, 2009
Messages
2,577
When my clients use GoogleApps/Gmail for email handling, how should I set up the SPF record then?

I have read this: http://www.google.com/support/a/bin/answer.py?hl=en&answer=33786

What make me unsure, is that there is already a SPF record setup in DNS by DirectAdmin, so I think I need to merge the SPF records from DirectAdmin with the one from Google?

Before making any change in DNS in DA, I have this SPF record:
Code:
"v=spf1 a mx ip4:**.***.***.*** ~all"

(Please note that the stars * is a replacement for my servers IP adress.)

After merging the existing SPF record with the one described at the above link from Google, it looks like this

Code:
"v=spf1 a mx ip4:**.***.***.*** include:aspmx.googlemail.com ~all"

Is this correct? I hope so, but I need to be sure, so any confirmation would be greatly appreciated! Thanks!
 
Yes, it is correct indeed.

After I added this change to SPF for my GoogleApps/Gmail clients, I get complainants from my clients saying that when they send Word or PDF attachment, the attachement becomes .dat files when receive by the recipient.

Is this really possible that it is because of the SPF? What change should I make to fix it then? I am lost about this issue ...
 
If your clients are using GoogleApps and/or Gmail, then they're sending and receiving mail through Google, and not through your server.

So my guess is that unless I'm missing something they'd have to ask their new mail provider (and we all know how good [read: bad] Google support is).

Jeff
 
If your clients are using GoogleApps and/or Gmail, then they're sending and receiving mail through Google, and not through your server.

So my guess is that unless I'm missing something they'd have to ask their new mail provider (and we all know how good [read: bad] Google support is).

Jeff

I feel it is my responsibility, because I offer this as a free addon to my hosting clients.

I have not been able to duplicate the problem (I use GoogleApps/Gmail my self on several of my domains). But my client told me that they where using "Groups" in GoogleApps (this is the same as regular email list), but I have not even been able to duplicate the problem when creating a group in GoogleApps and sending attachement to the group.

At the moment I am trying to reach the client on telephone, so that we can look into this.

In the meantime, I found this very interesting article (it does not say anything about problems with attachments and .dat-files, but it might be relevant to the problem:

Google Provides Incorrect SPF Record Info for Use with Google Apps: http://www.hybrid6.com/webgeek/2009/03/google-provides-incorrect-spf-record-info-for-google-apps.php (please read all of the article, including the comments, it is very dramatic, I think!).

At the moment I am considering trying out two different changes in the SPF:

At the moment I have this:
Code:
"v=spf1 a mx ip4:**.***.***.*** include:aspmx.googlemail.com ~all"

But maybe I should remove the servers IP adress? Like this:
Code:
"v=spf1 a mx include:aspmx.googlemail.com ~all"

Then I willl try to use the one suggested in the aricle (linked above):
Code:
v=spf1 a mx include:aspmx.googlemail.com include:_spf.google.com ~all

I am confused that the article don't include a IP adress to the server, like I did? So maybe that is my problem, that I should remove the IP adress (but keep the "a" and "mx" ... (but contact forms and stuff like that on the clients webpages, must still be able to send out email).

I don't even care to contact Google myself, because my experience with Google support in the past, is that it might take several weeks or month before I get a answer.
 
Last edited:
The SPF record of aspmx.googlemail.com reads "v=spf1 redirect=_spf.google.com" (which is the same SPF record of gmail.com), so to write "include:aspmx.googlemail.com include:_spf.google.com" is just redundant.

But some servers may incorrectly discard SPF check (and flag as spam) when forced to do more than 2 recursive queries, just like recursive CNAME records are forbidden: try using "v=spf1 a mx ip4:**.***.***.*** include:_spf.google.com ~all" directly.
 
The SPF record of aspmx.googlemail.com reads "v=spf1 redirect=_spf.google.com" (which is the same SPF record of gmail.com), so to write "include:aspmx.googlemail.com include:_spf.google.com" is just redundant.

But some servers may incorrectly discard SPF check (and flag as spam) when forced to do more than 2 recursive queries, just like recursive CNAME records are forbidden: try using "v=spf1 a mx ip4:**.***.***.*** include:_spf.google.com ~all" directly.

Thanks! I am testing this on one of my domains at the moment. I will get back to you with a update here shortly.

Remember I am a newcomer on this. Just to double check that we don't misunderstand each other. In this:

Code:
"v=spf1 a mx ip4:**.***.***.*** include:_spf.google.com ~all"

The stars **.***.***.*** should be my servers IP address, correct?

About the problem with the attachments that becomes .dat files, I have not been able to duplicate the problem, and the customer is not available for a week. So I will not be able to see if this fixes that problem before later -- but I will try your suggestion, and check the headers of the email and see if it is a SPF pass or fail ...
 
About the stars being the IP address of your server, that's correct.

Thanks! I tested it with your suggestion, and I can send and receive emails without any problems, also attachments works, and it works sending from php forms on the webpage. The SPF say it is a "pass". But there is not always any SPF information in the email headers (I don't think that was any different before...), like when I send email from my local email client on my desktop computer and the email don't have any attachments, then there is no information about SPF in the email headers -- when there is a attachment, there is information about SPF in the email header.

Anyway... I will let it rest, I can't do any more yet. I must wait until next week so I can duplicat the .dat file problem with my client.

Beginning to dislike SPF, because I don't feel like I have any control of what is going on ...
 
Just one more thing (sorry for nagging you all):

Before one of my users complained about the attachments sometimes becomes .dat files, they had there SPF records like this:

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

Then I changed it to this, and they then reported that some attachments became .dat files:

Code:
"v=spf1 a mx ip4:**.***.***.*** include:aspmx.googlemail.com ~all"

So I think that maybe it is the "a mx ip4:**.***.***.***" that creates the problem, or maybe it is only the IP address that creates the problem.
 
It is true, you don't have real control on what's going on with SPF, because it is a choice of the receiver side, and can also be used in the wrong way by the same party.

When you talk about SPF email headers it's not important to know from where you send the Email, at all.
It's important to know the domain of the sender Email address, and which server moved the message to someone's mailbox.

Example:

- you send a message from @domain_with_spf.tld to @destination_domain.tld.
- the MX of destination_domain.tld is receiver_host
- you used the correct SMTP server, sender_host, to send the message
- receiver_host decides to check the SPF record (its decision may be based on whether an attachment is present or not!)
- the SPF record matches, so the message now has an header saying that SPF passed
- receiver_host places the message within the user's Inbox

Other example:

- you send a message from @domain_with_spf.tld to @destination_domain.tld.
- the MX of destination_domain.tld is receiver_host
- you used a malicious SMTP server, spammer_host, to send the message
- receiver_host decides to check the SPF record
- the SPF record does not match, so the message now has an header saying that SPF failed
- receiver_host places the message within the user's Spam mailbox (or erases the message entirely, or whatever: it should follow what's written just before the "all" directive, like "~all = deliver but notify the user, i.e. place in the spam mailbox", but many do not)

Read http://www.openspf.org/SPF_Record_Syntax for more information on SPF syntax and try/build records with http://www.openspf.org/Tools .

UPDATE: referring to your last comment, no: SPF components always have an "OR" relationship: if one of them passes, then the test passed.
 
Last edited:
Thank you very much for the explaination! I have read it two times, and will read it over again several times.

One _last_ question. If my users use this SPF:

Code:
"v=spf1 a mx ip4:**.***.***.*** include:_spf.google.com ~all"

And the users use his Internet providers SMTP to send the email (instead of Googles SMTP), will that in many cases result in that the email is placed in the recievers spam folder or entirely deleted? If so, then the user must change SMTP or edit SPF according to his Internet providers SMTP, or as a third option maybe stop using SPF at all?
 
I am looking at the wizard on http://www.openspf.org/Tools

To have a more flexible SPF for my users, then I should maybe use the "?all" instead of "~all" -- just to be sure my users don't get any trouble if they send emails from their Internet providers SMTP? So I then would use this SPF instead?:

Code:
"v=spf1 a mx ip4:**.***.***.*** include:_spf.google.com ?all"
 
Last edited:
Exactly. Keep in mind that it's better to have an "?all" rule that no rule at all, even if the "official" behaviour is the same: some spamfilters (like SpamAssassin, or those of many large ISP) give bonus points if an SPF records exist, getting your messages more likely in the Inbox. Others understand ?all just like ~all.
 
Exactly. Keep in mind that it's better to have an "?all" rule that no rule at all, even if the "official" behaviour is the same: some spamfilters (like SpamAssassin, or those of many large ISP) give bonus points if an SPF records exist, getting your messages more likely in the Inbox. Others understand ?all just like ~all.

Thank you! I have now tested some more on one of my domains, and decided to use the following SPF for all of my GoogleApps clients:

Code:
"v=spf1 a mx ip4:**.***.***.*** include:aspmx.googlemail.com include:_spf.google.com ?all"

I hope I have not misunderstood you about the redundant variant of the SPF (using both: include:aspmx.googlemail.com include:_spf.google.com) and that this can case any trouble? I want them both so that if Google changes anything in the future, my clients want get trouble "over the night", but we will have some time to do the necessary changes -- this combined with the use of "?all" instead of "~all", is to my understanding the most bullet-proof solution I can offer my clients.

Edit:
...But some servers may incorrectly discard SPF check (and flag as spam) when forced to do more than 2 recursive queries, just like recursive CNAME records are forbidden: try using "v=spf1 a mx ip4:**.***.***.*** include:_spf.google.com ~all" directly.

I guess I misunderstood you! I now understand you that way I should not use both "include:aspmx.googlemail.com include:_spf.google.com", but only one of them. Okey. I will use this then (and hope Google does not change/break anything for us in the future):

Code:
"v=spf1 a mx ip4:**.***.***.*** include:_spf.google.com ?all"

I hope this will be the end of this story, and that this is the best possible solution ...
 
Last edited:
Google is not going to remove its _spf TXT record soon, that's for sure. Your final record is the best solution, I agree.
 
I believe your .dat file issue is not related to spf at all.

If the user has Outlook, and the files are named "WINMAIL.dat" this is probably the cause:
http://support.microsoft.com/kb/278061/en-us

It has to do with the "rich text" file format outlook thinks its being creative with. If you change it to default to plain text, the problem goes away.
 
I believe your .dat file issue is not related to spf at all.

If the user has Outlook, and the files are named "WINMAIL.dat" this is probably the cause:
http://support.microsoft.com/kb/278061/en-us

It has to do with the "rich text" file format outlook thinks its being creative with. If you change it to default to plain text, the problem goes away.

The file name is not changed to "winmail.dat", but to some "random numbers.dat". We are still investigating this. It seems it happen only when recipient of email is using Outlook ...

Thank you for the hint about plain text.
 
This is a very old topic (2010), but is there since an explanation or solution for the fact that while executing antispam/antivirus some files "random numbers.dat" are created and visible in the quarantaine, that then are flagged as "bad filename : No programs allowed" ?
 
Back
Top