Søren Brandbyge & Adam Burns on Email and DNS

Jeremy Snyder: All right. Welcome back to another episode of Modern Cyber. And we are going to be talking about something today that I think all of us use every single day. I think literally every person using the internet uses this thing every single day. And that is email. And we've got a two part conversation teed up, the first around the origins of email, how it came to be, the system that we know and love and hate today. And then the second part is going to be around DNS, specifically DNS around email. What are some of the security considerations there? How should we think about that? And for that, I've actually got two separate guests that are going to be joining me, one after the other, to talk about those two different components. I'm delighted to introduce my first guest today, and that is Søren Brandbyge. Søren describes himself as a security freak looking for ways to simplify things. And I think that really undersells his experience and his career, because Søren was involved in RFCs around email way back when. So Søren, thank you so much for taking the time to join us today.

Søren Brandbyge: My pleasure. It's really nice to be part of this, and I hope I can bring some good stories to the table.

Jeremy Snyder: Well, let's start with those stories, because I'm really curious. You know, I guess technically the internet predates email, but for most people, email is often the very first application that they get when they get connected, or they get, you know, quote unquote, an internet account. An email address is usually what comes with it. And, you know, for people of my age, that was like with your ISP, with AOL, whoever. In my case, it was my university that gave me my first email account. But talk to us about those early days. How did email come about?

Søren Brandbyge: Well, you could say by curiosity and by accident. It was an experiment that actually happened to go with the, I owe a lot to the old guys. Forgive me, because I'm going to make this very, very simplified and omitting a lot of interesting stuff. But basically it was the idea, uh, how about we have some computers and we have figured out how to have some networking and some communication going on. Uh, what can we use it for? And one of the best, and in the first ideas, was actually, let's send a message. How can we go about that? What do we need to do to send a message? And, uh, well, they were not primitive systems, not by far. But the tools that we had at that time were quite limited. And especially the character set was quite limited. So we had to make do with a small set of the ASCII table. Um, yeah. And a few very, very bright guys went on and worked on how to figure out to do this. And now I'm really jumping in the story, but they actually did succeed, and they did send some messages. And it pretty quickly took on. And, uh, I know I was quite new in the field, but I was working a little bit on, uh, it was written by, it's fun, it's interesting. And we could see a lot of interesting issues here, and, yeah, things we could fix. One of the problems we had quite often with these systems was we needed to coordinate stuff. Okay, so sending from one admin to another was quite nice. But pretty quickly one of the first issues came up, that we didn't have a star configuration, or we didn't have an all to all communication. It was a chain. So one of the first issues was, how do we actually get a message from A to B to C to D? And, uh, so the very first try, you had to know exactly how to route your own message. You had to tell the computer system how to deliver to the next system, to the next. And in the end, it should end up hopefully in the right inbox. And again, layer upon layer, a lot of evolution there. And alongside that, smarter people had figured out we should probably have this codified, specification, like most of all the other stuff we were dabbling with, specifications were what was needed. So there was actually a little bit of a, what you call a race, between, A, using it and evolving it, and on the other hand, actually doing the specification, creating that. Um, I tried to dabble a little bit in both ends, being part of a research institute, being the single one that could actually recognize a computer when I was facing one. So it was hectic. It was fun. But wrapping that up, it's actually the same status we have today. It's a specification, layer upon layer of specifications. There are so many gray areas. There are so many murky spots. Um, well, we are using emails for everything else than basically what it was supposed to be used for, and simply sending a communication from one to another in the form of a text.

Jeremy Snyder: Fair enough. But I mean, you know, if you think about that, postal mail was probably pretty much the same at the beginning, right? It started with, you know, me on some journey across the Atlantic, wanting to get a letter back to my loved ones to tell them I made it to the other side. Okay. And that's basically just, you know, a text based message from side A to side B. But then also, like, mail very quickly evolved into sending out catalogs and doing mail order commerce and everything like that. So I guess in a way, it's pretty natural that email also evolved in a similar pattern.

Søren Brandbyge: Um, yeah. Uh, yes and no. I would say if you were a little bit pragmatic and sat down right now and say, okay, I've got all these applications, all these purposes, kind of communications I want, I want to design it bottom up to actually work exactly like this, you would probably not come up with something so incredibly simple as email. Because basically email, what people don't understand is, I create some message and I toss it out, and I really, really hope somebody is catching it and helping me getting it delivered to the right person somewhere, somewhere. So, and that's the best we can do nowadays.

