The DMARC side of the Yoogle update with Ash Morin of dmarcian

00:00:05

Eric Trinidad: Welcome to Emails Not Dead. My name is Eric and this is JT.

00:00:08

Jonathan Torres: Hi.

00:00:09

Eric Trinidad: Hi

00:00:09

Jonathan Torres: JT. We're switching names around. I like it. JT.

00:00:12

Eric Trinidad: Yeah, man.

00:00:12

Jonathan Torres: Keep it fresh.

00:00:13

Eric Trinidad: Yeah. We try to keep it fresh. New Year, new us. We're a podcast by Email Geeks for Email Geeks and we're super excited to have an awesome guest. Returning guest for us. Ash Morin, the Director of Deployment at dmarcian. Ash, how are you doing, sir?

00:00:30

Ash Morin: Good, as always. Thanks for having me.

00:00:32

Eric Trinidad: Oh, thanks for coming back. Yeah. You must be a glutton for punishment because you're a three-peater.

00:00:36

Ash Morin: You know, third time's a charm. If the last two didn't do it, I guess this time we're just gonna knock it outta the park.

00:00:42

Eric Trinidad: We aim for the fence here. You know, so, I'm super glad to have you back. You know, we've been talking this season a lot about the stuff that's been going on with Google and Yahoo and everybody just kind of getting ready. A lot of excitement everybody's pretty much getting super frothy regarding, you know, the changes that are getting made and you know, have you seen anything like that on, on your side of the house?

00:01:05

Ash Morin: Yeah, it was pretty quick. Immediately after the announcement, we started getting a lot of questions coming in. Not only just questions from our existing customer base, but also in ecosystems. All the mailing lists I'm on, and there's been a lot of what does that mean? And even almost immediately trickled down to, okay, so does that change anything about the standards? If not, what's my current state? Like, am I actually good? Even organizations that were like, yeah, we deployed DMARC, we got to reject months ago. Am I actually ready? So everybody's asking themselves, are we actually ready?

00:01:37

Jonathan Torres: Taking up to this point for people to be like, okay, now I need to do something about this and make sure that I'm totally set up and ready to go. Which is, you know, it's one of those things I think. There will always be those, including myself a lot of times where, you know, you kind of wait until you're pushed a little bit to do something. You know, it's not everything that I do that, it's not everything that everybody does it, but I know there's definitely those things where it's like, okay, you need that little bit of a nudge to get going with stuff. So I'm sure that as soon as it was set, it's ready. Okay. Game on. How many questions can we get out?

00:02:07

Ash Morin: It's absolutely true. The thing is. We always wanted a lot of organization, I should say. Push DMARC when there was a carrot on a stick. Yeah. BB was one of those. Lower premium of security cybersecurity insurance was another. Less so the, I don't want my domain to be spoofed, but I can save money. Let's do it. So, and of course deliverability was another, security was almost like a third, fourth, fifth talking point. But now we have big players in the space, Google, Yahoo and Yahoo sometimes it seems like Yahoo? Like is it actually a big player in the space? Absolutely is. Their email infrastructure is everywhere, and they're one, the largest reporter of DMARC reports in the space. They're massive. So when you have, you know, a name like Google and Yahoo says, you better do this otherwise gonna close my doors then. Yeah, people listen.

00:02:54

Eric Trinidad: Yeah. People tend to perk up and just saying like, oh, what is it that we actually need to do? You know, this is a cool club. I wanna be part of that club that actually gets let in, you know?

00:03:03

Ash Morin: Mm-Hmm.

00:03:03

Eric Trinidad: From your perspective when you heard everything happened, like what were some of the main things that you wanted to check for first? What is it that people needed to do to be in alignment?

00:03:12

