Solving extreme email deliverability mysteries

Anna: 00:00:06 I had never seen where an entirely different message sent from an entirely different environment from an entirely different sender had affected those transactional messages of the original customer. That was a really big mystery for me.

Marek: 00:00:24 Hello and welcome to Talking Email with Postmark. I'm your host, Marek Loder, and in today's episode my guest, Anna Ward, head of deliverability at Postmark, talks to us about how she became an email deliverability expert and then unpacks a few of the most bizarre and extreme deliverability cases that she's encountered throughout her career. By exploring some of the factors that contributed to these catastrophic deliverability events, we hope that you'll come away with some ideas on how to protect and improve email deliverability for your business or side project. Hope you enjoy the episode.

Marek: 00:00:57 Thanks for joining me today, Anna.

Anna: 00:01:00 Hi Marek. I'm very happy to be here for sure.

Marek: 00:01:03 I'd like to start out with some quick intros. Email deliverability is certainly a very niche field and as far as I know, it's not something that you can study in college. I'd love to begin our conversation today discussing your path to becoming an email deliverability expert. Can you tell us how you even got into email deliverability?

Anna: 00:01:25 I think that this is a really interesting point because a lot of people expect someone in email deliverability to have a super technical background. I can absolutely admit that I was born in the middle of nowhere. To this day, I believe, we still don't have internet there. Whenever I go visit my family, there's no internet options except for Verizon. You can get some reception on Verizon through your cell phone but that's it. I got my first email address actually in 2006 and my first laptop in 2007. That was the beginning of my so called technical career or just even knowing that the internet really exists I guess at that point. That was when I started college. I don't know if that's relevant but I still want to put that out there.

Marek: 00:02:16 Where was this strange land where internet was very hard to access?

Anna: 00:02:22 It's kind of southern Georgia, like south of Atlanta. I always say that, "Oh, I'm from Atlanta," but that's not really true. It's just Atlanta is where you went to get culture, I guess. [inaudible 00:02:34] go out for a nice night, you could go to Atlanta, but really it was about an hour and a half drive south of there. Pike County, if anybody out there's from Pike County. Probably not, but it's a very fun little spot. My family owns some land down there and they've been farming it for a long time. That's where I grew up.

Marek: 00:02:56 Tell us a little bit about how you went off the beaten path and explored the technology scene.

Anna: 00:03:02 As most security techie people who are in weird roles, it all happens by accident and mostly because you just can't decide what you want to do or you're just interested in everything. I think that was my problem. I went to three different schools, I had four different majors. I was pharmacy track for a while, I was a mathematics major for three-ish years and I just couldn't decide what I wanted to do. I ended up graduating from Georgia Tech finally, after all these schools, and I was like, "What am I going to do? I don't even know what I want to pursue as a career." My advisor had told me things, "You could try being an actuary," but that sounds 100% boring.

Marek: 00:03:49 Oh yeah.

Anna: 00:03:50 Instead, I decided to just find some place to work in the meantime while I decided on the path for my life. Literally across the street from Georgia Tech was the MailChimp offices. I had heard about MailChimp from some friends who had worked there or had some spouses who worked there and so I applied just for a regular tech support job there, just supporting the MailChimp app across the street from where I was already at. That's how I got started into the email world, so to speak, was as a tech support agent there.

Marek: 00:04:30 Wow, it sounds like a just serendipitous encounter, just MailChimp was right there.

Anna: 00:04:36 I guess so. It wasn't a calling, it was a whisper I guess, but MailChimp was really small back then. I was one of the earlier hires, I think. People used to keep track of that number and I'm not exactly sure, I think I was like the 87th hire ever and people would compare numbers and be like, "Oh, I was 36." I guess I'm small potatoes, but it was super fun, really fun environment. I learned a lot as tech support, supporting an app, I had never done something like that even though at that point having gone to Tech and had taken some coding classes and learning a lot about analytics in general, I felt competent doing that job. It was really fun and challenging for me, so I liked that a lot.

Anna: 00:05:20 That's when I became a tech lead, what they call it back then. I think now they call it advisors. I have some friends who are still really amazing advisors on the MailChimp team but of course now the MailChimp team is way bigger. Back then the job was kind of a liaison between tech support and the developers to do bug fix checks and document releases and in general a little bit of QA testing and then to explain and be an escalation option for when shizz hits the fan or whatever for a customer, to just take over and delve and spend time getting in really complex cases.

Marek: 00:06:02 You basically walked into MailChimp, you weren't familiar with coding or anything of that sort.

Anna: 00:06:08 I had done web site design and stuff just on the side, as a side hustle during school, but mostly my job, I was a librarian. I worked for the Georgia Tech library, I worked for the Mercer Medical Library in Macon, Georgia, and I had spent time as a librarian for six years at that point. I thought I was going to go into library science or something.

Marek: 00:06:33 There you go.

Anna: 00:06:33 I know that's kind of dorky.

Marek: 00:06:34 The Dewey Decimal System.

Anna: 00:06:37 I didn't. I only knew a little bit of Python, always done a little Bash or whatever, and then of course HTML and CSS kind of stuff. That was the only coding experience I really had, just the basics.

Marek: 00:06:55 You start at MailChimp, you get hired on as a technical support representative. What did that look like on the day to day level?

Anna: 00:07:00 Day-to-day, as an agent it was important to do a certain number of tickets. I remember the first time that I hit a solid number and everybody was celebrating me, like, "What, you can answer tickets efficiently!"

Marek: 00:07:16 What was a solid number?

Anna: 00:07:18 70 tickets in a day.

Marek: 00:07:20 Wow.

Anna: 00:07:20 70 [inaudible 00:07:20] or email, whichever it was. You got to be fast typing, fast responses, really upbeat, constantly being able to juggle multiple conversations at once, and back then I was a huge social butterfly so it came really easily. That's kind of funny because I wanted to transition to a tech lead role but one of my issues as I was getting more and more knowledge was they were concerned about my ability to juggle a lot of cases at once. There was an issue where one of my managers, he was talking to me and he'd say like, "You are hitting your numbers, so that's good, but I just want you to know that you are spending more time per ticket than literally anyone else on the team. That, I think, is preventing you from being the exceptional person," people hitting hundreds a day, I would never be that person. I would only be the 70 to 60 a day just because I was spending so much time on each one, talking to them, slowing things down, explaining things, joking.

Marek: 00:08:30 Right. Quality over quantity.

Anna: 00:08:32 Sure, yes, I'll take that. It was definitely like I enjoyed the work, I guess, and so I just never would close a ticket. That was my weakness, I guess.

Marek: 00:08:43 All right, so you weren't burning through as many tickets as maybe some other folks but you did transition into a tech lead role. Tell us about what that transition looked like.

