Problems with FastMail's SPF Records
 

Good day.

Fastmail is not the DNS host for my domain. However, my domain's SPF RR were set, as follows:

Yesterday, one of my outgoing messages sent via FM's SMTP servers bounced with the following error message:
I resent the same message this morning and it bounced, again, with the following error message:
I added "ip4:66.111.4.226/32" to my domain's SPF RR, waited for the change to propagate, and resent the same message. To my surprise, it bounced a third time with the following error message:
This time, I changed "ip4:66.111.4.226/32" to "ip4:66.111.4.0/24",, waited for the change to propagate, and resent the same message. This time it went through.

My domain's SPF RR now are:
I was under the impression that "include:spf.messagingengine.com" would cover all FM's SMTP servers, but it doesn't.

Also, adding "ip4:66.111.4.0/24" is not going to work with the offending SMTP server in the first bounce message (64.147.123.30).

What am I missing?

Thank you.

--
Jacinto

I really think a support request is in order. If I had to guess, I would speculate that Fastmail changed a couple of SPF servers in an emergency to circumvent the original IP addresses appearing in spam blocklists. In the process, the update of spf.messagingengine.com was forgotten (or possibly did occur, but was not picked up because of propagation delays).

Thank you, BriTim.

I believe you are correct.

None of the three offending FM SMTP servers IP addresses come up when "spf.messagingengine.com" is searched:
The SPF RR TTL is 79,146 seconds or a few minutes short of 22 hours.

Since all the SPF IP addresses are in the "64.147.123.0" and "66.111.4.0" IP ranges, adding "ipv4:64.147.123.0/24" to SPF RR should do the trick (at least for now until FM decides to fix what ain't broke).

Thank you again.

--
Jacinto

Just a heads-up.

Checked FM's SPF RR today and the offending SMTP severs IP numbers (66.111.4.223, 66.111.4.226 and 64.147.123.30) are still not included in them.

Sure miss pre-Opera FastMail and all the FM founders and other staff who were active participants in this Forum.

I suppose that we'll have to stick with the current much less than perfect FastMail and hope we don't get burned too badly because of its lackadaisical attitude towards paying subscribers.

--
Jacinto

When I look up IP 64.147.123.30 I see this as the host: forward1-smtp.messagingengine.com. When I look up 66.111.4.226 I see this as the host: forward2-smtp.messagingengine.com. Those appear to be SMTP servers for email forwarding purposes. Are you using smtp.fastmail.com for sending?

Thank you, Ten Four.

Yes, outgoing mail is relayed from the MUAs, via SSL, to port 565 at mail.messagingengine.com.

This was set-up by FM years ago as a SMTP server that would not add its own "Received" headers (haven't checked it in a while to see if it still doesn't).

The FM bouncing problem has become so nasty that, for my biggest FM account, I'm embarrassed to say, I now relay outgoing mail via an old GApps (now grandfathered GSuite) account. So far, no outgoing mail has bounced using GMail.

--
Jacinto

I believe you should send via smtp.fastmail.com since they changed things in 2016. https://www.fastmail.com/help/accoun...tyupgrade.html

Good morning and thank you, TenFour.

As I said earlier, the server we currently use is the one that "was set-up by FM years ago as a SMTP server that would not add its own "Received" headers."

Even though I said "years ago," if I remember correctly, it was after 2016. There was a discussion thread about the same on this Sub-Forum. I'll try to find it when I have time (but not today).

Anyways, with all due respect to remaining FastMail admirers (of which I used to be one until the Opera debacle), it is irresponsible for a for-profit E-Mail host to actively use SMTP servers for which it has not published SPF RR.

We are paying FastMail subscribers and should not have to put-up with bounced sent mails, especially, transactional messages, because of the E-Mail carrier's irresponsibility.

--
Jacinto

Fastmail has two classes of outgoing server. One is for normal mail sent from locally hosted domains, the other is for forwarded mail and mail using third-party addresses. These third party addresses are registered at FM in identities, but not hosted there.

The SPF for hosted mail doesn't include the forwarding servers.

The spam in forwarded mail means that the servers in the latter set often have very low reputations.

If you want to send from a domain not hosted at FM you can put "include:spfall.messagingengine.com" in your SPF record. Be aware that you will be paying FM for a second class service.

BTW the DNS A-record lookup done on spf.messagingengine.com isn't relevant - it should have been a TXT look-up.

It may appear to work at FM if they've set up the IP addresses for spf.messagingengine.com to match its SPF record, but it's certainly not definitive, so there's no guarantee that it's consistent with the correct look-up.

include:spf.messagingengine.com means lookup the SPF for spf.messagingengine.com and look for a pass on that. You can't get a fail from an include so the term "include" is really a misnomer.

Good day and thank you, Bob.

Actually, I did both A and TXT look-ups before posting.

--
Jacinto

Hi, Bob.

I must be missing something.

There are no published A or TXT RR for "spfall.messagingengine.com".

--
Jacinto

Try it again there is a TXT record

Hi, Bob!

I use "host" rather than "dig" and got it this time. Perhaps I typed something incorrectly previously:
Not sure whether or not you read this whole thread, but I wrote earlier that I had already added those two SPFs:
And:
It did do the trick, but who knows for how long.

--
Jacinto

I've been pointing why your assumption that "include:spf.messagingengine.com" would cover all outgoing servers is wrong and why you should have used "include:spfall.messagingengine.com" instead. Adding explicit IP ranges is just a workaround.

This is why you should be using the spfall version, it will adjust with any changes to IP ranges.

There hasn't actually been a change, the spfall TXT record is the same as it was a year ago.

I'm assuming here that the email was sent out through wforward1-smtp for the normal reasons. If this happened to non-forwarded email sent using a domain hosted at fastmail, you should tell support.