1

I've made an SPF Record for my company domain and I took great carefulness to have it done properly without any errors.

I've also set up our mailgateway to check SPF Records of all incoming emails from 3rd parties.

The mailgateway checks two things:

  1. Is the SPF record valid (i.e. does it have errors) and if not
  2. Does the mail connection match the defined addresses in the SPF Record

My general problem now is that it seems as if an overwhelming majority of 3rd parties that send emails to us seem to get their SPF Records wrong. (about 90% of rejected emails are based on syntax errors, wrong use of options, etc.).

For example:

  • v=spf1 a mx a:mail.company.com~all (where there's is a space missing therefore mail.company.com~all cannot be resolved)
  • v=spf1 a include:mail.company.com ~all (where the include can't resolve an SPF Record from that domain and a:mail.company.com should have been used.)

and other things like that.

I'm kind of getting annoyed at telling other people how to fix their records. Especially when it happens with pretty big companies (at least for my country) So I'm asking myself, does it even make sense to check the record for such errors?

Or should one treat those records as if they do not exist?

On the one hand I think I should check them, by having a SPF Record those Domains "ask" me to validate everything so I feel compelled to do so when receiving a mail, if someone tried to forge an email from that company with something like a payment notice, they obviously want me to check that the mail is in fact valid. On the other hand, it seems as if they do not really care or they would have checked everything themselves.

schroeder
  • 123,438
  • 55
  • 284
  • 319
architekt
  • 986
  • 1
  • 7
  • 18

2 Answers2

3

The RFC for SPF addresses this case: an invalid SPF record will result in a PermError.

But there are no clear rules how to deal with a PermError: the mail might be rejected (thus making the sender aware of the problems) or it might be forwarded. In the latter case it might be useful to include the information into the mail, i.e. add an Received-SPF header with the PermError status so that spam filters upstream (like in the MUA itself) can take this SPF status into account.

Given that according to your information you deal with lots of invalid SPF records even from major companies rejecting such mails is probably a bad idea. I would thus suggest to forward the mails but include an Received-SPF header with the PermError status and details about the error as comment.

Community
  • 1
Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
0

I'd treat a domain with an invalid SPF policy just as it had none.

Why should it be your task to correct other peoples mistakes?

Of course, you could check your logs and inform any business partners if they got their SPF wrong, but blocking every mail from these domain seems wrong to me.

Lukas
  • 3,138
  • 1
  • 15
  • 20
  • While I agree with your first line, I disagree with your second. If you want to be able to protect your users from spoofed emails from unauthorised domains, then you do want these records created correctly. – schroeder Jul 20 '18 at 08:41
  • @schroeder that's what I thought too. I'm generally more concerned about my own users and if I treat faulty records just like non existing ones I put my users in a situation where they could get forged mails from well established customers – architekt Jul 20 '18 at 08:51