Anna: 00:08:54 As a tech lead, your job is to support support, so you're tech support for tech support essentially. I think that worked out really well because number one, I no longer had a ticket count that I was trying to hit, but what was most important was that I was able to have the time to delve into complex issues which was my favorite thing. I really enjoyed it. It included also thing like API support for the devs who were integrating with MailChimp and so I got to talk to people with more technical backgrounds and I got to work with the MailChimp developers who were developing and building the app. That gave me, again, more technical knowledge.

Anna: 00:09:36 Then from there, I guess one of the complicated questions in cases that kept coming up that none of the other tech leads were interesting in delving into were deliverability questions. During this time, spam filters were getting more and more complex, the emphasis on big data was coming around and so I assume things were just getting more complex. I probably became a little annoying to the existing deliverability team at MailChimp because I was just constantly talking to them about theories and ideas that I had about specific cases and so I got to know them really well and get to know a lot of stuff about delivery that a lot of other people didn't. I just fell into it. It was just something weird and interesting that I felt I was good at.

Marek: 00:10:29 There was, though, it sounds like a bit of a fence between the support team and the deliverability team. Did you make a transition from the support side to the deliverability side while you were at MailChimp?

Anna: 00:10:41 I did. As soon as a post, I guess a job opened on the delivery team, I applied. I got it, probably because they knew my face and that I cared deeply and was passionate or whatever and they were like, "This is probably a safe bet." They were like, "Okay, let's take Anna on," and I became what was called a deliverability engineer. It was all focused on how we're delivering messages, how fast, to whom, are we blocked, how are bounces, are things efficient, are we spam folder, like understanding all of that data and analytics and digging through logs and supporting support, again still because they were the ones coming in with a lot of the issues and observations. I really enjoyed it. It was just targeting something I was already interested in, really.

Marek: 00:11:34 Was there some sort of, I guess, training to help ramp you up on all those somewhat complex topics? Or was this just trial by fire, just learn as these things come in?

Anna: 00:11:45 Trial by fire, that is exactly it, that you just get thrown into the flames and you find out if you are fireproof or not or you, I don't know how you learn this kind of stuff except for just exposure. Like, "Oh, I've seen this before and it was something like this," and so you can get started investigating just based on experience. Then also, the MailChimp deliverability team was really cool. They were very friendly, interesting people. We had a lot of, I guess, swivel chair discussions where somebody would ask a question and everybody would spin their chair around because, you know, the open concept plan.

Marek: 00:12:28 I love that visual.

Anna: 00:12:28 We would all just, yeah, just spinning around, chatting, throwing things out, blowing off steam. It was a really great environment to learn in, I feel like. Everybody there was really supportive.

Marek: 00:12:40 Fast-paced, fun, a great place, it sounds like, to cut your teeth with email deliverability. Tell us, after two solid years on that team, what came next?

Anna: 00:12:52 One of the big things about being on the deliverability team is spreading the deliverability knowledge about what's going on. Me and one of the other engineers there, shout out to Dale Uecker, we made this little, what we called Delivery Camp, which is so cutesy and it made everybody want to join Delivery Camp. Anyone from anywhere in the company could come and sit and spend a week with us in the email deliverability sphere and just see how we did our day to day jobs, help us with investigations and just in general get an insider view to everything that we look at, which included, this took a lot of conversations with the security team but their Delivery Camp experience included access to our servers and user confidential information. There was a lot of insider knowledge that you can see and things that you would never get to see otherwise. Of course we're standing over their shoulder the whole time so nothing crazy could happen but still, it was something that I think made a lot of people really interested in working in deliverability.

Anna: 00:14:05 I'll be honest, that was kind of what we were hoping. We grew the deliverability team using Deliverability Camp because a lot of those campers ended up applying for jobs in the future on the team. We had a huge collection of deliverability engineers and I guess because I was one of the ones who trained them and because I don't mind making very authoritative decisions, I became the lead deliverability engineer there. That was fun, helping grow my own team.

Marek: 00:14:43 Gosh, this program sounds super cool. I imagine it was probably pretty hard to leave such an awesome thing behind. What did you end up doing, I guess, after MailChimp?

Anna: 00:14:53 It was a bittersweet moment when I decided to finally leave MailChimp. I had been there for so long. It was my first home, my first career, professional feeling, but one of the benefits I guess to working on the MailChimp deliverability team is I got to go to conferences, specifically M3AAWG which is a ridiculously long acronym for Mobile Messaging Malware Anti Abuse Working Group, I think is what it stands for. It's really long. It's a huge conference. It's essentially, Anti Abuse Working Group is the important part so everybody who is trying to fight abuse on the internet, in my case specifically email spam, getting together, from the sending side and the receiving side, to try and talk about problems and potential solutions.

Anna: 00:15:47 I got to meet people from literally all over the world, from Gmail to Yahoo to SURBL, Spamhaus, even competitive companies like SendGrid, Constant Contact, Postmark, GetResponse.

Marek: 00:15:59 Oh my gosh.

Anna: 00:16:02 GetResponse was the company that I guess I connected with the most or at first because they had talked to me a little bit and they needed somebody to take over and revamp their deliverability team. I was really interested in that opportunity and I'll say the reason I was really interested too was because their headquarters is in Gdansk, Poland, and I had never been out of the country.

Marek: 00:16:30 Oh wow.

Anna: 00:16:31 I thought this is my chance to get out of Podunk, Georgia, and go visit the world and specifically live somewhere other than the United States. I was young, I was single, I didn't have anything tying me down and so I thought this is the prime opportunity for me to move to Poland on the Baltic Sea, one of the most beautiful and historical cities that I can think of that I've ever been to, just full of history, at just the center of all of the things that have happened in World War II, World War I. I'm kind of a little bit of a history buff too. I got to go there and just live the dream out a little bit.

Marek: 00:17:13 Wow. That is wild. What a cool experience. I just want to before, I mean gosh, we could set up a whole new episode to talk about your Baltic Sea experiences. I just want to touch back on this M3AAWG concept. It sounds like there is just this incredibly tight community of people in the deliverability world from the ISPs and the mail clients to the actual email senders. What a neat thing. Has that been something that has been around for a while? Do you know?

Anna: 00:17:49 That's a really good question. I know that when I first started going, it had been around for a while. I think that it used to be really small and really select, like specific receivers getting together to talk about things. More recently, I think when I was first starting to attend it had been opened up to more people but there were still restrictions, obviously. You don't want a spammer to show up for example and hear all of the secrets. You have to come from a reputable company with a reputable background. You're kind of free vetted and then you get to become a member and that's when you get to attend.

Marek: 00:18:23 It sounds like M3AAWG and members that participate, it sounds like you guys are like the dream team to try and prevent all those crappy spam messages from getting to people's inboxes, yeah?