Jeremy Snyder: But I mean, that's not one hundred percent true. Like, we have deliverability checks and we have traceability and we have tracking pixels and all these things that, you know, arguably were never intended, but they are, they are things that exist.

Søren Brandbyge: It's patchwork upon patchwork, and it's never designed into it. So every time you do something like that, like tracking pixels, like delivery receipts, etc., there are so many ways you can actually sidestep and do all kinds of trickery based upon that. It's not designed into the communication protocol. It's not part of the email. It's stuff. And then, going back to my urge for simplifying stuff, it is basically, um, it's just text. It's like text on your mobile. Uh, yeah. Again, you overload it with a lot of stuff. It's like if we should have done the same thing with our housing, uh, you would say, okay, I got electricity in, okay, I want a phone line, why haven't you cable? It's just, uh, put the phone on the same electricity cable network. Okay, let's put it there. How about my TV? I'll put it there, etc. Well, you wouldn't do that, because it's different kinds of monetizing, different concepts. But for some reason, when it comes to internet, we have already, always have the urge to sort of run ahead of the specifications. There's so much going on, and we keep lagging, and, yeah, yeah, I'm devoting, yeah.

Jeremy Snyder: No, no, no worries at all. So I want to check in on something that you said. So, as you said, if we were designing it for the purposes today, we definitely wouldn't end up with what we end up with. And if I think about kind of my use cases for email, I really have kind of like three. One is for internal communications inside the company, where I just need to kind of, you know, from my position as CEO, broadcast messages out to the organization, announcements, hey, we have a new conference, hey, we have a new employee, whatever the case may be. Second is I have my external stakeholder communications. And in my case, that's like my investors, my lawyers, my partners, etc. And third is for sales. And we, you know, we do go out and we do sometimes reach out to organizations where we think we might be able to help them solve a problem, in our case, of course, around AI adoption. So if I'm hearing you right, that would be like three separate either applications or three separate channels of communication inside one application. How would you think about it today if you were starting from zero?

Søren Brandbyge: I would probably try to make an analysis and figure out, okay, what would the base platform be for communication? Um, and email is failing the first and most basic one. Emailing has not a full handshake. You don't have a full handshake along the line of where data is passed. Because, well, sorry, I'm being technical, but basically one server communicating with another and going to hand off an email, it definitely gets the connection and is accepted, okay, you may pass the email. It's only when the email has been passed, and the accepting server says, okay, I have the whole email, are you going to deliver it, for you, and then drop the line. At that time, you can say you have some sort of handshake. But after that you don't know what it will be doing with that. Um, is it going to drop it or not? The specification only says that now this server that has accepted it also has the responsibility. But you don't have anything within the specification telling you, or the systems, about what, then, how can I actually get a reply back or get confirmation? What's happening in the value chain until delivered? Um, so it's very async communication, and you can never, never really trust that anything has been delivered. I would start looking into that. And there are other protocols out there that actually could do the same job. You could actually just make a diversion on the SIP, um, which is being used, by the way, for carrying IP telephony. Yeah. So that would be one. Okay. It's pretty real time, or close to, but there's no need for it to be. So you could side channel that and say, okay, I've got a good communication channel just to say, uh, it's not because I want to see, but there are many ways to do it. And we could, instead of reinventing, we could actually take some base work from there and then build a layer and say, okay, emailing, or communication, these types, we should probably classify them. Right now, it's only, well, it's in the header of an email, but there's nothing in the specification anywhere that tells you, a hard code, how you should actually interpret this classification. It's just a hint, on, you should probably take this as very important, or this is just junk. But who knows?

Jeremy Snyder: Yeah, yeah. And, you know, in the second part of this episode, we're going to talk about SPF and DMARC and DKIM, and how they're like partial attempts at a solution in this space, or in this direction. But to your point earlier, email is, like you said, it's this thing that you just throw out into the universe, and it's pointed at some recipient, and you just hope that it gets to that person, you know, to that destination and then to that target individual. What's your view on, like, the biggest problems around email today? I think if you asked anybody, they would tell you it's basically two things. It's, like, spam, of course, um, but then it's also like phishing and business email compromise. And I think business email compromise, by the way, that's not an email problem, that's like a user credential problem, right? But what do you think about, like, spam and phishing? What's the right way to think about them as a problem?

