If, like me, you use Gmail to test and check email authentication results, then you're used to seeing SPF results that say pass or fail. But what does it mean when it says "best guess"?
Here's an example of a Gmail SPF results header that mentions "best guess":
Received-SPF: pass (google.com: best guess record for domain of bounce31@b.email.example.com designates 1.2.3.4 as permitted sender)
What this means is that Google's "faking it" -- they are synthesizing a potential SPF record based on what information they can figure out about the domain. The exact rules that go into the synthesized SPF record are unclear. It could be past email history. It could be that reverse DNS between the sending IP address and sending domain match. Or it could be other things. That's not the important bit. The important bit is this: When Gmail tells you "best guess," it means it can't find your SPF record in DNS. That's a problem, and one you should investigate immediately.
In the example above, Gmail is saying that it can't find an SPF record for "b.email.example.com." Google's systems are smart enough to deal with it, so your deliverability to Gmail subscribers is unaffected. But other ISPs do not all have similar "fake an SPF record" functionality. That means that some other ISPs probably will block this same mail due to DNS failures or lack of DNS entries. If you review all your bounces, you'll probably see that this is the case.
And it can be a difficult issue to troubleshoot, if you see those bounces, then test with Gmail, and Gmail says that SPF passes. There's little to indicate that something is wrong, except for that magic phrase "best guess." Keep an eye out for it and know that it's a strong indicator of a potential DNS issue with your sending domain.
Al Iverson’s Spam Resource
EMAIL, SPAM PREVENTION & DELIVERABILITY • SINCE 2001
Gmail: Improving spam filtering with TensorFlow
Google just announced today how they've improved spam filtering using TensorFlow.
What's TensorFlow, you might ask? "An open-source machine learning (ML) framework developed at Google. These new protections complement existing ML and rules-based protections, and they’ve successfully improved our detection capabilities. With TensorFlow, we are now blocking around 100 million additional spam messages every day."
That's a lot of newly blocked email messages. Does it affect you, dear sender? Hopefully not, because Google says that they're "now blocking spam categories that used to be very hard to detect," including "image-based messages, emails with hidden embedded content, and messages from newly created domains that try to hide a low volume of spammy messages within legitimate traffic."
This doesn't mean suddenly it is unsafe to send image-heavy emails to your Gmail subscriber base. Google's not about to intentionally start blocking legitimate mail that people actually signed up for. But it does highlight that the closer you get to the edge of best practices -- if you have any practice failings in different areas, you could end up overlapping with one or more of these categories. If so, your messages might actually merit blocking. I'm guessing the chances that it affects a "legitimate" sender are pretty slim, though. But, just a reminder -- "Don't be like Goofus," as the old Goofus and Gallant stores in Highlights for Children used to tell us.
Spammers often do things like rotate through newly purchased domains, embed content in unique ways to try to evade filters, and use images to hide messaging from machine filter review. Don't do these things, and I think you'll probably be just fine.
What's TensorFlow, you might ask? "An open-source machine learning (ML) framework developed at Google. These new protections complement existing ML and rules-based protections, and they’ve successfully improved our detection capabilities. With TensorFlow, we are now blocking around 100 million additional spam messages every day."
That's a lot of newly blocked email messages. Does it affect you, dear sender? Hopefully not, because Google says that they're "now blocking spam categories that used to be very hard to detect," including "image-based messages, emails with hidden embedded content, and messages from newly created domains that try to hide a low volume of spammy messages within legitimate traffic."
This doesn't mean suddenly it is unsafe to send image-heavy emails to your Gmail subscriber base. Google's not about to intentionally start blocking legitimate mail that people actually signed up for. But it does highlight that the closer you get to the edge of best practices -- if you have any practice failings in different areas, you could end up overlapping with one or more of these categories. If so, your messages might actually merit blocking. I'm guessing the chances that it affects a "legitimate" sender are pretty slim, though. But, just a reminder -- "Don't be like Goofus," as the old Goofus and Gallant stores in Highlights for Children used to tell us.
Spammers often do things like rotate through newly purchased domains, embed content in unique ways to try to evade filters, and use images to hide messaging from machine filter review. Don't do these things, and I think you'll probably be just fine.
Topics:
gmail,
google,
isps,
machine learning,
spam filtering,
tensorflow
2018: Did I get it right?
Just over a year ago I predicted that 2018 would be a year full of mailbox provider consolidation, many folks implementing DMARC, and ISP filtering getting more tougher than ever. Was I right? It sure sounds a lot like what I worked on much of the time last year.
Is it too glib to say 2019: More of the same? Because that's my first thought. Provider filters continue to get tighter, DMARC is bigger than ever, and AOL and Yahoo are not quite done merging. I suspect BIMI will grow in 2019, but I feel like we're two or three years out before somebody can declare that 20xx is the "year of BIMI."
I know I'll be focusing more on international (non-US) deliverability this year, but it's hard to say if that's just me, that might not be an "industry" thing.
What do you foresee for challenges and likely focus areas for email and deliverability in 2019?
Is it too glib to say 2019: More of the same? Because that's my first thought. Provider filters continue to get tighter, DMARC is bigger than ever, and AOL and Yahoo are not quite done merging. I suspect BIMI will grow in 2019, but I feel like we're two or three years out before somebody can declare that 20xx is the "year of BIMI."
I know I'll be focusing more on international (non-US) deliverability this year, but it's hard to say if that's just me, that might not be an "industry" thing.
What do you foresee for challenges and likely focus areas for email and deliverability in 2019?
Fun while it lasted...
Remember back in September when I blogged about how to create a Google+ account to make your brand icon display next to your emails when sending to Gmail users?
Well, looks like that won't work after a certain point, as Google is shutting down Google+ and will be deleting Google+ accounts and content.
I got a notice this morning that says my various Google+ accounts (used for logo display for various email sender tests I've set up) will be shut down on April 2, 2019.
It was fun while it lasted.
I wonder if this means Google will get on board with the BIMI logo display standard? Or there will be some other way to do this? We shall see.
Well, looks like that won't work after a certain point, as Google is shutting down Google+ and will be deleting Google+ accounts and content.
I got a notice this morning that says my various Google+ accounts (used for logo display for various email sender tests I've set up) will be shut down on April 2, 2019.
It was fun while it lasted.
I wonder if this means Google will get on board with the BIMI logo display standard? Or there will be some other way to do this? We shall see.
Topics:
brand image,
google,
google plus,
gravatar,
shutdown
Stop using NJABL! Now!
I just replied to an email from a guy who thinks I'm blocking his mail. I'm not, because I don't run a blacklist or a spam filter, and haven't done so for years. I would have loved to have helped guide him in the right direction, but my reply to him bounced because his mail server is misconfigured to use the NJABL blacklist.
The NJABL blacklist has been dead for almost five years.
If you still have it in your email server configuration, you're now going to block a lot of wanted mail. Because the domain's name servers just changed and they have a wildcard entry that now has the effect of "blacklisting the world."
You were warned...almost five years ago.
The NJABL blacklist has been dead for almost five years.
If you still have it in your email server configuration, you're now going to block a lot of wanted mail. Because the domain's name servers just changed and they have a wildcard entry that now has the effect of "blacklisting the world."
You were warned...almost five years ago.
Characters in the local part of an email address
Need a "common sense" breakdown showing you what characters should be allowed in the username part (local part) of an email address? This handy guide from Jochen Topf covers exactly that.
It doesn't EXACTLY align with RFCs, but when you look at it from a common sense perspective, I agree with his categorization of each character. This would be a good thing to reference if you were building your own email capture form. (I'd probably also reject the "maybes" for an email capture form, but not reject them in an MTA configuration. Some of the "maybes" show up in bounce addresses somewhat regularly, but are almost never found in legitimate end user email addresses.)
It doesn't EXACTLY align with RFCs, but when you look at it from a common sense perspective, I agree with his categorization of each character. This would be a good thing to reference if you were building your own email capture form. (I'd probably also reject the "maybes" for an email capture form, but not reject them in an MTA configuration. Some of the "maybes" show up in bounce addresses somewhat regularly, but are almost never found in legitimate end user email addresses.)
Subscribe to:
Posts (Atom)