Anna: 00:18:36 That's definitely the goal, although we're working with the first protocol ever of the internet and so it was built with all of the best intentions in mind.

Marek: 00:18:45 That's SMTP we're talking about, correct?

Anna: 00:18:48 Yeah, just one server talking to another server, right? That's supposed to be an open option. That was what the internet was. If you knew of a server, you could send messages to it, but M3AAWG is all about learning how to police those interactions and how to know when somebody you actually want to talk to is talking to you on the internet or server to server.

Marek: 00:19:14 This is something it seems that always follows us whenever we come up with technologies that are for the greater good. You were at GetResponse, you were hired to help them revamp their deliverability team. You spent a couple years there?

Anna: 00:19:29 I did, yeah, trying to ignite the passion in deliverability and, again, breaking down that fence between deliverability and support and the customers, trying to increase the communication level there. What was interesting there too, I got to learn a little bit about account management too, like big senders, whereas before I was focused on lots of really small users. At GetResponse I got to learn more about what it's like working with a really big sender, like someone who was like, "I'm spending a ton of money to use this platform and I have so many special needs and configurations." I got to learn what those are, what that looks like, master the concept of dedicated IPs too so that was a really interesting learning experience for me.

Marek: 00:20:20 Does it look a lot different with respect to the types of problems or issues or solutions that you're coming up with for those bigger senders than for those smaller senders that you were working with at, let's say, MailChimp?

Anna: 00:20:32 In my view, yes, because at MailChimp you could send a billion messages a day even. I think that was one of the goals that we reached, was a billion messages a day, oh my gosh, but that's small potatoes now. Nobody cares now about the billion. I think they've far exceeded that. Still, that represents millions of different customers' messages and so if you're doing a pretty good job of policing those customers then the reputation overall remains stable. The expectations of how things look over time, you can track it, you can predict it.

Anna: 00:21:17 When I went to GetResponse, now we've got maybe one or two senders sending all of their messages in a very limited environment, a dedicated environment. In that sort of case, reputation can fluctuate really quickly. A mistake happens and you can see that directly happen on the IP, on the domain. There's no buffer zone. If MailChimp, one of the users made a mistake, you have millions of other users to try and buffer that mistake for you, it's not as obvious. If you're in a dedicated environment, it's all on you and it takes a lot of management and paying very close attention to your mail. I guess the customers didn't enjoy it but I really enjoyed working with customers to try and resolve those sorts of issues and figuring out what worked and what didn't work.

Marek: 00:22:12 Interesting. It sounds like the issues themselves were certainly more apparent to you because they weren't obfuscated and spread across so many different little teeny senders.

Anna: 00:22:23 Exactly. You could see exactly how changes and how your messages were sent or changes in their content or changes in domains and stuff, how that affected deliverability directly.

Marek: 00:22:35 Wow, cool. You spent some time at GetResponse, exploring Poland and the Baltic Sea and learning from managing all of these big senders. How did the transition occur to Postmark?

Anna: 00:22:52 After a while in Poland, as you can imagine, I felt a little bit homesick, number one. Number two, I knew that the type of company that I wanted to work for had changed. I was really looking for something smaller, somewhere where I could work closely with the whole team and I had been following Postmark for a while. A lot of the customers at both MailChimp and GetResponse had used Postmark because Postmark was specifically for transactional mail whereas GetResponse and MailChimp focused on bulk. I knew that they were really cool, I knew that they had a beautiful product and when I saw that there was a job opening for a deliverability expert, I started reading more about what Wildbit is, Wildbit as a company, and who worked there and their interests and I explored the Wildbit page and the documents and blog posts and stuff and I just fell for it. I just really loved it, fell for it head over heels.

Marek: 00:23:53 For the sake of time, I'd love to just transition here. I certainly appreciate you giving us that full backstory. It's certainly wonderful to hear how you ended up becoming a deliverability expert, this very small club of people that you're a part of. To get us talking email and to set the stage for our listeners, in preparation for this episode I had asked Anna to think about some of the most bizarre and extreme email deliverability cases that she's encountered throughout her career as a deliverability expert.

Marek: 00:24:27 Part of the reason I had asked Anna to come up with these extreme cases is that as humans, we often learn more from processing negative events than we do from processing positive ones. Instead of talking through the top 10 things that you can do to protect email deliverability, which you can always find in support guides throughout the internet, we figured that it would make more sense to talk through a few instances where things went really wrong with respect to email deliverability and explore some of the factors that contributed to these catastrophic events and discuss some of the strategies that have been and can be employed to prevent them from happening.

Marek: 00:25:07 Anna, you came up with three very distinct email deliverability cases. Do you want to just give us a quick overview of these three cases that you've selected and perhaps tell us why you selected them?

Anna: 00:25:19 I was thinking about this pretty hard, about what I wanted to talk about, and I was thinking about everybody out there has all of those weird deliverability cases that they have described in a little, "Three things that you can do to make a difference, [inaudible 00:25:31]." I was thinking more about things that have shaped my career, things that have shaped my perspective about what email delivery is. Because of that, I picked some rather traumatic events for myself.

Anna: 00:25:47 The first one involved list bombing or subscription bombing, which touches on how mail is used in evil ways. Then also another one is about sending reputation and blacklists. Then I have a third one that explores more fully about why having a high deliverability rate doesn't always mean that your messages are going to get delivered.

Marek: 00:26:09 Awesome. I'm really excited to dive into these. Which of these three cases would you like to start out with, Anna?

Anna: 00:26:17 I am going to start with super scary list bombing. It's also known as mail bombing or subscription bombing but for my purposes, I see them all as pretty much the same thing.

Marek: 00:26:29 Wow. It sounds super scary just in the title or the name of this.

Anna: 00:26:34 Bombs.

Marek: 00:26:36 Do you want to tell us about an instance where this occurred in your career?

Anna: 00:26:41 Yes. It happened really early in my career while I was still at MailChimp. This was something that I guess everyone knew could happen and was happening generally on a small scale but in 2016 towards the end of the year, fall, August, that was when everyone in the world got hit with the hardest, most widespread, pervasive attack of list bombing. It resulted in what was our first, I guess, evidence or observation that it was happening, was a lot of MailChimp's IPs were getting blacklisted by some of the most reputable blacklists in the world, like Spamhaus specifically. You're used to, okay, maybe you'll get a Spamhaus listing once in a blue moon and you'll investigate that and it'll be some specific technique used and you'll correct it, blah, blah, blah.

Anna: 00:27:33 To see a lot of IPs having blacklistings all at once is pretty scary. You're like, "Am I going to get fired or something? What have I done?" No, it turns out that we weren't the only ones seeing a huge uptick in blacklistings. Almost ever ESP was having tons of blacklistings all from the same providers like Spamhaus specifically and we were all pretty freaked out about what it meant.

