EmailDiscussions.com  

Go Back   EmailDiscussions.com > Email Service Provider-specific Forums > FastMail Forum
Register FAQ Members List Calendar Search Today's Posts Mark Forums Read
Stay in touch wirelessly

FastMail Forum All posts relating to FastMail.FM should go here: suggestions, comments, requests for help, complaints, technical issues etc.

Reply
 
Thread Tools
Old 19 Mar 2016, 02:34 AM   #1
ioneja
Cornerstone of the Community
 
Join Date: Jul 2011
Posts: 713
Best practices with SPF records - FastMail now using ?all

I just noticed that FastMail's SPF record now contains "?all" instead "~all" or "-all"....

Here's FM's default SPF record:

Code:
v=spf1 include:spf.messagingengine.com ?all
I don't know when they made the switch (or maybe I just missed that they always used "?all" from the beginning) -- but anyway, I am curious about best practices for SPF records (and related issues) nowadays, and why FM is using "?all". I know "?all" means inconclusive... but wouldn't it be better for FM to use "-all" which is exclusive? Seems like "-all" is much stronger.

I imagine part of the reasoning is that people might be sending mail from a different server, but if we know that email will ONLY originate from FM's servers, then would it be advisable for us to change it to "-all"? If not, why not?

Hoping one of the engineers from FM will read this and give feedback about this and related authentication issues to make sure our email is deliverable.
ioneja is offline   Reply With Quote

Old 19 Mar 2016, 07:09 AM   #2
robn
Master of the @
 
Join Date: May 2012
Location: Melbourne, Australia
Posts: 1,007

Representative of:
Fastmail.fm
Quote:
Originally Posted by ioneja View Post
II don't know when they made the switch (or maybe I just missed that they always used "?all" from the beginning)
For FM-owned domains, it's been ?all since the beginning (2007).

For user domains, STANDARD_SPF has always been -all. More recently (October 2015), there's also a STANDARD_RELAXEDSPF which is ?all, and that's the one we use by default (obviously, you could configure the TXT record your to use ?all or whatever else).

Quote:
but anyway, I am curious about best practices for SPF records (and related issues) nowadays, and why FM is using "?all". I know "?all" means inconclusive... but wouldn't it be better for FM to use "-all" which is exclusive? Seems like "-all" is much stronger.

I imagine part of the reasoning is that people might be sending mail from a different server, but if we know that email will ONLY originate from FM's servers, then would it be advisable for us to change it to "-all"? If not, why not?
We don't know that. People still send through ISP email servers, or from cheap virtual machines, or from corporate networks.

-all is only reasonable when you can say with 100% certainty that legitimate email will never originate from anywhere but your own network. In my experience controlled corporate networks are the only places that even have a chance of using -all correctly.
robn is offline   Reply With Quote
Old 19 Mar 2016, 07:45 AM   #3
ioneja
Cornerstone of the Community
 
Join Date: Jul 2011
Posts: 713
Thank you, Robn! Very much appreciated. So it does look like there was a change to relax things a bit for user domains -- the default in the new control panel is ?all when I just added a new domain.

However, if I wanted to lock things down more, assuming I'll only be sending from the FM webmail and FM mobile app (which is really the FM webmail anyway, right?), how would I do that most effectively?

Would I disable the default SPF TXT record and add a new one like this?

TXT domain.com STANDARD_SPF

or should I do it explicitly like this:

TXT domain.com v=spf1 include:spf.messagingengine.com -all

or something else?

Also, I noticed in one of my older domains, you guys migrated it over to the new interface like this:

SPF domain.com STANDARD_SPF

But the SPF option is not available anymore in the dropdown list when I add a new record. So I figure just TXT should do the trick... thoughts?

Quote:
Originally Posted by robn View Post
For FM-owned domains, it's been ?all since the beginning (2007).

For user domains, STANDARD_SPF has always been -all. More recently (October 2015), there's also a STANDARD_RELAXEDSPF which is ?all, and that's the one we use by default (obviously, you could configure the TXT record your to use ?all or whatever else).



We don't know that. People still send through ISP email servers, or from cheap virtual machines, or from corporate networks.

-all is only reasonable when you can say with 100% certainty that legitimate email will never originate from anywhere but your own network. In my experience controlled corporate networks are the only places that even have a chance of using -all correctly.
ioneja is offline   Reply With Quote
Old 19 Mar 2016, 11:44 AM   #4
unlocktheinbox
Member
 
