SPF, DKIM and DMARC - Simply Explained

0:00 Welcome to the M365 FM podcast where we explore the people, ideas and technologies shaping the future of work. Anyone with a laptop can send email that pretends to be your company. The email system we all rely on was built to move messages, not to check who the sender really is. So a fake invoice or a fake note from your boss can land in a real inbox with your name on it. Three records in your DNS. Quietly close that gap, and a surprising number of organisations only ever set up one of them. Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. Over the next few minutes, we'll look at SPF, DKIM and dMarc in plain words so a stranger can never wear your company's name again. Why anyone can send email as you email was invented for a world that trusted everyone.

0:43 The system that moves your messages, known as Smtp, has no built in way to prove that a sender is who they claim to be. That was a fair assumption. In the early days, when a small number of universities passed notes between machines, but it turned into a serious problem once email started running the business world. Every message actually carries two different sender addresses, and this is the detail that surprises most people. One is the hidden address that servers use behind the scenes to hand the message along, and the other is the from line you and I actually see in the inbox. Nothing forces those two addresses to match in Microsoft's own documentation. There's an example where the hidden address points to one domain, while the from line shows a bank's name and the message is perfectly valid. Email from start to finish. Picture the message that lands in your inbox.

1:24 It carries your company's logo, your manager's name, and a request to confirm a payment before the end of the day, nothing on the screen tells you it came from a stranger on the other side of the world, because the only part that was faked is the part your email app shows you first. That gap is what the industry calls spoofing, and it fuels some very expensive crime business. Email compromise, often shortened to Bec, is what happens when a criminal uses a fake identity to talk a finance team into paying an invoice or changing a bank account. The FBI's Internet Crime Complaint Center recorded more than three billion dollars in losses in a single year, and the criminals only need one person to reply. Three standards were built to close that gap. They were designed to work as a team rather than alone.

2:05 SPF checks who is allowed to send Dcam checks, whether the message was changed along the way, and dMarc ties both of those checks to the name people actually see. We'll start with the first one SPF. The guest list for your domain, SPF stands for Sender Policy Framework, and the easiest way to picture it is a guest list. At the door of a club, the owner of a domain publishes a public list of the servers that are allowed to send mail on its behalf. When a message arrives, the receiving server checks the address of whoever sent it against that list, and anything that isn't on the list gets flagged as suspicious. That list lives in DNS, which is really just the internet's public address book. Anyone can read it. And that's exactly the point. The trust runs in one direction, because the rule was published in advance for the whole world to see.

2:46 SPF is a domain saying in public, here is exactly who is allowed to speak. For me, the end of the list carries the decision. If your record finishes with a hard fail written as a minus sign, and then the word all, then mail from any server that isn't listed should be rejected outright. If it finishes with a soft fail, which looks like a tilde and then all, then that mail should still be accepted but treated with suspicion while you finish tidying up. Most people start with the soft fail and that's a sensible place to begin. One more wrinkle explains a lot of broken email. SPF allows at most ten extra lookups when a receiving server works through your record and every service you add, like a marketing tool or a help desk eats into that budget. Go past ten and the whole check fails.

3:26 Nearly five percent of the domains using SPF had crossed that line, according to a large scan of millions of domains. The bigger limitation is this SPF only checks the hidden envelope address, and it ignores the from line that the recipient actually sees. It also breaks whenever mail gets forwarded because the forwarding server was never on the original guest list. A guest list alone can't protect you, so you also need a way to prove the message itself is genuine. DKIM the tamper proof seal. DKIM stands for Domainkeys Identified Mail, and it works like a wax seal on a letter. When your mail server sends a message, it stamps that message with a digital signature. When it lands, the receiving server checks that signature to prove nothing was changed in transit. And if even a single character moved, the seal breaks, the signature covers the parts of a message that matter most, including fields like the subject line and the from address along with the body itself.

4:15 Change any of those parts and the seal no longer matches. That's what makes DKIM a proof of integrity rather than a promise. The clever part is how the keys work. The sending server signs the message with a private key that never leaves its side, and the matching public key is published in DNS for anyone to check. It's the same idea as a wax stamp that only one person can press, paired with a public picture of what that stamp should look like. Nobody can forge the stamp, but anybody can verify it. This is where DKIM beats SPF because the seal travels with the message. It usually survives forwarding, which is the very thing that breaks SPF. That one strength makes DKIM the quiet workhorse of email security. One limitation leads straight to the third standard. DKIM doesn't care whether the domain that signed the message matches the name a person sees in their inbox.

