View Single Post
Old 11 Aug 2017, 03:02 AM   #9
jhollington
Essential Contributor
 
Join Date: Apr 2008
Posts: 371
Quote:
Originally Posted by camner View Post
Yikes! I don't think I know what half of these DNS records are for! In looking at my zone record, I see that the only DNS records I have related to email are two MX records pointing to FM and the following TXT SPF record:
Code:
"v=spf1 +a +mx +ip4:129.121.176.191 +ip4:108.165.20.5 +include:relay.mailchannels.net +include:spf.messagingengine.com ~all"
Do you know why you have that SPF record set up the way you do? Right now, you're listing a few other servers as being allowed to send mail for your domain, which is fine if you're sending mail through other SMTP servers, but if you know you're only using FastMail to send mail, you can (and should) simplify that SPF record a bit to take out the two ip4 entries and the first include (relay.mailchannels.net).

On the flip side, if you do have a valid reason to use that SPF record, you'll need to disable FastMail's default SPF record and add that back in manually in your DNS setup at FastMail.

Quote:
Can you elaborate on what setting up a custom TXT SPF record accomplishes? When you say "force outgoing traffic to use FM's SMTP, " what circumstances are you talking about (obviously sending email via the FM web interface will use FM's SMTP, and using an email client will use the SMTP server set up in the config, right?). What kind of custom TXT SPF record accomplishes this?
The default SPF record that FastMail publishes looks like this:

Code:
v=spf1 include:spf.messagingengine.com ?all
The use of the question mark in "?all" at the end of this record tells receiving servers that the SPF record is actually "neutral," which means it really doesn't technically have any effect on receiving servers (or at least it shouldn't), so it technically renders the SPF record meaningless for all practical purposes. FastMail does this because they don't want to make any assumptions on behalf of their customers as to what other SMTP servers you might be using.

A more restrictive SPF record for sending messages through FastMail only would simply replace the "?all" with "-all" resulting in this:

Code:
v=spf1 include:spf.messagingengine.com -all
This change, often used in conjunction with a DMARC policy, tells receiving mail servers that messages from your domain should only come from FastMail's servers (spf.messagingengine.com is actually another SPF record that lists the specific servers used by FastMail to send messages). In this case, if a message originates with a FROM address at your domain name and is delivered by another server, it should be rejected, although this will depend upon how the receiving server implements its spam filtering and other policies, as well as what you've published in your own DMARC record.

To break it down, SPF records designate which servers are allowed to send mail on behalf of your domain, DKIM records contain the key used to "sign" messages from your domain, and DMARC records tell receiving servers what you want them to do if a message from your domain fails to match either the SPF or DKIM records.

Note that you can also use ~all, which is considered a "soft fail" —*again how this is handled depends on the receiving system, but it generally indicates that messages that fail the SPF record are more likely to be categorized as spam (given a slightly higher score), and be reported on, but less likely to be rejected outright.

Quote:
In a general way, what are the advantages of using the various "safety mechanisms" such as DKIM and DMARC for someone like me, who does not send bulk email or other kinds of email that could more easily be seen as spam?
The real issue isn't about whether you're sending bulk e-mail or spam, but more about preventing OTHER people from sending bulk e-mail or spam in your name. Proper SPF/DMARC/DKIM records help to prevent mail with your FROM address from being sent by anybody but you. How this is handled will vary based on how each receiving server looks at the SPF/DMARC records, but it generally ranges from simply a higher probability that such messages will be categorized as spam or otherwise suspect through to telling the other servers to reject such messages entirely as invalid.
jhollington is offline   Reply With Quote