John (00:08): Hello, and welcome to another episode of the Duct Tape Marketing Podcast. This is John Jantsch. My guest today is JT Beckham. He is currently a senior manager of deliverability at ActiveCampaign, leading the deliverability team and collaborating with other teams across the organization. So JT, welcome to the show.

Beckham (00:29): Thanks, John. Pleasure to be here.

John (00:31): Deliverability is a hard word to say actually, but that's what we're going to talk about is email deliverability, and we're going to talk about some technical things. I'm going to lean on JT to not make it too crazy technical, but there's some things that you need to know. Email still the best channel for most marketers today, or at least the best online channel today. So it's important that we get that email into the inboxes. They're obviously, we know all the privacy and spam and issues that a lot of organizations will work on. It has kind of come to a forefront with Google and Yahoo in particular, introducing new email authentication requirements. So JT, and by the way, depending upon when you're listening to those requirements, go in effect February, 2024. So jt, is there a way to summarize what is going into effect in January, 2024 that's important to people that maybe haven't paid attention?

Beckham (01:24): Yes, sir. So there's three main things with email authentication. We want to make sure that DKIM DNS records are defined for any from domain or from email address domain you're going to be using when you send out your emails. The next thing is DMARC . You need to have a basic DMARC record in place. Those are the two key things that have to be done for authentication. And then of course, there's two other parts of the requirements that are coming out. One that you can't [email protected] address unless you're sending email from their platform and you need to watch your spam complaint rates at Google. So those are the three main areas.

John (02:09): Okay. You nailed it. Those are the three main areas. Now, 5% of my listening audience knows what you were talking about. So we need to back up and say, what does all that mean? So when we talk about authentication, I mean, what we're essentially talking about is ways that because people are sending spoof things, we all get 'em all the time. It's like I get an email that's supposedly from me, from somebody out there who's trying to rip me off or something. I mean, so it's really just an effort to make sure that you are who you say you are, especially, and it's really focused on bulk senders, right? People that are sending five, 10,000 person lists, right?

Beckham (02:46): That's been the guidance that has been laid out by Google and Yahoo is the 5,000 limit. However, they have come back and said in other conversations, that's just like a soft number. Their basic guidelines is that if sending a single email to multiple recipients, then you are a bulk sender. And so it's advised that everybody follows through and makes sure that you do what you can to make sure that the mailbox providers and ISPs out there in the world know that this email is from you and that you authorized it to be sent from certain IP addresses. And that when you do dec, IM signing, you are basically adding a digital, an encrypted signature to your emails that if that gets damaged or broken along transit, then it fails to check when the ISPs and mailbox providers look at that and do a lookup on it. And so that would fail your authentication. So like you said, it's really key to make sure that you prove that you are the one sending the email, and that helps your recipients and your contacts that you're trying to reach know for sure that's you, that it didn't get spoofed.

John (03:57): And even if it's not being spoofed, you're not spamming. I mean, you have the ability to send you these records. The setting up of these DNS records are really how you prove that you are who you are. And if you don't prove you are who you are, then it's, it's going to bounce. Right? I mean, that's what's going to start happening. Your mails just won't go through, right?

Beckham (04:17): That's correct. They're going to start out slowly with warning signals, letting people know, or letting ESPs like ourselves know through the bounces coming back, what would happen if they were to flip the switch and enable it. So they say that they're going to slowly roll this out and starting February 1st is when they said, so a lot of interesting times ahead.

John (04:43): Alright, so you mentioned these, and I don't know, don't know if people need to know what these DKIM and DMARC stand for? Probably they don't because everybody just calls 'em DKIM and DMARC. But these are essentially records that are created in your DNS settings. So if your DNS is hosted by Google, that's where you make those changes. If it's hosted by CloudFlare, that's where you make your changes. Some hosts, some actual domain hosts or website hosts, I should say host, DNS. So that's really the first place to go and look. Right?

Beckham (05:13): That's absolutely true. You want to focus

John (05:15): On that? Tell me, if I'm listening to this and I don't really know if I've got these records or if they're set up, are there tools out there that I can take my domain and say, tell me if I need these things fixed?

