~ is "undecided". That is, neither allow or deny. You probably want

v=spf1 include:_spf.google.com -all

if you want to allow only Google servers, or

v=spf1 include:_spf.google.com a -all

if you want to allow the server machine itself to send stuff directly (which you probably do, unless you have msmtp set to route all outgoing messages via Google).

Ahhh, that would make sense, but it's odd that google recommended not to use the "-" in an spf record.

Thanks :D

@adrian18w:

Ahhh, that would make sense, but it's odd that google recommended not to use the "-" in an spf record.
Using "-" is dangerous as it will tell others to reject your messages if they come from anywhere but what you have specified in your SPF record. Even big players seem to be able to get their SPF records wrong, so I think google is just trying to minimize the damage when people make mistakes.

If you understand SPF well enough to be using the "-", then you probably should be confident enough to ignore a recommendation from google ;)

~all means soft fail. -all is hard fail. With soft fail, when the spf test fails the receiving server may still accept the message.

If the spf record is correct, either should return an spf pass (as seen in the message headers).

I'm not sure about the Linode DNS manager, but sometimes it's necessary to enclose the TXT record in quotes, e.g.

"v=spf1 include:_spf.google.com ~all"

@adrian18w:

My settings in the Linode DNS Manager for TXT Record are:

• Name: mail125

• Value: v=spf1 include:_spf.google.com ~all

• TTL: default
  What you have specified above will only apply to mail coming from user@mail125.yourdomain.com.

You want to leave the "Name" field blank in the linode DNS manager to make an SPF record for mail coming from user@yourdomain.com.

@sleddog:

~all means soft fail. -all is hard fail. With soft fail, when the spf test fails the receiving server may still accept the message.

If the spf record is correct, either should return an spf pass (as seen in the message headers).

I'm not sure about the Linode DNS manager, but sometimes it's necessary to enclose the TXT record in quotes, e.g.

"v=spf1 include:_spf.google.com ~all"

So really either using "-" or "~" shouldn't really cause a fail. There has to be a different source of a mistake. I have added the quotes.

@Stever:

@adrian18w:

My settings in the Linode DNS Manager for TXT Record are:

• Name: mail125

• Value: v=spf1 include:_spf.google.com ~all

• TTL: default
  What you have specified above will only apply to mail coming from user@mail125.yourdomain.com.

You want to leave the "Name" field blank in the linode DNS manager to make an SPF record for mail coming from user@yourdomain.com.

As an extra precaution I have also left the "Name" field blank.

Thanks again for the hints. I shall post back the results :D

All right, that'll hopefully teach me to re-check docs before posting… anyway, Linode DNS Manager automatically puts quotes around the TXT contents. If you put a pair of quotes in there manually, they'll end up INISIDE the record, as

"\"v=spf1 a mx -all\""

. And yes, I just tested it. Remove the quotes.

Heh, speaking of… there seems to be a bug afterwards… when I clicked Edit on the above record to remove the quotes, the value form field was empty… no idea if it's an escaping problem inside the manager or just a problem with Opera/10.10, but that's how it looked. The data was still there - the Remove option did display the entry - but the edit form shown empty value and let me overwrite it.

@rsk:

All right, that'll hopefully teach me to re-check docs before posting… anyway, Linode DNS Manager automatically puts quotes around the TXT contents. If you put a pair of quotes in there manually, they'll end up INISIDE the record, as

""v=spf1 a mx -all""

. And yes, I just tested it. Remove the quotes.

Heh, speaking of… there seems to be a bug afterwards… when I clicked Edit on the above record to remove the quotes, the value form field was empty… no idea if it's an escaping problem inside the manager or just a problem with Opera/10.10, but that's how it looked. The data was still there - the Remove option did display the entry - but the edit form shown empty value and let me overwrite it.

Ok, thanks, quotes removed :)

@rsk:

no idea if it's an escaping problem inside the manager
Try again. It should be fixed.

@jed:

Try again. It should be fixed.
Indeed, it is… darn, I love Linode. :P

Hmm, ok guys, now emails which I send from google apps work great, but when the server sends one, the email headers say " (server ip) is neither permitted nor denied by best guess record for domain of … ".

So it seems that adding the "a" into the spf record doesn't verify the emails send by the server.

Should I add the server's ip : "ip4:xxx.xxx.xx.xxx" in the record?

Thanks.

@adrian18w:

best guess record for domain of … ".
When they say "best guess" it means that they didn't actually get your SPF record and they are making one up for you.

What domain did they say they were making a best guess for?

The server is setup under domain "xxxxxxxx.com" and the mail is send from "yyyyyyyy.com".

Each domain you send mail from needs to have an SPF record that includes all servers that may send mail for that domain.

If your setup is that mail from yyyyyyyy.com can originate either from google apps or the server foo.xxxxxxxx.com, then it seems like you want an SPF record in the yyyyyyyy.com zone that looks something like one of these: v=spf1 a:foo.xxxxxxxx.com include:_spf.google.com ~all v=spf1 ip4:a.b.c.d include:_spf.google.com ~all
Where a.b.c.d is the IP address of your server.

If you also send mail from the xxxxxxxx.com domain, then you need another SPF record for that zone.

And stick with the ~all until you get everything working right - once you are comfortable you can switch to -all if you want.

Can't help much more if you are going to keep the real details secret.

@Stever:

Each domain you send mail from needs to have an SPF record that includes all servers that may send mail for that domain.

