Google Postmaster Tools doesn’t like us. How can I fix it?
Are you struggling with how to improve your sending reputation in Google Postmaster Tools? 250ok's LoriBeth Blair just published a very insightful blog post on this very topic.
Mailkit's BIMI Inspector Tool
Trying to publish a BIMI record? Wondering if you've done it correctly? Mailkit has this cool new tool in beta that will help you check and validate your BIMI record. Check it out!
AOL & Yahoo Mailbox Merger: It’s Done!
Verizon Media (aka Oath, aka Yahoo & AOL) folks report that the merger of the AOL user base into the Yahoo Mail infrastructure is complete! Congrats! I'm sure it was a long, hard road.
The bad way to do this would have been to keep the AOL accounts alive on some old, deprecated server cluster that people will eventually forget about, and some day it would crash and data would be lost. So while it was harder up front to immediately consolidate everyone onto one single platform, I'm definitely sure that in the long term, it's for the best.
The bad way to do this would have been to keep the AOL accounts alive on some old, deprecated server cluster that people will eventually forget about, and some day it would crash and data would be lost. So while it was harder up front to immediately consolidate everyone onto one single platform, I'm definitely sure that in the long term, it's for the best.
When Gmail Was First Announced, People Thought It Was an April Fools' Joke
Gmail just turned 15 years old! Hard to believe that when it was announced on April 1, 2004, some people actually thought it was an April Fools' joke.
And now? Gmail's pretty much in charge of email. Don't count out Microsoft and Verizon (Yahoo), but most B2C senders will tell you that Gmail houses the largest single pool of subscribers that they send messages to.
And here's Google looking forward: Hitting send on the next 15 years of Gmail.
And now? Gmail's pretty much in charge of email. Don't count out Microsoft and Verizon (Yahoo), but most B2C senders will tell you that Gmail houses the largest single pool of subscribers that they send messages to.
And here's Google looking forward: Hitting send on the next 15 years of Gmail.
AMP: The next big thing?
AMP (short for “Accelerated Mobile Pages") is a method to place dynamic content in email messages, announced by Google, now supported in Gmail, and with Verizon (AOL/Yahoo) now announcing support for it. What is it? Should you care? Want to learn more about it? Lifehacker has posted a pretty good overview of it, albeit from a user's perspective. It's worth a read.
How Do I Avoid the Spam Filter?
Savvy deliverability expert Karen Balle answers a common but important question: How do I avoid the spam filter? And follows it up with a spot-on 6-Step Plan to Escape the Spam Folder.
Hello, Verizon Media Postmaster!
Verizon Media (previously known as OATH, previously known as Yahoo, previously known as AOL) has just launched their new Postmaster Site. Check it out!
As announced on their Postmaster Blog by Lead Postmaster Lili Crowley.
I think it's fair to assume that the legacy AOL Postmaster site is likely to shut down at some point in the near future. It brings a tear to my eye, as that site goes back quite a long time. Here it is in 2003, courtesy of the Internet Archive.
As announced on their Postmaster Blog by Lead Postmaster Lili Crowley.
I think it's fair to assume that the legacy AOL Postmaster site is likely to shut down at some point in the near future. It brings a tear to my eye, as that site goes back quite a long time. Here it is in 2003, courtesy of the Internet Archive.
The latest trend at D.C. restaurants? Spam. And it’s delicious.
Sometimes you get tired of working on email spam and just want to go out to dinner. To eat ... spam? Read about spam musubi and more courtesy of the Washington Post.
How to Make Sure Important Emails Stay Out of Your Spam Folder
Today, Gizmodo explains how to train Gmail, Outlook/Windows Mail, and Apple Mail on what shouldn't be considered spam.
They left out filter rules in Gmail -- it's pretty easy to create a filter rule in Gmail where the action is "never send to spam" -- this comes in very handy for me, as a lot of the mailing lists I'm on talk about spam and sometimes include samples. Though they might legitimately be spam, if they go to my Gmail spam folder, it makes it hard to see them.
They left out filter rules in Gmail -- it's pretty easy to create a filter rule in Gmail where the action is "never send to spam" -- this comes in very handy for me, as a lot of the mailing lists I'm on talk about spam and sometimes include samples. Though they might legitimately be spam, if they go to my Gmail spam folder, it makes it hard to see them.
GPT Downtime
Over on the Mailop list (ignore the SSL warning, that is a long-standing issue), people are noting that Google Postmaster Tools has been missing data and/or been glitchy and/or disallowing new domain registrations over the past days. If you had trouble before, you might want to try again now -- a few folks are saying that things seem to be getting better as of today (Wednesday), though it is unclear as to whether or not all missing historical data will be populated.
For more on Google Postmaster Tools, start here.
For more on Google Postmaster Tools, start here.
DMARC Policies Up 250% In 2018
Look at the explosive growth of DMARC implementations! This is great to see.
Read more about it over on dmarc.org.
Gmail SPF Status of Best Guess: What does it mean?
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.
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.
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.
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.
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)