5

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:80.74.254.215 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 "noreply@example.com".

There is a username and password set up to send through but we change the "from" address in our application. The from address is "enquiry@clientdomain.com".

"enquiry@clientdomain.com" 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 enquiry@clientdomain.com) client-ip=212.71.234.103;

Authentication-Results: mx.google.com; spf=permerror (google.com: permanent error in processing during lookup of enquiry@clientdomain.com) smtp.mail=enquiry@clientdomain.com

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

Chris Lomax
  • 173
  • 1
  • 2
  • 8
  • 1
    Possible duplicate of [What are SPF records, and how do I configure them?](https://serverfault.com/questions/369460/what-are-spf-records-and-how-do-i-configure-them) – MadHatter Jul 18 '17 at 06:31

4 Answers4

2

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 "ninja@ninja.com" 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 ?

Mwuanno
  • 89
  • 3
  • 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? – Chris Lomax May 28 '14 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:80.74.254.215 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 http://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 '14 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? – Chris Lomax May 28 '14 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 '14 at 11:42
  • There should be no reason why it is failing though should there? My mail server is listed against their SPF record? I don't understand what this "lookup" is that google is making? – Chris Lomax May 28 '14 at 11:49
  • 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 '14 at 12:01
  • For the record, the SPF record should *not* be matched against the header-From: address, but against the envelope-From address. – MadHatter Jul 18 '17 at 11:20
1

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:80.74.254.215 ip4:212.71.234.103 ip6:2a01:7e00::f03c:91ff:fedb:4ec8 include:smtproutes.com include:smtpout.com ~all

This seemed to work for me and SPF passes

Chris Lomax
  • 173
  • 1
  • 2
  • 8
1

The reason for Google's PermError is that the domain mx1.helloevery1.co.uk mentioned in your SPF include: mechanism has no SPF record configured of its own. This is mentioned 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.

Community
  • 1
tanius
  • 590
  • 5
  • 13
0

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.

Jim
  • 1