Spoofing, phishing, and for the love of DMARC with Ash Morin of Dmarcian
Email’s Not Dead: Season 2, Episode 7
Spoofing, phishing and for the love of DMARC with Ash Morin of Dmarcian.
Email's Not Dead
About this episode:
We're wrapping up this wild ride of a year and season by clearing the air on phishing and spoofing with Ash Morin, Senior Deployment Manager at Dmarcian. We cover why spoofing is so scary and why you need to love DMARC. Join your favorite email buds Jonathan and Eric and our VP of Deliverability, Kate Nowrouzi, for the season finale of Email's Not Dead.
Meet your presenters
VP of Deliverability at Sinch Mailgun
Manager of the TAM team at Sinch Mailgun
Technical Account Manager II at Sinch Mailgun
Sr. Deployment Manager at DMARCIAN
Email’s Not Dead – S2, E7: Spoofing, phishing, and for the love of DMARC with Ash Morin of Dmarcian.
Eric Trinidad: Welcome to Email's Not Dead. My name is Eric and with me, as always, is Jonathan.
Jonathan Torres: Hello.
Eric Trinidad: We're here this week to talk to you as we do all the time about email. This is a podcast created by a couple of geeks that just happen to work around the email space. So welcome back, friends. This week post Halloween. We're still going to get into a little stuff that is scary. So we're talking about phishing and spoofing, which is kind of dangerous out there. So, you know, to help us along this journey, we have a couple of friends with us. We have, joining us, Ash Morin from Dmarcian. He is a deployment manager. Ash, thanks for joining us today.
Ash Morin: Thanks for having me.
Eric Trinidad: And we also have Kate Nowrouzi, who is our VP of Deliverability... Kate. Thank you again for joining us. How are you doing today?
Kate Nowrouzi: I'm doing great. Thank you for having me.
Eric Trinidad: Great to have you back. So today we're talking about spoofing and phishing and just security in general. Ash, I understand, you know, you have a background in security, but primarily around the email space, you know, so how has that life been?
Ash Morin: It's been fun, actually. So for a lot of people, I think I started as a generalist and focused primarily on your typical desktop sites, support on site primarily, you know, making sure that hardware and all that kept on going and working along. But eventually, as I got more into email and email administration, especially around the mid-2000s when some really fun technology started to come out of the woodwork, but it's out of necessity. Let's be honest. I got hooked and I started focusing more and more on that. Eventually, around 2011 is when I managed to land a full time position into antispam and security. Then I realized that was probably going to be a love that I will have for a long time. And in fact, that's interesting because that's just one year before the DMARC specification became more official. So my timing was very interesting. But you know what? It panned out in the end.
Eric Trinidad: Yeah, that's awesome, got its hooks in you and hasn't let you go since.
Jonathan Torres: Yeah, that's what email I think will tend to do for all of us. I feel like this group in particular, but I mean, there's so many people out there that once email, like, sinks its teeth in like you're set, you're good. It's like this, it's a bug and you're going to go for it.
Ash Morin: Absolutely.
Eric Trinidad: So you've handled probably some scary things that have come out there and hit up some of your clients and your customers like Kate. I know you've experienced that as well. You know, just with your background.
Kate Nowrouzi: I used to do spam fighting at AOL’s anti spam operation, and it was fun. It's like a puzzle. That you, the more that you go after that, they change their tactics and then it's like a really fun game. Since then, I have always enjoyed fighting the bad guys and making sure the email ecosystem stays clean and safe.
Jonathan Torres: Yeah, safety is definitely a big part of it. And I think that that's kind of where the conversation leads us to. Right. Is that the next step, because we do have spam in general. Spam is a thing. We've talked about it so much and I think the conversation will never end about spam, how to fight it, how to not do it, you know, make sure that we're doing the right thing. So that doesn't come into play. But I think specifically here, what we're focusing on is the whole spoofing part of it. Right. That's a whole another level where it's not just spam anymore. It's something intentionally bad that somebody is trying to do. And I think that should be talked about. And we need to make sure that we make time to talk about that. And within the space. So spoofing, what is it does anybody want to take a stab at that because I'm going to leave it open.
Ash Morin: Well, I think I would feel bad if I didn't to be honest. I really want to start by prefacing that effectively, you know, when you were talking about spam versus, you know, spoofing when we have to understand that spam is technically unsolicited bulk email. The intent is not necessarily malicious. It's bad practice. And sometimes it may be, but not always. But when you talk about spoofing, this is a deliberate, generally targeted, attack that there, you have individuals out there that are trying to get something out of you and that will generally mean that you will incur a loss. So it is an attack. And that attack is effectively pretty scary because for the average users, they will have no idea. And very often they're going to have to trust that their ITSEC or, you know, the organization that they work with is properly equipped to keep them safe. And that's not always just in a work environment. We're also talking about, you know, your own personal email address that you use that's, you know, like a free account of some kind. And it is overwhelmingly also a target of those attacks. But effectively, the whole idea of spoofing is that because of the way email works, the way your email client will display where an email is coming from, that address from if you wish, can display absolutely anything that the sender wants it to. Anything, absolutely anything. And without specific technologies that have been developed down the line to install some control surrounding that, some verification, there was none of that before. And ultimately, that's what it needs. Is, once you get a piece of mail, it's going to attempt at being someone that they're not, they will come up to the door and show their badge, saying, hey, I am your gas provider, we need a payment. And at first glance, there's a good chance that you will not notice the difference. And that is, in essence, what spoofing is, you know, nuances and tactics that an attacker would take. But in essence, that's what it is. It's someone wearing a costume that is so believable just because of the way email works and your email client tries to facilitate and add a layer of convenience to your life that effectively makes it dangerous just to trick you and get something out of you. And that is bad for you and good for them.
Jonathan Torres: Yeah. There's so many different layers when we talk about that kind of stuff, too, because there are the little micro attacks that are very targeted, like, whaling type of attacks that are sending information, pretending to be I know I've gotten these where it's like, hey, it's your CEO. Like, please buy a gift card and send me the gift card code because I need this money. And it's like, well, that doesn't make sense. But they're still trying it. And obviously it's still a thing because people are doing it. It's happening and people are falling for it. So that's a very dangerous place to be in. And that can cause, you know, definitely some problems. But then we see things on a mass scale. I know that I love shopping online. I think the pandemic has made it so that I love shopping online even more because I can get more stuff right to my door. So and then there's so many things that come into my mailbox. And I mean, it's a hard thing for providers to combat. And it makes it very dangerous because any big company that's doing this on a mass scale, it's easy to find their logo. It's easy to find the way that they format their messages. It's easy to mimic that information and then send it to everybody, send it to anybody that they can have and get their email address for trying to fool somebody that that can happen to you. So it's one of those things that I mean, to me, it seems like a very scary place to be. I mean, in email in general. It is something that, you know, kind of gets my heart going a little bit. And I think that's kind of, you know, continuing the Halloween theme. Yeah, it is. It's intimidating, I think, at times. And just scary overall.
Eric Trinidad: Yeah. Especially now during the holidays. You know, we're going to have so much more messages now probably than ever before, you know, being in that space. Yeah. What was that Kate?
Kate Nowrouzi: I was going to say it does matter if you have worked in email security, if you have the experience, you can look at email headers, you know those details. But even for me I was, like, always thinking, oh, I'm solid, no one can fool me. I was once fooled by... I use Wells Fargo as my bank account... by a Wells Fargo phishing attack that the W was two V's. So even if you are the best, you can still be fooled. So that is the main point to keep in mind that there are so many things that need to be done in order to protect the ordinary or even experienced people to protect them from their phishing attacks.
Jonathan Torres: Yeah, I've seen so many different combinations of those kind of things where they'll use an R and an N to make it look like an M, they'll use that same kind of tactic there like that you saw with two V's to make a W. There are so many, there's so many different tactics out there in the way that they'll do that. And it does, it makes it very kind of, you have to be paying attention to, you know, you as a consumer, but then also as a sender like how things are performing. So I think that's where we kind of start tilting the conversation a little bit. Let's make it a little bit less scary and what we can do to help ourselves out. So I know when we start going from the very top right, we start going and looking at the very basics of this and where it's gone in the past. We know that SPF is a thing, right? So SPF allows you to basically say these are the places that are sending messages for me. Right. Simple TXT record, fairly easy to set up. Most everybody should have that set up. If everybody doesn't have that set up, please go set it up. It really just says this is my domain. This is where my emails are coming from. These are the servers that I want to say that, yes, they can send for me. So very, very basic. Then we start getting into things that get a little more complex. Where you're signing your messages with DKIM. Ash, do you want to tell us a little bit about the DKIM side of things?
Ash Morin: Yeah, absolutely. So in essence, DKIM came into play in its current iteration as a kind of emerging of two technologies around 2004. And effectively, the idea is to use cryptographic key pairs at a very high level. I'm not going to go too much into detail, but effectively the sender is going to be applying a signature to the email, sort of specifying, hey, you know what, I verify the authenticity of this email. This is my signature. And once it's received by the intended recipient, then that environment, if it's checking DKIM, the majority, overwhelmingly the majority will do that now. It will then build its own verification using a public key. And then what it'll do effectively is compare what they come up with versus what was originally signed by the sender. If it matches identical, then it means that that email was sent and received without any modification. To what? That DKIM or that signature is covered so effectively, it's a way to apply a certificate seal of approval stating when it was sent, these specific parts of the message looked like this. And then this way, using that technique, a receiver can go, well, it looks the same then when you verified it. So we're good. But if there's any changes that's done to a specific part of the message, replacing a few things, changing the content of the body, things like that, then when the receiver gets that mail, it'll go. No, actually, I'm seeing something else you saw when you sent it. So at that point, we'll know something happened. Now, the tricky part is, was the thing that happened, was it done, you know, just legitimately it was just a mistake or was it nefarious? That's a different can of worms. But in essence, that's what DKIM does.
Jonathan Torres: Yeah. And I mean, it's one of those things where it's nice to have something in place to stop those things from happening. Right. Those, you know, whether accidental or whether intentional, like. Right. For those changes happening whenever things aren't looking the same, whenever sent out that was signed and then coming back into the space, really with both of those, though, because if you're sending a message and you basically say you don't have DKIM and it's not a signed message, then it really kind of makes that kind of a moot point, really. Whenever we're talking about spoofing. Not that it's completely useless, but it does make it so that there's a little bit of a fall gap. And I know that's kind of where, you know, we have the SPF, you know, thing kind of still kind of coming into play a little bit and kind of taking care of some of that and basically saying a few things about where the email should be coming from. But still, it's not a full, secure or full complimentary suite of everything, you know. And I think that's why so many of us within the email space are so gung ho about DMARC, because it's kind of the savior to bring it all together.
Ash Morin: Absolutely is. And in fact, we have to also remain real, if you wish, in a sense that there's no single measure that's going to fix everything. There's just isn't what we need to look at. And that's what SPF was originally. It's like, okay, now I'm authorizing who is authorized to send on behalf of my domain, but only as part of the return path. And that's now we're talking about the anatomy of an email. You know, there's two sending addresses there's going to be from header and there's going to be the mail from or the rfc5321 mail from or the return path or envelope from or bounce address. It's the same the different names, all for the same specific identity that set in an email. And unless you are familiar with how SMTP works, you don't that, the average user evidently don't know that. But from a system administrator you're looking at, okay, you know, I got SPF set up and so i'm good there, but more can be spoofed. And the main issue with there is DMARC brings it all together for a very specific reason because it is possible for let's say I'm John Spammer and I've registered spammer.com. It's you know, yes, it's a bit on the nose, but that's on purpose. So i've registered spammer.com. So I own that domain. So I have control over it's DNS, I have control over whatever mail server I've configured to send on behalf of that domain. And because of the way email works, I can send an email that is scripted in such a way that will use a different from header then the return path. So I'm going to send a return path to my domain spammer.com so I control the domain so I can set SPF record to whatever I want. So a special authentication is going to pass. Yeah, but I'm going to start sending from PayPal using a different header and that's what a receiver, a mail client overwhelmingly has started to change. That's started to change and that's good. But overall, especially on mobile, we know that mobile is... everybody checks their email on mobile now very rarely on a desktop, mobile client you've got limited screen space. What are they going to do? They're going to show the from header. They're not going to start showing you in detail all the different addresses that are on there. So you're going to see, oh, I got an email from PayPal. And if you know, John Spammer's, real good at creating a body and to look like an email from PayPal and let's be real, it's really easy to find an authentic looking PayPal logo in images and whatnot on the Internet.
Eric Trinidad: People have a lot of time on their hands right now.
Ash Morin: Absolutely. And you know, you're a spammer. So you're a phisher, that's effectively their job. So they are good at what they do. So you make an email that looks like PayPal. They send it. You check your mobile, it looks like PayPal.com, but it's sent from spammer.com and SPF passed. And what's scary is DKIM will pass too, because if I used DKIM to be sending from my spammer.com mail server, quote unquote, then I have control over the signature. So, and I have control over where the public key is hosted, which would be in spammer.com, so all of that passes SPF authentication pass, DKIM authentication pass, but it looks like it's from PayPal. So what do I do? Like what does PayPal do to protect the reputation of their domain at that point? And what does a user do, but can I even trust what this is? Honest really it just doesn't fall on spam heuristics. It doesn't fall just on the users to be well educated because it's not realistic to think that everybody just has the right and let's say let's call it an education or skills to be able to notice. Should I be worried about this? Is this legit? Now, it's better now than it's ever been because it's been socialized, but we're still not there. So then we have to shift the responsibility to the domain owner, hey, do something. And that's what SPF was. That's what DKIM is but then that's not enough. So DMARC is there to act at a you know, if I mean, if we're going to be using layman's term as well it's not enough that SPF passes or decompresses the what's being used to do those checks against a domain that you had to look up that a receiver has to use to see if SPF passes or DKIM passes. There needs to be a relationship between those identities. And what's displayed as who they're pretending to be the sender of. That's really where, well there was already a need, that need was identified before DMARC and there's been some isolated piecemeal effort in kind of establishing that kind of behavior through other specification and text, but none that was overwhelmingly adopted as a standard that everybody would use. DMARC was really the first that ended up doing that. So then at that point, once the adoption rose and I'm talking about verification, adoption, so that receiver is properly equipped to do a DMARC check for mail that they receive. So at that point, what DMARC ended up doing is, okay, you know, to use my example, I'm trying to send an email because I'm a bad person. I'm trying to send an email from paypal.com but to returnpath and DKIM is spammer.com. Well then somebody who let's say PayPal goes, okay, well that's not good. So I'm going to publish DMARC and I'm going to install when I need to install and do so now that anybody that's not authenticated will fail. So what ends up happening is a receiver of course will see that they will see PayPal. Oh PayPal has DMARC. Well I better see if the returnpath and DKIM is also payPal.com. Oh no, it's spammer's.com. That's not the same. Well that's not good enough. And at that point, what happens to that email is based on what that DMARC policy says. So then again, the domain owner is in control of that. So then the receiver will go, oh, they want me to reject that. I'm not taking it. And it's just one or zero all or nothing, black and white thing. Right. It's not a spam heuristic, it's just there to go. Does it pass or it doesn't. And that's it. So that's the idea behind DMARC.
Jonathan Torres: It's so beautiful, I think within its design that it does exactly that. Right. That's the thing we're looking for, is for some way to protect yourself. Right. As the sender. If I'm sending stuff and I'm sending things as myself with my brand, with my images, with my content, I want that to be me sending it and not anybody else. And, you know, and if it is somebody that's doing it, well, yeah, I'm going to protect myself and I want to be able to protect myself to say, no, don't let these things in. And I think that's from you Kate, like, you know, where have you seen, like stuff like that impact, you know, the deliverability aspect of things. When somebody does do that abusive thing, that makes it look like somebody else who's a legitimate sender and then it's not.
Kate Nowrouzi: So the most important thing for any brand is their reputation. So if they get phished or spoofed, if the brand, the consumers, will lose trust in that brand. And repairing the trust will take a very, very long time. If you have lost that trust, it may take forever. You may not even be able to survive. So that's why we highly encourage all the brands to authenticate their traffic, to definitely establish DMARC records. But one of the challenges that I see, it has become easier to encourage brands to establish a DMARC record. But the policy that they are enforcing so everybody publishes a DMARC record, like it's easier to do that. But then they start with P, the reporting. The report P equals so on. It's the reporting. This is really meant for a very, very short period of time until you are testing and doing so forth. So you need to move to quarantine and reject, so do not stop, so it's okay to build, to have a policy as p=none at the beginning. But if you stay there, it feels like you got a present for a birthday and you wrap it, but you never gave it to that person. So basically going through all of that and then being proud, oh, I have a DMARC policy.
Eric Trinidad: Building that relationship. And then when you get that trust with your customers. I mean, that's what Jonathan and I do, is TAMs every day is telling our customers, you know, you have to build that reputation, earn that trust. It's just like any other relationship. I don't know if you've ever called a significant other by another name and how easy it is to gain that trust back after you do that is pretty dang hard. So, you know, just do it right, you know, and you'll be good. Get it set up, get it set to reject so you don't get rejected.
Ash Morin: Yeah, absolutely. And just to expand a little bit on what Kate said, what I find interesting is going to deploy a p=none as we are monitoring enforcement, whatever you want to call it. And what I like to say also is, okay, you know, you think people are going through the gates, you know, and you want to stop that from happening while p=none is there to turn the lights on. So we install a camera at the gate to look who's actually coming through that gate. But you're not buying a door and you're not buying a lock. You're doing nothing to actually stop it. Now you know who's coming, but what are you going to do? And yeah, to your point, there's a lot going on as far as what reasons could explain why they stay at that policy and not actually move forward. Very often what ends up happening is they know that DMARC is beneficial. They know they need it, they start with it. And then they start seeing those reports and then they don't have any way to process it. It's like, what do I do now? Like, I'm getting thousands and thousands of reports and they're all XML and I'm going through them and this is just not doable. So that could be one reason. Now, there's a lot of solutions out there now for that evidently Dmarcian being one of them. But when you start looking at, let's say you have a solution, regardless of what it is, you have always maybe you built it yourself. You went professionally. It doesn't matter. You have a way to see what they mean. And then the realization comes down that, oh, there's a lot of work here to do. That's going to take a lot of people hours. There's bandwidth that needs to be associated that we might actually need to work on a project here to talk to a lot of people within the industry at that point, depending on the kind of organization you're at, if you especially if you're fairly complex organization, a lot of users, a lot of people to talk to and start having to piece all of that together to do what we call source discovery is understanding who uses that source. I can't make a change. There's no amount of DNS change I can make right now to make this complaint. I need to find who uses this. That can be very difficult, depending on your organization's structure and how you spread out and how you operate. And then when that realization sets in that it's a lot of work, then they might have to realize, do we have the bandwidth for it now? And if they don't, then they need help. Another reason why they would come to a company like Dmarcian, but that's beside the point. The point is, a lot of them, unfortunately, will stay at none because they don't know how to tackle it. It's a lot of work. And time is important for these folks. They're very busy at mitigating threats from everywhere. So now they have to look at it from, well, what are the risks of actually just moving to reject without doing the work? And then very quickly, they'll also realize that that's not possible because they may have some very important critical stream of mail that will be impacted. And that's a revenue generating maybe or something similar, and they just can't impact it. So they're stuck. And that's unfortunate.
Jonathan Torres: That's exactly the point, right, is that there's so much time where it's just overwhelming work. And I know there's a lot of times where it's just fear, fear that if you do go on and do some of that work, that you're going to miss something or something is going to happen. And, you know, you didn't implement it exactly right. Or and then you critically break something that was working before and then things come crashing down on you. Has the person who was trying to implement that. So I completely understand that fear and I've never had that happen to me, thankfully. But it hasn't been at that level or hasn't been with DMARC specifically. But I understand that sometimes, you know, well, there's things that are entrusted to you and you want to make sure you're doing the right things with them. And that's, I think, what it comes down to. And for those of you that are out there that might be in that situation, that maybe you have, like, a p=none policy right now. This is why I love the Dmarcians of the world that have a system and a source that you can kind of plug into and get that feedback back. Right. Get the information that you need kind of at your fingertips and really be able to act on it because there are so many things. I don't even know how many times I've gone in and looked at somebody's SPF record, even. Let's start with something simple, right? You look at an SPF record. How many people are sending messages for this one entity, you know, recognizable brand? They're doing a lot of things from a lot of different places. We look at the SPF and the record is maxed out on how many different sources they're using for, for sending email from their domain. And so then translate that into trying to implement DMARC. With that, you're going to have to look at all these places, evaluate who's actually sending for you. Do they need to be sending for you, you know, this kind of audit, you know, and what department is doing that? You know, like if you're a big company, you probably have a lot of different departments that each kind of chose their own place to send from and maybe are doing half of the authentication. And it's big and it's overwhelming. And I can definitely see where it's, you know, that scary part of it. Right, where kind of you're trying to do the right thing, but you get frozen because of the amount of work that, that needs to come down with that. So it's definitely one of those things where you've got to take it a piece at a time, but you gotta work toward that next step, toward that quarantine and eventually toward that rejection.
Ash Morin: Exactly.
Kate Nowrouzi: So Ash, I have a question for you. So you guys help the brands to set up DMARC and you also so you don't leave them there, you continue. They can continue to benefit from you guys monitoring, sending them reports and if something goes wrong, resolving the issue. Correct?
Ash Morin: So we do a little bit of everything. So specifically I'm part of managing the US professional services part of America's I should say, of Dmarcian. So our goal here is to do all of the above. So it depends on what help they want and which stage they are. But the idea is we come in if they're interested, we'll scope out what the amount of work that needs to be done. And we provide them an idea of what would be involved so that we prime them. We make them ready. We make them understand. Hey, this is not a set and forget technology. You're going to be married to DMARC going forward. And there's a lot to consider. So we first provide them that perspective and then scope out the project so they have an idea as to, OK, what would it take to go from none to reject? And from there we can come to an agreement. Maybe they want help to stay with us until we get a rejection. And at that point we'll do as much as we possibly can, we'll help them not only get used to in our case, we're going to be talking about the Dmarcian platform, of course. So I'm there to ensure that they become pro users of our system so they understand it inside out. I'm there to also ensure that they understand how DNS, SMTP, email, SPT, DKIM, all work together and the nuances there, best practices for example, just to you mentioned earlier, let's start with SPF, because that's an easy one. Not always, unfortunately. Sometimes SPF can be SPF management is a known issue from bad advice that's on the Internet, down to the limits that are that exist within an SPF record, both because the big one that everybody dread is the max of 10 DNS lookup that are that a receiver needs to go through before it issues an error or DNS TXT record just can't contain so much characters. And because if we are in a SAAS world, your record can grow immensely. And then we have also to, especially if we work maybe with more old school individuals, they may want to start with the SPF record as v=SPF1 mx-all. That's a very common SPF record that used to exist. That's not relevant anymore. Just isn't. And that's two DNS query mechanisms right there that are useless for the majority of domains. So it's just an example. But then if they're you know, if they're huge and a lot of SAAS and they want to focus primarily on the on their main marketing domain, they might not be able to then we're going to have to talk about the segmentation strategy, which is effectively isolating streams to subdomains for a variety of reasons, including domain reputation. I'm sure Kate could comment on it. So that's just one of the aspects. So we're going to be talking about how to configure specific MTAs down to making DNS changes, coordinating and planning out those changes, discovering and also cataloging every source that sends mail, who owns them, who does what, and then formulate a plan and hold their hands. I don't want to sound patronizing. Of course, it's meant with the best of interest and best of intentions, but hold hands so that if they need us, we're there. We'll give them the best advice that we know based on our experience. And then from there, we ensure success. We're effectively there to give them a successful outcome with minimal risk. If I were to boil it down as much as possible.
Jonathan Torres: Yeah, no, I mean that's exactly awesome. Yeah, that sounds great. Well I mean, I think that covers a lot of what we kind of wanted to talk about today. Right. Like what is it, where is it coming from. Solutions, the scary parts of it. And then hopefully finding a nice place, you know, and thank you for bringing that to us, Ash, I think that's really a big thing. And Kate, your insight on the deliverability part of it and that reputation piece. I know you have not just the knowledge behind it, but the experience behind it as well. And I think that speaks hugely and with great volumes of, you know, what the importance are of this and why it's so important for everybody to kind of come in and do this and do the next step in that security space, because it is super, super, super important.
Kate Nowrouzi: I would love to continue this conversation. Probably the next podcast about... Ash brought up a really interesting point about segmentation and why we need to be segmenting different traffic on different subdomains, and how to implement a DMARC policy. Does this DMARC policy need to be implemented at the organizational level or at each subd domain. So stay tuned. Watch for our next session. We'll be discussing all of these details. Yeah. Thank you so much, Ash, Eric and JT for having us.
Ash Morin: It's been a pleasure.
Eric Trinidad: Thank y'all very much. We really do appreciate your insight and your time, your knowledge, all the things. If we didn't cover anything today and you want to hear more about it, you want us to get into the weeds to get into the nitty gritty of what DMARC is and how to set it up, you know, we can definitely look at that in the next cast, maybe a webinar, maybe something live maybe we can do something like that. I don't know. Let us know what you think. But if they want more information about DMARC and Dmarcian specifically, feel free to hit up dmarcian.com and look at their posts and blogs there. And also look at Mailgun.com/blog for our blogs as well. Thank you again, everybody, for your time. I really appreciate it and hopefully we'll see each other again soon.