Søren Brandbyge: I would say spam, uh, yeah, whatever, it's a problem we've brought upon ourselves, because, again, we are using the wrong communication channel for the wrong things. It's an open invite. And there's actually very little we can do. We can patch by DMARC, SPF, all that stuff. We can try to encrypt, we can try to use cryptographic fingerprinting, etc., etc. But basically, um, oh, my point in this is, there's absolutely nothing you can say about an email communication that you can use to differentiate between what is, okay, it's legit communication, or it's a criminal or whatever. There's absolutely nothing, because, well, we never thought that into it. So let's refer back to the history. Um, one of the reasons why it worked so well, and why it actually was developed so fast and got spread out, was that systems back then were built based upon trust. We trusted each other. There was no need for us to put in any kind of checks and balances on, is that okay? Hackers, crackers, all the bad guys came later on. And at first they were just a nuisance, and they were not big, big time criminals, as we see nowadays. So what we did was we built a lot of systems, not just email, but most systems were actually based upon, well, we trust these systems. We trust that you get an error of some sort and you can act on that. And you trust that others will utilize the systems, with errors, until they were fixed. And that's not the case, not only, well, we have all the bad guys actually looking for this and trying to be covered.

Jeremy Snyder: And I mean, should we be implementing more of a trust system, like we're doing, this DNS stuff that, again, we're going to talk about, but, like, you know, should new email senders have to go through like a KYC check, like a know your customer check, like you do at a bank? I mean, if I set up a new domain on Google or on Microsoft, like, is there no responsibility on their side to verify me?

Søren Brandbyge: It could be one way to go. I would say, again, simplify stuff. I think identity is one of the crucial things. But identity that's open to the world, with all what that encompasses of risk of identity theft, etc., etc., is probably not the way. But systems that have been developed that actually give you the ability to prove who you are and you are okay, etc., and give you the ability to exchange that kind of identity with others that you trust, well, yeah, that's doable. And that would probably be a way to start building stuff. I would say we might be forced to go down that path, with all the things going on in the world, that we will probably end up, not like anyone to be able to pinpoint exactly who you are and where you are and what you are doing, unless you, by yourself, actually give that information. Uh, yeah. Right now, the systems as they have been created, there's no way you, as an individual or a system, can protect yourself. Everyone can fingerprint and pinpoint you. That, well, basically the Google business model. They can connect virtually anyone to anything, if they want to or if paid for to do so. So, yeah, I know it's going to disrupt a lot of business models, but I think that kind of simplification is what we need to do. But there are many ways it could be done.

Jeremy Snyder: Yeah, yeah. So we've got just a couple of minutes left. And, you know, we've kind of talked about, like, some of the weaknesses that are basically, like, design flaws of the current email system. And I guess we all just accept them, because nobody is talking about, hey, let's tear email down and let's rebuild it, or not that many people, and certainly nobody who actually has control over email, not Google, not Microsoft, who are really the big two players in email at this point. What do you think are things that people don't understand about email today that you would share with them? And what do you think are some of the biggest challenges organizations are facing? And how do you recommend, like, any company that's getting online, you know, just being formed, getting online for the first time, setting up their email, what recommendations do you give them?

Søren Brandbyge: Three questions, but the one answer that actually covers all. Well, people need to understand, it should be mandatory training for CEOs, and all the way down, that email, that kind of communication, is basically sending an open postcard out into the world. There's a lot of stuff you can send like that, and it does have a lot of value to be able to simply communicate and give messages to people all around the globe. That's nice. You can also send ads like that. People can delete them if they don't want them, etc. But on the other hand, and that's why I say, okay, time out guys, because, yes, you do have a responsibility yourself, as a business owner, etc. Don't utilize a system that's never been built to be error proof. Use it for, process data or processes or stuff that cannot be sent, shouldn't be sent, as an open postcard. Usually other systems that are more trustworthy and more efficient systems you can use. And you should probably start having that. Uh, secondly, second part of that is that I've seen many companies that rely so much upon emails that they've forgotten that it's actually possible to write a piece of paper, put it in an envelope and use the post, uh, email, or sorry, the postal system. And probably there are some communications that should be sent like that. Please have that as your plan B, so you are not stuck with one technology, and if that goes down or something goes really bad, then you are lost. You know, try, have a plan B. That's the security man in me.