Beckham (05:28): Yeah, there is. So there's third party tools, like D Martian their website, they have a domain checker tool on their site. There's one called DNS info. The MX Toolbox is a commonly used one that many people use. My team, we use several different ones just to make sure that if one is not reporting something correctly, we always have others that we go and check. Because sometimes these tools do have issues, but most of the time they work very well. And you just define your domain and say, show me the records, and it'll tell you if it sees the DKIM records or any other DNS.

John (06:07): Right? So couple scenarios. Let's say I'm using Google Workspace and it is a Gmail, but I'm using it on my domain. Are there any things I have to do? Because in my DNS records, I'm using Google's MX records for sending, but is there anything that, does Google actually tell me what my DMARC record needs to say, or my domain key needs to say,

Beckham (06:34): If you have a problem that your chem is not there or it's failing at any point in time? One of the tools that Google has is a free tool to everyone is Google Postmaster tools. And that's a tool that we and the deliverability base highly recommend every customer to take advantage of and sign up with their domain. You just define your domain, it will give you a text record that you need to add in to your DNS to authorize their system to be able to use your domain and pull data for it. As they see data coming across their servers will show you more insights on it.

John (07:14): And I love using Google tools because you're basically saying, here's what Google sees. And no matter if you have it all set up and you've hired a consultant to do everything, if Google doesn't see it right, then it doesn't matter, right?

Beckham (07:28): That's right. That's right. That's again, another reason we like to use other tools, and specifically if a mailbox provider has a tool for themselves like Google, we really strongly want you to use

John (07:40): Those tools. Now, let me give you another scenario. I use Google Workspace tools, but that's really more for individual emails than I'm sending out. I happen to be an active campaign customer and we send out bulk emails to people that have opted in to receive those, and other people are using other email service providers. Are there any special things that you should be looking for if you're actually sending most of your bulk mail through a service like ActiveCampaign?

Beckham (08:09): Yeah, so whichever service you're using, DKIM keys. The DKIM records are unique to each service provider and their platform. So you couldn't take and put our DNS or DKIM key that we give. You could put that in there and then send from our platform and they'll sign it. If you try to use that key and send it off of Google or another different solution, the DKIM is not going to work. It's not going to pass. It's specific, like I said, to the mailing infrastructure of the BSP that you're using.

John (08:45): And essentially what it's saying is this email says it's coming from Duct Tape Marketing in my case, but it's actually being sent by this company. And so you're essentially saying, I authorized this company to send on my behalf, essentially what's going on? So in that case, would you potentially have, let's say you're also, I don't know, you're using MailChimp for some other things too, so there's a third player. So would you have DKIMs from all three of those places?

Beckham (09:13): That is correct. Yeah. Any platform that you would be sending from MailChimp into it, whatever it is, they're going to give you the same type of DNS records.

John (09:21): It's basically just a long encrypted code is what it amounts to. Yeah, that's

Beckham (09:26): Right. And it is unique again, to that service provider.

John (09:30): And then underneath, behind the scenes and stuff, that code is actually part of your email. It goes out in the header of your email.

Beckham (09:37): That's correct. So when you look at, if you're looking at your Google Mail and you say view source, then you can see your header information and absolutely see is deam signing or is it passing or failing? And again, I want to stress, you can have multiple dms in here for any platform as long as you've got it for each platform you're actually sending from. That's the key.

John (09:58): And that's actually what you should do is have it for all the platforms you're sending from. Yeah, that's correct.

Beckham (10:03): And you should always make sure you maintain, right? If you change platforms, for example, one of the things you really want to be diligent about is making sure you update these records and remove any platform you're not sending from anymore so that no one could potentially take advantage of that.

John (10:20): Okay. So I think we've unpacked the understanding of what the DKIM record is. That's kind of the encrypted authorization. What does DMARC do? I understand the settings for it. What does it do?

Beckham (10:32): Yeah, so DMARC is another DNS record and it's commonly referred to as a policy. What this basically does is it gives instructions to the mailbox providers or the ips on what to do if your email does not pass authentication. So there's a couple of parameters to it that there's a couple of different ways you can configure it to look at your DKIM key, for example, and enforce it in a strict mode or relaxed mode. This is going to be probably one of the most challenging areas for many people because you're not real sure how to set it up unless you've got DMARC experience and you understand what's going to happen. When you implement A DMARC DNS record, there's usually an email address that's associated and defined in that record. So when you enable or define this record for a domain, every email you go out that goes out and gets processed at every mailbox provider is going to report back what happened. So if you're sending out 500 emails, you're going to get 500 responses or reports into your email address that you specified. So we highly recommend working with a company like DMARC digests to ingest that data. Oh,

