EmailDiscussions.com - View Single Post

jhollington · 4 Jul 2017, 09:18 AM

What Bill said.

Just to add to that, however, it's worth noting that if you use FastMail as your DNS provider for your own domain, default SPF and DKIM records will be published, although the default SPF record is "neutral" in that it specifies FastMai's servers, but doesn't declare those as the only servers authorized. Therefore, most receiving servers shouldn't get too cranky about receiving e-mail messages from non-FastMail services. Further, FastMail won't automatically publish a DMARC record for your own domain — that's up to you if you want to do so.

Also, just to clarify some of the terminology here...

SPF: Defines which e-mail servers are authorized to send mail for a given domain.
DKIM: Specifies the signature to be used when sending messages from a given domain.
DMARC: Specifies the policy that should be used when looking at SPF and DKIM records*— that is, what to do when a message comes from a server not authorized by SPF, or has a missing or invalid DKIM signature.

SPF records can also assert three levels for the servers listed, ranging from "never accept e-mail from any server not listed here" (-all) to "View anything that doesn't originate from these servers with some suspicion" (~all) to "Here's a list of servers, but I'm not saying these are the only ones" (?all).

DMARC records can range from having a policy of "none" (basically telling the server to generate reports, but take no other action) to "reject" which basically tells the receiving server to refuse to accept any messages that fail SPF or DKIM tests.

For example, here's the SPF record for fastmail.com:

Code:

"v=spf1 include:spf.messagingengine.com ?all"

This lists the servers that are authorized to send mail from "fastmail.com" in a list at spf.messagingengine.com, asserting that while a list has been provided, it's really for reference purposes only.

On the other hand, Google has a record like this for gmail.com:

Code:

"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

In this case, three lists of servers are provided, and the "~all" suggests that any other servers sending mail from gmail.com should be viewed with suspicion — which usually means that messages with a "gmail.com" address that come from other servers, such as FastMail, will be more likely to be classified as spam.

Of course, how receiving mail servers factor in all of these isn't as standard as it should be; some servers still ignore SPF/DMARC records entirely, while others may incorrectly weigh a "neutral" (?all) SPF record more heavily than it should be.

Further, while receiving mail servers are supposed to look at the DMARC record to decide what to do about the SPF and DKIM records, not all yet do this. While very few servers will reject mail based solely on an SPF record, it still often gets factored into spam scores by many systems, regardless of whether a DMARC record is even published or not.

For the most part, most providers at this point would rather err on the side of caution — SPF and DMARC records are generally pretty permissive — but this is slowly changing, so it's better to be prepared for this new reality at the outset rather than being caught by surprise.

4 Jul 2017, 09:18 AM	#544
jhollington Essential Contributor Join Date: Apr 2008 Posts: 371	What Bill said. Just to add to that, however, it's worth noting that if you use FastMail as your DNS provider for your own domain, default SPF and DKIM records will be published, although the default SPF record is "neutral" in that it specifies FastMai's servers, but doesn't declare those as the only servers authorized. Therefore, most receiving servers shouldn't get too cranky about receiving e-mail messages from non-FastMail services. Further, FastMail won't automatically publish a DMARC record for your own domain — that's up to you if you want to do so. Also, just to clarify some of the terminology here... SPF: Defines which e-mail servers are authorized to send mail for a given domain. DKIM: Specifies the signature to be used when sending messages from a given domain. DMARC: Specifies the policy that should be used when looking at SPF and DKIM records— that is, what to do when a message comes from a server not authorized by SPF, or has a missing or invalid DKIM signature. SPF records can also assert three levels for the servers listed, ranging from "never accept e-mail from any server not listed here" (-all) to "View anything that doesn't originate from these servers with some suspicion" (~all) to "Here's a list of servers, but I'm not saying these are the only ones" (?all). DMARC records can range from having a policy of "none" (basically telling the server to generate reports, but take no other action) to "reject" which basically tells the receiving server to refuse to accept any messages that fail SPF or DKIM tests. For example, here's the SPF record for fastmail.com: Code: "v=spf1 include:spf.messagingengine.com ?all" This lists the servers that are authorized to send mail from "fastmail.com" in a list at spf.messagingengine.com, asserting that while a list has been provided, it's really for reference purposes only. On the other hand, Google has a record like this for gmail.com: Code: "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all" In this case, three lists of servers are provided, and the "~all" suggests that any other servers sending mail from gmail.com should be viewed with suspicion — which usually means that messages with a "gmail.com" address that come from other servers, such as FastMail, will be more likely to be classified as spam. Of course, how receiving mail servers factor in all of these isn't as standard as it should be; some servers still ignore SPF/DMARC records entirely, while others may incorrectly weigh a "neutral" (?all) SPF record more heavily than it should be. Further, while receiving mail servers are supposed to look at the DMARC record to decide what to do about the SPF and DKIM records, not all yet do this. While very few servers will reject* mail based solely on an SPF record, it still often gets factored into spam scores by many systems, regardless of whether a DMARC record is even published or not. For the most part, most providers at this point would rather err on the side of caution — SPF and DMARC records are generally pretty permissive — but this is slowly changing, so it's better to be prepared for this new reality at the outset rather than being caught by surprise.