Jeremy Snyder: But, Søren, like, you're in Denmark. Didn't you guys just end your postal service?

Søren Brandbyge: Yeah, and it's not for my good. Well, I can assure you, I think that's the most stupid thing. Well, we have a private carrier that has actually taken over. It's the more old official, but we do have a postal system. It's just costly, you know?

Jeremy Snyder: Yeah, but you do have a backup option. Like, there is another option if needed.

Søren Brandbyge: Indeed. Yes.

Jeremy Snyder: Yeah. Awesome. If you had any closing thoughts for today's conversation about, like, the history of email, I certainly would, take my personal takeaway from this is, one of the things that you said is, like, every email you should think of it like an open postcard. And I know, you know, we talk about, hey, email goes over encrypted channels nowadays, it's end to end encrypted, or some providers will tell you that it's end to end encrypted. But, like, I think your point on this is much more valid. Like, you don't have anything built into the design of email. There's no guarantees of that. And there is nothing in the design that is built to give you that level of certainty, or, to your point, the validity of the sender that you're getting it from. It's a postcard that arrived that claims it's from, you know, Jeremy or from Snowden or whoever, but you don't actually have any guarantee of that. So thank you for, you know, kind of correcting, I think, a few false assumptions that we all have around email. Any closing thoughts on email or its future?

Søren Brandbyge: Oh, yeah, indeed. Um, I think, um, more crucial than email, let's assume we somehow could figure out how to fix it, uh, recode, whatever, but it still relies, it's based upon a few other standards, created to make life simpler for us. DNS being one. If DNS is being tampered with or broken down or whatever, either we all have to start memorizing IP addresses that run the globe, just to get one hundred millions or billions of addresses, uh, it's going to go well, um, that's one thing. But secondly, DNS and email actually relies upon a second thing that's very human, that we somehow seem not to have been able to codify in a good standardized way. And that is naming conventions. Yeah. So try to think about those. And that's something that companies actually do have some control over, and they can do a lot to secure that, if they do that. So if you secure your naming conventions within your company, and then your DNS, then your email, then you're pretty well off. And then there's a side note to that. That's cryptography that actually somehow is interwoven with all this, and rely upon each other. Um, that's yet another topic for a few hours' talk. Yeah. But just to mention, it's a family of stuff. If you do something with one of them, you should probably remember to do something with the rest of them, otherwise it might not be worthwhile.

Jeremy Snyder: That is a great point to end today's conversation on, Søren. And thank you so much for sharing your expertise, taking us through a little bit of memory lane on the history of email and an explanation on how we got to where we are today, which, like I said, is kind of our love hate relationship with email. We all live with it, we all use it, we all get benefit from it, but we all have frustrations with it as well. And understanding that the system is not designed, or was not designed however many years ago, for what it is doing today, is a great reminder. And we will pick up that thought in the second part of our conversation around exactly some of those topics that Søren mentioned, DNS, etc. So stay tuned. We'll continue the conversation.

Jeremy Snyder: All right, welcome back, and let's pick up the conversation, changing gears from the history of email to where we are today. What are some of the problems that we're facing? How can we try to navigate this situation better? And I'm joined by Adam Burns of Black Veil Security. Adam's been on the show before, on our breach series, talking about some of his experiences from a past life in the MSP world and dealing with a ransomware event in some of his customers. So if a name and the face are a little bit familiar, that's where it's from. But Adam has started Black Veil, and I'll let him talk a little bit about what Black Veil, excuse me, is setting out to solve for customers. But Adam, thank you for taking the time to join us today.

Adam Burns: No worries. Thanks for having me, Jeremy. It's good to be back on the show. Um, yeah. So DNS and email security, as Jeremy mentioned, with another guest on the show, it's an old tech we've adapted and changed over the years and, you know, tried to secure it as best as we can. But today, in twenty twenty six, it's still a bit of a bandaid fix on top of an old technology. And we're finding, you know, weak DNS config and weak email security is being exploited at scale now with AI, and it's making it really, really easy. So what used to take a hacker a couple of weeks, they can do in a couple of minutes now. So, yeah, we stood up Black Veil to fight this problem, because it's, yeah, it's a big, big issue. And I think it's traditionally not on most people's radars. It's a big visibility problem.