John (11:47): So it's sending it to their URI?

Beckham (11:50): Yes. Yeah, exactly. And the users a much more user-friendly way to interpret what's happened and can see very easily who is sending on your behalf using your domain. And if you are failing on DKIM, if it's failing, you'll get a report.

John (12:08): So you'll get reports back that's correct. From those tools that will give you basically a health report on your deliverability. So in addition to that being a requirement, that sounds like a good best practice anyway.

Beckham (12:23): Absolutely. It is like the third step of authentication to help reduce the likelihood of being spoofed, having your email spoofed.

John (12:33): So where does one turn to, and maybe the answer is, well, it depends and that there are multiple places, but where does somebody turn to find out what should be in those records? Because there's syntax and things like all kind of coding things that have to be done. How does somebody get that information?

Beckham (12:52): Yeah, the best site would be DMARC.org. That is the main site that defines what DMARC is, every parameter about it, how it works. It should answer any and all questions you have. However, you may find that you might be better off working with a consultant that specializes in implementing DMARC. I've worked with several companies in the past that are very large with multiple brands under them, their IT team gets involved and things like this. And putting a DMARC record in place in enforcement mode instead of reporting mode can be damaging if you don't do it correctly.

John (13:31): We've had a client that did and all of a sudden nobody was getting email.

Beckham (13:34): Yes, yes, I've seen that happen. Somebody thought that they were doing the record setting the record up for their subdomain that they were using on their from addresses in turn. But what actually happened was they implemented for the root domain and that caused major headaches for a very short period of time until they fixed it.

John (13:52): All right. So if you're still with us listeners, I'm getting ready to confuse you a little deeper. So we've been talking about DMARC and one of the important parts of DMARC is it's going to check the DKIM to see that as part of its reporting. There's a sender policy framework. SPF is another element that's a record in DNS. We haven't talked about that yet, but is that part of these new requirements or is that just a good best practice to have that set up for the right servers?

Beckham (14:18): So great question. It is best practice to have that set up and defined. The SPF record is where you specify the ips of the machines that are allowed to send your mail, right? So most people will see an include colon SPF under google.com or something to that effect. And again, you want to only have one SPF record for a domain. It's not like DKIM keys where you can have multiples. It's one record and you just have to add to it and update it. You

John (14:47): Just depend it

Beckham (14:48): With, yeah, correct. And so DMARC does have an option, a parameter where you can say, look at the SPF record and make sure it passes. You can assess on the DKIM, make sure it passes. You can say both of them have the pass. So it can get complicated when you're trying to implement that. But yes, SPF best practices always make sure you're diligent again on making sure it's updated and doesn't have IPS or platforms defined that you're no longer sending from that way you're making sure nobody's potentially using your phone

John (15:24): Domain. Now, I'm guessing most certainly the bigger name ESPs active campaign certainly has this. I mean, I know when I set up my account, part of the setup was actually setting up these DNS records, and I suspect most people, most of their bulk email is being sent from somebody like an active campaign. Is that you want to talk about a little bit about how you all view that's part of the onboarding, right? As far as you're concerned?

Beckham (15:50): That's correct. We try to work very closely during the onboarding process to ensure that we help you get your accounts set up correctly. We help you check your SPF Your DKIM DMARC policies for you. And so it's critically important that we do this so that you can get started right away. We commonly have in the industry what we call a custom mail server domain, and the custom mail server domain allows you to brand your mail server that is sending the mail on from our platform or any other platform. So you might see an email come into your inbox that says, from John via sent by or sent via, and then some unique name. That doesn't make any sense. And that's where the SPF is checked on your DMARC policy. It's looking at that mail server's name and what that SPF record looks like. So many of the platforms like ours, we actually do this for you. We provide the SPF by default for that weird looking mail server name. That's our name, our domain. We do have the ability to help a customer set up a custom mail server domain and rebrand it. So then now your domain and your subdomains all line up. And so when that SPF check is done through the DMARC policy, it will see, oh, okay, your SPF is there for your subdomain of your mail server that you're using.