4:56 A criminal can sign a message with their own domain and still show your company in the from line. So the seal is real, but it's sealing the wrong name. Inside Microsoft three hundred sixty five, one useful default is already in place. Mail sent from your default on Microsoft Com addresses signed automatically. Your custom domain. The one carrying your company name isn't signed until you switch DXM on yourself. And that's a switch. Plenty of administrators never flip a perfect seal on the wrong name. Still looks completely trustworthy, and that is exactly the problem. dMarc was built to solve dMarc, the rule that ties it together. dMarc stands for Domain Based Message Authentication, Reporting and Conformance, which is a mouthful. So think of it as the referee. It's whole job is to check that the domain which passed SPF or DKIM, actually lines up with the domain in the from line people see that matching idea has a name and we call it alignment.

5:42 The surprising part is what dMarc actually does. It doesn't run its own test on the message. Instead, it takes the results from SPF and compares them against the visible name and then applies a rule. A message passes dMarc if at least one of those two checks passes and matches the from domain, and it fails only when both of them fail to line up. Alignment matters because of what it blocks. Without it, a criminal can pass SPF using a domain they own. While showing your company's name to the recipient, SPF would happily report a pass, and the person reading the message would never know the difference. Alignment is the bridge that connects the checks. You can't see to the name. You can. One dMarc record also does more work than its cousins. A single record on your main domain covers all of your subdomains by default, unless you deliberately set a separate one for a subdomain.

6:24 SPF and Dkm don't behave that way, which causes a lot of confusion. A domain should also publish exactly one dMarc record, because publishing two can make receivers shrug and apply no policy at all. Now the three pieces finally make sense as a set SPF says, who may send. DKIM proves the message wasn't altered and dMarc ties both checks to the name people actually see. Next, we'll look at what these records look like when you write them down, what the records actually look like. Now for the concrete part, because these records are far less scary than they sound. Think of DNS as the internet's public phone book and a TXT record. As a short note you attach to your domain so anyone can read it. All three of these standards are just public notes plus one pair of pointers. SPF sits at the root of your domain. A typical Microsoft three hundred sixty five record starts with a version marker, then includes Microsoft's own sending service, and finishes with the decision we talked about, read it out loud and it says only mail from Microsoft three hundred sixty five is allowed and everything else fails.

7:17 That's the whole guest list squeezed into one line. DXM is published a little differently in Microsoft three hundred sixty five. Instead of one note, you create two pointers named selector one and selector two, and both of them point to Microsoft's signing service. Only one is active at any given time, and the second one exists, so you can rotate your keys later without any downtime. A very common mistake is publishing only the first pointer, because Microsoft three point six five expects both. dMarc lives at a special address that begins with an underscore, followed by the word dMarc, and the record always begins with a version marker of its own. A simple starter version reads version one policy none, and an email address for the reports. Read that from left to right and it tells a small story. The first part says this is a dMarc record.

7:58 The second part says what to do with a failing message, which is nothing for now. And the third part says where to send the evidence. If you take one thing from this section, let it be that these are ordinary public notes. There's no secret key to memorize and no software to install. You add a few lines to your domains, DNS. And from that moment the whole internet can check your mail for you. None. Quarantine and reject. In plain words, the most important letter in a dMarc record is the policy written as P equals, and it comes in three flavors. It decides what every receiving server should do. When a message fails your checks. That's single choice sets how hard your domain defends itself. The first option is none. This is monitor only mode, and it tells receivers to take no action and just send you the reports.

8:40 It sounds useless, but it's the most valuable step in the whole process because it shows you every service that sends mail as your domain before you block anything. The second option is quarantine. This tells receivers to accept the message but treat it as suspect, which usually means it lands in the junk folder or gets flagged. It's a middle ground that lets a small mistake slip through without disappearing. The third option is reject. With this setting, receivers refuse the message outright, which in practice means it's usually discarded. Reject is the destination you want, and it's also the one that punishes you fastest if you arrive too early. Two smaller dials sit alongside the policy. One sets what percentage of failing mail the policy applies to which lets you test a ten percent, then twenty five, then fifty before committing fully the other controls, how strict the matching has to be, and by default, subdomains are allowed to line up with their parent.

9:25 Most beginners can leave that dial alone, so none is a watchtower. Quarantine is a warning label and reject is a locked door. The skill isn't choosing the toughest one. The skill is knowing when to move to the next one. The reports that tell you what's happening. A policy without visibility is just a guess, which is why dMarc can email you reports. There are two kinds and they serve very different purposes. The first is the aggregate report and it's the one that matters most. Receiving servers send it on a schedule, usually once a day, as a compressed file that summarizes everything they saw inside. You can see which server sent mail claiming to be your domain, whether each one passed or failed, and what action was taken. That's how you spot the payroll system or the marketing tool you forgot was sending as you. The second is the forensic report, which arrives almost immediately after a single failure.

