I cannot seem to get a SPF record working for a client of ours, Google mail keeps failing on the lookup.

My SPF record is

v=spf1 a ip4: include:mx1.helloevery1.co.uk include:_spf.google.com include:smtproutes.com include:smtpout.com

The clients main mail server are

smtproutes.com and smtpout.com

These are working fine, SPF passes as expected.

mx1.helloevery1.co.uk is our mail server. It is a simple ISPConfig Postfix setup. We send all mail through 1 account, let's say that is "[email protected]".

There is a username and password set up to send through but we change the "from" address in our application. The from address is "[email protected]".

"[email protected]" is not set up on mx1.helloevery1.co.uk. It is only on the client servers.

When I send through my SMTP server from the site, I am receiving the following error when I send to my email account.

Received-SPF: permerror (google.com: permanent error in processing during lookup of [email protected]) client-ip=;

Authentication-Results: mx.google.com; spf=permerror (google.com: permanent error in processing during lookup of [email protected]) [email protected]

This looks like it is trying to lookup the domain on my SMTP server (where is not is configured). If I were to set up the domain on my SMTP server and create an account then when I send through my SMTP server then it will try to deliver it locally.

I've always assumed that SPF was just a verification tool to say which server is allowed to send but never really took into account the email it is coming from.

I'm stuck as I can't find a resource on SPF record creation that I can relate to


4 Answers 4


An SPF record states which mailservers are allowed to send mail from the sending domain. Basicly, what is in the from: address.

So if you have someone sending mail as "[email protected]" and the receiving mailserver checks SPF, it looks for an SPF record on "ninja.com" to see if the sending mailserver is listed.

Does this answer your question ?

  • In this instance though my mail server is listed in the SPF record. The SPF record above is for clientdomain.com and my mail server is listed "mx1.helloevery1.co.uk". Shouldn't that be enough for it to pass SPF checks? May 28, 2014 at 11:11
  • I did a lookup of what I could, and the client-IP does match with the DNS name of your mailserver. clientdomain.com is ofc a placebo, so I cannot lookup the record there to check it - but looking at v=spf1 a ip4: include:mx1.helloevery1.co.uk include:_spf.google.com include:smtproutes.com include:smtpout.com indicates you may have left out "-all" at the end of the record which designates that mails that fail SPF should be rejected. - see en.wikipedia.org/wiki/Sender_Policy_Framework#Qualifiers for reference. If the syntax is incorrect, it should return a PERMERROR as youget
    – Mwuanno
    May 28, 2014 at 11:24
  • It was originally there, it is ~all I use. I've added it back in. The client IP is a linode box of which reverse DNS I cannot change. If I change the "from" address to the actual sending account then all works as expected? If I added ~all and it doesn't work what should I do? Would this be easier if I provided real domains? May 28, 2014 at 11:29
  • ~all indicates that if your email fails SPF check, it should only be tagged as failing SPF - also known as SOFT FAIL. The PERMERROR you got, will show up if the syntax of the SPF record is not correct as I wrote. Reverse DNS doesn't factor in regards to SPF. (some antispam does check it though) - in regards to sending account, this is irrelevant for SPF.
    – Mwuanno
    May 28, 2014 at 11:42
  • 1
    google looks up the SPF record. It then parses it. v=spf1 MUST be there. -all or ~all MUST be there. Basicly, if any part of the record fails parsing correctly, it returns a PERMERROR. Another limit might be the amount of DNS lookups it takes to parse it. No more than 10 lookups may be used. This can quickly become a problem with nested records (include:) and such. You could try and change the SPF record to only use IPv4 mechanisms. Also, DNS lookups can be cached, so it may take time before an update to the record takes effect.
    – Mwuanno
    May 28, 2014 at 12:01

The reason for Google's PermError is that the domain mx1.helloevery1.co.uk, contained in your SPF include: directive, has no SPF record configured of its own. This issue is treated here:

include:<domain> : The specified domain is searched for a match. […] Warning: If the domain does not have a valid SPF record, the result is a permanent error. Some mail receivers will reject based on a PermError.

As you found out, using the ip4: ip6: mechanisms helps (use both, as you don't know what IP Google sees of the sending host, so it may fail if you only use ip4:). To provide some resilience against IP address changes, you can allow a range of IP addresses (instructions).

However, if you have access to the DNS of the include:-ed domain, it is a cleaner solution to configure a SPF record for it too, such that your sender's IP address passes that SPF test. It makes your other SPF record resilient against IP address changes.


At the advice of Mwuanno I changed my records to be ip4 and ip6 based and it started accepting the spf record. The record now reads

v=spf1 a ip4: ip4: ip6:2a01:7e00::f03c:91ff:fedb:4ec8 include:smtproutes.com include:smtpout.com ~all

This seemed to work for me and SPF passes


The reason the SPF record with the ~all parameter at the end probably worked is not necessarily because of the inclusion of both IP4 and IP6 Addresses but because of the ~all parameter.

~all is a Soft Fail: All mail servers not listed in the SPF record are not authorized to send mail using the sender’s domain, but the owner of the domain is unwilling to make a strong assertion to that effect. So in other words the SPF check will not necessarily fail and the receiving server may accept the email message.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .