Imagine you are sitting at your desk, it is a Tuesday morning, and you get an email from your CEO. The subject line is urgent, something like internal wire transfer authorization needed immediately. You look at the sender address, and it looks exactly right. It says ceo at yourcompany dot com. You click it, the tone sounds like him, the signature is there, everything feels legitimate. But the reality is that an attacker in another country just typed that address into a script and hit send. No password was stolen, no server was breached. They just lied, and the global email system, by default, believed them.
That is the fundamental flaw of the Simple Mail Transfer Protocol, or SMTP. It was designed in an era of academic trust where nobody thought someone would just pretend to be someone else. It is basically the digital equivalent of writing a return address on the back of an envelope. You can write whatever you want there. The post office doesn't verify it before they put it in the recipient's mailbox.
It’s wild to think that the backbone of global business communication is essentially built on a pinky promise. If I send a letter claiming to be the IRS, the paper doesn't catch fire. SMTP works the same way. It just carries the message from point A to point B without glancing at the ID of the sender.
And that little design oversight is currently costing businesses billions of dollars every year in business email compromise. Today's prompt from Daniel is about how we actually fix this using DMARC. He wants us to dig into what it is, how it stops impersonation, and why, as of April two thousand twenty-six, it is no longer just a nice to have security feature, but a requirement for even getting your emails delivered.
It is a great prompt from Daniel because DMARC is one of those things that sounds like alphabet soup until you realize it is the only thing standing between your brand's reputation and a phisher's script. By the way, today's episode is powered by Google Gemini three Flash, which is helping us break down these protocols.
I love that we are using an AI to talk about a protocol that is increasingly being used to fight AI-generated phishing. It is a very two thousand twenty-six circle of life situation. But Herman, before we get into the weeds, let's establish the acronyms. We have SPF, DKIM, and DMARC. Every time I see these in a DNS setting, I feel like I am looking at a flight manifest. What is the actual hierarchy here?
Think of it as a three-layered security check. SPF is your guest list. DKIM is your wax seal or digital signature. And DMARC is the set of instructions you give the bouncer at the door for what to do if someone isn't on the list or the seal is broken. Without DMARC, you have a guest list and a seal, but the bouncer has no idea if he should kick people out or just let them in anyway.
So if I have SPF and DKIM set up, but no DMARC, I am basically telling the world, hey, here is who is allowed to send mail for me, and here is how to verify it is me, but if you see someone pretending to be me, do whatever you want. I don't care.
That is exactly the situation for about seventy percent of domains out there, even now. Most people stop at SPF because it is the easiest to set up. But SPF has massive limitations. It only checks the return path address—the "envelope from"—not the "header from" address that the human actually sees in their Outlook or Gmail.
Wait, can you break that down? Why are there two different "from" addresses? That seems like it was designed specifically to help hackers.
It’s a relic of how mail is routed. Think of the "envelope from" as the return address the post office uses if the mail can't be delivered. The "header from" is the name written at the top of the actual stationery inside. SPF only checks the envelope. So, if I am an attacker, I can set up a fake domain like attacker dot com, pass SPF for that domain because I own it, but then put your email address in the "header from" section. Most email clients will show the header, and the user gets fooled.
That is the exact-domain spoofing Daniel mentioned in his notes. It is the most dangerous kind because it looks perfect to the naked eye. There is no typo, no yourcompany-support dot net. It is just your domain. So, how did we get here? Why is SMTP so broken that we need three different patches just to make it functional?
It goes back to the early eighties. The pioneers of the internet were more concerned with making sure the mail actually arrived than making sure it wasn't a scam. SMTP doesn't have a built-in authentication mechanism. When a mail server receives a message, it just looks at the commands. If it says mail from corn at sloth dot com, the server says, okay, hi Corn. It doesn't ask for an ID.
It is the ultimate polite system in an increasingly impolite world. I remember the twenty twenty Twitter Bitcoin scam. That was a high-profile version of this where spoofed messages caused massive financial loss. People often forget that even if you have a blue checkmark or a verified status on a platform, if the underlying email delivery can be spoofed, an attacker can reset passwords or trick employees into giving up credentials.
Right, and that brings us to the first pillar of the fix: SPF, or Sender Policy Framework. This is a simple text record in your Domain Name System, your DNS. It lists the IP addresses or services that are authorized to send mail for your domain. So if you use Google Workspace and Mailchimp, your SPF record says, only servers owned by Google and Mailchimp are allowed to send mail claiming to be from mydomain dot com.
But what happens if my company is huge? Like, if we have five different marketing agencies all sending mail for us from different platforms? Does that SPF record just grow forever?
It can, but that’s actually a trap we should talk about later—the ten-lookup limit. But for now, just think of it as a whitelist. If a mail comes from an IP not on that list, the receiving server marks it as "soft fail" or "fail." But again, without DMARC, most servers just deliver it anyway because they don't want to be responsible for blocking a legitimate message.
Okay, so SPF is the list. But you said earlier that SPF only checks the return path. If I am a hacker and I use my own server that passes its own SPF check, but I lie in the from header, SPF doesn't catch me. So then we bring in the second pillar, DKIM. Tell me about the digital signature part.
DKIM stands for DomainKeys Identified Mail. This is where we get into cryptography. When your server sends an email, it takes a look at the content of the message—the headers, the body—and it creates a cryptographic hash. It then signs that hash with a private key that only you own. The public key is published in your DNS records.
So when the recipient's server gets the email, it sees the signature, grabs the public key from my DNS, and does the math. If the math checks out, it knows two things: the email definitely came from my server, and it hasn't been tampered with in transit.
Precisely. If a hacker tries to change the wire transfer amount from one thousand to ten thousand dollars while the email is moving through the internet, the DKIM signature will break. The hash won't match anymore. It’s like a tamper-evident seal on a pill bottle. If the seal is broken, you know someone messed with the contents.
But here is the catch, Herman. What happens if an email arrives with no DKIM signature at all? Or if the signature is there but it’s for a completely different domain?
That’s the "broken seal" problem. Without a policy to guide it, the receiving server just shrugs and delivers it anyway. It assumes it is just an old-school email from a server that doesn't support DKIM. This is why these two aren't enough. You can have the best locks in the world, but if the door is left wide open for anyone who doesn't have a key, the locks are just decoration. This is where DMARC comes in to save the day.
DMARC is Domain-based Message Authentication, Reporting, and Conformance. That is a mouthful. But essentially, it is the glue. It says, hey, receiving server, I want you to look at both SPF and DKIM. And more importantly, I want you to check for alignment.
Alignment is the secret sauce. This is what stops that from header spoofing we talked about. DMARC requires that the domain validated by SPF or DKIM actually matches the domain the user sees in the from address. If I send an email from my attacker server and it passes SPF for attacker dot com, but the from address says corn at sloth dot com, DMARC sees that sloth dot com and attacker dot com do not align. It flags it as a fail.
This feels like such an obvious requirement in hindsight. Why did it take us so long to get to a point where this is mandatory? Daniel mentioned that in twenty twenty-four, Google and Yahoo finally put their foot down.
It was a massive coordination problem. If Google had started blocking all unauthenticated mail ten years ago, people would have just complained that their emails weren't getting through and switched to another provider. But by twenty twenty-four, the volume of phishing had reached a breaking point. Google and Yahoo, who handle a massive percentage of global personal email, basically said, if you send more than five thousand emails a day to our users, you must have a DMARC record.
And what does that actually look like for the sender? If I’m a big retailer sending out a Black Friday blast and I haven't set this up, am I just hitting a brick wall?
You’re hitting a very expensive brick wall. They started by "throttling"—which means they just slow down your delivery until it takes days for your mail to arrive. Then they move to the "void." If you don't have a DMARC record, your mail simply doesn't exist to them. And here we are in twenty twenty-six, and those rules have only tightened. I've heard that now, even if you are a small sender, if your spam complaint rate ticks above zero point three percent, and you don't have DMARC, you are basically invisible to the major inboxes. It is the deliverability death penalty.
It really is. And the beauty of DMARC isn't just the blocking; it is the R in the acronym, Reporting. This is the part that most people overlook but it is actually the most powerful tool for an IT department. When you set up a DMARC record, you can include an email address where you want to receive reports. Every day, major providers like Google, Microsoft, and Comcast will send you an XML file listing every single IP address that tried to send mail using your domain and whether they passed or failed authentication.
That sounds like a lot of data to sift through. I can imagine a sloth like me getting overwhelmed by a bunch of XML files every morning. Do people really open these in Notepad and read the code?
Oh, you definitely don't read them yourself. That would be a nightmare. You use a tool like DMARC Analyzer or MXToolbox. They take those files and turn them into beautiful maps and charts. Suddenly, you realize, oh wait, why is there a server in Eastern Europe sending ten thousand emails a day using our CEO's name? Or, more commonly, you realize, oh, our marketing team in the London office started using a new newsletter tool and they forgot to tell IT, so all their legitimate emails are failing authentication.
That is a huge point. Implementation isn't just about flipping a switch and feeling safe. If you do it wrong, you are basically DOSing your own company. You could block your own invoices, your own marketing, your own password resets. It’s like hiring a bouncer who is so strict he won't even let the owner of the club inside.
That is why there is a very specific, phased approach to implementing DMARC. You don't start by blocking everything. You start with what we call p equals none.
Monitoring mode. The bouncer is just standing there with a clipboard taking notes, but letting everyone in regardless.
Right. You stay in p equals none for a few weeks or even months. You look at those reports. You identify all the legitimate services that are sending mail on your behalf. You make sure they are added to your SPF record and that their DKIM keys are set up correctly. Once your reports show that ninety-nine percent of your legitimate mail is passing and aligning, then you move to the next level: p equals quarantine.
And quarantine is the spam folder. The bouncer says, I don't recognize you, you're not on the list, so I'm going to let you in but I'm going to tell everyone to keep an eye on you. It’s a "soft" rejection.
It's a safety net. If you missed a small legacy server somewhere—maybe an old printer that sends scan-to-email alerts—the mail still gets through, but it's hidden. If that goes well and you don't see any legitimate mail getting lost, you move to the final boss level: p equals reject. This is the gold standard. This is when the bouncer just slams the door. The email is never delivered. The attacker gets nothing, and your user never even knows someone tried to spoof you.
That reject policy is what you need if you want the cool perks, too, right? Daniel mentioned BIMI. Brand Indicators for Message Identification. I've started seeing logos next to emails in my inbox lately. Is that tied to DMARC?
It is directly tied to it. To get your verified brand logo to show up in the avatar slot in Gmail or Apple Mail, you are required to have a DMARC policy of p equals reject. The email providers are basically saying, we will give you this premium branding and trust signal, but only if you prove to us that you have secured your domain so thoroughly that no one can impersonate you. It is a brilliant incentive structure. It turns a boring security task into a marketing win.
I love that. It's like getting a VIP pass because you proved your house has a security system. But let's talk about the common pitfalls. I know you've seen some horror stories in the research papers you read, Herman. What goes wrong when people try to do this?
The biggest one is the SPF ten-lookup limit. People don't realize that when a receiving server checks your SPF record, it is only allowed to perform ten DNS lookups to avoid being used in Denial of Service attacks. If you use a lot of third-party tools, like Salesforce, Zendesk, Mailchimp, and HubSpot, each of those has their own lookups inside their SPF records. You hit that ten-lookup limit very quickly.
And if you hit eleven? Does it just ignore the eleventh one, or does the whole thing blow up?
The whole SPF check fails. Even if the service is authorized, the server just gives up. This is a huge cause of legitimate mail failing DMARC. There are modern solutions now, like SPF flattening, where a service dynamically keeps your record under the limit by resolving everything into IP addresses, but it's a classic trap for the unwary.
Another thing I've seen is issues with third-party senders not supporting DKIM properly. If I'm using a small, niche SaaS tool for my industry, they might send mail from my domain but not give me a way to add a DKIM key. What do you do then? Do you just live with the vulnerability?
That's where you have to lean on SPF for alignment, but it's risky. DMARC passes if either SPF or DKIM passes and aligns. But as we discussed, SPF is fragile. If that email gets forwarded by the recipient to someone else—say, a manager forwarding an invoice to the accounting department—SPF almost always breaks because the forwarding server's IP isn't in your list. DKIM, however, survives forwarding because the signature is attached to the message itself. This is why you really want both. If a vendor doesn't support DKIM in twenty twenty-six, honestly, you should probably find a new vendor. It's a sign of a very dated architecture.
It’s basically like a car manufacturer not including seatbelts at this point. It’s a basic safety standard. I want to go back to the human element of this. We talk about DMARC as this technical shield, but phishing is fundamentally a psychological attack. Does DMARC stop the guy who buys a domain that is just one letter off from mine? Like sloth-support dot com instead of sloth dot com?
No, and that is a crucial distinction. DMARC only protects the domain you own. It stops exact-domain spoofing. If an attacker buys a look-alike domain, they own that domain, they can set up their own SPF, DKIM, and DMARC for it, and it will pass all the technical checks perfectly. The bouncer sees their ID, sees it's a real ID, and lets them in—even if the name on the ID is "Sl0th" instead of "Sloth."
So DMARC isn't a silver bullet for all phishing. It's just the shield for your specific castle. It doesn't stop someone from building a fake castle next door that looks just like yours.
To stop look-alike domains, you need other tools, like AI-based content analysis or brand monitoring services that alert you when someone registers a domain similar to yours. But exact-domain spoofing is much more dangerous because it bypasses the most basic human intuition. Most people have been trained to check for weird characters or typos in a sender's address. But if the address is literally ceo at yourcompany dot com, you've removed the primary red flag. That's why DMARC is so foundational. It handles the stuff that humans can't be expected to catch.
It’s interesting to think about how this affects the broader ecosystem. If everyone implemented DMARC at p equals reject, would phishing just disappear? Or would it just evolve into something even more complex?
It already is evolving. We're seeing a massive shift toward compromised accounts. Instead of spoofing your domain, an attacker just steals the actual credentials for one of your employees—maybe through a session cookie theft—and sends the email from their real account. DMARC can't do anything about that because it is a legitimate login. This is why we always say security is about layers. DMARC stops the cheap, high-volume spoofing, which forces attackers to work harder. It makes them have to actually breach an account or build a convincing fake domain, both of which are harder and more expensive than just lying in an SMTP header.
It's the classic "move the goalposts" strategy. You don't have to be unhackable; you just have to be harder to hack than the guy next to you. If the attacker has to spend three days trying to breach an account versus three seconds to spoof a header, they’re going to move on to an easier target.
Precisely. And for bulk senders, it's about reputation. If you are a company sending out millions of emails and you don't have DMARC, your domain reputation with Google and Microsoft will slowly tank. Because attackers will use your domain to send spam, users will report that spam, and the algorithms will associate your domain with garbage. DMARC allows you to protect your reputation by ensuring that the only mail being counted against you is the mail you actually sent.
So, for the listeners who are sitting there thinking, okay, I need to check my DMARC status. Where do they start? If I'm a small business owner or an IT manager who hasn't looked at this in a while, what is the first move? Is there a "check my grade" button somewhere?
The very first move is to go to a tool like MXToolbox or dmarcian and just type in your domain. It will tell you immediately if you have a record and what the policy is. If it says "no record found," you need to act. Step one is simply publishing a record that says p equals none. It's safe, it won't break anything, and it starts the flow of data.
And then you start the inventory. You have to find every single shadow IT project that is sending mail. I bet that’s where the real work is. Finding that one old server in a closet that’s been sending automated reports for ten years. Or the HR department’s third-party survey tool.
Every single time. You’ll find things you didn't even know existed. You might find that your HR system sends out payroll notifications from a legacy domain. You might find that your building's security system sends alerts using your corporate domain. DMARC implementation is secretly a great way to do a full audit of your company's digital footprint. It forces you to know who is talking on your behalf.
It’s like a digital census. I also think it’s worth mentioning that this isn't just about email anymore. We’re seeing similar concepts being applied to other forms of communication. But email remains the king of the business world, and as long as it is, DMARC is the crown jewel of its security.
It really is. And as we move deeper into twenty twenty-six, we're seeing governments get involved. The European Union's NIS2 directive, for example, is pushing for much stricter authentication standards for essential entities. DMARC is often cited as a baseline requirement. If you’re doing business in a regulated industry, you might soon find that you’re legally required to be at p equals reject.
It’s the move from optional best practice to mandatory compliance. We’ve seen this story before with things like HTTPS for websites. Ten years ago, a lot of sites didn't bother with SSL. Now, if you don't have it, your browser screams that the site is dangerous and you lose all your traffic. Email is going through that exact same transition right now.
That’s a perfect comparison. The "green padlock" of the email world is BIMI and the absence of a spam warning. If you want your messages to be treated as first-class citizens in the inbox, you have to pay the entry fee of proper authentication. If you don't, you're relegated to the "dangerous" category.
I think the most interesting takeaway for me is that DMARC is actually a collaborative protocol. It only works because the senders and the receivers agreed on a way to talk to each other. It’s a rare example of the whole internet coming together to fix a fundamental flaw in an old system. It took a long time, but the consensus is finally here.
It is. It took twenty years of arguing and different competing standards, but we finally landed on something that works. It’s not perfect, and it doesn't stop every type of fraud, but it effectively eliminates one of the oldest and easiest tricks in the hacker’s book. That’s a massive win for the good guys.
So, the practical roadmap is: monitor, analyze, authenticate, and then enforce. Don't be the person who flips the reject switch on day one unless you really like getting angry phone calls from your boss about missing emails. You have to earn that "reject" status through data.
Please, for the love of all things holy, do not start with reject. I have seen companies accidentally block their own outbound sales for an entire week because they forgot that their CRM sends emails from a different set of IPs. Start with none. Be a sloth about it, Corn. Take it slow. Watch the data for at least thirty days before you even think about moving to quarantine.
Hey, I’m always in monitoring mode. That’s my natural state of being. But seriously, the reporting part is fascinating. If you’re a nerd like us, seeing a map of all the servers around the world that are trying to use your domain is eye-opening. It makes the threat landscape feel very real and very immediate. You see these pings from random data centers in places you've never even visited.
It really does. You realize you’re not just a passive target; you’re part of a global battle for identity. And DMARC gives you the weapons to fight back. It’s one of the few areas of security where you can actually get to a state of near-perfect protection against a specific attack vector. You can't say that about many things in cybersecurity.
Well, I feel a lot better about my inbox already, or at least I will once I check the DMARC record for sloth dot com. We should probably see if anyone is trying to impersonate us. Though, why anyone would want to be a sloth or a donkey is beyond me.
Maybe they want our collection of technical white papers. I’ve got some rare ones from the early nineties about the original SMTP proposals. They're worth a lot in certain very specific, very boring circles.
I’ll stick to the summaries, thanks. This has been a great deep dive. I think it’s one of those topics that feels dry until you realize it’s the difference between a secure business and a wire transfer to a stranger. It's the plumbing of the internet, and nobody cares about the pipes until they burst.
Exactly what Daniel was going for, I suspect. It’s the plumbing of the internet. You don't think about it until it leaks, but once it does, it’s all you can think about. It's about building a foundation of trust in a system that was originally built on nothing but handshakes.
Well, no leaks here today. We’ve covered the why, the how, and the pitfalls. I think we’re ready to wrap this one up.
Agreed. It’s a great place to leave it. If you’re listening to this and you haven't checked your domain today, let this be your sign. Go do an MX lookup. It takes thirty seconds and could save you a lot of heartache. It's the easiest security win you'll get all week.
Thanks as always to our producer Hilbert Flumingtop for keeping us on track and making sure we don't get too lost in the DNS records. And a big thanks to Modal for providing the GPU credits that power this show. If you found this useful, or if you’ve had your own DMARC disaster story, we’d love to hear about it. Did you accidentally block your own wedding invitations? Let us know.
This has been My Weird Prompts. You can find us at myweirdprompts dot com for the full archive and all the ways to subscribe. We've got show notes there that break down these acronyms in even more detail for those who want to see the syntax.
And if you're enjoying the show, a quick review on your podcast app really does help us reach more people who might be currently getting spoofed. It helps the algorithm realize we're the "aligned" version of a tech podcast.
See you next time.
Later.