Ash Morin: Well, what I was really wondering is are they doing anything new with the existing standards? Because it took years for people to finally understand not only the standard, but implement the standard as a sender. As well as receivers. Receivers, you know, adhering to reporting, the reporting schedule, the proper action to take when a policy enforcement is in place. Properly, you know, have alignment, respected. Now senders had to learn what that meant. And then not only when we say senders, we're only not only talking about, you know, I'm a domain owner and I set up Microsoft or Google or whatever email corporate system you're using. You also have a lot of other systems and vendors and third-party service providers that are gonna be sending on behalf of you. What does that mean for them and that space? Like Mailgun is very important to understand how can I make DMARC approachable for my customers and also support it to a certain point. It's been, you know, up to successful, up to a point. As far as the responsibilities for third parties in relations to DMARC, and now we're gonna expect even more out of them customers that need to deploy DMARC to be compliant, especially if the bulk sender are gonna not just look internally for support. They're gonna look externally to all these third parties and when they're, Hey, is your system ready? So that's a question everybody's asking effectively, everyone. Right. They're asking their email IT admins, are we ready? They're asking then, their telemarketers or their e-marketers, are we ready? And then in turn, you know, you're then gonna go and ask Mailgun, Hey, are we ready? Like, how do we make sure that our setup with you is actually accurate? Also? Are we a bulk sender? What does that mean? Like how can I verify this? And of course, there's a lot of tools available for that. Overall, yeah, people have a lot of questions for a lot of people. But ultimately we all agree on one thing. Okay, I need DMARC. You know, that's the first step I need, DMARC, where do I start? And those who are already having a record, you know, they publish a record at some point a long time ago in their DNS, it's been at p= none for in some cases years Now, they realize they actually have to look at their data and figure out what all of that means.

00:05:29

Jonathan Torres: It's funny, one of the things that you said in there is one of the ones that I just keep like harping on that just keeps coming into my mind. And as I hear it's a constant thing for me of the people that are asking am I a bulk sender? You know, do I fall into that category? And I, I think it's a fairly relevant question because I think, you know, there's definitely gonna be people that are impacted that are in the bulk sender category. Some of them don't know they're in the bulk sender category, but at the same time, I feel like it's the wrong question to ask. It's like, you know, what do I need to do to start getting ready for these changes? And not just this particular change, but any future change that comes after that. Because I feel like this is, you know, the, the toppling of the first domino, we've all been set up. It's been the carrot on the stick for a long time, we've done the carrot method, we've done the, hey, do this to benefit yourself and not the, Hey, this is gonna be a requirement thing for a very, very long time, like you just said. And the question of am I a bulk sender? Well relevant. Great. Ask it if you need to, but also think about moving past that, like move past it into, in the way of like, Hey, just let me do this. Whether I'm transactional, you know, marketing, bulk, sending, you know, or I fall somewhere in the middle. If there's any kind of question of does this benefit me? Yes, a hundred percent. This benefits you as a trying to authenticate your mail, making sure that things are set up in a good way and do it, like start moving in that direction to get this completed. But yeah, it's funny how much it's come up. It's come up a lot.

00:06:50

Ash Morin: For good reasons. But yeah, you are absolutely right when it comes to do it anyway. There's a reason it's called best practices. It's a reason why there's so many documents on that topic about authenticate your mail, deploy DMARC. Be compliant, be aligned wherever possible. Like these best practices when it comes to email sending domains is well documented. There's tons of stuff to follow, tons of references available in order for domain owner to be able to start their journey somewhere if they feel like they're starting or continue going down and tidying up all their system and environment. But there's still gonna be people rightfully so asking what is a bulk sender? And that's a question you have to ask individually, Google and Yahoo. Because Google right now they're saying, well, if you send close to or more than 5,000 messages to personal Gmail account within the twenty-four hour period. But then they also start saying. Any emails from primary domains count. So we're talking about if you've got like, you know, Example.com that sends mail and then you have sales.example.com sending mails. They're not separate entity, they're not separate senders. You know they're seen as the same. So if 2500 sends from 1, 2500 sent from the other, that's the 5,000 threshold that they talk about. That's one thing. Then Yahoo is a bit more vague. Yahoo says, well, bulk sender is classified as sending a significant volume that is not quantified any more than that. That's all we got. And then they also say, well, spam that is sent from your domain also matters. So what we're talking about is that domain that is being used to sent from, whether or not it's legitimate counts towards that volume. That's one part, which is true, but sounds a bit funny. They do say if you have a spoofing problem, you should have DMARC implemented anyway. Absolutely true. Yeah. Right. But at the same time, again, it's vague. So that leads even more credence to what you mentioned earlier, JT is do best practice implement DMARC! If you go through that journey. If you go through a deployment project, get your domains you know, sorted out, then there's a really good chance that you will not be impacted or minimize the impact greatly based on a change that we're expected to see by next month really.