Jeremy Snyder: Well, honestly, I mean, just to your point, I've been working in cybersecurity for a long time, and honestly, before I started talking to you, I heard about these different things, SPF, DKIM, DMARC, etc. I knew there were things, I knew they connected to kind of email security, but also deliverability and kind of like trust and authority for sending emails to larger corporations. But I think a lot of people don't really understand what these three things are, how they connect, and why they are kind of this patchwork for what Søren was talking about previously around, like, trust and identity on email. So could you give us, like, just start at a high level, what are these three things, in as brief a way as you can express them?

Adam Burns: Yeah, I think the best way to explain things to people who aren't technical is use an analogy. So I'll do that. So SPF, sender policy framework, if you think about that like a bouncer at a bar. He's got the guest list at the door, and he's checking to make sure if you're on the guest list. If you're not, he tells you to go away. If you're on the guest list, he says, all right, I'm just going to check a couple other things. Then he checks your identification, which is your DKIM. That's basically saying, all right, you've come from the right place, the ID is saying you are this person and it's been issued from the right place. And then the third check that the bouncer does is to make sure that you've come from where you've said you've come from. So DMARC basically protects a brand's outbound. It stops a brand from being able to be impersonated. So if you've got your DMARC set up correctly, at reject, what that means is that someone can't then go and send a spoofed email as your domain to somebody else. And, yeah, if you think about cybersecurity and breaches, from what I've seen historically, I would say eighty to ninety percent of breaches originate from an email. So, yeah, it's the most common way in.

Jeremy Snyder: Yeah, I think the numbers on that might be shifting a little bit with the discovery of vulnerabilities at scale due to, you know, AI scanners and whatnot. But still, you know, it's got to be above fifty percent of breaches here today are still happening because of email and email compromise. So I like that analogy. So SPF is kind of, um, are you on the guest list? DKIM is, are you who you say you are? And DMARC has, you come from where you are supposed to have come from? If I got the analogy correct, right?

Adam Burns: Yeah, yeah, perfect. Yeah. That's essentially how I would explain it to my grandma.

Jeremy Snyder: Okay, okay. And it's interesting because, like, you know, I've, from my own organization, you know, we're reaching out to a lot of companies and partners that we want to work with and so on. And I'm more concerned with deliverability than I am with somebody being, like, oh, I want to impersonate Jeremy at FireTail. We're a small company, right? We're not a big global brand that is, you know, kind of globally known and trusted, that people would want to be using our domain name to try to scam other people. So, like, that's maybe less of a kind of existential risk to us. But I worried about it more from the deliverability perspective. But it kind of solves both problems, if I'm hearing you right?

Adam Burns: Correct. Yeah. So when you get the SPF, DKIM, DMARC trio correct, that's basically the holy grail of email identification security. So when you send an email out, the recipient's mail server will run a bunch of checks. It will check your SPF, DKIM, DMARC. If you've got those set up correctly, it will score the email, you know, a much higher result. So the chances of it being flagged as spam are much, much smaller. Um, okay. And yeah, a lot of the sending services even out there haven't configured themselves properly as well. So, um, I won't name any specifics, but yeah, some of them, you rely on them for legitimate, you know, email source sending, and they haven't configured, they're incorrectly either. So often you'll send your email through another service thinking it's all good, and it's not. So it's a tricky and complicated thing to get right, but once you do, it solves so many different problems.

Jeremy Snyder: Well, let's talk about that, what you just said. What are the things that people get wrong as they go to roll these out? Like, what are the common mistakes that you've seen?

Adam Burns: Uh, the most common one is DMARC being left on p=none. So I think, okay, industry doesn't quite understand the DMARC record itself. It's not doing anything when it's set to p=none. All it's doing is flagging the emails that are being sent as your organization. But it actually requires someone to go in and look at, you know, look at those logs and identify the sources and then figure out whether they're legitimate or not. Um, so, yeah, if you get your DMARC record wrong, you can actually break email flow. So it's quite critical. It's a tricky one, and it's quite time consuming to get it right.

Jeremy Snyder: Okay, all right. So that's one. What about some of the others?

Adam Burns: Uh, SPF. Okay. Um, so what was, sorry, say that, what was the question again?

Jeremy Snyder: Yeah, so this DMARC example is one of the problems. What are some of the other problems that people get wrong as they're rolling out these three records?