If your setup is that mail from yyyyyyyy.com can originate either from google apps or the server foo.xxxxxxxx.com, then it seems like you want an SPF record in the yyyyyyyy.com zone that looks something like one of these: v=spf1 a:foo.xxxxxxxx.com include:_spf.google.com ~all v=spf1 ip4:a.b.c.d include:_spf.google.com ~all
Where a.b.c.d is the IP address of your server.

If you also send mail from the xxxxxxxx.com domain, then you need another SPF record for that zone.

And stick with the ~all until you get everything working right - once you are comfortable you can switch to -all if you want.

Can't help much more if you are going to keep the real details secret.
I appreciate the help :D

Ok, that didn't seem to work. Spf record not found "Received-SPF: neutral (google.com: 74.207.235.111 is neither permitted nor denied by best guess record for domain of www-data@mail.adrianm.com) client-ip=74.207.235.111;"

My server is setup under the domain mail.adrianm.com . The second domain is 125.pl . I want to be able to send emails from both google apps and the server for both domains and more in the future.

I were trying different variations of the spf records, the current ones are:

• 125.pl

name:

value: v=spf1 a ip4:74.207.235.111 include:_spf.google.com -all

• adrianm.com

name:

value: v=spf1 a:mail.adrianm.com include:_spf.google.com -all

@adrian18w:

Ok, that didn't seem to work. Spf record not found "Received-SPF: neutral (google.com: 74.207.235.111 is neither permitted nor denied by best guess record for domain of www-data@mail.adrianm.com) client-ip=74.207.235.111;"
You are sending mail from www-data@mail.adrianm.com, so you need an SPF record for mail.adrianm.com. The SPF record for adrianm.com does not apply to subdomains.

Or you could change your config to make the mail from your server come from www-data@adrianm.com.

@Stever:

@adrian18w:

Ok, that didn't seem to work. Spf record not found "Received-SPF: neutral (google.com: 74.207.235.111 is neither permitted nor denied by best guess record for domain of www-data@mail.adrianm.com) client-ip=74.207.235.111;"
You are sending mail from www-data@mail.adrianm.com, so you need an SPF record for mail.adrianm.com. The SPF record for adrianm.com does not apply to subdomains.

Or you could change your config to make the mail from your server come from www-data@adrianm.com.
So how can I create a spf for a subdomain in the Linode DNS manager?

@adrian18w:

So how can I create a spf for a subdomain in the Linode DNS manager?

Take a look at this post: ~~[http://linode.com/forums/viewtopic.php?p=26166&sid=179baaa0559fa31b0e217592cbfdf35d#26166" target="_blank">](http://linode.com/forums/viewtopic.php? … f35d#26166">http://linode.com/forums/viewtopic.php?p=26166&sid=179baaa0559fa31b0e217592cbfdf35d#26166](

@adrian18w:

So how can I create a spf for a subdomain in the Linode DNS manager?

Add a new txt record, and set the "name" field in the linode DNS manager to the subdomain.

> - adrianm.com

name: mail

value: v=spf1 a -all
It is also good practice to set an SPF record for any hosts that do not send mail. So my normal SPF setup for a domain where I send and receive all mail for the domain on the same host will look something like so:

Name       Value
           v=spf1 mx -all
mail       v=spf1 a -all
www        v=spf1 -all

The first line means any mail from @example.com must originate from the server(s) that receive mail for @example.com.

The second line means mail from @mail.example.com must originate from the host mail.example.com, and it also means that any host that uses a HELO greeting of mail.example.com must match the IP for mail.example.com.

The last line says all mail claiming to be from @www.example.com should be discarded. Any host that has an A record but doesn't send mail can be given one of these lines.

@Stever:

@adrian18w:

So how can I create a spf for a subdomain in the Linode DNS manager?

Add a new txt record, and set the "name" field in the linode DNS manager to the subdomain.

> - adrianm.com

name: mail

value: v=spf1 a -all
Doesn't work.

"The following errors were generated:

Record conflict - CNAMES must be unique"

Thanks :)

@adrian18w:

Record conflict - CNAMES must be unique"

http://www.openspf.org/DNS#Resource-Record > CNAME

roughly saying: "this is not an official name. Look there instead." If a domain has a CNAME RR, there cannot be another kind of RR (there's one exception, which will not be discussed here). For e-mail, and thus for SPF, you will need to look at the official domain name. Example: "alias.example.org. CNAME canonicalname.example.org." means you need to define an SPF policy for canonicalname.example.org and not for alias.example.org.

I would probably suggest that you change the CNAME you have in place for mail to an A record.

@Stever:

@adrian18w:

Record conflict - CNAMES must be unique"

http://www.openspf.org/DNS#Resource-Record > CNAME

roughly saying: "this is not an official name. Look there instead." If a domain has a CNAME RR, there cannot be another kind of RR (there's one exception, which will not be discussed here). For e-mail, and thus for SPF, you will need to look at the official domain name. Example: "alias.example.org. CNAME canonicalname.example.org." means you need to define an SPF policy for canonicalname.example.org and not for alias.example.org.

I would probably suggest that you change the CNAME you have in place for mail to an A record.
Ok, so that would mean I would have to use an IP address instead of a domain. This might be a problem, because google wants you to use a CNAME when directing mail.adrianm.com to google apps (ghs.google.com), or I could just change the CNAME to mail1.adrianm.com.

mail.adrianm.com can't be both the name of your server and an alias of ghs.google.com. The best long-term option might be to rename the server, since if it's not the mail server, it's confusing to call it "mail." (See RFC 1178 for guidance.) However, using something like ghs.adrianm.com as the alias for ghs.google.com would be a decently quick and technically valid fix.

Ok, thanks guys. Everything works now :D