Countless myths abound in the world of email deliverability. That’s why there’s no one better to clear up these common misconceptions than the leading experts in the world of email. Every month, we’ll bring you a Q&A with leaders from inbox providers, spam trap networks, antispam systems, and more in our new Expert Series blog.
In our sixth Expert Series blog, we’re chatting with Alex Brotman. Alex has been working in the Comcast Anti-Abuse & Messaging Policy group since joining the company in 2011 and is currently a senior engineer. This group is responsible for ensuring customers get the messages they want and doing their best to keep undesirable messages out.
I'm not sure I have a primary responsibility. I sometimes define my job as "doing our best to make sure customers get the email they want while keeping the bad stuff out and the platform available."
In reality, my job is some portion of postmaster, developer, engineer, systems admin, analyst, and so on. Juggling all these roles can make for a varied day. It's sometimes interesting to analyze an issue and be able to develop and deploy a resolution in the same day.
I'm also our primary email industry representative for groups like the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) and Internet Engineering Task Force (IETF), and you'll sometimes see me speaking at other conferences. Helping to define best practices or new mechanisms to help secure email is a part of my role that I especially enjoy.
When a customer reaches out, I assume they've reached the end of their ability to resolve their problem by themselves. The demographic isn't important here: the customer just needs help. As such, the goal is to treat the customers with care and kindness, and work as best you can to resolve their issues in a timely fashion.
That said, we do work to create policies or a user experience that work more for our customer demographic.
Obviously, I can't give away the secret sauce, but there are numerous decisions that impact that decision, including internal reputation systems, external data feeds, antispam vendors, and more.
In other words, there’s a matrix of decisions that help us arrive at a verdict. Also, of note, customers can override this in most cases by adding the 5322.From (Friendly) address to their address book via our webmail.
The filtering algorithm ultimately belongs to that vendor, so they would have to comment on that. As for reputation, we don’t currently consider opens as part of the reputation, so the MPP situation isn’t impactful.
Again, without giving away the secret sauce, our reputation systems center around factors largely within the senders’ control, as well as False Negative/False Positive (FN/FP) reports.
To a degree, those FN reports are within the sender’s control, as they can manage lists and be responsive to prior FN reports. Adhering to best practices, monitoring bounce logs/messages, and tracking engagement are all cornerstones for good reputation and successful, timely delivery.
There’s a significant portion of negative feedback that generally impacts filtering, and I don't think that's surprising. Customers make their wishes known via feedback loops, and systems are responsive to that.
Some of this depends on how technical you would like to get. Obviously, M3AAWG publishes a high-volume of documents that are helpful to the community. IETF is also a great resource for learning more about what systems should do.
But those are just a couple. There are a few companies and people out there with stellar blogs as well. Additionally, the Email Geeks community occasionally points to resources.
There could be numerous factors. We don’t currently keep tabs/folders for categories or something like the Focused Inbox. Instead, our users have 2 primary folders: inbox and spam. So that means the messages are more obvious.
If a user gets frustrated and doesn't understand that the best resolution for (legitimate) messages is to unsubscribe from them, they can react in other ways:
There’s no rule here. A few years ago, I proposed a data-driven session at M3AAWG that would have senders look at their data to determine how long a user was unengaged before they started marking messages as spam or unsubscribing. That session didn't happen, but I think the general idea still holds true.
Different types of senders/sectors have different engagement models. For example, right now, your online tax filing company probably gets a ton of engagement, but in October, it may get nearly zero. Should you unsubscribe them after 6 months? Probably not. What about 2 years? Maybe so.
The same model for an auto dealership? How frequently do you expect an individual to buy or lease a car? Then again, the service department may look at different (segmented) metrics.
Brands can be smarter about how frequently and for how long to engage with customers to avoid friction in the relationship. Perhaps the auto dealership can send something as the lease approaches its end. Or if linked with the service department, the auto dealership can see if there have been many recent and expensive service incidents.
What’s the right time? That's what market research can tell the brand—although I'm almost certain that it's not weekly for a year after they've just bought or leased a car.
We only maintain one internal blocklist meant to be remediated by a sender—although we do have some others for egregious cases. Typically, if a sender sees a BL000000 block code, that means the messages were marked as spam (see above about the decision matrix).
If the system places you on this list, the URL that points to our postmaster site (https://postmaster.comcast.net/) is how you can request to be unblocked. Of note, that particular listing will expire automatically after a few weeks.
I'll go ahead and answer a tangential question while I’m at it. We get some questions about the RL00001 and RL00003 mechanisms. The RL00001, which we’ve had for a while, centers on the IP's Sender Score.
On the other hand, the RL00003 centers on internal reputation calculations and is calculated using historical quantity and quality. In most cases, your systems don’t need to suspend delivery for very long. When we derive the calculations, it's on an hourly volume, but that doesn't mean you get the entire hourly volume in the first 5 seconds of the hour.
Now, if you've hit one of the others, or the postmaster page doesn't seem to work, please feel free to reach out to our team (delivery-support@cable.comcast.com). We can take a look. I should also mention that we do have other BL responses, which are maintained by the various external groups, as noted on our postmaster site.
Thanks to Alex! And be sure to stay tuned each month, as we’ll chat with another expert in the world of email marketing to provide you with further insight into the ins and outs of email deliverability.
Until next time, check out Twilio SendGrid’s email deliverability services packages to level up your email program with the help of a deliverability expert.
