 Welcome. We're going to be talking about some email stuff today. A couple of disclaimers. There's going to be a number of disclaimers throughout the talk. First two, I tend to curse a lot during presentations. I'm going to try to curb it to an absolute minimum, because I know it can be annoying. Number two is I'm going to be going very fast throughout these slides. So just bear with me. I have a lot of content. It was really hard to push this to 45 slides in 45, to 80 slides in 45 minutes, but unfortunately, because of the timeline and everything, it was almost impossible. So really quickly, who am I? My name is Marcello. I go by Byte Leader a little bit everywhere. I'm an open-source developer, researcher, engineer. I like to call myself an Infinity Stones teamer, because I collected all the colors. And hey, fresh off the press, I'm looking for a new gig. So if you're hiring, come grab me after talk. Even if you're not hiring, you can come grab me after the talk and chat. I'm a friendly guy. I like talking to people. Second, this third disclaimer, rather, please don't do crimes. This is going to be apparent why I'm saying this towards the end of the talk, but you're just going to get in trouble. And yeah, please don't. I know doing that here is like going to a heroin convention and asking them not to do heroin, but, you know, just please don't. So how did this all get started? I just wanted to send an email. I did it programmatically and through a Cloudflare worker. If you're asking yourself why through a Cloudflare worker, it's because I backed myself in a corner from a tech stack perspective that had no other option. I built this entire backend website using Cloudflare workers because I wanted to be the hip person using the latest stuff. And if you're not familiar with Cloudflare workers, they're like sort of akin to AWS lambdas. So it's a serviceless computing platform. And it's a little bit edgy though in the sense that there's a twist to the Cloudflare solution, which is like they take your code and they distribute it automatically throughout their CDN. So it's always like the person hitting your service is always latency optimized like geographically to where you're trying to hit the service. And then you can also write them and only write them in JavaScript, TypeScript, and anything that emits WebAssembly. So they're also slightly depressed as well because they can only be living in TypeScript land. This is basically how you start out with Cloudflare workers. You basically just run a command, creates a directory structure, then Cloudflare provides a tool called Wrangler that automatically like you can use to manage and upload your Wrangler and your worker code. And then your worker code is just automatically available at an HTTPS enabled URL that everybody can access. And the main takeaway here is that by default the worker code is public because like that's the whole point like people need one and access your service so they can use it, right? So just for some context here, this is like, you know, imagine like 1 a.m., you know, I'm just trying to work on this freakin' website. I want to go to bed so I can actually get to my day job, you know, it's late, maybe even a little drunk. And I just need this website back end to send an email, right? So I'm just drunkenly like Googling, you know, send email, Cloudflare workers. And I stumble across this blog post from Cloudflare. It's like send email using workers or something called MailChannels. I've never heard of whatever MailChannels is, but at the time I didn't care. Hey, it's got code. Great. Copy, paste this thing into my worker. Works first try. And we'll go back to that code in a second. But it works first try, which in hindsight, Red Flag, nothing really ever works first try. But hey, I get an email and it goes to my spam inbox, which is somewhat normal, I think, right? Because I didn't set up any email security stuff, which I had very little about at the time. I leave this behind, like, come back a couple of days later. And I see that there was an open browser tab, like, throughout the gazillions that I had opened from when I was working on this a couple of days ago, where there's this person asking on the Cloudflare community forum saying, hey, so, like, if I use this feature, this MailChannels thing, like, doesn't this allow anybody to impersonate my domain and send emails from my domain? And I'm like, why, as the kids say, that's pretty sus, right? So we've been asking that. Like, that's a weird question to be asking, just randomly out of the blue. And then there's a MailChannels person in there saying, yeah, this is just how the email works, though. So, like, you know, there's nothing really going to do with that, which at this point, I'm completely nerd sniped. So I just keep googling, like, what's going on with this MailChannels thing? I've never heard of this before. And a bunch of people asking a little bit all over the place, hey, can't people just impersonate my domain with this? And I'm like, okay, what's going on? And then there's this guy on Reddit that's like, hey, like, asks a really important question, because I didn't even think of this. Like, why is this free? Like, why aren't you monetizing this? Like, this seems weird. Like, you're just allowing people to send emails for free. And they're like, yeah, no, no, no. We don't care about the money, right? We just care about sending an email. It's fine. So they just went full joker. So I'm like, okay, let me just go back to the code that I just, like, in my sleepless stupor, just copy-pasted into my worker code. And I stare at this for like a good two minutes. And for those of you who are not TypeScript inclined, first off, I envy you. Second off, basically all this is doing is just sending an HTTP post request to some mail channels, API, right? With the contents of the email that you want to send, right? And if you stare at this for a while, you're like, wait a second, there's no authentication here, right? Like, there's no, like, username and passwords or, like, API key in the shits, right? There's nothing. So that's really weird. So I do a little more. And it turns out that the cloud flares and mail channels partnership entailed mail channels creating this API, no auth required. However, the twist is that it's only allowed listed at the network level to Cloudflare SP space. So you'll only be able to hit this API if you come from a Cloudflare IP. Well, anybody on the internet can just create a Cloudflare account for free and hit this API. So, you know, just, like, connecting the dots at, like, 1 a.m. in the morning here. It's like, OK, so is this, like, I just need to create a Cloudflare account, which I already did. I just uploaded the worker code, which I already did. And then you can just send emails through mail channels for real. And, yeah, that's basically how it works, which is really weird. And then there was this other user in the same community forum after all, like, the snarky comments also asking the same issue about worker impersonation, which I still don't understand at that point. And the person's like, hey, so I created, like, a Cloudflare worker that demonstrates this capability, right, that demonstrates this partnership between Cloudflare and mail channels. And it's just an HTML form where you just put in the contents of the email, right? It's publicly available. I blacked out the URL because I don't want you guys running up this person's Cloudflare bill. But it's publicly available. And you just put in, oh, sorry. It's publicly available. And you just put in the content of the email. And you just submit. And you send the email. Which, okay, and I'm like, okay, for testing purposes this is fantastic. And I guess since I'm completely nerd snipped at this point, I'm just going to, like, what's the first three or four test cases that I can think of in order to possibly figure out, like, what these other people are talking about in terms of impersonation. So test case number one, what happens if I just, like, put a domain that doesn't exist in the HTML form of the worker. So I put in, as a sender, test.waterhawker.com, which is a domain that didn't exist at the time. And I get an error back saying, hey, failed to send email because the domain doesn't exist dummy, which, yeah, makes sense. If this worked, that would be completely full bar, right? And then how about a domain that does exist but I don't control? So as the sender, then I put in test.example.com. And it gives me back null. Yay. I don't know what null means, but turns out null means it works. So, and I got the email, right? But it goes to spam again, which is normal because I don't control the domain. So I'm like, okay, this seems completely normal. What are these people talking about with impersonation? And I don't know much about email security, but I look up the headers and they're like, yeah, it's fail, soft fail, everything's bad, like, go back, whatever you're doing, stop doing it. But test case three, I'm like, okay, what's the next logical step? What happens out of sheer curiosity if I use a domain that actually uses this thing called mail channels because I still don't know what the hell it is at this point, right? So okay, websites that use mail channels. And at this point, I'm just thinking, you know, I've never heard of this. This must be like some bottom of the barrel email service that maybe like your grandma used in the 1980s or something, right? Nobody, maybe like a thousand people use this if not less. Nope, nope, nope, nope, nope. So two million somewhat domains, at least according to builtwith.com, which is a site that like aggregates technology that a bunch of like websites use and stuff. This might be a little small there, but there's some, a few heavy hitters in terms of people who use this mail channel service is like Boston.gov. There's no pad++.org, which is really funny. There's, and then everything else though is more like just random ass websites that hosts everything and everything. And I really like builtwith.com because, you know, if you were like someone trying to target people, the filter, you know, mail channels, websites with estimated sales revenue over one million dollars just really just preem stuff right there. Turns out I didn't even need to do this because mail channels also has a list of all their customers on the website, yay. So then I'm like, okay, so then I go back to the worker and I put in like, you know, lobsters at Boston.gov because Boston.gov was the one that popped out and, you know, go bigger, go home. Yeah, and it goes straight to my inbox. No, doesn't pass code, doesn't collect two hundred dollars, just goes straight into my inbox. And on top of that, if you take a look at it, SPF and DMARC both pass. Okay, just to be clear, at this point, I'm like, this is a worker publicly available just on random on the internet that anyone can hit. They could just put it in the details of the email and they'll just be able to spoof any of these, those mains. And then, so I try another, like how about minus at notepadplusplus.org, right? That's, yeah. So, and then I try another, same deal, like goes to my inbox and another and another and another. There's a lot of humorous stuff that you can pull from builtwith.com about this. And, yeah, they all land in my inbox. So, at this point, I'm like, okay, this is obviously a problem, but what the hell is MailChannels? I've been, I've been using this thing for like at least a few hours now. I still don't know, like, the who. I know the how, I guess, but not the who. So it turns out, surprise, surprise, MailChannels is an email transaction of service. And just to be on the same page, transactional email is like your mail. So, like, these are emails going from robot to human. So, like, your password resets, your notifications, your emails, newsletters, that kind of stuff. But what was really weird and just, like, really confusing at the time is that also they're sort of like almost like a cybersecurity company. Well, at least, like, they're trying to market that, yeah, we're an email transaction service, but we also stop, you know, the bad hackers with the spam and stuff, which is very ironic because, you know, the bad guys. But, you know, you find out too that when you start digging into the MailChannels website, it's its own little microcosm, you know, like, it's like a multi-universe of things that you never really thought could be possible. Like, you got people putting, like, RDP credentials in the comment sections of blog posts, you know, like, it's its own little universe of things that you never knew could be possible. And it turns out MailChannels, I was the ignorant one because it turns out MailChannels turns out MailChannels turns out transactional space. It's got 42% of the market share, and it's got double, more than double the amount of domains or clients rather than, like, Sengrid, MailGun and all the ones that I knew that I've heard of before. But MailChannels turns out to be double, more than double the bit like Sengrid, for example. So, at this point, like, I'm like, okay, how is this possible? I know some of the basics, and just so we're on the same page, like SPF, so you've got to know is that in every email there's like two front fields. There's one in SMTP, at the SMTP level, and the one that the user sees in the actual email. So SPF, aka Center Policy Framework allows you to set a security control on the front field in SMTP, so the one that the user doesn't see. And it basically just allows you to say, hey, these are the IPs and host names that are allowed to send email on behalf of my domain, okay? So this is what it looks like in practice. It might be a SPF record of Boston.gov, and there's a bunch of IPs that basically are saying, hey, these IPs are allowed to send emails on behalf of my domain, but there's also an include statement that includes relay.mailchannels.net, which I'm like, okay, that kind of makes sense because, like, you know, they use mail channels, right? And then I try another SPF of another domain that builtwith.com uses it, same deal. Always had that include statement with relay.mailchannels.net, try a few others, same thing. And lo that part of the setup process of using this mail channel service that they tell people to put this include statement in their SPF in order to use their service. But the thing is if you start thinking about it, right, that also means that all of their customers can spoof each other because if, like, they all have the same SPF, that means all of the other domains that have the same SPF are authorized to send on behalf of each other, right? And couple that with this Cloudflare worker thing, it's almost like an open relay situation where anybody can just go to the Cloudflare worker URL and just put in the email details that they want to see and bam, you can just spoof their emails. And I'm like, okay, there's no way. This is a little bit too simple. How has this not been found out before? It turns out people back in 2016 were already saying, doing the same calculations like I was doing, I'm like, hey, website A is using mail channels and website B has the same thing. And again, mail channels in the comments section, they're like, yeah, so the great thing about using us is you just call us and we'll stop the spammer. So, and again, I don't want to misrepresent, this might be, this was 2016, so they might have some other stuff, but this is a fine situation in my head going off here. So I'm like, okay, these guys obviously know about this because people were complaining about 2016, but I'm just going to email them, they had no official vulnerability reporting channel, I'm just going to email them saying, hey, I found some stuff, whatever. And I email them, and within two minutes the CEO replies to me, like this guy had this email on speed dial. It was crazy, I thought they were using chat GPT for a second. And he was like, yeah, so you're probably talking about the SPF issue, right? Yeah, no, we know about that. We can email them about, okay, but you got the cloudflare worker thing now, don't you think that requires a little bit of a different kind of thinking, at least mitigate that? And they're like, no. And radio silence after that. There was no response. And at that point, I'm also questioning myself because it's like, wow, okay, this guy seemed very assertive. Am I the idiot here? Is just how these services work? But turns out no. Other people, other companies like SendGridMailGun have a bunch of stuff that solves this situation completely, especially regarding the SPF headers. So they send identity verification, which is basically like what you do with Let's Encrypt certificates to prove domain ownership. You have dedicated sending IPs, which allows you to actually put unique SPF records in your DNS text record. And then actual authentication on their API, which ties back the verified domains when you actually try to send an email through the service. And this is what, if you try to do the same thing with SendGrid, for example, you basically, you put in the API key, you have to first verify you own a domain. But if you try to send an email from a domain that you haven't verified you own, it just says get out of here, bucko. This is not how this works. Stop doing this. You're not allowed to do it. So at this point, I'm like, okay, I need a bigger picture and I don't understand stuff. And I heard through just random research that there's this thing called Project Sonar from Rapid7 and they aggregate internet-wide data regarding HTTP DNS and stuff. So I hit them up in order to get access to this database in order to like check, like check all these assumptions of like, hey, are two million domains actually using this? Like what's the, what's the, like another very important information if we want to go forward with this. And so I hit them up and they give me access and not only do they give me access, they're like, hey, yeah, we're going to help you with this because this is really weird. So shout out to these people of our Rapid7, there were a few that I think don't work there anymore, but they used to work at a time. So shout out to them. And once we start digging through data, it turns out builtwith.com is accurate. And there are around 2 million 200 domains as of January 2023 that use, use mail channels. And at this point Rapid7 reaches out to them as well as part of the standard vulnerability disclosure process. And they're like, hey, like, you know, we're working with Marcello now and the CEO again replies in two minutes saying so we don't consider this SPF thing an issue. But this is the piece of the puzzle that we are missing here. Most of our clients are web posting providers that don't necessarily own the domains that they send emails from. Okay. So it's a feature. So we have to understand is that apparently there's a niche market out there for web posting providers to send emails on behalf of their clients. And mail channels is sort of like a middle man in order to do that. So it's a feature. Not a bug. So it turns out you're probably asking yourself, how do they stop this from being like Wild West? Well, mail channels has a bunch of like compensating controls at least, you know, according to them that they do like signature checking, math, statistics, trends, IP domain reputation. They also analyze the email responses from people that like receive the email. So like if that means, I don't know if that means like if I just tell someone to fuck off, do they block them? Like, I don't know. I'm not sure how that works. But they also do like OCR stuff. But okay, fine. I couldn't really tell you how good these compensating controls are because none of our testing, like none of the emails were blocked. We probably sent like a hundred domains between me and Rapids, 100 emails between me and Rapids 7 and none of them were blocked. That being said, it was our emails were clearly labeled West, right? So this might, I don't want to misrepresent things. However, I did try to send myself like legit phishing emails and they weren't blocked. So I don't know. But then he says something very interesting. He says, domain owners are welcome to secure their domain against impersonation by signing messages with Decim and setting up an appropriate DMARC policy. So the mail channel is basically saying, yeah, I mean we have this SPF issue, but you just set up a DMARC record in Decim and you're fine, nobody can impersonate you. But here's the thing, we've got Boston.gov email, SPF passed, but also DMARC was passing as well. So what the hell is that all about? So DMARC really quickly is a way of putting a security control on the from field that the user does see. So when we're talking about DMARC alignment, we're talking about, hey, does the from field that the user does see match the from field in SMTP and does it match also any domain sent with any Decim signature, right? So that's when we talk about DMARC alignment. And in order to test if DMARC does actually stop impersonation from this, we had to grab a bunch of mail channels, customers, domains that had DMARC setup and Decim setup, right? In order to test that. So it turns out out of the 2 million domains using mail channels, only 407 actually have any DMARC record whatsoever, right? And out of that only 105 actually use Decim. So this whole encouraging thing for customers to do the right thing is definitely it needs a little bit more encouragement if you ask me. So test case number four, right? So this is the obvious next step. It's like, okay, let's try to spoof an email from a domain that does use mail channels in their SPF but also has DMARC and Decim setup. Gits.com, I don't know what the hell this is, but they are serious about email. They are using mail channels but they have DMARC set to strict mode in regards to Decim alignment and their SPF record. So what this means is basically if the from field doesn't match the one that the user sees in the email that doesn't match the one in SMTP and doesn't match the one in Decim signature, it just rejects it. The end person doesn't even get the email at all. So this is like very serious about email stuff. So Gits.com and it goes straight to inbox. At this point we're like, okay, I don't know what's going on here and it turns out that DMARC and Decim don't really actually fix this because DMARC passes if SPF or Decim passes. The OR is the important part there. As long as you pass SPF you're also guaranteed to pass DMARC. That's the gist here. There's no actual proper way to tell receivers to strictly enforce Decim apparently at least from what we understand. So in summary you're also guaranteed to pass DMARC by using the Cloudflare worker that uses mail channels and we verified this really quickly as well through MailTester because if you just send the email through MailTester which is a service that actually tests the delivery, the chances of delivery every email you can see, hey, DMARC pass, SPF pass and we get a 9 out of 10. We're good to go here. There's no problems here. We get Doc the point for missing Decim signature but it'll still hit the inbox. At this point, you're probably wondering but wait what could there possibly else be? I'm here to tell you there's more. While analyzing the emails, we found a bunch of ARC stuff and we weren't really sure what this was. We've never seen these headers before in an email. We live as ARC seal, ARC message signature, ARC authentication results and we were wondering what is this? I've never seen this before. Let me introduce you to ARC authenticated receive chain. That's what ARC stands for and I quote here, ARC allows an intermediate mail server to sign the message's original authentication results so that even when SPF or Decim fails at the receiver end, the receiver can still check the chain of authentication records to determine whether the message can be accepted. What the important thing to know about ARC is that it guarantees chain of custody. It doesn't necessarily mean that the email wasn't spoofed. ARC was made specifically for email forwarding scenarios because if you want to send a newsletter out what happens is that the newsletter service sometimes modifies the body of the message and stuff with unsubscribe links and subject links and that kind of stuff and so that makes it impossible to use Decim for example in order to actually forward that mail securely. It's a relatively experimental protocol like it was written up I think in 2016, it was published in 2019 however that hasn't stopped some few brave souls in adopting it and by few brave souls I mean like Gmail, Outlook, Zoho, Fastmail, like all the big ones and Protomail, new which I found out which you'll see in a second, it's pretty hilarious. So this is what ARC looks like in practice so when you want to forward an email ARC basically records the authentication results hence the ARC authentication results header each hop the email goes through so like you send it from your email server it gets sent through multiple other email servers each hop puts the AAR header the AMS header and the AS header each step of the way in the email in order to record those results and for the sake of this talk we're only going to talk about the AAR header, the AR header because that's where the juice comes in and again like ARC is meant to determine that the chain of custody hasn't been broken in the email so like the message hasn't been tampered with it's not really meant to it's left up to the end receiver to determine if the email was spoofed with the ARR header so the end receiver has to look at the ARR header to see if SPF, DKIM and DMARC results in that header to determine if the email was spoofed or not so according to the RFC this is what an AAR header is supposed to look like so you got your hop which is the I property there and then you got the results of SPF, DKIM and DMARC so you can see in the RFC example they all passed and the end receiver has to take these results and interpret that in the calculations of the spam score in order to determine if the email should go to inbox or should go to spam this is what mail channels AR looks like header looks like so basically they're not checking SPF, DMARC or DKIM at all and what happens is they put in these properties that aren't really necessarily like representing what the ARR, at least what the header is supposed to do they put like this off equals pass what off, there's no off you just do this you just put the workers public you don't need off to do this so they don't actually check the SPF, DMARC or DKIM results and at this point we're just like please why can't you just be normal I don't know this is the weirdest freaking thing we've ever seen and it always claims off equals pass in the AR header so we were really confused about that and unfortunately though because it's left up to the end receiver to take this information and calculate the spam score with it it's really impossible to know how like putting bad values in this header will influence like email delivery so with Fortinet for example Fortinet is a good example of anything to be clear however they have documentation out there that states check this check box in our product and we can basically override all of the SPF, DMARC and DKIM results with the results of the ARC header so you could potentially so it's great, it's fantastic and again there's no way to actually know how this gets interpreted at the end of the receiver unfortunately but what we found through research is that the presence, the sheer presence of ARC passing in the email headers guarantees a better spam score and we confirmed this with Protonmail because Protonmail actually gives you the spam score result like it breaks down how it calculated the spam score with Gmail and Outlook there really isn't a good way of knowing that however in our tests it seems like it sort of behaves the same way so ARC passing generally guarantees a better spam score so if you're like conducting phishing engagements all you have to do is adopt ARC you'll have a better chance of landing that email in the people's inbox Little Red Team Pro tip right there but as a consequence of this which is very interesting is that if a domain doesn't have any SPF DMARC or DKIM record at all using mail channels you can actually potentially spoof them at a higher success rate and then this sort of increases the blast rate is a bit where you can basically spoof emails from domains that aren't set up to send email and you have a very high chance of actually landing that email in the inbox so this opens up the blast radius from like 2 million domains to like over 3 billion which is very interesting and again like the caveat being as long as the end service adopted ARC here you have a higher chance of doing this which is very interesting so in order to prove this I was like okay well first off I have to find I have to find a domain without any SPF and DMARC record which is pretty easy but it was one in particular that was super interesting to me and about that time my black hat talk about this got accepted so that was really weird also because like I didn't actually submit the black hat talk so it turns out I spoof black hat.com so black hat.com so black hat.com didn't have an SPF or DMARC record until February 2023 and because proton mail which is the service I use for my mail takes ARC into consideration through the cloudflare worker that used mail channels I was able to spoof black hat.com because of their adoption of ARC proton mail calculated that into the spam score and it just landed straight into the inbox and these are the headers to prove it where you can see like proton mail is like okay black hat.com doesn't have a DMARC SPF or decom record right so that adds zero to the spam score it's neutral but hey ARC passed so hey that minus one and apparently that's all that was needed to get that mail into the inbox that little minus one and again like there's no way of knowing this outside of proton mail because Gmail and outlook from what we've seen doesn't actually give you the spam score calculations like this but yeah this is very interesting so another disclaimer before I do the demo here don't do crimes again but yeah I'm basically now this is public where you can go to spam channel that hacks with three x's that worker.dev and you can basically spoof all of mail channels domains and any domain that potentially doesn't have a DMARC SPF record and this was based off of Isangun's cloudflare worker code which is the original person who wrote this shout out to him or her and then only test on domains you control the code for this will be available after a talk as well so quick demo here one second it's thinking about it I'm gonna try that again wow demo guides really hate me how about this one well there are videos here I don't know we're gonna be able to fix that in time but maybe we will I don't know well let's see let's continue the presentation is there am I allowed to connect to the internet this point I think I'm not gonna get invited to black hat so I think at this point I'm just alright well if I don't know I don't know what's going on but I'm gonna continue and maybe somebody can come up here and figure that out let's see where's the presentation button perfect I'll be able to show you a video of this if not you can literally just try it yourself you just go to that URL so disclosure timeline this all started in November of 2022 initially contacted mail channels and told them hey you know this is a thing you should probably reconsider considering the cloudflare workers you did this partnership with cloudflare now and you got the cloudflare worker thing going on and no further response after that January 2023 they were contacted by rapid seven and they were again response immediately saying we don't consider this an issue but then no further response then in June of 2023 I sent the final update to them saying hey I got accepted at DEF CON and I summarized all the findings and everything again no response and then July of 2023 my mail channel sends me a random email saying hey we noticed that you're speaking at DEF CON can you please share your findings with us to which I said well I mean I've been literally talking to your CEO for since November of 2022 but okay so it turns out my vulnerability reporting was going straight to spam which is very ironic I should have used mail channels for that apparently so yeah like a gmail filter on that was literally sending my emails to spam for some reason but after that they basically said hey I had we introduced this thing called domain lockdown mode so the take away here is as of June 2023 if you're a mail channel's customer you have this domain lockdown record that they implemented which basically allows you to specify the worker the cloudflare worker that is actually allowed to send emails on behalf of your domain or you can completely disallow mail channels from sending emails from your domain at all so that's nice the kicker here though is that you can still send emails without the domain lockdown record so it's not like you don't need a domain lockdown record in order for people to randomly just send emails from your domain so you need to actively go in there and put the record and otherwise people can just spoof your domain it's to be announced when this will be like a default thing where you're not going to be allowed to send emails through cloudflare through mail channels unless you put in the domain lockdown record so as of now you can still spoof all of their customer domains with this and so if you're an org that uses mail channels you should well if you don't know you should check your SPF record number one and if you do use mail channels put in the domain lockdown record you should probably go through all of your also domains and just make sure that you have an SPF record and you and if it's a thing you can also have like you can potentially display a banner if an email that doesn't have a decim signature comes from a domain that has implemented decim I've never seen that I don't even know that's a thing but that's potentially something you can do if you're an email service provider like Gmail Outlook don't just bump the spam score of an email just because ARC is passing that's that I don't know like why that's a thing but you should probably like not do that because I don't think it's that's how the protocol is intended to work and if you're an email transaction service just don't do this like it just use sender identity verification and dedicated sending IPs because like that this solves this entire swath of problems and everybody uses this except mail channels apparently and so the final take away is email security is very critical it still relies on users and orgs to do the right things and ARC potentially could incentivize like a trend of gaming the system which is something to consider as well and then finally I want to shout out two researchers Shanghai and Gang who basically is who I stole the awesome graphics for DMARC and SPF explanations and stuff and they did a lot of the initial research into ARC as well and then I put the code that I based the tool that I released off of and a huge shout out to the RAPIN7 folks as well to help me through this research thank you perfect I just want to double check that