10:07 A bit like a bounce message. It can help you track down one specific problem, but it also tends to be noisy. Microsoft three hundred sixty five handles these two very differently, and that's worth remembering. Microsoft three. Sixty five will send aggregate reports to the address you set, but it will never send forensic reports even if you ask for them. If you sit around waiting for that second type, you'll be waiting forever. Reports also show you the other side of the story. When a stranger tries to send mail as your domain, the receiving server logs that attempt too. So your reports reveal both your legitimate senders and the impersonators pretending to be you. The practical advice is simple send your reports to a shared mailbox instead of a person's inbox so they don't vanish when someone goes on holiday and review them once a week. While you're getting started, read them for one clear signal, which is any legitimate sender showing up as a failure.

10:53 The right order to roll this out. If you remember one thing from this whole episode, make it the order. Because doing this backwards is how people block their own mail without noticing the steps build on each other, and skipping ahead removes the safety net. Start with SPF. Publish a record that lists the senders you know about, and finish it with a soft fail rather than a hard fail at first. That soft fail tells receivers to be suspicious instead of hostile, which gives you room to find senders you forgot about without losing their mail? Then turn on Dqm in Microsoft three. Sixty five. That means creating both selector pointers in your DNS and flipping the signing switch in the admin tools. Google's own guidance is to have SPF and DKIM in place at least forty eight hours before you touch dMarc, so the pieces are settled before the referee arrives.

11:34 Now add dMarc at none and watch the reports. Google suggests giving that monitoring phase about a week, and that's usually enough for the daily reports to show every stream of mail you send. This is the stage where you fix surprises, not the stage for enforcing anything. Once the reports look clean. Move to quarantine and use the percentage dial to raise the pressure gradually rather than all at once. When you're confident that nothing legitimate is failing, move to reject, which is where the real protection lives. The reason to move in this order is simple. Every step gives you information that makes the next step safer. Skip ahead and you're guessing about your own mail streams, and guessing is how a real invoice ends up in a spam folder. One last habit keeps you safe. Start with a low volume subdomain instead of your main domain, and save the one everyone uses for last.

12:17 That way, if something goes wrong, the blast radius is a few messages instead of your whole company. The mistakes that trip people up in Microsoft three hundred sixty five. Even with the right order, a handful of Microsoft three hundred sixty five details catch almost everyone, and each one leaves the door open just enough. Here are the ones worth checking twice. The first mistake is assuming your custom domain is already signing its mail. It isn't signed yet. Microsoft three. Sixty five signs your default on Microsoft Com domain automatically, but your branded domain stays unsigned until you enable DKIM yourself, and plenty of tenants never do. Publishing only one of the two DKIM pointers comes next. Microsoft three hundred sixty five expects both selector records and a missing second one is one of the most common reasons a domain shows up as unsigned.

12:57 Then there's a DNS setting that can sabotage everything if your DNS is hosted on Cloudflare. The orange proxy switch has to be off for those DKIM records, because a proxy lookup points somewhere else and the signature can never be verified. A fourth trap is publishing two dMarc records for the same domain. That sounds harmless, but it can make receivers apply no policy at all, which means you feel protected when you aren't. One domain should carry exactly one record. Plenty of teams stop at none and call it done. Monitoring isn't protection, and the data shows how common this is. Among the millions of domains that publish dMarc et al. Most are still sitting in monitor only mode. Watch out for the tools that send mail on your behalf. A marketing platform, a help desk, or an invoicing system all send as your domain and each one needs to be authorized or your reports will fill up with failures.

13:41 The last trap is treating this as a one time task. New services get added, old ones get retired and sign in keys should be rotated. So a domain that was clean last year can drift out of shape over time. Recap. And one question for you. The whole idea fits in a few sentences. SPF is the guest list of who may send us you. DXM is the seal that proves the message wasn't changed, and dMarc is the rule that ties both checks to the name people actually see on their own. Each one has a whole. And together they close the gap that lets a stranger wear your company's name. If you want more practical breakdowns like this, subscribe to M365 FM to master the tools and the mindset shaping the future of work. I'll leave you with one question. If someone checked today, which senders are allowed to send email as your domain?

14:22 And do you actually know every one of them?