00:09:08

Jonathan Torres: It's coming up quick. It's coming up real fast. It's one of those things that we've had time. From my perspective, right, where I have been involved in the industry working with customers to do this kind of things, to work through those best practices and to get into better spots of sending email, just, you know, doing that. There's definitely a lot that has been focused on how do I do it? What should I send, what shouldn't I send? How do I acquire a list correctly? How do I acquire my senders correctly? You know, what do we do for opt-outs? But this has always been a piece that, that we've talked about with people that are sending is you gotta make sure you're not being spoofed. There's dangers in that happening in and of itself, right. Before we, we start getting into any other parts of the conversation, there's bad actors and bad actors are gonna be out there that are gonna be doing the bad actor thing that they do. And, you know, you can only do so much to protect yourself. And if, if we do this part as the bare minimum, that's extremely helpful already. And you know, it's moving past that conversation. And now we feel it from this side where it's a scramble to, hey. Now it is not a choice. Like if you're doing this, if you wanna make sure you don't get caught up in this, you don't get your messages rejected. We got to make sure that all this is, is done. From the experience that I've had, like systems where the ones that I have worked with, it's always been an authentication piece first. That's how we verify domains, SPF, DKIM, set that up first that we can easily say, okay, you own the DNS. You're obviously putting in these records to say, hey. I own this. And I send from it. Doing the DMARC is now kind of like the next jump and leap beyond that. But I know there's also a lot of people out there that don't have that luxury in their ESP setup, that have never had to do that in their ESP setup. What has been the experience I guess from your side and what you've seen and people talking about that with the challenges that they have from where they send email? 

00:10:48

Ash Morin: Well, it's a pretty big spectrum because we have, like you say, we have individuals who are technically inclined. They manage a relatively large organization, so they have process in place. They have a fairly well cataloged list of all vendors and technologies that are using for email. And they're still not entirely sure how to navigate all that email jungle really. Their ecosystem. Yeah. When it relates to authentication, because every piece is a bit different. So that's their challenge. Their challenge is not the domain piece. So the domain verification piece is to know who's using what for what purpose do they want to keep them authorized? And also how does that ESP actually support DMARC? For example, Mailgun will support it in one way, in a very specific self-serve way where admins can configure authentication within their account. And then, you know, others will do it in a very different way, but you still need to find an admin. In most organizations, those accounts are not necessarily gonna be owned by IT or cybersecurity. So that's their challenge. On the complete other end of the spectrum, we've got maybe a small law firm of three individuals and they had outsourced, or potentially they have an MSP that handles all of their email server stuff, their domain hosting, and their WordPress administration, their email administration, which is perhaps even part of the domain hosting deal that they purchased. Now, certainly they hear that they need DMARC. They will not understand what that mean. You know, as far as they know, DMARC is a specific product that's very tangible that they can just buy and then flip a couple switch and it's done like adding a module or turning on a new feature in Microsoft. Right? They, they don't know any better and we can't expect them to know better. 'cause that's not their job, you know, and their lawyers or their secretary or their data entry specialist or whatever, now suddenly they're told, Hey, I need you to figure out how to make that work. And that is a challenge 'cause we need to be prepared to talk about what DMARC is at every level. And this is where we have, you know, services, all that ranges from professional services all the way to our dmarcian Wizard, where this is like, hey, let's take it step by step if you need a valid record. 'cause you don't have one yet. You say you need DMARC. Well, it's just a bunch of tags. It's just a bunch of texts in a written a very funny way. And in order to understand how this is written. Answer those questions in our wizard. I'll spit out a record and then we are gonna tell you where it needs to go based on where domains hosted. At least put them into a place where they feel more confident that they can actually move forward with this and it's no longer this esoteric wall of nonsense that really they wish didn't have to deal with.