Marek: 00:27:59 Wow. There are just alarm bells going off, I imagine, in the deliverability squad over at MailChimp.

Anna: 00:28:05 Oh, for sure.

Marek: 00:28:08 All right, so you see this crazy, just spike in, all of a sudden, IPs being blacklisted with reputable blacklist providers. What did you suspect that the issue was at this point? Can you tell us a little bit about where the investigation began?

Anna: 00:28:29 Just so you know all that's happening, I would think that they just hated MailChimp but then when you saw that all of the other people were getting blacklisted too it's like, okay, they don't hate the world, something is happening very specific. You go on to Spamhaus's site just like you always do with a listing and you start your investigation, seeing what examples that they have there. Then of course, especially in this case, reaching out to everyone you know at Spamhaus and trying to figure out what could be going on. What evidence are they seeing or what justified these sorts of listings?

Anna: 00:28:57 That information combined with what other ESPs were seeing, it was pretty clear that there was a recent uptick or attack against, in this case, specific government officials, like dot gov addresses, and some security professionals too. The attack involved some robots, scripts or maybe some individuals and organizations, they were taking the addresses of these government officials and these security pros and putting them into subscription forms all over the internet, like every form they could find essentially.

Marek: 00:29:34 Oh my gosh.

Anna: 00:29:36 Think tens of thousands, hundreds of thousands, who knows how many forms they hit with these addresses really, but that results in, when you fill out a form you expect to get email from that form. Who was sending those emails except for all of the ESPs? Unfortunately, MailChimp and other ESPs became an accomplice in this attack against these important people, effectively rendering their inboxes completely useless, just bombarded with messages from every sender ever.

Marek: 00:30:09 Oh my gosh.

Anna: 00:30:10 It was pretty intense.

Marek: 00:30:12 That's super scary. Is there always generally for, when we talk about list bombing, which sounds like it's basically pointing bots to fill out forms with other people's email addresses, is there typically always some sort of target in these types of attacks?

Anna: 00:30:27 There is, yeah. In this extreme case it was very high profile people. Today, we see it all the time. It can happen to a government official, it could be happening to your mom right now. That's because list bombing is also really effective if, say, "Okay Marek, I've stolen your credit card information and I've been making all kinds of payments with it and I don't want you to know. I don't want you to get your bank alert." A great way to prevent you from knowing that I've done this is to bomb your inbox account with messages so you'll never get those bank alerts and you'll never know that your information has been stolen.

Anna: 00:31:04 It can happen to anyone and it does happen pretty often, but this issue really brought it to the spotlight for a lot of senders.

Marek: 00:31:13 Getting back to this particular incident, how did the team at MailChimp begin to try and resolve this?

Anna: 00:31:20 I guess at the upmost top level we were like, "Okay, we have to get our IPs delisted," but the moral obligation of course is we have to stop mail bombing. It seems almost like an impossible thing to stop but working for MailChimp or an ESP like MailChimp, they are uniquely equipped to battle mail bombing because they also host a lot of their customers' sign up forms or forms in general.

Anna: 00:31:47 At Postmark, we rely on our customers to manage their own forms and to tell us what to send, but at MailChimp they are hosting the forms. They see exactly what's submitted to them, they make the decision on what to send, so they have tons more data about what's going on. They're able to use that data, like what are the addresses that are getting submitted to forms the most? How often are they being submitted? What's the rate, like this many times per hour, this many times per minute? What do those addresses look like? Are they dot gov addresses, for example? Are they from a certain domain? You can also see the sign up IP address and see if that's the same, because if you have the same IP address submitting email addresses across multiple forms, that looks like a bot to me.

Marek: 00:32:33 Right.

Anna: 00:32:34 Then you could also see if locations match up. Let's say that you see a .gov address or a .GA for Georgia address or something, you could say, "Does that domain's location match up with the location that I'm seeing the address submitted for this form," using the IP address. You could use that comparison too.

Anna: 00:32:57 The idea is that once you have this sort of data and you can see what a list bomb looks like in practice, then you can create some sort of logic about preventing sending mail to people when you can detect that they're probably being bombed without someone having to report it to you retroactively.

Marek: 00:33:16 At MailChimp, you mean you guys clearly had an interesting window to be able to see this attack at a high level because you guys were hosting these forms. I'm curious to know on the flip side as a business owner who perhaps has a form hosted with MailChimp, can we just discuss what it would look like to be list bombed and have your form actually used in this type of attack?

Anna: 00:33:40 If you owned a list, and let's say that you don't have some team of data scientists analyzing it for you, the idea is you'd be looking for a sudden increase in the number of subscriptions you're getting. Specifically if that's just like one address or one domain getting submitted a bunch of times. For that, you really need to have historical knowledge of what's normal for you, like, "I'm used to getting 10 subscriptions a day or 20 subscriptions a day." If you suddenly see 100 or 200 and you didn't do anything to promote that, take a look at your list because you may have become an accomplice to a list bomb and you need to get rid of those addresses.

Marek: 00:34:22 I can imagine a day where you get list bombed being a massive emotional rollercoaster where you're thinking, "Oh my gosh, we're crushing it as a business, we got all these new subscribers," and then, yeah.

Anna: 00:34:34 Aw.

Marek: 00:34:35 Look under the hood, uh oh. Oh man.

Anna: 00:34:38 It's definitely not a good feeling. If you have access to IP or location data about that person or those subscriptions, you can also use that. If it's the same IP submitting different addresses, that's probably not a very good sign, so look for those things. Know your subscription rate.

Marek: 00:34:55 All right. Let's go back to this incident. With respect to resolving this but also resolving this more globally, have any mechanisms been in place, put in place to try and reduce the frequency of these types of attacks?

Anna: 00:35:11 A lot of ESPs have built in house systems about how to detect when list bombing is happening, how to block an address that you know is getting list bombed. There was also a proposal that was put forth for a special header. It was called the Form-Sub header with a hyphen in between and some senders and receivers have adopted it but not all. I don't know exactly if it's been used successfully but the idea was that if you're a sender and you know this is the first message that you've sent to an address that was just signed up, so it's your first time sending to some new subscriber, then you can enter the Form-Sub header to essentially say, yes, this was a form subscription response confirmation, first email or whatever. Then also there's an option to include the sign up IP.

Anna: 00:36:07 Those two factors, "This is the first email and this is the sign up IP," it gives receivers two new parameters to filter on. Instead of blocking your IP or blocking your domain, they can block new subscriptions from that IP or they can block just new subscriptions emails or something like that. It's just a way to let receivers be more targeted about what they block while letting legitimate mail go through.

Marek: 00:36:33 Did that really come out of this particular list bombing attack?

Anna: 00:36:38 It did, specifically that stuff.

