DMARC Updates Every Email Sender Needs to Know

Foreign. Welcome to Email After Hours by SenderScore. Powered by validity. We're your hosts. My name is Guy Hanson. And I'm Danielle Gallant and this is Email After Hours. Email authentication underpins the trusted relationship between senders and subscribers. It proves emails genuinely came from the domains they claim to represent, protecting recipients from spoofing, protecting senders reputations. So when dmarc that part of authentication that tells the receiving servers what to do when emails fail, authentication announces major updates. Email marketers need to pay attention. And that's what we're talking about today. Regular listeners will notice that Danielle isn't with us. She's on show duty this week. Instead, we're joined by Tom Bartel, SVP of Data Services here at Validity. Tom's day to day focus is making sure that we have the right data for all our products and services. It means working closely with senders, email service providers, email security partners, and of course, the major mailbox providers. So he's very well positioned to provide some commentary on the DMARC changes we're talking about today. Tom, welcome to the show. It feels like forever since you last joined us on Email After Hours. I know, I'm excited to be here and yeah, I think I've caught most of the episodes in between. You know, you guys do a great job covering the full landscape and I'm, I'm excited to be back. Yeah. We love all of your LinkedIn comments, so keep them coming. Before we jump into today's conversation, we normally kick off with a quick icebreaker, and I think today's icebreaker, we can actually use it to frame the conversation we're going to have. But outside of validity, you've recently been appointed as chair of Morgue's Board of Directors. So for listeners who maybe aren't familiar with this organization, can you provide us with a very quick overview of what MORG does and what your new role entails? Oh, yeah, of course. Yeah. So MOG is M3AAWG. Right. So messaging, malware, and mobile. It is abuse or Anti Abuse Working Group. Right. And so we, we love, we love saying mog. My favorite letters. This is a phrase I like to drop because I, I truly believe it. My favorite letters in MOG are the wg. And that's because we're a working group. And I think this is what has given the organization its unique place in the ecosystem. You know that we recently redid the, the vision and mission at MOG in the past sort of two years. And that is our vision. A world free of online abuse. And so obviously the anti abuse in the name speaks to that directly. You know, what makes MOG special, I think, is the mission is to be this global trusted forum and that is driving collaboration towards that end. And so what you see from the organization in terms of outputs and our work product, our best common practice documents that would cover things like dmarc, technical summaries, which would cover things like DMARC and authentication. And we, and we also spend a lot of time responding to policy issues and, you know, in the broader Internet community, government organizations. And so thanks for mentioning. For me, it's, you know, we've been a part of MOG for over 20 years and MOG's now in its third decade and it's, it's beyond humbling and something I take great pride in and a great honor to work alongside the members in this organization, the sitting board, the staff, of course, the great support that validity has put into the organization over all this time. So, anyway, I'm excited to talk about technologies today, and MOG is definitely an entity that is supportive of these things in our email ecosystem. That's awesome. And I think we'll touch on that a few times in the conversation we're going to have today. But let's start with a quick recap. I feel like most email marketers have probably at least heard of dmarc. I suspect fewer of them might actually be able to explain what it actually is or how it works. So perhaps in layman's terms, can we spend a couple of minutes just answering those questions? I mean, dmarc, we love our acronyms, right, in email messaging. And most folks probably know DMARC is Domain Based Message Authentication, Reporting and Conformance. Dmarc. Okay. And it's of course what we would call an email security protocol. And I think of it as, I like to think of it as there's really a triune component here. And DMARC I think is the connector in email authentication. Right. So of course you have SPF and dkim, you know, which I would talk about the authentication methods. You know, these are the things that identify your sending infrastructure, you know, sort of protect your, your message and transport. And DMARC is sort of what ties it together. And DMARC is really your public policy statement, right? And it's what informs mail receivers on how to handle messages then that fail authentication. And something that became a learning across all these years of implementation and getting DMARC and getting authentication up to scale is that mailbox providers needed to have confidence to act on failing mail to better protect their users. Even when an obvious message stream spoofing traffic shows up spoofed in a name brand, you're still questioning, you know, what if this is actually real? Right. So that's kind of the problem that DMARC stepped in to solve. Absolutely. And it's not like it's something brand new. DMARC was originally introduced all the way back in 2015. So I guess the next question is why has it taken so long to make these changes and why did we get to a point where they needed to be made? When you say something like that, like why did this take so long in so long time, 2015 to 2026. But I like to say that I actually think that is success and not delay. And it's because this is how it works. The email community saw a concept with real potential and said, let's give this a go. Because of smtp, because of what's great about smtp, it's an open standard and that's got two sides to it, right? It's what makes it open to abuse and therefore we have to manage those issues. But it's also what makes it so useful to us. Right? Email is what they would call historically a killer app of the Internet. And it's precisely because of its open nature. And that's why it's so widespread and deeply entrenched. You can never rip and replace smtp. Right? And so what ends up happening is we find these gaps and we have to do add on solutions like dmarc. And because it's so widespread and deeply entrenched, the implementation of that has to be carefully thought through, experimented with, validated through proof of concept. And so that's really what's happened here, right? And over all that time is that iterative feedback of usage to sort of get, get things from functional to optimized. So if we can digress for just a moment, I'm sure there's at least some in our audience that might be interested in how something like a DMARC update actually gets developed. So how does it get developed? And who are the people behind the scenes that were instrumental in bringing the changes we're talking about today to reality? You know, it's an IETF standard, right? And that organization is, you know, about, it's a rigorous, technical, formal, structured body. You know, their role is to develop and ratify these exact standards, you know, to support, you know, what I would call, you know, you think about it, our critical infrastructure technology components that are, that are embedded throughout our global systems. So that's their specialty. You know, when I talk about MOG operating on a different wavelength. Right. MOG I think of as like a collaborative operational think tank. And for sure there's some member overlap between an Iet at DMARC Working group and mog. We collaborate on those processes through overlap in members. And obviously there's a lot of other contributors to the process, individuals and organizations and so forth, mentioning those two that have contributed to that work and to any RFCs. But I think it's this, you know, interesting dynamic of getting draft protocols into production, providing iterative feedback, and participating in effectively the proof of concept testing and validation in market. You know, that's the, that's the community effort. And so, you know, what's, what's happened now is, you know, bringing that back in terms of the tunings to where it started, the ietf, and get the formal standards work done. And so we end up with these nice, new, tidy, updated, crisp RFCs. Awesome. And for any of our listeners who already feel like you're drowning in acronym SOUQ today, IETF is the Internet Engineering Task Force. You heard it here. So we talked about what brought us to the point where DMARC needed updating. Can we touch a little bit on the specific elements that have now been addressed by the updates? Sure, yeah. So I think, you know, one layer was sort of organizational. I think folks will notice there's now three RFCs, and that was just splitting them, I guess, more functionally, you know, the protocol itself and then. And then two additional RFCs around the reporting components. You know, once somebody is deployed and is using dmarc, both reporting affecting obviously both senders and receivers in a different sort of coordination of information exchange. So those are now nicely split for clear understanding of how to implement, how to comply, et cetera. Specifically for email senders that might be thinking about what do they need to change, getting a little bit more technical, what aspects do they need to be aware of in terms of what's been introduced via the new DMARC updates for senders? I mean, I think a lot of it is interesting for senders. And by the way, I always encourage senders to know the technical nitty gritty, even though they're separated by, on the screen by their workflow interface, however they're implementing their message sending, I think it's important to understand the gears and the wheels and the machine. And these are not long documents. Right. So I would, I would encourage our senders to go read them because in particular, to your point, these things that are, that are different and new are pretty clear and pretty sensible. And it's just, I think it's just good information to have an understanding of in the back, in the back of your head. So there's been cleanup of like removal of tags were basically not being utilized or deprecated by a new, a new function. I think for senders what jumps out for me there's a new NP tag which talks about non existent subdomains. And this is great, this is I think actually shows when we talk about that timeline guy of how long it sort of took to get here. You have to observe it in the wild. And this is a malicious practice that we see in other vectors that then got applied the same sort of security gap. So in the old spec there was this SP tag that covered your subdomain so you could indicate your policy for your authoritative domain and then separately or similarly for your subdomains. Well, guess what, fraudsters, they like to exploit the idea of like a phantom subdomain, right? That they can make up anything that doesn't exist your domain and that you're effectively setting a loose policy for those things or no policy. And so something like that is a hole that's being closed. And so as a sender, if you have that open in your policy, go close it. So that's, you know, that's first what comes to mind. There's also some other new tags which maybe we can touch on briefly. There is the PSD tag which indicates where the public suffix domain should be used or not as part of the DNS lookup. Can you expand on that for us a little bit? Yeah, this one again, and this one's fascinating. I think this is one of those things that maybe your regular, every inner everyday Internet user doesn't think about. But when you start to deal with domains technically for processing on any level, sort of semantically or just as streams, you realize that at some point when you go to determine what you would call maybe the top level domain, the.org, the.com, the.net that becomes programmatically when you realize that some top level domains are actually delimited, right? So there's.com and.org and.net, like I mentioned. But there's also guy4u co uk. Yes, right. And so it becomes, it becomes a very fundamental parsing problem, you know, for systems. So the early iteration of DMARC folks were relying on a public suffix list, which is sort of a third party effort to basically create a dictionary of these cases. To sort of identify any particular delimited route that you know to be interpreted as one or the other. And the new PSD tag is effectively a bit that lets you flip, which you want to do. Right. There's now a new tree walk method as a method to sort of query your way down to the right route versus relying on the third party. So it's just become a new option. Absolutely. And achieving consistency between the various mail receivers who perhaps were each doing it slightly differently before. The third important new tag is T equals. And this is basically if you are implementing DMARC or perhaps you're upgrading the sort of policy that you're applying. And T basically says to the receivers, we're still implementing it, you know, we want to sort of apply a degree of leniency, if you will. And this, to all extents and purposes replaces the PCT tag, where previously you could say, I only want to apply dmarc to, for example, 20% of my total volume. Can we run through this in a little bit more detail? Yeah, for sure. Yeah. It is a much cleaner test flag and replacement for pct. And again, another one of those learnings that you get from the market usage and the. The industry conversations around it becomes a binary function versus percentage. And I think percentage was a good idea. Right. But the learning was if you look at the language of the original draft, if you're the receiver doing reporting or taking action, and it said 20%. Is that 20% of all mail I saw or 20% of what failed, for example. Right. So a lot of. A lot of. I don't know. And so I think in practice nothing really got done there except for 0, 100, which was effectively a binary anyway. Right. So easy evolution to the new feature. The other thing that I like about the testing flag is the interpretation. And so the idea that receivers will apply one level of leniency. So as you test this, going to market, you know, with the test flag on reject would be treated as quarantine, and quarantine would be treated as none, and you'll still get reports. And so it seems like the right testing mode that'll allow senders to safely push their way towards enforcement. And in terms of tags that need to be removed, another one to be aware of is the RI tag reporting interval. And I think this was really the previously the idea was that DMARC users could specify how often they wanted to receive their reporting files, but it seemed to end up as an industry default, that they got them pretty much on a daily basis anyway. So that Became a bit of a redundant parameter, didn't it? Correct. And I think it's one of those things. I think just giving a nod of understanding to large scale receiver operations. It takes a lot to produce the reports. It's actually quite a commitment to produce the reports. So to have a kind of rigorous sound function to produce these things, it takes out some complexity to have different various cycles on which you might be basically storing profiles for what domain, when do you report and just imagine the difference in complexities of your programming for that reporting engine versus hey, I just run daily release. It becomes a simpler, more effective mode. And Tom, in terms of reporting, so reporting is now covered by RFCs 9990 and 9991. And my understanding, please correct me if I'm wrong, is that schemas haven't changed. So reporting processing shouldn't break. But it would probably be prudent for, for email senders to at least check that their processing still working correctly and doing what they'd expect. Yeah, I think, I think that's correct. I haven't looked as closely at the schema as my understanding the XML schema, you know, should be fixed. I think the only one of the formats previously declared was the only one really ever used. So I think those ingestion systems are probably okay. But yeah, I would encourage folks to make sure that if they see for some unexplained gaps in their, in their data processing that maybe, maybe there's an issue for them. We'd probably have to forgive some of our listeners for sitting there thinking, oh man, you're giving us more homework. But hopefully there's some upsides for them as well in terms of how they're actually going to benefit from these changes to dmarc. What are your thoughts there? You know, what are they going to get out of these changes that are going to be positive for them and their email programs? I think from the mailbox provider side especially, you know, when we think of the large globals and you and your team have, with this platform have done so much to cover this. But you know, when we think about sender requirements and guidelines and all of those improvements over these last couple years, you know, providers have been working hard, I think to create a much brighter line between legitimate senders and, and miscreants. Right. So again we've seen that with sender requirements and for me email authentication is at the heart of that. Our good friend Todd her, who is one of the, the editors involved in this, always likes to say you get the Deliverability you deserve. And, and so what I would tell a sender now, it's perfect, right, with Telesender now is you get the deliverability deserve because you're properly identified, which is what DMARC allows for, and then properly measured. And so these updates are going to help make that identification more reliable. Now you have a crisp, clear standard. We've gotten rid of redundant tags and other things. So you should have greater confidence that your DMARC policies will be enforced, interpreted consistently across providers. And also you should know that you're going to have greater protection, right? So definitely use the RUA tag to get your reports, definitely have your reporting and that's going to tell you one how you're doing with your authored transmitted mail and if you ever have any breakage in that. But it's also going to tell you, are you spoofed? Right? Do you have spoofing attacks in the name of your brand? And so again now we have a really clean, clear, updated framework for this data, this visibility, this insight for senders. That's a great summary because we do spend a lot of time talking about the importance of trust between senders and their recipients. And trust can sometimes be a little bit of a nebulous thing. What is it exactly? But when you can quantify trust by saying what we're talking about today means that you can reliably verify that the emails are genuine, they're coming from the brand that claims to the correct brand that claimed to send them, sender reputation improves and it becomes more durable, your deliverability improves, the damage from that spoofing that you're talking about gets reduced, so brand credibility wins. It sounds like a great update. So I think we've. That's a great overview and I think, yeah, my challenge to you when we started out was to sort of put it into layman's terms. I think we've done a great job of that and I think our listeners are probably thinking, fantastic, where can we learn some more? And Tom, you talked about the IETF and their website, ietf.org is where you can find all three of the new RFCs. By the time you're listening to this podcast, we will have published a brand new blog post on the topic covering off all of the points that we've talked about today, some of them in a little more detail. And Tom, you and I were talking before we started recording today that there are some MOG resources on the topic as well, correct? Yeah. So I think listeners on the MOG site can find our published technology summary on dmarc. I would say that's a relatively simple document and it will be updated shortly to have these three new RFC references. I'd also note we have a current initiative, it's not yet been released. That is more it goes further DMARC enablement and enforcement. And so, you know, trying to go deeper on the ways that we can ensure DMARC adoption will continue to be increased. Right. We want to look at driving stronger enforcement policies, you know, understanding, you know, mua, you know, male client presentation, understanding what better tooling for understanding DMARC reports might look like. So we are attempting to go deeper and I'd say, you know, look for future notices on potential new materials coming out supporting DMARC technology. Excellent. So a whole load of great resources for our listeners to go and have a closer look at. We started out the conversation with a quick fire question. We're going to close out with one as well. So today we've been talking about changes that improve the world of email marketing. If you could tomorrow introduce one change to our world of your own, what might it be? I thought in the sense of DMARC in this conversation, I wouldn't change anything now on that. Yeah, I think that these are the right tweaks and it's good and solid. I was thinking about this in the prep and a little bit of potential lore around this. So I might suggest that for DMARC we go back to the original name for dmarc. I don't know if you know what that was. I don't. Educate me. The original working group that had sort of spawned up on this was actually called moocow, which is spelled as you probably think it sounds. And that stood for. I had to go dig to remember what it stood for. Messaging Operational Overlay Coalition of the willingness and moocow. We talked about the legacy and the timeline. So JD Falk, who we worked with at Return Path, he was also a former postmaster at Yahoo and Hotmail, were sort of integral with others in that early work. And so I mean there was a number of years where that concept kind of got refined and became sort of the basis for dmarc. And so anyway, I we were going to do something. I think we go, we go back to moocow, moocow, no ball. That's all correct. I can't cap that. So I think we'll just finish up. Tom, it's been great having you with with me in the hot seat and email after hours today. Thanks so much for a wealth of insights that you shared with our listeners in a very short period of time if they want to connect with you directly. What's the best way to reach out? Sure. Well LinkedIn is a great place. Love to engage there, so I'm easy to find there. Tom Bartell and yeah, I'd love to hear from folks about DMARC or anything messaging or anti abuse related. Great. Love it. Take him up listeners. He's one of the smartest guys I know, so you'll only benefit from reaching out to Tom Final word to our listeners. Tune in again in two weeks time. Hit subscribe so you don't miss any of our future episodes. Make sure you visit senderscore.org for even more resources to help you become stronger senders. And if you want to join us as a future guest some stage along the line, drop us a comment, ping us on LinkedIn, fill out the guest form that's linked in the show notes. That's it for today. Thanks for listening and we'll see you all again next time in two weeks out half it out. Be sure to tune in next time and hit subscribe so you don't miss any future episodes. And don't Forget to visit sendascore.com for loads more great resources to help you become a stronger sender. To all you sleepless senders out there, thank you for joining us after hours and see you next time.