00:13:20

Eric Trinidad: Yeah. I know like when JT and I, speaking with a bunch of our customers, it'd be a place that we send customers first to, like, when they talk about DMARC or wanting to get more information about it you know, just easy just plug it in, check out your domain, see if it passes, and if it doesn't, what are the steps that you need to like kind of move forward, which is, you know, super great. You know, it's very visually appealing and able to help people, even like myself, move through it very quickly and understand like, what are the next steps that need to be done? I think that's a great tool.

00:13:53

Ash Morin: It's very interesting because you have those smaller organizations like an SMB that will outsource their technical need to an MSP. Generally they will get to a point anyway, they will have a better, easier time with DMARC. 'cause it's largely gonna be a technical challenge because they will have very few sources of mail, potentially one or two, maybe one marketing system, maybe one HR notification system, and then their primary mail and that's it. So getting things sorted out, it's likely going to be relatively simple for people that are otherwise non-technical. Then again, if we go back to the enterprise level, their challenge is, not going to be the technical piece. 'cause they're used to learning new stuff. They'll read the standard, they'll potentially even read the RFC raw and they'll go, okay, I get it. They'll understand what they can expect on how things should behave. And then read the documentation per system. Their challenge is mostly shadow IT, and by that I mean in business units within their organizations that you know, they have a need for their business unit to perform their function. So they go out, purchase a system, subscribe to their service, either because the primary purpose is to send mail or something else, like a benefits provider that just happens to send reports every month. And it just does that spoofing your domain in a legitimate way, but still does it. Now they have to worry about DMARC. They don't want to cause a problem to those mail flows. It needs to be delivered, but they have no idea who manages those things. They don't know who to talk to. And it's not as simple as, oh well it sends on behalf of my domain, so I'm simply gonna add those IPs into my SPF record. It's not that simple. Because we know that DMARC needs alignment and the majority, by default, the majority of service providers will not be sending using a return path. That is your domain. Because they do bounce management. Now we're getting to the weeds here, but that's the bounce management. And the primary reason why SPF won't be aligned by default and it won't. Alignment doesn't change magically just by adding IPs to your SPF record. It's a configuration change that needs to occur within the service that you're using. So that means is the self-service is an admin that I need to find who's that admin and at that point, it's the business process aspect of deploying DMARC that those large organizations will struggle with is what's my vendor management process? Is this properly catalogued? Now we've onboarded this before. Is there any gut documentation that tells me who owns this stuff? Who do I need to talk to to make changes to the environment? Not only that, but now they also need to learn how do I even make a change? For example, if an IT professional is not used to Mailgun system, they won't know where to go, which panel to be, what settings to change, how to generate the record for domain verification. Do I need to set up a subdomain? Do I need not to? Does this support, direct alignment? There's so many questions that it simply won't know without documentation, without a guide, without being able to see the application itself. Now times 20, times 30, times 40 in larger organizations. Yeah. And then times 10, 20, 30 domains potentially that are sending and then sub domains. It's a big task, so Yeah. Everybody's scrambling for different reasons.

00:17:02