Adam Burns: Yeah, okay, sorry. So SPF, um, the correct way to set your SPF is to identify the only sending services that you're aware of, that the legitimate ones, and put them into the SPF record. And then once you've identified them all, the syntax at the end should be set to hyphen all, which is a hard fail, rather than soft fail, which is the tilde all. And what that does is it means, basically, if it sets a soft fail, the recipient server that receives the message, it's up to that server to decide what it does with the message. Like, if it's set to soft fail, it can either flag it or not flag it. So it's always better to set it to soft fail, so the receiving server knows exactly what to do with it. There's no gray area, if you know what I mean. And DKIM, DKIM is often just not even thought about. So DKIM is a service that I think a lot of people don't realize exists. Um, so when you sign up for a sending service like SendGrid or something like that, they will offer to DKIM the email as well. And so what I'm seeing is people sign up for these services like SendGrid, but then forget to do the DKIM.

Jeremy Snyder: And just to go back to your analogy, DKIM is the 'are you who you say you are' aspect, right?

Adam Burns: Yeah. If you think of, like, the rubber stamps on an old letter, you know, the stamp, that's a stamp to say, yes, this message came from where it says it came from.

Jeremy Snyder: Yeah, yeah, yeah, the wax seal kind of thing, where the letter is closed with my seal and nobody else has my seal until, you know, it's come from me. Got it, got it. And on SPF, well, there's a couple of things I want to get into there, because it sounds like some of these things are really easy to get wrong. So you mentioned on the SPF there's the tilde and the hyphen before the all. Run me through that one more time. Which one is soft fail, which one is hard fail?

Adam Burns: So the tilde all is soft fail. And what it does exactly, it's basically instructs the recipient server to decide what it wants to do with the email. And if you see it's a hyphen all, that's hard fail. So the recipient server is always going to obey that, and it's going to drop the message if it doesn't meet the requirements.

Jeremy Snyder: Okay. And why would you not want the hard fail? Because, I mean, if you've got these three records set up correctly, it sounds to me like the hard fail should actually, you know, give me a little bit more, let's say, trustability with the recipient, where, like, they know, okay, FireTail, they've got the hard fail, so this message isn't coming from firetail.ai, you know, they've got their three records configured correctly, we absolutely want to drop that. What's the rub here?

Adam Burns: Um, so, sorry, um, could you repeat that last bit of the question?

Jeremy Snyder: Yeah, like, why would I not want the hard fail, you know, if I've got my records configured correctly? It seems like I would gain more trust with my recipient if I have a hard fail.

Adam Burns: Yeah. So there's three different ways to configure the SPF record. There's the soft fail, hard fail, and there's a question mark all as well, and that's the monitoring mode. So it's exactly the same as DMARC, where it's got three different stages where you start. Start at monitoring, progress to quarantine, and then move to reject at the end. It's exactly the same with SPF. So you, I don't think most people follow this, but you should be starting at question mark all, which monitors, and then soft fail, and then hard fail. So it's basically a stepped process. So, yeah, a lot of people would leave their organization at DMARC equals none and soft fail, because they haven't continued the journey and figured out what all the email services are, and, you know, moved it to reject and hard fail. It's basically the last step in the email authentication journey. So once you're confident you've identified everything, you move it to hard fail.

Jeremy Snyder: Well, how long should those steps take, and how do you go through those steps?

Adam Burns: Um, depending on the age and size of the organization, it can take anywhere from one to three months. So the first step is creating the DMARC record, p=none. The second step is actually sending the report somewhere. Traditionally the old way was to send them to a mailbox, but now you've got products out there on the market that just do DMARC. So you send all the reports to the DMARC aggregator, log into the aggregator, and you can then figure out from there what, you know, what all these email sources are.

Jeremy Snyder: And what is somebody going to see from a service like that? Like, what gets analyzed in that? If I'm sending all my DMARCs to one of these companies and one of these services, what are they actually looking at? And what is it going to tell me?

Adam Burns: Uh, so it's basically an XML report of every single email that gets sent from your organization. And then all of the receiving organizations flag the results of all of these messages, and these get aggregated into a DMARC, hole, so you can actually see, uh, who, not exactly who, but what service sent the email, what date, what IP address. And then you can, you know, dig into the results there, identify what's behind the IP address, etc., etc. It's basically log, it's like log files on a firewall, but for email deliverability.

Jeremy Snyder: And does it help me then catch if I've made mistakes in my domain configuration and things like that?

