Quote:
Originally Posted by digp
I think v=spf1 include:spf.messagingengine.com -all is the solution Really this should be the FM default
|
Sorry that this post is so long!
That's what I have done for my domain. But if that was the Fastmail default, persons setting up new DNS hosting at Fastmail would find they could no longer send from other SMTP servers as they might have done before. And anyone you send to who forwards their email to another account for reading might not receive any of your messages (unless you set up
DMARC for your domain), since
SPF normally breaks email forwarding and only DMARC DKIM can be used on forwarded email.
So Fastmail requires you to disable the default SPF record contents and add your own custom SPF record so you don't accidentally block messages you send. The default SPF record for your domain is set to:
Code:
v=spf1 include:spf.messagingengine.com ?all
which currently expands to:
v=spf1 ip4:66.111.4.0/24 ip4:107.150.24.0/24 ?all
The default qualifier is "pass" or +. So the default SPF entry current used (which could change if Fastmail moves there server IP) means:
- Messages sent from SMTP addresses 66.111.4.0 through 66.111.4.24 (Fastmail) are allowed.
- Messages sent from SMTP addresses 107.150.24.0 through 107.150.24.24 (Fastmail) are allowed.
- Messages sent from any other SMTP address are classified as "neutral".
- This setup allows messages sent from Fastmail but does not block any other SMTP server, since Fastmail has no idea what other servers you might use to send your domain email. You should add any SMTP IP addresses you also use and change the ending tag to -all to block others. You can use the provided default SPF record as a template. So your final SPF record might be:
Code:
=spf1 include:spf.messagingengine.com +xxx.xxx.xx.xx -all
- Please consider that SPF only checks the envelope-From address. It does not check that the header From (which is what the recipient sees). DMARC is an attempt to cause alignment between the envelope-From, header From, SPF specification of allowed sending SMTP servers, and DKIM cryptologic signing for your domain by the sending email system.
- So (back to your original post), SPF will not cause the recipient server to reject a message based on the header From address. SPF usually won't cause rejection based on the envelope-From. Since SPF usually breaks email forwarding, rejecting SPF failures would usually not allow anyone automatically forwarding your message to another of their accounts for reading email to see your messages.
- DMARC only rejects a message if both SPF and DKIM fail, and it forces the From header to be aligned (the same) as the envelope-From address, the SPF DNS record domain, and the DKIM encrypted signature for your domain. So DMARC does what you are asking for, not just SPF.
- Before activating a reject (-all) SPF policy and reject DMARC policy, I recommend that you try using the default SPF and a quarantine DMARC policy similar to the following:
Code:
v=DMARC1; p=quarantine; rua=mailto:postmaster@example.com; ruf=mailto:postmaster@example.com
This will send DMARC reports (in XML format) to your postmaster address (which should be inserted in place of postmaster@example.com). You can look at these reports and see if messages are passing or failing SPF and DKIM at recipient servers before you implement a reject policy. I get these delivered from several major email providers (Fastmail, Yahoo, Google/Gmail, Microsoft/Hotmail/Outlook.com, AOL.com). You can perform a web search for "DMARC reports" to discover more about these optional reports.
As you can see, proper SPF and DMARC implementation for your domain is not easy. You must be very careful which servers you use to send email from your domain (including automatic messages which use your domain) and you should use DMARC if possible. Forwarding and some email discussion groups are not fully compatible with SPF (as used with address alignment by DMARC).
Bill