Marek: 00:36:39 Wow.

Anna: 00:36:40 It was so widespread and such a concerning issue, but this is really the best way that we know so far to communicate what's going on between receiver and sender despite just knowing someone who works there and messaging them, "Hey, remember me from M3AAWG?" This is a much more uniform way to do it that anyone can use.

Marek: 00:37:00 Neat. I take it that many third-party tools to manage forms, I imagine many of them certainly have these mechanisms in place, yeah?

Anna: 00:37:10 Right, a lot of them do, but because it's not that widely adopted, there's still an adoption curve to get through. I think the more people who use it, that can't be a negative thing. It's not a bad thing.

Marek: 00:37:23 Let's say you were a business and you obviously have your own signup forms, is it pretty straightforward to be able to implement this Form-Sub header?

Anna: 00:37:32 It is. All you have to do is just add the header. You don't even have to have any special information except, "This is just the first message I've ever sent this person." That's essentially all you have to know.

Marek: 00:37:43 Cool. Thinking about, I'm Joe the plumber and I own this business and I have my sign up form on my site, at the ground level what are some of the best ways that people can protect themselves from being an accomplice in one of these attacks?

Anna: 00:37:57 I am so glad that you asked this question because it's really, really easy to protect against people using your form for these malicious attacks and that is to use a CAPTCHA. That's that little, "I am not a robot," checkbox or, "Fill in the little letters that you see," anything like that.

Marek: 00:38:15 "Click the pieces of the image that have a car in it," yeah.

Anna: 00:38:18 Yeah, exactly. Sometimes I'm a little bad at those.

Marek: 00:38:20 Me too.

Anna: 00:38:21 Everything else is super user-friendly, especially the checkbox one. I think Google even has one out where it can pretty much detect already based on, I don't know exactly what kind of algorithm it uses but it will only display if it suspects that you might be a robot or a bot crawling the page. There's a lot of ways to make it super user-friendly in a way that does not impact the user experience whatsoever and it protects you from getting blocked eventually and it protects innocent victims from being attacked in these horrible ways. Use a CAPTCHA. There's basically no reason not to.

Marek: 00:38:59 It's that simple.

Anna: 00:39:00 That simple.

Marek: 00:39:02 Oh man.

Anna: 00:39:02 Then of course we mentioned paying attention to your subscription rates, making sure there is no fluctuations there that are unexplained and look like a mail bomb attack potentially. Then also, if you have extra fields in there, you're asking for a name or a comment or something like that, you can try to police those fields too. Make sure that they're being submitted with information that makes sense, number one. Some people even use what's called a honeypot field. That's essentially an invisible empty field that's a part of your form in the underlying code. A human person who's viewing the web page and filling out your form won't see it, won't be able to fill it in. They'll click submit, it will remain empty, but a bot who is trying to submit the form might fill in something in the code for that field. If you see a value entered for that field, you know that only a bot could have submitted it and you can disregard them. Honeypots are pretty effective.

Marek: 00:40:02 What a cool tool.

Anna: 00:40:04 Then something else that I personally think is important for forms is try not to send any automated responses that include submitted content. For example, if you have a comment section on your form, don't send that comment, what the user inputted, in your automated response. Because a lot of bots, not just list bombing bots but spam bots that just want to send spam to random people, will fill in those fields with something like, "Try Viagra free," and then you end up sending, "Try Viagra free," to this person who did not put in their email address there. Never send anything that's automated with the original content that was submitted. You're probably going to get blocked from that too.

Marek: 00:40:52 Awesome. It sounds like the solutions to address this pretty scary problem are actually quite straightforward.

Anna: 00:41:01 Yeah. There's a lot of really, really simple, easy things that almost anyone can implement. Then even if you don't have coding skills, like WordPress or whatever, there's a million plug ins out there where you can add stuff for free that will protect your forms from all kinds of different bots. I always recommend it.

Marek: 00:41:19 Cool. All right, moving forward here. This first case obviously is all about protecting your email list sources. Our next case is all about sending reputation. Anna, do you want to give us a quick overview of this case?

Anna: 00:41:34 Yes. I'm kind of piggybacking off of what happened with the list bombing case, we saw a ton of IPs blacklisted all at once. About a month ago, I saw one of Postmark's shared IPs, that's an IP that a lot of customers are using at once, I saw one of those shared IPs get blacklisted again by Spamhaus. That is super rare and unusual, thank goodness. Spamhaus is probably one of the most well known and reputable blacklists out there and so seeing a shared IP blacklisted by them is a pretty big deal. It indicates something really serious has happened and that was absolutely dumbfounding me. What could have happened here? The investigation was super fun.

Marek: 00:42:20 Just to give the listeners some context. Because we focus on sending these event triggered emails that customers generally expect to receive like password resets, getting caught or stuck on a blacklist like Spamhaus is incredibly rare. Anna?

Anna: 00:42:36 Yes, it is super rare to see one of our shared IPs blacklisted because the types of customers that we have are most like app developers. Our small senders are people who are sending transactional emails, so that's recipient generated, like they've bought something, they've created an account, that sort of thing. The messages themselves tend to be 100% solicited. They are wanted, they are expected even in a certain timeframe and so our IPs in general have really high reputations in the sending and receiving communities. That's something I'm very proud of, of course, but if one of those IPs gets blocked, especially at such a high level, to me that tells me that we've done something profoundly wrong and I had really no evidence of that. That was why this case stuck out to me, about the effects that certain activity can have on a whole environment.

Marek: 00:43:40 Right. Frankly, dealing with blacklists isn't something that I do in my day to day and I'm sure probably some of the folks that are listening are curious. You get stuck on a major blacklist like Spamhaus. What happens? Do they reach out to us? What does that look like?

Anna: 00:43:58 You really have to have some sort of blacklist monitoring in place. At Postmark, obviously, we monitor all of the major blacklists with all of our IPs and we get instant notifications when something is blacklisted. For you that may mean subscribing to a feed if you have a dedicated IP, for example, and just in general running automated checks against known blacklist providers. I recommend things like SURBL, Spamhaus, SORBS can be helpful, things like that.

Marek: 00:44:27 We'll certainly include links to those in the resources section.

Anna: 00:44:29 Thank you very much. For us, when I saw that Spamhaus listing I thought, "I have to go to their site and see, number one, if maybe my check is broken." Number one, we make sure that this is a real listing, but also Spamhaus includes a little bit of information about what messages they saw that were spammy. When I looked at the samples there, again, what Postmark sends are transactional messages so the messages that they included as a sample of spam were account creation confirmations from a specific Postmark customer. I thought to myself that that doesn't seem very spammy, somebody created an account. Wouldn't they want that confirmation, the details of what they submitted, the documentation that they're now in the system? That seems like a purely legitimate message.