Jonathan Torres: I like the way that you frame that too, because it is one of those things where if it's a larger organization, you're gonna have a lot more challenges. Hopefully there's more resources for you as, as a sender that when you have those internal resources, because I mean, you start looking at you know, whenever you see those email needs, marketing is always I feel like one of the big senders in any organization, right, marketing needs a way to get the message out what your company does, you know all those things that, that a normal marketing department does. But then you start looking at you know, everything from you know, reporting any kind of like, sales organization, any kind recruiting organizations that use those systems to send out emails in a bunch of different ways. So there's definitely that, and hopefully you have the resources and I think you know, with all the examples of the different locations, right? Potential senders within an organization hopefully you're getting some ideas on who you would need to contact. Hopefully you getting some ideas of which departments you need to contact as far as technical departments that would own a DNS record. Any website departments that actually would potentially also have a hand in that, in hosting the DNS and knowing where the DNS is hosted for different parts of it. And I know the other thing that I wanted to kind of touch on is how often whenever we see these you know, big senders aside, right? Because I think they're kind of a unique thing and they're gonna have a very unique set of process once we start getting to the more medium sized or even smaller size senders. I would assume that the recommendation would be to just make sure that we have a subdomain for sending for what we have and what we can control, and then recommend that they use that subdomain route and use a policy just at the subdomain level to make sure that at least this portion that we have control over can continue to be utilized in the future.

00:18:34

Ash Morin: Yeah, so we always recommend, and this falls within best practice we're talking about a segmentation strategy and segmenting your email stream is very important for a variety of reasons. Security is one of them as well, but that's not always what a business decides to do. Because we spoke actually many years ago now that especially when we addressed BIMI. That symbols are important. There's power in symbols in a company's logo and a company's name is a symbol. And we've gotten so used the internet that certain domain names are immediately very powerful upon seeing them. You know, at first glance, especially for organization that's been around long for a fair bit of time, Mailgun or Amazon, or Microsoft, you know, big names. Immediately we see Thisdomain.com and we're like, oh yeah, we've seen this domain around forever. So of course they wanna send from that domain as much as possible. It's not advisable. It really isn't. You don't want to put all of your eggs in the same basket. This is effectively what you're doing. And if one egg is rotten, it could spoil the whole basket. I know it's a silly, you know, comparison, but it's true, unfortunately. And so you, you wanna avoid to do that, but some organizations will not budge from that position. So at that point it becomes a little even more challenging from for these individuals, for those organizations. And they may have to change their tune. They may have to finally approach this differently. And it's best practice even there, how to name a subdomain, the length of it. How is it delegated to a service provider? Do we have full control over that subdomain, and sometimes it's gonna be used not only because hey, we already have a subdomain for this marketing stream. It's fully compliant. It's a single source domain. So imagine you sign up for a Mailgun service and you're like, well, I'm gonna send from m.example.com that Mailgun is the only one using it. So I'm gonna go ahead and lock it down 'cause I know no one should and will be using that subdomain. Great way to secure a stream very quickly. And then you can do that with your subdomains. And then worry about the primary later if you need to. But sometimes it can also work the other way around if you have a problem with a source and it's isolated or you intend to isolate it because maybe you're using a system that is not DMARC capable or it's very difficult to configure DMARC for it. And by that I mean a third party. So you have no control over the infrastructure. Like for example, me, I would not be able to log in or access Mailgun's email infrastructure directly and mess around, right? That's locked down. I can only access what your front-end portal allows me to access. So it's gonna be the same thing with other third parties. So if their email infrastructure is not capable or does not support a self-serve, or even a supported DMARC configuration. By asking them, Hey, do you support DMARC? You need to send emails from my domain and DMARC compliant way. If the answer to that is no, then it becomes very challenging what to do at that point. Because especially now that we have, Google and Yahoo saying, you better be DMARC-compliant or else. And now if you have a source that says, no, we don't support it, well, if you're lucky, you'll be able to find an alternative. If you're not lucky, because let's say you are a K-12 where you have no decision over the services or system that you have to use because it's mandated at the government level and yeah, that's it. Then it becomes a challenge. You're gonna be powerless, the only thing you can do is advocate for a change. And hopefully they'll update their system on their provider's list. So it's best practice. But of course there's always going to be unique situations where what's available to you might not be available to another.

