Filters evolving

F

I started writing this blog post while sitting on a conference call with a bunch of senders discussing some industry wide problems folks are having with delivery. Of course the issue of Microsoft comes up. A lot of senders are struggling with reaching the inbox there and no one has any real, clear guidance on how to resolve it. And the MS employees who regularly answer questions and help folks have been quiet during this time.

In some ways the current situation with Microsoft reminds me of what most deliverability was like a decade ago. Receivers were consistently making changes and they weren’t interacting with senders. There weren’t FBLs really. There weren’t postmaster pages. The reason knowing someone at an ISP was so important was because there was no other way to get information about blocking.
These days, we have a lot more institutional knowledge in the industry. The ISPs realized it was better to invest in infrastructure so senders could resolve issues without having to know the right person. Thus we ended up with postmaster pages and a proliferation of FBLs and best practices and collaboration between senders and receivers and the whole industry benefited.
It is challenging to attempt to troubleshoot deliverability without the benefit of having a contact inside ISPs. But it is absolutely possible. Many ISP folks have moved on over the years; in many cases due to layoffs or having their positions eliminated. The result is ISPs where there often isn’t anyone to talk to about filters.
The lack of contacts doesn’t mean there’s no one there and working. For instance, in the conference call one person asked if we thought Microsoft was going to fix their systems or if this is the new normal. I think both things are actually true. I think Microsoft is discovering all sorts of interesting things about their mail system code now that it’s under full load. I think they’re addressing issues as they come up and as fast as they can. I also think this is some level of a new normal. These are modern filters that implement the lessons learned over the past 20 years of spam filtering without the corresponding cruft.
Overall, I do think we’re in a period of accelerating filter evolution. Address filtering problems has always been a moving target, but we’ve usually been building on known information. Now, we’re kinda starting over. I don’t have a crystal ball and I don’t know exactly what the future will bring. But I think the world of deliverability is going to get challenging again.
 

About the author

2 comments

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  • What is worrying is the disconnect between the developers working on Microsoft’s spam filter and their support team, who seemingly have no way of communicating any customer concerns to them.
    Our sending is showing markers such as “SCL” being given an irrationally and incorrect high number, and emails that have no problems with any other recipients have problems only at Microsoft/Outlook.
    Additionally, there appears to be no correlation between Microsoft’s SNDS data and their “SCL” figure they are assigning to emails. If “SCL” equals 5 or higher, an email gets puts into the Junk folder, so it is absolutely critical they get that right. Problems started around November 2017.

  • While there has been talk about the O365/”eop” spam filtering technology possibly -merging- with the Hotmail/outlook.com spam filter technology – and perhaps there has been some movement towards that already? – But it is my understanding that these are still technically very different/separate (even if they are headed towards a merger?). So my question is this: Is this article (and the feedback described) referring to the O365/”eop” side? Or to the hotmail.com/outlook.com side? or both?

By laura

Recent Posts

Archives

Follow Us