Anna: 00:45:21 I even looked up the customer that we had who was called out and we'd never had any issues with them. They'd been a customer for a couple years, so I was really, again, confused as to why this would warrant blocking an entire IP of thousands of users all because of this one account creation confirmation message.

Marek: 00:45:42 Wow.

Anna: 00:45:43 Essentially this customer wasn't a troublemaker that I really felt that I should be concerned about, which means that I really needed more information.

Marek: 00:45:50 Right. At this point I imagine your blood pressure is probably totally elevated. "All of our customers or a large chunk of our customers are being affected by this." The Spamhaus description is really confusing because it's basically saying, "Hey, this message triggered this," but you're looking at that message and it's a totally legitimate transactional email. What next?

Anna: 00:46:16 In this case, I wanted to make sure that everything was normal on Spamhaus's end too. Like maybe this is some sort of strange false positive. I emailed them. They have a little contact option if you have a dispute about a listing and so I used that. I used the proper channels and I said, "Hey, can you please give me more information about this listing because from my end, everything looks normal. It looks fine." That is where things got really strange because the spam message that they had provided as a sample wasn't the original spam that was sent. I'll try to explain that.

Marek: 00:46:56 Yeah, please do.

Anna: 00:46:58 Postmark's customer really was just sending account confirmation messages. That was all they were sending. They really were confirmations when someone real had signed up to their account or signed up to their product.

Marek: 00:47:12 Sure.

Anna: 00:47:13 That was totally, 100% legitimate, so to speak, but Postmark's customer, which shall remain nameless, they had hired an outside firm to advertise their product. That person who was advertising for them used spam to do it. They essentially sent a bunch of spam with ads for this customer's site, which is not okay, obviously. Spamhaus caught on to this pattern, that these spam messages with this advertisement were routing people to our customer's site who was getting sign ups because of the spam message and now was sending out account confirmations. Spamhaus wanted that process to stop and they best way they knew how was to block all of this person's messages, even those legitimate account creation ones coming from Postmark.

Marek: 00:48:12 Wow.

Anna: 00:48:13 Yeah. I've never seen anything like it, honestly, in my career. It was something I even asked some other people in the industry, "Have you seen this before? What do you think I should do?" I feel that the listing, there must have been some really extreme activity happening with that spammer that they had hired, that external person, because Spamhaus was really desperate to put a stop to it. I feel that as much as I hate it, I understand that it was necessary, so we took action.

Marek: 00:48:49 Just to summarize. This is a pretty wild thing. The transactional email that our customer was sending through Postmark got blacklisted which affected then all of our other customers because they were sending on a shared IP because of nefarious sending that was happening on a completely different ESP with just this third party agency that our customer had hired.

Anna: 00:49:11 Exactly.

Marek: 00:49:11 Oh my gosh. That's something that you really have not seen?

Anna: 00:49:15 I have not seen it, no. I've seen sending where the same person is doing the sending, like let's say I send transactional messages through Postmark and I send marketing messages through MailChimp and I do something gross with my marketing messages. I'm used to seeing that affect my transactional on a different ESP because we're all interrelated, can connect the dots sometimes. I had never seen where an entirely different message sent from an entirely different environment from an entirely different sender had affected those transactional messages of the original customer. That was a really big mystery for me. It must have been a serious investigation on Spamhaus's end for sure.

Marek: 00:50:02 They certainly, it sounds like, really connected those dots. It sounds to some extent like had you not been able to reach out to them and have that conversation, you would never have been able to uncover what was going on. I'm just curious, do you have any insight or any sense of how even a blacklist makes those types of connections?

Anna: 00:50:24 I don't. Well I mean I know that the advertisement must have had our customer's domain in it to send them to that web site. Then that same domain would have been used in these transactional messages that Postmark was sending for them. That would be the good connector there.

Marek: 00:50:43 Right.

Anna: 00:50:43 What's interesting is we talk about domain reputation a lot and what creates your domain reputation and where that comes from and we talk a lot about, "Oh, where are you sending email from?" It's not just sending email from a domain that contributes to your reputation, it's also how you're using that domain in content. If you're using that domain in a lot of spammy messages for example, that can affect your domain reputation especially in extreme cases like this.

Marek: 00:51:16 Just for clarity, you can obviously do damage to your domain reputation doing something illicit like this. I'm curious to know, let's say you've done this type of damage to your reputation, what can you do to fix that?

Anna: 00:51:33 For this case, this was an extreme, extreme, extreme case. I cannot stress that enough, this was so extreme, but I think the extremity of it is what makes it so effective, I think, at understanding how domain reputation works. In this case, obviously there was nothing we could do for this customer. They had to be terminated, unfortunately, after a conversation about why. We never just throw people under the bus. We're like, "Listen, we cannot send messages on your behalf, they will literally be blocked and so sorry, you got to find some other solution or work with Spamhaus directly to get this issue resolved," which they agreed to do. I'm very thankful for them taking that forward.

Anna: 00:52:13 For a regular sender who just sees twinges of a reputation shift based on maybe poor choices or even a mistake, we see mistakes happen a lot like, "I sent that message when I wasn't supposed to or I sent it to the entirely wrong people and I got complaints."

Marek: 00:52:31 That's a slip up that could happen on the marketing side of a company, especially a larger company where all of a sudden something goes out the door and it's being sent from that domain but that domain is also tied to the domain that's sending notifications. I imagine that can happen probably more often than not.

Anna: 00:52:47 Exactly, or like your head of marketing says, "Everyone wants to get this message," and turns out nobody really wanted it except for just a handful.

Marek: 00:52:56 "You get a free car and you get a free car."

Anna: 00:52:58 "You get a free car," yeah. The idea is that there's all kinds of ways that the content or the messages from one environment can affect the other. What I always recommend is if I'm sending from Wildbit.com and I have transactional messages to send, I'll use Wildbit.com for those transactional messages because generally speaking they tend to be pretty high engagement and not so scary. Then if I have some marketing messages, maybe I want to send on a subdomain like mail.Wildbit.com or marketing.wildbit.com just so that receivers can see, "Oh, marketing.Wildbit.com, that's for marketing messages." If something is going wrong there, I can feel confident just slowing down or affecting that subdomain and I don't have to do anything aggressive against Wildbit.com. I can just make changes on how I handle marketing.Wildbit.com, for example.

Marek: 00:54:01 It sounds like the subdomain is actually similar to, going back to case one that you walked us through, the list bombing case, having that Form-Sub header is something that allows the receivers to make more informed decisions. The subdomain is empowering those mail clients to say, "Hey, let's actually throttle or slow down these marketing sends but definitely let's leave alone these more critical sends that are happening on the root domain."