00:22:18

Jonathan Torres: That's tough. We've definitely have seen that, we've experienced it in the past where seeing a provider move or somebody moving providers to send through a different service, and in particular the ones that you know I've worked for and been a part of, and then you end up with the situations that they don't even know and understand yet what a DKIM record is because they've never used it. So the domain doesn't have a new reputation, and we're starting from scratch building on something because it's never been there, it's never been utilized. So, you know how often that happens, I think really kind of just opened our eyes a while back to how many people are gonna be impacted by this because they're in a system that doesn't support that and doesn't allow them to do it or really identify and authenticate fully with what they're doing. Or we've seen those other ones that just, you know, and don't have to call anybody out and we don't wanna step on any toes. But there's definitely the ones that just do spoofing intentionally. And that's just the way that it's always run because it's allowed to be done that way for so long by all the providers. And now them getting everybody to do the right thing and now everybody's, you know, scrambling to pivot toward that because it is one of those things that you know, has been allowed. So people have done it and it's just been the easiest way to do things for a long time. So it's just become the norm.

00:23:24

Ash Morin: It's been definitely a level of complacency, a bit to that. 10 years ago, I need a DMARC record of p = none. I know p = none. Will not cause an impact. I'll get some data. I'll do the bare minimum just so that my email continue flowing. And then they set up a bunch of stuff with SPF. They may have set up DKIM, maybe even with an older weaker key signs like 768. It was deprecated a while back. Now in 1024 might last much longer. So the new best practice is 2048. But the thing is you can have that set up a long time ago, years ago, and really never have looked at it again. So you just make the changes when you need to. Just managing an SPF record is, I think a good example. You add, you know, way back when, you know your SPF record was v=spf1 mx ~all done. And the reason being is because you know your MX record was likely something like mail.example.com where it was used to send mail and receive mail. So you just put your MX directive in there. Then you used A, because SMTP a fun part of that, and maybe not many people might know this but if a sender tries to send to a domain and the MX record are not responsive, so not that they get rejected, but you can connect to them. SMTP says, well, failover to the address record, to the, A record trying an SMTP connection there. And the point is that you had one server that did everything. You had one server, one public IP that was used to net your web server too as well as your mail server two, and that's all you needed. But now things have changed. Now you're using, there's so much cloud solutions. A lot of services are saying, well add this to your SPF record. These are our IPs. Or we do domain verification based on an entry in your SPF record. Now the problem with that is that it gets bloated and bloats and bloats and bloats. You know, many organizations they will add to it, but never really revisit what was added in previously. 'cause they just don't have time. They also don't have easy data to follow with. And this is another reason why, Hey, if you don't have DMARC now, p=none is the first step. And that's also what's the only thing required for the new requirement is not that you have an enforcement, it's that you have at least p=none. But start getting data. We talked about the wizard before. You don't know what a DMARC record is. Follow the wizard, get a record, put that in your DNS. Collect data. Collect data for a week, and then you'll have an idea as to what email ecosystem looks like. And now you have empirical data on how these sources of mail sends those emails, are they aligned or not? And it'll be able to tell which IP are actually used in your SPF record to send mail from. You can remove the stuff you don't need anymore, so then you can finally start cleaning up a lot of stuff. But that's the great things with DMARC, you get data. And to that point, some questions we get asked is, how can I possibly know if I send 5,000 emails a day to Google if the only thing that I see, imagine if you're speaking to an IT professional responsible for, you know, the email system. The only thing I have access to is, let's say Google. You know, my Google Workspace stuff or Microsoft 365. That's the only thing I know. I know how many emails we send out and I can do a search on what goes to gmail.com, but how do I know? Where all the emails are coming, like what's the volume of our marketing system or potentially or, you know, benefits provider or HR provider or so, and so. Well, the great thing with DMARC and Google and Yahoo for that matter is that they report. They are reporting every email they get. If you have a an XML processor, you know, once you have your DMARC record in there and your DNS, you start collecting data depending on your system. For example, DMARC, since you can filter based on the reporter, so who's sending us the report, who you're sending mail to effectively, you can filter based on Google. Then you'll know how many emails you've sent to Google for a week and then every day. What's that total? So if you wanna know if you're potentially gonna be seen as a bulk sender. This is a great way to do it. Use the DMARC data for that. And you can, now, not all receivers report, but the one that matters right now for that change is that's happening next month. They are reporting. So there's no reason not to use that DMARC data, not only to know if you're a bulk sender, or potentially if you fall within their bulk categorization, but also to start your journey. Now is the best time to do it. The, the two big players that are implementing this, they provide you with a lot of data and a lot of tools to figure out how you're seen, you know, you have postmaster tools with Google and then Yahoo has a pretty good customer complaint feedback loop, I should say. And you know, use those tools.