Join Date: Feb 2016
Posts: 47
The TXT record should do the trick, I always feel better putting "mx and a" in the SPF which authorizes any MX or A records on your domain to send mail.

PHP Code:
v=spf1 mx a include:spf.messagingengine.com -all 
unlocktheinbox is offline   Reply With Quote
Old 19 Mar 2016, 03:41 PM   #5
robn
Master of the @
 
Join Date: May 2012
Location: Melbourne, Australia
Posts: 1,007

Representative of:
Fastmail.fm
Quote:
Originally Posted by ioneja View Post
However, if I wanted to lock things down more, assuming I'll only be sending from the FM webmail and FM mobile app (which is really the FM webmail anyway, right?), how would I do that most effectively?
If you want to assert that email will only ever come from FastMail servers, use STANDARD_SPF instead of STANDARD_RELAXEDSPF. The only difference is -all vs ?all.

Quote:
Would I disable the default SPF TXT record and add a new one like this?

TXT domain.com STANDARD_SPF

or should I do it explicitly like this:

TXT domain.com v=spf1 include:spf.messagingengine.com -all

or something else?
All other things being equal, you should use the STANDARD_ values so that we can maintain the expected behaviour if things ever change. That said, our SPF records are highly unlikely to ever require a change.

Quote:
Also, I noticed in one of my older domains, you guys migrated it over to the new interface like this:

SPF domain.com STANDARD_SPF

But the SPF option is not available anymore in the dropdown list when I add a new record. So I figure just TXT should do the trick... thoughts?
The SPF RRTYPE is deprecated and the current recommendation (RFC7208 section 14.1) is that it not be published. For that reason, we don't offer it for new setups. The TXT record is all you need.

Last edited by robn : 19 Mar 2016 at 03:47 PM.
robn is offline   Reply With Quote
Old 19 Mar 2016, 03:42 PM   #6
robn
Master of the @
 
Join Date: May 2012
Location: Melbourne, Australia
Posts: 1,007

Representative of:
Fastmail.fm
Quote:
Originally Posted by unlocktheinbox View Post
The TXT record should do the trick, I always feel better putting "mx and a" in the SPF which authorizes any MX or A records on your domain to send mail.

PHP Code:
v=spf1 mx a include:spf.messagingengine.com -all 
It won't hurt anything, but we will never send mail from our listed MX servers, so it won't gain you anything either.
robn is offline   Reply With Quote
Old 19 Mar 2016, 07:30 PM   #7
neilj
Cornerstone of the Community
 
Join Date: Apr 2004
Location: Melbourne
Posts: 971

Representative of:
Fastmail.fm
Unless you can guarantee that none of your *recipients* will ever forward mail from you (for example if you send to their Gmail address, but they actually forward all that mail to FastMail), don't use -all. Unless the forwarding system implements SRS, this SPF policy will cause mail to bounce.

Since you cannot know what your recipients will do, we do not recommend setting -all in your SPF policy, which is why the default option at FastMail is now ?all.

Neil.
neilj is offline   Reply With Quote
Old 21 Mar 2016, 01:51 AM   #8
ioneja
Cornerstone of the Community
 
Join Date: Jul 2011
Posts: 713
Thank you gentlemen! Very much appreciated! Will ponder which way to go, but I definitely appreciate the detailed responses. FM FTW.
ioneja is offline   Reply With Quote
Old 21 Mar 2016, 07:33 AM   #9
jhollington
Essential Contributor
 
Join Date: Apr 2008
Posts: 371
On a semi-related note, I used my own DNS provider, and it looks like Fastmail's SPF checking in the new UI might be a bit too literal... When I go to edit my primary domain name settings, I get a message that SPF is not configured, and it recommends an SPF record of

Code:
v=spf1 include:spf.messagingengine.com ?all
(See screenshot here)

My actual SPF record is:

Code:
v=spf1 include:spf.messagingengine.com include:_spf.google.com include:_spf.freshbooks.com -all
Is Fastmail actually looking for an SPF record that matches exactly? It looks like all of the necessary components should be in there otherwise, and I definitely pass SPF record tests that I perform from elsewhere.
jhollington is offline   Reply With Quote
Old 21 Mar 2016, 07:49 AM   #10
robn
Master of the @
 
Join Date: May 2012
Location: Melbourne, Australia
Posts: 1,007