Anna: 00:54:29 Exactly. Receivers, they want their customers to be happy too. If someone is complaining to them that they aren't receiving mail, that's frustrating for them. They want people to want to use their inbox with them. If they can more competently block or route messages that people don't want and retain the people or retain the messages that people really, really want, then they're doing their job the best way that they can. You're empowering them to do that, like you said, by creating a more granular separation between your different types of messages so that they can make the best decisions for each of their users.

Marek: 00:55:08 Super cool. It sounds like separating mail streams onto domains, subdomains, and it also sounds like being aware of all of those different sources that are sending email on your behalf are two of the most important things that we touched on here.

Anna: 00:55:23 Exactly. I will also say we've talked about how you use your own domain but it also matters how you use other people's domains, so be careful of who you advertise for. Be careful which third parties you link to in your content because those URLs also have a reputation and it can affect your delivery as well. Pair up with people that you trust and know and don't get too crazy with ads.

Marek: 00:55:48 Do the right thing.

Anna: 00:55:49 Just do the right thing.

Marek: 00:55:49 It's so simple. All right, well I think we did a pretty good job covering that. I'd like to just move into our last case here which explores why having high delivery rate doesn't always mean that messages are making it to the inbox. Do you want to tell us a little bit about this case, Anna?

Anna: 00:56:06 Yes. This one is another one that's relatively recent, the end of February of this year. I started seeing some support tickets coming in here at Postmark and they were all strangely suggesting at the same time that their messages were going to spam in Gmail. Thankfully that's not very common of an issue at Postmark and so seeing a bunch of them coming in at once raised a red flag for me. At the same time I wasn't able to see it in my own tests. Globally as I looked at other users, they weren't seeing the same thing. It was just a bunch of customers being affected by the same thing at once in a very targeted way at Gmail.

Marek: 00:56:55 This sounds like a pretty strange scenario.

Anna: 00:56:58 Yeah, definitely strange. It's sort of widespread, like I had definitely seen a specific customer have issues at Gmail and we can work through that or I've seen, for example earlier talking about a blacklisting. That would have affected everyone's deliverability at once, but this was only affecting specific people all at once. That's what makes this case so unique.

Marek: 00:57:21 These specific people that it was affecting, they were decent senders, yeah?

Anna: 00:57:26 Oh yeah, they were so attentive of their mail, so careful senders. In fact, that's why they noticed it so quickly, was because they care about their engagement rates, they care about their customers, they're expecting responses and suddenly those engagement rates were dropping. The responses they usually get weren't coming in and that made them on their own take a look and reach out to Postmark for assistance.

Marek: 00:57:52 I'm sure that this left you scratching you head, like, "Huh, what could this be about?" Tell us a little bit about how this all unfolded.

Anna: 00:58:01 For about two weeks I was just collecting cases and testing everything that I possible could. My test accounts basically mail bombed them with tests because I was just trying so hard to figure out and replicate exactly what these users were seeing. Unfortunately, it only seemed to affect them and their customers and it wasn't something that I could see happening on my own. All of these tests and all of these things I was asking them to change and test on their side wasn't really making a significant difference and it definitely wasn't explaining why it was happening in the first place.

Marek: 00:58:40 Right, so now what?

Anna: 00:58:42 This is where I've had a little bit of privilege. I was able to, again through M3AAWG conferences and stuff and certain industry-specific communication methods and channels, I was able to reach out to someone at Google who works in the anti-spam department. I said, "Listen, I would never contact you normally about something like this but I really am at the end of my rope and I think that there's something legitimately wrong here." I provided all of the examples that I could. This person was extremely receptive and helpful, agreed with me that they looked like they should not be going to spam, that they should not be getting delayed, that they should not be going missing, agreed that these looked like legitimate mail that people wanted and was accepting all of the examples that I gave to try and mark them as a false positive on Gmail's end, so great, so receptive, so helpful.

Marek: 00:59:39 I just want to pause right there. The fact that you were able to reach out to somebody directly at Gmail, that's certainly a testament to the closeness of people that are in the email ecosystem on the sending and the receiving side of things. It's pretty special.

Anna: 00:59:56 For sure. It is a really special thing. Our marketing teams may be enemies and competitors but I feel like everybody in the anti-abuse, anti-spam world, we have to work together and there has to be an element of trust. That's why meeting face to face is so important. That's why participating and sharing data when you can is so important. It builds trust in the community between individuals, between companies and I think that that's the reason that I was able to speak so candidly and get immediate help from someone at Gmail, is because perhaps we have that rapport. It helps to pick an ESP that is active in the anti-abuse community, because it shows that they care, they're trying to make the internet a better place and hopefully when things do go crazy weird, they can work it out. They aren't just a sitting duck.

Marek: 01:00:53 Your contact over at Google is helping mark some of these emails as false positives. Then what happened?

Anna: 01:01:00 Obviously, manually submitting false positives to an individual is not the solution that you would be looking for and it wasn't what satisfied me either. I kept insisting, "Are you thinking that there's something going on over there? Has something changed? Is there something that I can accommodate for for these going forward? I don't want to have to submit these manually, that seems crazy," and it's always after the fact. Tons of people aren't getting these messages and then after the fact I say, "Oh yeah, in the future don't block these." It's just not a solution.

Marek: 01:01:29 Sure.

Anna: 01:01:31 Obviously Gmail can't share their secret algorithms or what they're looking for or issues that they're having that they're trying to block, so the answers that I was getting back were vague and cryptic feeling. I just retained being polite and everything and waited for more information. Later that month, Gmail made a blog post announcement on their Google Cloud blog and it said from the product manager of Gmail security, it said that they had now started using a product called TensorFlow, which was like a machine learning framework that they had built. It was this new fancy way of doing spam filtering and they had specifically been trying to target more spoofing phishing type of messages lately. Not to say that Postmark was doing any spoofing or phishing but a lot of times it's stuff like password resets and invoices and those transactional messages that are used by phishers to get people's information, obviously.

Anna: 01:02:40 The false positives were hitting transactional mail more than any other mail. It was a really unique case and it pointed out to me, oh, Gmail did make some changes at the exact time that our customers started seeing weird delivery issues and it specifically seems like it would target the kind of messages that they send, like be looking for those messages as potential spoofing phishing attempts, which is crazy.

Anna: 01:03:07 I talked to our Gmail contact a little bit and I said, "Oh, I just saw this blog post. I'm thinking maybe that might be related to the issues that we've been seeing." In general, after a while they had to continue working on it and it resolved itself. That's a kind of happy ending to this, is that we had to wait it out and wait for Gmail to get their new machine learning technology to catch up with all of the false positives that we were able to contribute to to improve this technology and make it work better for their users.

Marek: 01:03:45 It sounds like you actually in some ways helped connect some of those dots for Gmail.