Adam Burns: It will help you with that. Yeah. So it will flag stuff that is not passing the SPF but passes DKIM, for example. So then, you know, okay, I've missed this source from SPF, but it's in DKIM, things like that.

Jeremy Snyder: Okay, okay. So that's some of the basics. I appreciate the walkthrough. Even still, now, after knowing you for a while and having used Black Veil, you know, I'm still learning things from this conversation. I want to change gears from this configuration to now thinking more like an attacker, and why this is like a security problem in addition to just a deliverability problem. So talk to us about, like, what are some of the things that you've seen or experienced where organizations have either been, you know, compromised or impersonated or whatnot by getting this wrong?

Adam Burns: Yeah. So the most common thing that I've seen in my time in the industry is phishing emails. And those get through organizations with weak email security, soft fail SPF, no DKIM or DMARC p=none. What that allows a hacker to do is send a malicious email. The recipient thinks the email is legitimate because it's come from, well, what looks like maybe their CFO or somebody else from within the organization. The email contains a link, they've clicked the link, the link asks them to put the password in and credentials for something, they put those in, and then bang, the hacker's got hold of their credentials. So that is often how these attacks start. It's not usually a zero day, it's often an email, and someone clicking a link they shouldn't have clicked on.

Jeremy Snyder: And from, like, a defender's perspective, if I'm the recipient, what do I need to do? Things on my mail server to, like, enforce stricter standards for incoming email? Or is this something that, like, Google and Microsoft just take care of for me?

Adam Burns: So, yeah, if you're using M365, they will have a default rule set which covers anti-spam and phishing and spoofing and stuff, but it's not the be all and end all, and it often needs tweaking. So the best thing to do is to not rely on default configs from M365, Google, etc., and actually have a look at the rule sets and have a look at your mail flow and analyze it and see what it's actually doing. These rule sets are often quite relaxed. So it's better to, yeah, create your own custom profile, or look for an additional filtering service like Proofpoint or SM, etc.

Jeremy Snyder: Okay, okay, okay. So we're a new organization, we're just starting out, we've registered our domain name, we're on either Google or Microsoft by default. We're probably, like, I think our mindset is generally just, like, hey, get to work, I've got to do the bare minimum to just get up and running, start sending emails, because it's such a crucial, critical service for business communication. You know, I might follow these steps. Okay, I need an SPF, everybody's told me enough by now and I'm a little bit more informed, I go through the DMARC and the steps to just create those records. But I generally find that, like, you know, people are lazy, they're not necessarily going to take the time to go back through, update these records, check them, or, to your point that we were just talking about, also, let's say, like, check my M365 or my Google Workspace configuration. Like, is there some kind of wake up event that's going to happen to organizations? Is there some kind of specific risk that people should be thinking about if they're listening to this episode right now, and they're like, yeah, that just described me, I set them up but I never went back. Like, what would you tell people about, like, why this is so critical?

Adam Burns: Um, I think it's traditionally been a forgotten area in the industry, and there's not been too many tools that actually focus on domains and DNS. So traditionally, people will buy a domain and forget about it, and they assume the registrar takes care of it. But it's not the case. So the best thing to do really is to make sure that you can actually identify every single domain within the organization. And actually, you know, answer the question, what is this domain doing? Should it be sending email? Should it not be sending email? Is it parked? Why is it parked? And then making sure you've got eyes on it twenty four seven. Because if you think about DNS, the internet literally cannot work without it. So if I can hijack the DNS, I can hijack your entire business. So the zone file should be the most important thing that's protected, in my eyes, because without protecting that, you can literally redirect an entire business.

Jeremy Snyder: Yeah. And there have certainly been cases of zone files being hijacked and redirected and domains being stolen. And, you know, some crazy stories, if you ever want one for just entertainment purposes, go read the saga of the sex.com domain, and how many times that was, you know, trademark claimed, hijacked, transferred, etc. Um, so some of that stuff is, uh, you know, is very, very interesting. And it is, to your point, I mean, it's existential. Earlier we were talking to Søren and he made a similar point that, like, email and DNS, they really go hand in hand. And without them, you know, we're navigating the internet with insane series of numbers that nobody's going to ever be able to remember, or, you know, really kind of organize or classify. And especially in the modern era, when we use things like cloud platforms where these addresses are changing so rapidly, you know, it's just not practical in any way, shape or form to even consider an alternative scenario like that.