Representative of:
Fastmail.fm
Quote:
Originally Posted by jhollington View Post
Is Fastmail actually looking for an SPF record that matches exactly? It looks like all of the necessary components should be in there otherwise, and I definitely pass SPF record tests that I perform from elsewhere.
It checks that it parses as a valid SPF record, has "include:spf.messagingengine.com" and ends with either "?all" or "-all".

I'm a little confused - hollington.ca is marked "has valid SPF" in the database. I can't see how you'd get the "SPF is not configured" warning in the UI - it's entirely based on that flag. I'll investigate further; there might be a bug somewhere.
robn is offline   Reply With Quote
Old 22 Mar 2016, 12:16 AM   #11
jhollington
Essential Contributor
 
Join Date: Apr 2008
Posts: 371
Well, whatever you did (assuming you did anything), it now seems to be okay as of this morning. Yesterday wasn't an isolated incident, however — I had noticed the problem a couple of weeks ago, but didn't really have time to deal with it, and shrugged it off at the time since I couldn't see anything wrong with my SPF record and it otherwise checked out fine everywhere else.

I'm assuming that Fastmail doesn't really behave differently whether it detects a valid SPF record or not, as it's up to the receiving server to deal with mail, correct?

(On the other hand, I would guess DKIM is a different story, since there's no point in signing mail without a valid record, so if Fastmail isn't detecting the DKIM record properly, it won't add the necessary signature on outgoing mail?)
jhollington is offline   Reply With Quote
Old 22 Mar 2016, 06:23 AM   #12
robn
Master of the @
 
Join Date: May 2012
Location: Melbourne, Australia
Posts: 1,007

Representative of:
Fastmail.fm
Quote:
Originally Posted by jhollington View Post
Well, whatever you did (assuming you did anything), it now seems to be okay as of this morning.
I didn't do anything. All I did was look up your domain record

Quote:
Yesterday wasn't an isolated incident, however — I had noticed the problem a couple of weeks ago, but didn't really have time to deal with it, and shrugged it off at the time since I couldn't see anything wrong with my SPF record and it otherwise checked out fine everywhere else.
If you see it again, please let me know (DM/email/support).

Quote:
I'm assuming that Fastmail doesn't really behave differently whether it detects a valid SPF record or not, as it's up to the receiving server to deal with mail, correct?
Correct.

Quote:
(On the other hand, I would guess DKIM is a different story, since there's no point in signing mail without a valid record, so if Fastmail isn't detecting the DKIM record properly, it won't add the necessary signature on outgoing mail?)
Correct. No signing until the DKIM record is published properly (you'll still get signing with the messagingengine.com key though; everyone gets that).
robn is offline   Reply With Quote
Old 24 Mar 2016, 07:25 AM   #13
jhollington
Essential Contributor
 
Join Date: Apr 2008
Posts: 371
Quote:
Originally Posted by robn View Post
I didn't do anything. All I did was look up your domain record
Odd, unless your lookup poked some cache in such a way that the FastMail back-end suddenly "saw" the record. I've been messing with this technology for over 30 years, and it still seems like magic to me sometimes....

It's still fine on this end, but I'm pretty sure it was consistently not okay prior to this.

Quote:
(you'll still get signing with the messagingengine.com key though; everyone gets that).
Right, I've noticed that before. I'm just curious about the logic behind adding the messagingengine.com signature? I guess the extra signature can't hurt, but I'd think that a DKIM record for the sending domain combined with a proper SPF record for that domain would pass all the necessary validation by most verifying agents? (assuming, as always, that the sending domain's DNS hasn't been compromised, in which case all bets are kind of off anyway ).
jhollington is offline   Reply With Quote
Old 26 Mar 2016, 04:56 AM   #14
ao1
Essential Contributor
 
Join Date: Oct 2003
Posts: 327
FM insists that "SPF is not configured!" even though I have enabled the corresponding TXT record.

What gives?
ao1 is offline   Reply With Quote
Old 26 Mar 2016, 07:25 AM   #15
robn
Master of the @
 
Join Date: May 2012
Location: Melbourne, Australia
Posts: 1,007

Representative of:
Fastmail.fm
Quote:
Originally Posted by ao1 View Post
FM insists that "SPF is not configured!" even though I have enabled the corresponding TXT record.

What gives?
If you tell me the domain I can look it up.
robn is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +9. The time now is 04:33 PM.

 

Copyright EmailDiscussions.com 1998-2022. All Rights Reserved. Privacy Policy