Anna: 01:03:51 Maybe. That would be cool. I would love to put that on my resume but I don't think that that's true. In general, I'm hoping that we helped show that it was more of a widespread issue, that it was maybe affecting more legitimate mail than they thought and correct it. Because it wasn't long after I had stopped sending examples to our contact at Gmail that things started leveling out and improving and going back to normal.

Marek: 01:04:19 I guess the one thing that's particularly troublesome about a case like this is that from the outside, clearly all of these senders that were affected were doing everything right and their deliverability rates were pretty much standard, yet emails weren't actually making it through to the inbox. Have you encountered any other scenarios like this where deliverability appeared to be fairly normal from the outside and yet it really wasn't?

Anna: 01:04:44 Totally. Normally what I see pretty often is maybe a receiver has an issue on their end with accepting mail. Maybe they've done a weird update or if they had some sort of DDOS attack or maybe they had some changes or some big increase or, who knows what's going on on their end. I'll see that resulting in maybe some strange bounces that shouldn't have happened or some weird delays. That definitely isn't uncommon but it's usually really temporary and I can see the cause and I can talk to the recipient and the receiver and I can get some sort of confirmation like, "Yes, there was an issue, yes, we're correcting it. You should see things improved in X amount of time." That sort of process is pretty normal.

Anna: 01:05:37 That sort of communication with me is what I expected, but this was a very unique case where the secrecy around Gmail and how it filters mail and the machine learning that it uses, not only is it important that they keep spammers from knowing this information but because they're using machine learning, there's automatically a built in black box about how it makes decisions. You have to feed it enough cases for it to understand what's good and what's bad and so it just needed more cases for a while, I guess.

Marek: 01:06:10 Sure. As we've covered today, there are often a number of factors that can contribute to deliverability issues, even sometimes when those issues appear to be quite straightforward. Anna, I imagine that by the time most deliverability issues land in your inbox, like some of these cases that we've just discussed, the issue's pretty significant or very obscure. Can you just talk to us about your approach to solving deliverability issues?

Anna: 01:06:35 I think a lot of maybe receivers or deliverability professionals nowadays, we're so used to putting it all on the sender as they've done something wrong. There's the sender made some sort of mistake or did something malicious. Then from the sender's perspective it's like, "Oh, my ESP has messed up, it's my ESP that's bad." Based on cases like this, I think it's really important that in all of my investigations I approach and consider the possibility that maybe it's not the sender and maybe it's not the ESP but there's an issue on the receiver's end. I think that's often overlooked and it's a big part of my investigations going forward.

Marek: 01:07:18 Cool. Certainly one of the things that's become apparent in our conversation is that there's a tremendous amount of collaboration between you and a lot of the contacts that you have throughout the industry. My guess is that many of our listeners don't have the luxury of having an in house deliverability expert like you. Obviously having you on this podcast presents us with a unique opportunity for you to be able to speak directly to those individuals who may be tasked with sending email reliably on behalf of their company. I guess as we wrap this up, do you have any high level recommendations to help our listeners improve or protect their email deliverability?

Anna: 01:07:57 Yes, I do. High level stuff, I think the quickest way and the easiest way to protect your deliverability, I believe, is to separate your message types, your message streams, so to speak, transactional, bulk. I even like to think of it as like your sending source, so is it an automated form that's sending your message? Give it its own subdomain. Is it a marketing team that's sending the message? Give it its own subdomain. Is it for a specific purpose like, say, a terms of service change or a weird alert on an account or something that's automated and security related? Then that might need its own subdomain as well. The more that you can identify those different purposes and message types and separate them using subdomains, the easier it's going to be for the receiver to filter and route them appropriately. If you do end up making a mistake, it doesn't affect those things that are most vital to your business.

Anna: 01:09:05 I will also mention too the idea that a lot of people believe that you need a dedicated IP in order to get good deliverability. In my view, that is just isolating yourself. That is making all of the sending reputation, all of the routing decisions based on you alone and you lose that ability to have the reputations of other good senders to buffer your mistakes, your bad choices maybe. In my view, a high reputation shared IP pool is always going to outperform a dedicated IP. It's just how I feel of my experience.

Anna: 01:09:45 Of course, there are some cases where someone can be extremely attentive of their mail and they have extremely high volume or they have specific sending configurations that they need and sure, a dedicated IP might be more appropriate in those cases. In the long run for most people, a shared IP pool on a reputable ESP is the way to go. I don't think enough people consider that or feel that way. Maybe they've been burned too many times by another ESP, I don't know, but with Postmark I try and emphasize that, that they'll probably do better using our shared IP pool.

Anna: 01:10:20 Thirdly, I want to mention, yes, I try to be approachable and you can email me any time and ask me your deliverability questions and I will do my very best to answer them and investigate them for you, but you don't always need an expert. There's a lot of tools out there that can give you a lot of the information about how you're performing as a sender. The one that I talk about the most because most people send a lot to Gmail is to use Google Postmaster tools. Postmaster.Google.com. All you have to do is just register the domain that you send from, typically your DKIM domain or your Return-Path envelope sender domain, which often matches your from domain. Just register that and as long as you have enough volume to obfuscate the data, anonymize it, then Google will tell you directly what your domain reputation is, what your IP reputation is, let you know about spam complaints. It's just a really useful tool to see if there's anything out of the ordinary.

Anna: 01:11:24 There's also some things like TalosIntelligence.com. I believe that they will show you a little bit about your domain reputation and data. The same thing with ReputationAuthority.org. If you send to Russian domains like mail.ru and Yandex.ru, they also have their own postmaster tools that you can subscribe to that give you some Google Postmaster tools like data.

Anna: 01:11:50 Beyond that, of course there's also DMARC. If you haven't thought about implementing a DMARC record, you might want to. I usually recommend people have a none policy to start with. That means take no action yet, just send me reporting data. Participating receivers will let you know, number one, your sources of mail, and number two, whether they passed certain authentication methods. It's an easy way to get some information direct from receivers as if you had some sort of insider knowledge. You can get from them directly exactly how you're performing and where your mail's coming from so you can get ahead of any issues there.

Marek: 01:12:30 Awesome. We'll be sure to include links to all of those things that Anna mentioned in the resources section of this episode. With that, Anna, we're ready to wrap this up. I want to just thank you so, so much for taking the time to be with me today.

Anna: 01:12:43 Thank you for having me. This was really fun, actually. It's a great break from my normal workday.

Marek: 01:12:49 To our listeners, thank you for joining us today for this episode of Talking Email with Postmark. If you enjoyed the episode, please leave us a review on iTunes and subscribe to receive updates on all future episodes. As always, be sure to check out the resources section for this episode where you'll find helpful email deliverability articles and tools. Lastly, if you're ever looking for help improving email deliverability for your app, be sure to reach out to us at support@Postmarkapp.com and we'd be more than happy to help.