00:27:49

Eric Trinidad: Yeah. I hear that they're working on their own sort of like Google postmaster tools as well.

00:27:55

Ash Morin: Yeah, there's a hub, a sender hub that they have. Yeah. All their best practice is posted there, but there's some signs that are intended to expand those services and tools, especially in light of the announcement from last year.

00:28:08

Jonathan Torres: That's exciting. It's always good to have information and to circle all the way back to your point, I know as people have started scrambling as people are trying to get that bare minimum foot in the door to get set up and ready for this. Like we've definitely talked to a lot of people about like the bare minimum of what they need. And I mean, even with just the p=none you can start already, like it's, it's done, it's set. But like the very next recommendation we have is like, just start consuming those reports. Like find a way to get those reports in, find a place to send them, to start processing that data and then start figuring out, because like I feel like this is giving us the green light to start really pushing people to say like, Hey, you can't leave it on p=none forever, because they're not gonna be okay with leaving it as p=none forever. So start collecting data, let's start looking at what the next steps are to go up to quarantine, to go up to reject, because we need to start enforcing things better. But like, I think that's exactly the first thing. Foot in the door. p=none. Great. Done it. Next step. Report, report, report.

00:29:03

Ash Morin: Extremely important.

00:29:03

Jonathan Torres: We need it. Yeah.

00:29:05

Ash Morin: And I will make a statement, just to be clear here is the majority of third-party services, when out of the box, they're not going to be DMARC compliant. You may say, well, I've added their IPs to my SPF record. The majority of them, yeah, the grade majority of them are not going to be SPF aligned. The return path is not aligned to your sending address. The majority of them are not going to be. Salesforce isn't actually, even Mailgun isn't. Sendgrid ,doesn't matter. Constant contact, iContact, Salesforce marketing Cloud, and I can go on. They're not aligned by default. Adding their IPs to the SPF record is not enough for DMARC compliance. And DMARC compliance is what's required. So you need, like you said, deploy that record, collect data, the sooner, the better. All you need is that one record and a place to process those reports. Collect data. The more data you have, the more comprehensive of a picture of your email ecosystem you will have, so that you understand how many of these sources are at 0%. Despite me thinking that they're not, because I thought that my SPF record covered those bases. That is a common scenario, and then you realize, oh. It's not actually enough, so don't assume, assuming is bad. Test and learn empirical evidence. DMARC data is there for that purpose. You can't make a guess here. You need to know what it looks like. So absolutely don't assume, publish that record, collect data, look at the result, and your mind's probably gonna get blown and then start your journey.

00:30:41

Jonathan Torres: I love the analogy you just threw out because that made me think of it is you know, right now, I feel like if you don't know any of that information, you're probably looking at like a stick figure drawing and you can really make that go all the way to like a Van Gogh, right? Let's get all those colors, let's get all that detail in there. Let's get some like really beautiful stuff if you're receiving those reports and consuming and being able to paint that picture truly. What's going on with the email you're sending?  

00:31:03

Ash Morin: Absolutely.

00:31:04