John (17:18): Yeah.

Beckham (17:19): And I know sub domains and domains can get a little confusing too. So

John (17:24): Yeah, we'll stick to just domains right. Now, the one other thing that's not a DNS record, but I am understanding it to be highly recommended by at least Google, and that is to have unsubscribe in your header. A lot of for years, people would bury it down at the very bottom, maybe make it even hard to find. It's kind of goofy because then people just hit spam. But talk a little bit about that. I'm not even calling it a requirement. I think they're just suggesting it as a deliverability element and maybe how you guys address that.

Beckham (17:56): Yes, sir. So what they're referring to is one click unsubscribe and it has to be part of your header. We've had that as part of our platform for years, that it is part of making sure your emails are RFC compliant. And so we want to make sure that everyone understands that it's usually already built in, and usually your provider that you're using can tell you pretty easily, yes, we already do it for you, or no, here's how you need to enable it. This is a requirement. It's buried into the other parts of the documents, but they're not calling it out per se other than you just have to make sure you're RFC compliant. And this is

John (18:39): Part of that. So when we talk about it in the header, I mean it is still visible, but it's really, we've all probably seen those where you've wanted unsubscribe to something. It was right there almost in the subject line. And so that's what we're really talking about and it's really, I still get emails from people that don't have an unsubscribe anywhere, which is just amazing. I mean, those people will probably get swatted down pretty quickly, won't they?

Beckham (19:03): So it's a good call out right there. So if you're doing transactional messaging where you asked for a mail be sent to you like password reset kind of thing, then those emails don't have to actually have an unsubscribe in it. It's actually not required. So there are some types of emails you can send that will not be looked at or won't be scrutinized in that manner, but it is still a good practice to put 'em in every communication you send out just to make it so people don't say, this is spam. That's the worst thing we want. We don't want

John (19:37): That to happen. Yeah, absolutely.

Beckham (19:40): Yeah. We make it easy as possible. And some with the unsubscribed, there are some customers and users that would like to have a preference center where you can choose which list you want unsubscribe from that is not filling, fulfilling that requirement. In other words, you can still do it, but you have to have that one click unsubscribed so that you have it at the top

John (20:03): Of email and that unsubscribes from any list, right? Yes. Okay. So let's end this by scaring people. What happens if I just go, ah, that seems really hard. I'm not going to do it. What's going to happen to, let's say by summer if you just ignore this?

Beckham (20:20): So if you ignore it, you are most likely going to start seeing most, if not all of your emails bounce and not be delivered. If you have your DMARC record in place, by chance, you're going to start getting flooded with a lot of failures, but the bounce messages will be very clear that come back to your provider. They can see, we can look at the syn logs and see the messaging and say, yep, you are bouncing because you don't have DKIM and plot implemented. You don't have SPF implemented. You haven't done anything. So you're going to see a major impact, especially Google and Yahoo. But we also know other mailbox writers are going to follow this example.

John (21:03): Well, and I suspect you started having 50% bounce rates, your ESPs or somebody's going to start blacklisting your domain period, right?

Beckham (21:12): That's right. And active campaign, we actually have automated systems in place, so we monitor that across all accounts. And if an account hits a certain threshold on their bounce rates for a particular campaign, we actually have a compliance team that will reach out proactively and say, Hey, by the way, we've observed your bounce rate went a little higher than we were expecting. Let's have a chat and figure out what's going on and see how we can help you recover from that. Because this also has a risk of if you don't do anything damaging your domain reputation, which ultimately hinders your ability to deliver email.

John (21:50): So I guess we could also do a whole nother episode on list hygiene, but I know that's not your area of expertise, but we certainly, when you talk about the bounces, I know we routinely clean those bounces out because they're going to bounce again, and so they're just going to add up. jt, I appreciate you taking a moment to share info. Obviously we didn't tell people exactly how to do this because it is a technical aspect, but hopefully we've given you enough information to go out and buy it done or to talk to your ESP or talk to your IT folks to get this done. So I appreciate you taking a few moments to stop by the Duct Tape Marketing Podcast.