Adam Burns: Not really, no. It's the nuts and bolts of the internet, and they're always moving and changing. So people need to have eyes on them at all times. And if you think about the AI and the agentic era, they will rely on the exact same things the humans rely on to navigate the internet, which is DNS. So, yeah, if those DNS records are incorrect or not watched, then they are the source of the problem.

Jeremy Snyder: Is it your opinion that, like, DNS records are more at risk nowadays because of AI? Is there any AI impact on zone files?

Adam Burns: Um, I just think the ability in which a hacker can do its reconnaissance on a business, the cost of it has dropped to zero. So that traditionally would take someone about two weeks to canvas a business, come up with a campaign to attack them. But now you can do it with AI, and, you know, you can canvas a hundred businesses at the click of a button and then get AI to design the campaigns for you. So while it might not be used to exploit or attack, it's used to gather information extremely quickly and correlate, and basically make the job of the attacker a lot easier.

Jeremy Snyder: Yeah. There's two aspects, as you were talking through that answer, two things came to my mind. Number one is, if I think about in the past, from an attacker's perspective, you've got the external view of an organization, like, let's say, blackveil.com. And I'm trying to think, like, okay, what kind of services could Black Veil have? You might have heard of something called the dictionary attack, where I just, like, use common dictionary terms. So, you know, think about common internet services. So we've got www.blackveil.com, but I might also think, oh, okay, you know, there's probably something like mail.blackveil.com and api.blackveil.com. And I think about these common services, and you can kind of create a dictionary, if you will, of what these common domain records might look like, and then just, like, test them all, gather the IP addresses, map out an organization. And, to your point, with AI, first of all, just generating all the list, give you the probable DNS entries for this organization, you know, that's probably a matter of a few seconds here. And secondly, to your other point about designing a campaign, well, figuring out, like, hey, you know, Claude, ChatGPT, Gemini, Copilot, whatever, go tell me what blackveil.com looks like and craft for me a message that is, you know, plausible, coming from Black Veil, as if I'm Adam, the CEO, whose name is also discoverable on there, and I'm sending out a message, like a scam message to other people, or a message designed to target an organization with spearphishing. Like, I agree, you're right. You know, it takes me five prompts and, you know, forty five seconds to come up with the content and the messaging and the image and the design of that email, along with, you know, looking, scanning your DNS zone file for vulnerabilities and, you know, maybe, like, an unmapped, uh, like a dangling DNS record pointing at an IP address that I can go try to collect somewhere. So, yeah, yeah, I think your point is, like, super spot on.

Adam Burns: Yeah. It's a scary world we live in. The internet is a bit of a, I think of it like the Wild West. You kind of can do whatever you like on there. So, yeah, it's a little bit terrifying. But I think the best thing people can do is keep an eye on these things and monitor them and watch them and make sure you can actually answer that question. What are these digital resources that I have, and what are they doing? And do I have eyes on them all?

Jeremy Snyder: I mean, that really pulls it back to the core basics of cybersecurity. If you don't have visibility onto it, like, forget it, you're pretty much stuffed from the beginning. Adam, tell us a little bit, as we wrap up today's episode here, tell us a little bit about Black Veil, what you're doing and where people can find you.

Adam Burns: Yeah. So if you want to jump on our website, blackveilsecurity.com, you'll see on the front page there's the scanner. So you can track your domain or any other domain in there and see straight away whether you can be spoofed, whether the site is protected, etc., etc. And it breaks it down in plain English. So, yeah, feel free to jump on and have a look. We've got tons of guides and stuff on there as well. And, yeah, working through the multi-tenant SaaS at the moment. It's in trial mode at the moment. So, yeah, we're almost ready to launch.

Jeremy Snyder: Awesome, awesome. We'll have that link from the show notes, again, that's blackveilsecurity.com. Adam, thank you so much for taking the time to join us on Modern Cyber, and to really kind of bring home this connection between, like, email, that, as I was talking about with Søren, we all use it, we all have this love hate relationship with it, but it is so critical. It is so fundamental to the businesses that we're running in this digital age. And DNS, which, to your point, is also just, you know, the nuts and bolts of the internet, and the internet doesn't work without it.

Adam Burns: Absolutely. Yeah. Thanks for having us, Jeremy. It was a pleasure.

Jeremy Snyder: Awesome, awesome. And we will talk to you next time on another episode of Modern Cyber. Until then, thank you so much. Goodbye.

Adam Burns: Cheers.

‍