Eric Trinidad: We have here on the last bit, any potential exceptions?

00:31:07

Ash Morin: I'm gonna say this exception is just putting off the work till later.

00:31:12

Jonathan Torres: I like it. Yeah.

00:31:14

Ash Morin: And now that we have two of the biggest players in a space saying this is gonna happen, and this kind of makes me think of 2014 when Yahoo said Hey, yahoo.com and Aol.com is now p=reject and everybody complaining about mailing list. Well, what's gonna happen with mailing list? You know, turn that back. They didn't. They didn't turn it back. So mailing lists had to date, you know, their stuff and they had to start munging the from header whenever the main had enforcement. So we're not walking this back. This is moving forward. It has to because the more people that adheres to best practice when it comes to email sending the more, the safer. For everybody. Email environment, email system is going to be, so we're not moving back. So exception, don't think about it that way. Just baby step. If you need to. Ask for help, if you need to, there's more help now than it's ever been. Yeah. So just. Just do it. Just do it. Yeah.

00:32:10

Eric Trinidad: Ash, you saying that kinda reminded me like from some of the conversations that we had before, just about just people in the industry, like the email industry as a whole, have so many useful resourceful folks out there that like, wanna see you succeed and want to see you do well. You know, that do want to see you be a better citizen of the email community because that benefits us all. So, yeah, if you have questions, you know reach out to your mailbox provider, your email service provider. If you have questions regarding you know, DMARC and setting up your policy, you know, reach out to dmarcian, they're gonna be a great resource for you as well. I think we've listed some things here where you can get some of that information. You know, the truth is out there. You can find it easily.

00:32:52

Jonathan Torres: We're, we're getting close to wrapping up here pretty much at time. But Ash, like, thank you so much for always coming on. I know this is probably one of the more technical episodes that we do every season whenever we start talking about this stuff. But you really make it a really good conversation. And, you know, turning that technical part into an interesting thing is a tough thing to do and you nail it every time. So thank you so much for coming and doing that because it's something that we all need to hear.  

00:33:13

Ash Morin: It's a pleasure. I love talking about this stuff as I think I made obvious. It's rarely your passion. Never thought it would turn into a passion, but, you know, as soon as I started tinkering with the stuff I knew. All right. I'm gonna be doing this for a long time. Yeah.

00:33:26

Eric Trinidad: Yeah. You're in it for the long haul. Right on. Ash, if folks out there wanna listen or wanna see more of some of the things that you've been putting together, where can they find stuff about you?

00:33:36

Ash Morin: The best thing to do, honestly, is go on dmarcian.com and from there under our resources link. There's everything you need to read as far as not only our DMARC tools, but our knowledge base. I like to do a fair bit of writing, so under our knowledge base, we have many news and knowledge blogs. Speaking about events and technology best practices in the email ecosystem as it relates not only to authentication, but also other topics like the segmentation strategy, SPF challenges and so forth. So take a look there. I think there's a lot of good stuff to learn. And if you are not entirely sure how to start your DMARC journey. We have also the DMARC Academy, which is a good resource to get a free course in everything DMARC. So, dmarc-academy.com, take a look, sign up for free, learn some stuff, and you'll feel just a little bit more comfortable starting your journey.

00:34:32

Eric Trinidad: Yeah. Right on. Right on. And Thomas, if they want to hear more episodes or find out, any more information about us, where can they find us?

00:34:39

Thomas Knierien: Yeah, for sure. You can find more information about the podcast at mailgun.com/resources/podcasts. And you can also listen to the previous episode we released today. We will make sure that we add these resources from dmarcian in there, such as the record Wizard that they put together, which is a pretty stinking cool tool, and along with these resources as well. So we wanna make sure everyone is following along with this update because that's what we wanna do. We want to entertain and make sure that we inform you of what's going on.

00:35:06

Eric Trinidad: Right on. Right on. Well, Ash, thank you again. Appreciate your time, and until next time, everybody else have a great one.