Defender for Office 365: Tuning Anti-Phishing and Safe Links Policies

M365 FM - Defender for Office 365 - Tuning Anti-Phishing and Safe Links Policies

00:00:00 Speaker: Most tenants run defender for office three hundred sixty five on defaults and call it protection. Somebody switched it on during a rollout, checked a box in a project plan, and moved on. Two years later, nobody can say what the policies actually do. But the flaw isn't the product. The product is capable. It's the model behind it. Set it once. Assume it's safe. That model treats email security like a lock on a door. You install it, you test it, and you walk away. Attackers don't work that way. They test your filter every day and they change what they send until something lands. So here's the thesis for this episode. Tuning isn't a configuration event, it's a measurement loop. You set a policy, you measure what it catches and what it misses. You adjust and you do it again. If you want ongoing breakdowns of Defender Exchange online and the security model behind them, subscribe to the M365 FM podcast. Here's the route. We start with the policy model, then impersonation, then safe links, safe attachments and quarantine. And we finish with simulation and measurement because that's where you find out if any of it works. But first the sponsor and then the foundation sponsor segment. Stellar Migrator for exchange. Before we get into policies, one thing about the ground they sit on security tuning depends on a clean mailbox and domain structure. That sounds boring. It isn't because every policy you build points at something a user list, a domain list, a set of mailboxes and migrations change all of that. A migration moves, MX records, it changes which mailboxes exist in which tenant. It adds domains, retires domains, and leaves half finished mailboxes behind. Each of those changes shifts what your protection policies actually cover. A protected user list that was right in March can be wrong by June and nobody touched the policy. That's why migration planning belongs in the same conversation as security tuning. This episode is sponsored by Stellar Migrator for exchange. It's a tool for migrations inside the Microsoft ecosystem. If you're moving mailboxes between tenants, consolidating after an acquisition, or bringing an on premises exchange environment into Microsoft three hundred sixty five, it's built for that work. Use it or use something else. The point is this plan the move so your mailbox and domain structure stays clean, and then recheck your security scope afterward. Now to the model itself, the assumption that breaks email security. Here's the old model. Email security is a perimeter filter. mail comes in, the filter checks it, bad stuff gets blocked, good stuff gets through. You tune it once during setup and then you forget it. That model made sense when attacks were loud mass spam, obvious malware, the same bad attachment sent to a million people. But in reality, that world is gone. Attackers adapt to your filter. Within days, they send a batch, see what gets blocked and change the wording, the sender, the link, or the file. Then they send again. Your policy stays frozen while their method keeps moving. A static policy doesn't stay safe. It decays and one level deeper, the attack itself has changed. Phishing today doesn't start with malware. It starts with context. A name you trust, a real threat you were already in, a request that looks like normal work, an invoice from a supplier. You actually pay a message from your CFO that sounds exactly like your CFO. There's no virus to scan for. There's no obvious bad link. There's just a believable person asking for a believable thing. That's where the perimeter model breaks. It was built to ask, is this message bad? The better question is, is this message who it claims to be? So what does defender for office three hundred sixty five actually give you to answer that? It comes in layers. At the bottom is Exchange Online Protection or EOP. Every exchange online mailbox gets it. It handles the basics spam filtering, malware filtering, connection filtering, and core anti-phishing. On top of that sits defender for office three hundred sixty five that comes as plan one or plan two, and each adds features on top of EOP. We'll break down exactly what's in each one in the next section. For now, the structure matters more than the feature list layers. Mean decisions. Each layer has settings, each setting trades protection against disruption, and someone has to own those trades over time. That's the part most tenants skip. So here's the thesis again with more weight behind it, the product ships capable. Microsoft has put a lot of engineering into these layers, but outcomes don't come from the product. They come from the loop. You run around it, set the policy, measure the result, find the gap, adjust an admin who runs that loop on a modest policy will beat an admin who built a perfect policy and never looked at it again. But a loop needs a starting point, and you can't tune what you don't know you own. Plenty of tenants are paying for features they've never turned on, and others are assuming protection they were never licensed for. So before we touch a single setting, we need to find out what you actually own. Plan one versus plan two and what you're actually licensed for. Start with what you already have. Exchange Online Protection comes with every exchange online mailbox. It filters spam. It scans for known malware. It checks the connection, the sender reputation, and the basic authentication results. It also includes Anti-phishing with spoof protection built in. That's a real baseline, but it's a baseline built around known bad things, known bad senders, known bad files, known bad patterns. Defender for office three hundred sixty five adds the parts that deal with unknown things, and it sells in two tiers. Plan one is the prevention. Tier three pieces matter here. Safe links checks URLs when someone clicks them, not just when the mail arrives. Safe attachments opens files in a sandbox before they reach the user, and the Anti-phishing policies get impersonation protection, which is the piece that asks whether a sender is really who they claim to be. Those three are the core of this episode. They stop the attack before it lands. Plan two is the investigation and response tier. It includes everything in plan one and then adds four things. Threat explorer lets you search real time detections across your tenant automated investigation and response, or IR looks at an alert and proposes a cleanup attack. Simulation training lets you send fake fish to your own people, and campaign views group messages into a text so you see one story instead of five hundred separate emails. So plan one blocks. Plan two shows you what happened, helps you clean it up, and trains the people on the other end. Here's the pattern I see most. A tenant license is plan two. Maybe it came bundled in a Microsoft three hundred sixty five E5 agreement. Maybe someone bought it for a few executives and a pilot group. And then the team configures safe links and safe attachments and stops. Nobody opens Threat Explorer, nobody looks at campaign views, air sits on defaults, and nobody reads what it proposes. Attack simulation has never run once, so the tenant pays for plan two and behaves like it bought plan one. That's the gap. And it's expensive in two ways. You're paying for tools that produce no value, and you're missing the exact signals the tuning loop depends on. Remember the loop from the last section. Set measure, find the gap. Adjust the measure step lives mostly in plan two features. Without them, you're adjusting blind. The reverse problem exists to. Some tenants assume they have impersonation protection or safe links because they read about it in a blog post or saw it in a demo, but nobody checked whether those licenses are assigned to the actual users. Defender for office three hundred sixty five licensing is per user. If a mailbox has no license, the policy doesn't protect it. Even if the policy exists and looks perfect in the portal and licenses drift, people join roles change. A contractor gets a mailbox with an ERP only plan, and that mailbox becomes the soft spot. So step zero of any tuning effort is a licensing inventory. It's simple work. Find out which plan each group of users holds. Compare that against who needs what executives, finance and IT admins should be the first names on any plan two list. Then check which plan two features your team actually uses today, and write down the ones nobody touches. That one page tells you what you can enforce, what you can measure, and what you're paying for without using. Because every decision after this point depends on it. You can't build a measurement loop on tools you don't have, and you can't promise protection to users who are never licensed for it. So with licensing clear, the first real decision is a structural one, not what the settings are, but how the policies get applied to people in the first place. Preset security policies. The model Microsoft wants you to start with. Microsoft knows most admins won't tune this from scratch, so it ships a model for that preset security policies. There are two of them standard and strict. Each one is a bundle. You switch it on, pick who it applies to, and a whole set of policies gets created behind the scenes. Anti-Spam anti-malware anti-phishing. And if you hold the licenses, safe links and safe attachments to standard is the balanced profile it's meant for most of your users. Strict is the tighter profile. It acts earlier, it holds more mail, and it's meant for the people attackers care about most. Here's what the difference looks like in practice. Standard sends a high confidence Phish to quarantine and handles ordinary Phish with a slightly lighter touch. Strict quarantines, both strict, also sets a more aggressive phishing threshold and shortens the time before it acts on bulk mail. Same engine, different dial positions. Now, why do presets exist at all? Because of what Microsoft can see that you can't. Your tenant sees your mail, maybe a few thousand users, maybe a few hundred thousand messages a month. Microsoft sees the whole service. It watches which senders turn malicious, which lures get reported, and which settings produce false positives across millions of mailboxes. The preset values come out of that telemetry. They get adjusted as attacks change. You can't match that alone. Not with a spreadsheet and not with a good weekend of reading documentation. A custom policy is one admins judgment applied to one tenant. A preset is a judgment built from the whole services evidence. That's a real advantage. And it's worth saying plainly because plenty of admins treat presets as the beginner option. Now think about the tenant that has done nothing at all. No presets, no custom policies. Is that tenant unprotected? No. There's a floor under it. It's called built in protection. When you have defender for office three hundred sixty five, Microsoft applies a baseline of safe links, safe attachments, and impersonation related protection to every recipient who isn't covered by any other policy. It's on by default, and it's the last layer in the stack. But look at what that means. Built in protection is a safety net, not a design. It catches the tenant that forgot. It isn't the setup you'd choose if you were choosing on purpose. So here's where the real decision starts. When you turn on a preset, you get consistency, but you also lose something. You can't edit the settings. Not one of them. The fishing threshold, the quarantine actions, the safe links options all of it is fixed by Microsoft. What you control is scope and exceptions. Who gets the policy and who specifically gets left out of it. That's the honest trade off. You give up control and you get consistency. Some admins hate that, and I understand why you see a setting you do differently and the portal says no. But think about what control costs you. Every setting you own is a setting you have to review. Every review is a meeting, a ticket, a test, and every setting that drifts quietly is a hole nobody notices until an incident points at it. Presets remove that burden. Microsoft owns the settings, and Microsoft owns the updates. When the recommended values change, the preset changes with them. A custom policy never updates itself. It sits exactly where you left it, whether that was a good place or not. So for most of your users, the trade is a good one. You lose the dial, but you gain a policy that gets maintained by people with more data than you have. The cost lands in two places your edge cases and your documentation. If a mail flow in your business needs something unusual. A preset can't bend to fit it. You work around it with scope and exceptions, or you step out to a custom policy. We'll get to when that's worth it. But before any of that, there's a problem that catches almost every tenant, and it has nothing to do with which settings are good. Presets sound complete. Turn them on. Assign the users done. The trouble is what happens when more than one policy could apply to the same person. Because the system doesn't blend them, it picks one, and the order it uses to pick is where tenants get surprised. Policy precedents why your custom policy isn't doing what you think. Here's the order. First, the strict preset policy. Second, the standard preset policy. Third, your custom policies. And last, built in protection. Microsoft evaluates them in that sequence top to bottom. And the moment a recipient matches one of them, the evaluation stops. That's the part that surprises people. The system doesn't merge policies. It doesn't take the stricter setting from each one it finds the first match, applies that policy and ignores everything below it. So think about what that means for a custom policy. You build it carefully. You pick a phishing threshold. You add protected users. You write a clean name, assign a scope, and save it. It looks perfect in the portal, but if a user already sits inside a preset scope, that user never reaches your custom policy. Not partly. Not on certain settings, never. The preset caught them first, and the walk down the list ended right there. And there's a second layer to the problem. Inside the custom policies themselves, there's a priority number. Lower number wins. If two custom policies both match the same person, the one with the lower number applies and the other does nothing at all. Now put those two facts together and you get what I'd call the silent override problem. Nothing breaks. No error. Shows up. No alert. Fires. The portal still shows your custom policy as enabled with the right settings pointed at the right group. It just never fires for the people you built it for, because something higher in the order claimed them first. How does this happen in a real tenant? What typically happens is this. An admin turns on the standard preset for everyone early in the project. Months later, someone writes a custom anti-phishing policy for the finance team with tighter impersonation settings. Nobody connects the two. The finance users are already inside the standard scope, so the custom policy has zero recipients. The admin believes finance has stronger protections, the data says otherwise, and the gap sits there until an invoice fraud attempt walks right through. So how do you check what actually applies? Don't trust the policy page. Trust the evidence. There are two good places to look. The first is the configuration analyzer. It lives in the defender portal under the Email and Collaboration section. It compares your policies against Microsoft's standard and strict recommendations, and it flags where you've drifted. But more useful for this problem, it shows you the policy structure in one view. You can see which presets are on who's in scope and which custom policies sit underneath. The second is advanced hunting email events in the hunting tables record what happened to each message, including which detections fired and what action the system took. If your custom policy is supposed to quarantine certain mail for finance users, and you query for those users and see the action coming from a different policy, you have your answer in about a minute. One policy side check helps too. In the preset policies page, look at the scope of strict and standard. First, write down exactly who's included and who's excluded. Then compare that list against the recipients of every custom policy you own. Any overlap is a conflict and the preset wins. Here's the failure. I'd put on a sticky note and admin spends a week tuning a custom policy. Thresholds, protected lists, tailored actions. Then nobody checks whether a single recipient actually hits it. Weeks of careful work and the effective policy for every one of those users is something the admin never touched. That's not a settings problem. It's a verification problem, and it comes straight from the model we started with. Set it once, assume it works. So the rule is simple. After any policy change, confirm the effective policy for a sample of real users. Pick two or three people. The policy is meant to cover and trace what actually applied to their mail. Because once you understand the order, the next question changes. It's no longer how do I tune my custom policy? It's does this person need a custom policy at all? So when do custom policies earn their place. Preset versus custom. A decision framework start with a default presets for the broad population. Custom policies only for exceptions you can justify out loud. That's the posture. Not because custom is bad, it's expensive, and most tenants spend that money without knowing it. So what counts as a justified exception? Three things hold up. First, a protected user list that has to be built your way. Pre-Set policies can't give you a handpicked set of executives and approvers for impersonation protection. If you need specific names defended with specific settings behind them, that's a custom anti-phishing policy. Second, a mail flow that's genuinely unusual may be a business unit receives files from outside parties all day, and the standard handling breaks their work. Maybe an internal system sends mail that looks suspicious to any filter alive. A preset can't bend to that. A custom policy scoped narrowly can. Third, a third party gateway. If another filtering service sits in front of Microsoft three hundred sixty five, the way mail arrives changes connection details, sender reputation, authentication results all of it looks different by the time defender sees it. That setup often needs its own handling, and a custom policy is where you do it. Notice what's missing from that list? I'd like to do it differently. Isn't on it. Neither is the default. Seems too soft or I read a blog post. Those feel like reasons, but their preferences and the preference doesn't pay for the maintenance that follows. Here's what follows. The moment you write a custom policy, you own three things.

00:15:00 Speaker: You own the drift A preset updates when Microsoft's recommendations change, your policy doesn't. It sits at the values you chose while attacks move and the recommended settings move with them. Six months on, it's behind and nothing tells you you own the review cycle. Someone has to look at that policy on a schedule, check its scope, check its lists, and compare it against current guidance. If that's someone leaves the team, the review leaves with them and you own the incident. When a fish gets through a custom policy. Nobody at Microsoft chose those settings. You did. The post-incident question lands on a name and the name is yours. That's the full cost. It isn't a reason to avoid custom policies. It's a reason to treat each one like a small system you've agreed to run. Now the other side of the posture. Who gets the tightest protection? That's what strict is for not everyone. And not randomly. The people. Attackers pay for executives because their names carry authority and their inboxes hold sensitive material. Finance staff, especially anyone who approves payments or changes bank details IT admins because one compromised admin account opens far more than one mailbox HR because they handle personal data and receive attachments from strangers all day, and anyone else whose account, if lost, creates a problem bigger than a single user. These are your priority accounts. Put them in the strict preset and you get a tighter dial position with Microsoft still maintaining the settings. That's a strong answer for a lot of tenants, and it often removes the need for custom policies altogether. There's a trade, of course. Strict holds more mail. Those users will see more false positives, and they'll notice. Tell them first. A short note explaining why their mail gets held a little more often costs nothing, and it saves you the ticket that says email is broken. Now, the discipline that keeps all of this honest, every deviation from preset gets written down. Every single one. A short record with four fields. What the custom policy does, why a preset couldn't cover it, who owns it, and a review date. If you can't fill in the owner, the policy isn't ready. If you can't fill in the reason, it probably shouldn't exist. And if there's no review date, then you've built something that will outlive everyone's memory of why it's there. That record is also how you'll find the policies that no longer earn their place. Run through it at each review and ask a simple question does a preset cover this now? Sometimes the answer is yes, and you can delete the custom policy and take a maintenance burden off your own plate. So the foundation is set presets for most people, strict for the priority few custom only where it's justified, documented and owned. But a foundation only decides who gets which policy. It doesn't tell you what the policy is protecting against. And there's one attack that presets alone don't solve, because it doesn't look like an attack at all. Impersonation. How impersonation attacks actually work. Impersonation isn't one trick, it's three, and they work in different ways. The first is display name spoofing. The attacker creates a free mail account and sets the display name to Sara Chen, CFO. The address behind it is some random string at a free provider, but on a phone in a narrow inbox view, you only see the name Sara Chen, your CFO. Urgent. The second is the lookalike domain. Here, the attacker registers a domain that's close to yours. One letter swapped a hyphen added our DN that reads like an M at a glance. Then they send mail from a real working address on that domain. It passes every technical check because the attacker owns it and set up the records correctly. The third is the compromise partner. This one is the hardest to catch. A real supplier gets breached. The attacker logs into a real mailbox, finds a real thread about a real invoice, and replies inside it. The sender is genuine, the domain is genuine. The conversation is genuine. Only the bank details have changed. Now look at what those three have in common. No malware, no attachment to detonate, no bad link to scan. Often there's nothing in the message body but a few plain sentences. Can you update our payment details before Friday's run? And that's why they slip past classic filters. A classic filter hunts for bad content. Known bad files, known bad URLs, known bad sender reputation. But there's nothing bad to find here. The text is clean. The request is ordinary. The only lie is about who's asking. And that lie lives in the relationship, not in the message. So the content check passes. The attachment check has nothing to check. The link check has nothing to scan, and the mail lands in the inbox looking like every other message that day. Then the outcome is financial. This is business email compromise or bc the attacker isn't after a password or a foothold. They want money and they want it moved by a human who believes the request is real a wire transfer, a changed bank account on a vendor record. Gift cards bought for a client. Payroll redirected to a new account. It doesn't need any exploit. It needs one approver, one busy afternoon, and a message that sounds right. And once the transfer clears, recovery is slow, uncertain, and often impossible. So how does a filter defend against something with no bad content? It needs a different kind of knowledge, not what's inside the message, but who normally sends mail to whom. That's what Mailbox Intelligence does. Defender watches how each user's mail behaves over time, who they email, who emails them, how often, which senders get replies, and which get ignored. From that, it builds a map of each person's real contacts. Think about what that map makes possible. If Sarah Chen has never written to you and a message arrives claiming to be Sarah Chen from an address you've never exchanged mail with, that's a mismatch. The name is familiar. The pattern isn't. The system can see the gap because it knows who your contacts are. It also helps in the other direction. If a sender really does talk to you every week, defender can learn to trust that relationship, which cuts false positives on legitimate mail. And this is the structural shift, The old detection question was, is this message bad? That question fails here because the message isn't bad. It's clean. The new question is, is this message who it claims to be? Does the name match the address? Does the address match the history? Does the domain match anything? A real contact would use. Is this sender someone this user has ever talked to? That's identity, not content. And the filter can only answer it if it knows who matters. Here's the catch. Mailbox intelligence covers contact patterns across your users, but it can't guess which three hundred names are worth defending most, or which partner domains your accounts payable team depends on. It can't know that a lookalike of one particular supplier is a real threat, because it doesn't know that supplier is the one you wire money to every month. That part comes from you. Detection depends on what you tell the system to protect, and that's the setting we turn to next. Anti-phishing policy. Anatomy. Open an Anti-phishing policy in the portal and you'll find a lot of toggles. It looks like a settings page, but it's better read as a map. Each setting answers one specific attack, and once you know which the choices get easier, start with the phishing threshold for levels. Standard. Aggressive. More aggressive, most aggressive. This style controls how readily defender treats a message as fish when its machine learning models aren't sure. Standard acts on the clear cases. Each step up acts on weaker evidence that catches more real fish, but it also catches more legitimate mail that happens to look odd, so the trade at every step is the same. You buy coverage with false positives. We'll spend a whole section on how to move that dial safely. Next, the impersonation settings three pieces here and they stop different things. User impersonation protection takes a list of names you choose and watches for anyone who looks like them. Same display name. Close variations of the name. This is your answer to the fake Sara Chen from a free mail account. Domain Impersonation protection takes a list of domains, yours and others, and watches for lookalikes. The swapped letter, the extra hyphen. This is your answer to the registered for the purpose domain mailbox intelligence is the third piece, and it's the one that makes the other two smarter. It uses the contact map we just covered. When it's on. Impersonation verdicts can account for who your users really talk to, so a trusted regular contact doesn't get flagged and a stranger wearing a familiar name does. There's also a mailbox intelligence protection option that goes further. It applies impersonation checks to the senders in each user's own contact history, not just your hand-picked list. That's what gives you reach beyond three hundred names. Now the layer that works without any list at all. Spoof intelligence spoofing is different from impersonation. In impersonation, the attacker sends from a lookalike. In spoofing, the attacker forges the actual sender address, so the mail claims to come from your real domain or real partners without having any right to spoof intelligence checks. Whether a sender is allowed to send for the domain it claims, and that check leans on the authentication records underneath SPF, DKIM, and dMarc. When those records are published and correct, the verdict is clear. When they're missing or sloppy, defender has to guess. We'll go into those records properly in a few sections, but know now that this setting is only as good as the DNS behind it. Then there's the part users actually see safety Tips. First contact safety tips appear when someone gets mail from a sender. They've rarely or never exchanged mail with a short banner says. So it sounds small, but think about the invoice scam. The attacker is a new sender pretending to be a known one. That banner is the one visible hint that something about this person isn't what it seems. At the exact moment a human decides whether to act. Unauthenticated sender indicators work in the same spirit. When a message fails, authentication checks outlook can mark the sender with a question mark on the profile picture and show the actual sending address. That helps with the display name trick because the real address gets pulled out of hiding. None of these block anything. They inform, but they cost nothing to switch on, and they're aimed straight at the moment of decision. So here's the map. In short, display name spoof user impersonation protection, plus first contact tips. Lookalike domain. Domain impersonation protection. Forged sender. Address. Spoof. Intelligence backed by authentication. Compromised partner. Mailbox. Intelligence. Because the relationship pattern may shift even when the address is real and borderline Phish with no obvious tell the threshold. Every setting has a target. If you can't name the attacker setting stops, you probably shouldn't be changing it. But one thing runs underneath all of this user and domain protection only defend the names you give them a perfect policy with the wrong list defends the wrong people, so the settings only work if the protected lists are right, and getting those lists right is its own decision. Protected users and domains. Choosing who gets defended. Here's the first limit you can't protect everyone. The user impersonation list has a cap in the Anti-phishing policy. You can add up to three hundred and fifty users per policy. That sounds like plenty until you try to fill it. A company of five thousand people has far more than three hundred and fifty names that someone could fake, and that's the point of the cap. Every name on the list is a name. Defender checks against every inbound message, add too many and the list stops meaning anything. You're back to treating everyone as equally important, which is the same as treating no one as important. Worse, you'll see more false positives on lookalike names, and your team will start ignoring the flags. So the list isn't a directory. It's a short list of names an attacker would gain the most by wearing who belongs on it. Start with the executives, the CEO, the CFO, the board members who actually send mail, their names, carry authority, and a request in their voice gets answered fast. Then finance approvers. Anyone who releases a payment changes a vendor's bank details or signs off on an invoice run. These are the people who receive the fake request, but they're also the names attackers use when targeting their own staff. HR belongs there, too. Payroll changes and personal data requests are favorite lures, and HR director is a title people obey without checking. Then IT admins a message from the help desk lead asking for a password reset or an approval prompt works because staff expect to hear from that role. And finally, anyone else who authorizes payments or access procurement leads legal counsel. The assistant who manages the CEO's inbox. If a fake version of that person could move money or open a door, they're on the list. Now the domains domain impersonation protection works the same way with a different target. Your own domains go in first everyone you own, including the old ones from past acquisitions and the vanity ones nobody mails from attackers. Love a lookalike of a domain you've half forgotten. If you've added the option to protect all domains you own in the tenant. Good. But that only covers what's registered to you. The second group is the outside domains. Your business depends on your top suppliers, the partners who send you invoices, the bank, the payroll provider. These are the domains an attacker would clone to reach your accounts payable team, because your people already expect mail from them. You can protect a bounded number of custom domains in the policy, so choose the ones where a fake would cost you money. Think about where your payments actually go, not which brands you recognize. So how do you decide? Here's the mistake I see most. The admin opens the org chart, finds the top of the tree and adds those names the CEO, the vice presidents, the directors. It feels logical. It's also incomplete. Risk doesn't follow the org chart. A junior accounts payable clerk who can release payments is a better target than a vice president who can't. A shared mailbox that handles supplier banking changes matters more than half the executive team, so pull the list from real data instead. Ask finance who actually releases payments. Ask procurement which suppliers you pay the most. Look at your own detections. Which names show up as impersonation attempts in threat explorer and the quarantine. Who gets targeted by fish that tried and failed? Those attackers already told you who they think matters. Take the hint. Then there's the clock. A list built at deployment starts decaying the same day. People change roles, someone moves into finance and starts approving invoices. An executive leaves and their name stays on the list for two years. A supplier gets replaced. New domains come in after an acquisition, so review it on a schedule. Quarterly works, check who still belongs, who's new in an approval role, and which partner domains your payments now flow through. It's a one hour job, and it's the difference between defending the real targets and defending last year's org chart. But even a perfect list rests on something else. Impersonation checks only work well when defender can trust the authentication records behind each domain, and those records live in DNS one level. Under all of this SPF, DKIM, dmarc the layer under the layer. Every impersonation check starts with one question can I trust the sender address on this message? If the answer is no, everything built on top gets weaker. Protected user lists, domain lists, mailbox intelligence. They all depend on that answer. So Anti-phishing quality comes down to domain authentication. And authentication lives in DNS outside the defender portal entirely. Three records. Each one proves something different. SPF says. Which servers are allowed to send mail for a domain? You publish a list of approved sending sources in DNS. When a message arrives, the receiving side checks whether the server that delivered it is on that list. It proves the delivery path was allowed. What it doesn't prove is the name the user sees in the from line. DKIM adds a signature. The sending server signs each message with a private key, and the public key lives in DNS. The receiver checks the signature if it matches. The message wasn't altered in transit and the signing domain really authorized it, so DKIM proves integrity and origin. dMarc ties them together. It checks whether SPF or Dkm passed and whether the passing domain matches the From address. The user actually sees that matches called alignment. Then dMarc tells receivers what to do when the check fails. Nothing. Quarantine or reject, so SPF proves the path DK improves the signature. dMarc proves the sender matches both, and states your policy for failures. Now how does Microsoft read all that? It rolls the results into a single verdict called composite authentication, or Composite Defender. Doesn't just look at SPF, Dkm and dMarc separately, it combines them with other signals like sender, reputation, and history, and produces a pass or fail. You'll see it in the message headers. A pass means the sender is who they claim. A fail means they aren't, or that defender can't confirm it, and a if fail doesn't always trigger the same action, what happens next depends on your policy, on whether the sending domain publishes a dMarc policy, and on how the domain relates to your tenant. A fail from a domain with a reject policy gets treated harshly. A fail from a domain with no policy at all leaves defender weighing softer evidence. That's why your own records matter so much. If your domain has a weak or missing dMarc policy, an attacker can forge your address, and nothing at the protocol level says no defender has to fall back on its models. If you publish a strict policy, the forged mail fails cleanly, and everyone who receives it inside your company or at your partners can reject it. So how do you get there without breaking your own mail? You move in stages. Start at monitor, which is a dMarc policy of none. Nothing gets blocked. You just collect reports showing every source that sends mail as your domain. That's where you find the marketing platform. Nobody told it about the old invoicing system, the forgotten application server. Fix those sources first, add them to SPF, enable DKIM signing for them, and watch the reports until the legitimate traffic passes, then move to quarantine. Failing mail gets held. Start with a partial rollout, a percentage of mail and widen it as the reports stay clean.

00:30:19 Speaker: Finally reject failing mail gets refused outright. That's the end state. It's also where mistakes get expensive, so don't skip the stages to reach it. Now the inbound side because it works the other way too. Your partners publish records as well, and plenty of them do it badly. A supplier sends you legitimate invoices from a system that isn't in their SPF record or without a DM signature. Their mail fails. Authentication defender sees a failure and treats it as suspicious on your side that shows up as a false positive. The invoice lands in quarantine, accounts payable files a ticket and the instinct is to allow list the supplier. But the real fault is in the supplier's DNS and the better fix is to tell them so. Authentication gives the policy something solid to stand on and gaps in it show up as noise you'll have to sort through. Which brings us to the dial. Most admins avoid touching because turning it up has a cost you'll feel in your helpdesk queue. The phishing threshold. Phishing thresholds aggressive without breaking mail for levels. Standard. Aggressive. More aggressive. Most aggressive. The setting sits in the anti-phishing policy and the names tell you the direction but not the cost. So let's spell it out. Standard is the default. It acts when the models are confident. Each step up lowers the bar. Aggressive acts on moderate evidence. More aggressive acts on weaker evidence. Most aggressive acts on almost any signal that looks like fish. Now what does act actually mean here? The threshold doesn't change what the policy does with the fish. It changes how much mail counts as fish in the first place. A message that's scored as a borderline case. That standard gets delivered the same message at a higher level, gets treated as a fishing verdict, and then the action tied to that verdict kicks in, quarantine, moved to junk, whatever your policy says. So raising the threshold widens the net. You catch more real attacks, you also catch more legitimate mail that happens to resemble one, a supplier's invoice with an odd link, a newsletter with a tracking redirect, a first time sender from a new partner. That's the trade, and it never goes away. Coverage costs false positives. So where do you start? Start at a level you can defend. For most users, that's the standard presets own setting and you leave it alone. That's the point of the preset. Microsoft already tuned it against far more male than yours. Then measure before you move anything. Look at your false positive rate at the current level. How many messages land in quarantine that shouldn't have. How many tickets does that create? That number is your baseline, and without it you can't tell whether a change helped or hurt. Only then do you step up and only for the people who justify it. This is where strict earns its place. Executives, finance approvers and IT admins sit in the strict preset, which already runs a tighter threshold. Those users get the wider net and they get it because an attacker pays more to reach them. Move one level at a time, wait a few weeks, check the same numbers. If the false positive rate holds, you've gained coverage for free. If it jumps, you've learned where the line sits for that group and you can step back. Here's a detail that makes aggressive settings livable. Pair the threshold with the right quarantine policy. A quarantine policy decides what the user can do with a held message. For lower confidence verdicts, you can let users see the message and request release or release it themselves. So when an aggressive threshold catches a legitimate invoice, the accounts payable clerk fixes it in a minute without a ticket. But that freedom has a limit. High confidence fish should stay admin release only if the model is sure no user gets to click it back into the inbox. We'll cover that set up properly when we reach quarantine policies. For now, the point is simple. A tighter threshold and a user friendly release path work as a pair. Now the wrong move. An admin reads that most aggressive catches more fish, so they open the policy, set it to most aggressive and apply it to everyone. Same day, same tenant. No baseline. No pilot. No warning to the business by afternoon. Quarantine is full of real mail, customer quotes, partner contracts, calendar invites from a vendor. Sales can't see their replies. Finance misses an invoice approval. The help desk queue fills up with the same sentence over and over. I didn't get my email and then something worse happens. The admin under pressure starts. Allow listing senders to make the complaints stop. Every allow entry punches a hole in the policy within a month. The tenant has a strict threshold on paper and a pile of exceptions. In practice, that outcome costs you twice. You lose trust with the business and you lose the protection you were trying to buy. So the discipline is slow on purpose. One group, one level, one measurement window. Then the next step. Because the threshold is only one piece of the picture, it governs how suspicious a message looks and impersonation protection governs who sent it. Both of those stop Acenda from being believed. But Acenda is often just the delivery vehicle. The payload that does the damage is frequently a single link inside the message, and that link has its own problem. Safe links. What time of click protection really does. Here's the old model. A message arrives, the filter scans the URLs inside it. Each one gets checked against a list of known bad sites. If nothing matches, the message goes through. After that, the link is trusted forever. That decision happens once at delivery, a single snapshot of a single moment. But in reality, a link isn't a fixed thing. It's an address that points somewhere and where it points can change. Attackers know this. They use it. They send a message with a link to a clean page, a harmless landing site, a fresh domain with no history. The scan passes, the mail lands. Then an hour later or the next morning, they swap what's behind that address. The page becomes a fake Microsoft sign in or it starts serving a malicious download. The message sits in the inbox untouched. The filter already made its call, and the user clicks a link that was safe at delivery and dangerous at click. Sometimes the delay is even simpler. The attacker holds the weapon back until the mail has been delivered at scale, then flips the switch. Either way, the check and the click happen at different times and the attacker lives in the gap. So Safe Links moves the check to the moment that matters. It works through URL rewriting. When mail arrives, defender takes each link in the message and wraps it. The visible text stays the same, but the underlying address now points to a Microsoft service first, with the original destination attached. Then the user clicks before they go anywhere that request passes through Microsoft's servers, the service checks the destination right then. Is this URL on a blocklist? Has it been reported? Does the page behave like phishing or serve malware? If it's clean, the user is sent through to the real site and they barely notice. If it's bad, they land on a warning page instead of the attacker's page. That's time of click verification. The verdict isn't a snapshot from delivery. It's a fresh check at the only moment where a decision actually changes the outcome and it keeps working after delivery. A link that was fine on Monday and turned hostile on Tuesday still gets caught on Tuesday because the check runs when the user acts, not when the mail arrived. Now where does this cover you? Email is the obvious one. Links and messages in both the body and attachments that support them get rewritten and checked. But work doesn't only happen in the inbox. Safe links also covers links shared in Microsoft Teams, in chats, in channel posts, in meeting messages that matters because attackers moved there to a compromised account, drops a link into a teams thread, and it carries the trust of a coworker. It also reaches into the office apps, links, inside word, Excel, and PowerPoint get checked at click in the desktop, web and mobile versions that support it, so a malicious link buried in a shared document gets the same treatment as one in an email. The protection follows the click wherever the click happens, but no protection covers everything, and it helps to know where the edges are. Safe links can only check what it can see if a link sits in a place defender doesn't process, there's nothing to rewrite and nothing to verify. Plain text that isn't recognized as a link, a URL typed into a message by hand, or one that arrives as an image of text, a link copied out of a message and pasted into a browser where the wrapper is gone. Apps and clients outside the supported set. Links inside encrypted or protected content that defender can't open. Some of that you can't fix with a the setting. It's the reason user behavior stays part of the control surface, and we'll get to that later. But some of it is down to configuration because Safelinks isn't a single switch. It's a policy with options, and those options decide whether the protection actually holds up when someone clicks several of the defaults. Leave real gaps, and that's where the next section goes. Safelinks policy Settings worth changing. Open a Safelinks policy and you'll find a short list of checkboxes. Most of the matter. A few of them decide whether the whole policy works. Start with real time URL scanning. The setting is called scan URLs in real time or something close to it, depending on the portal version. When it's on, defender checks the destination at click, which is the whole point of the product. Turn it off and you've kept the wrapper but dropped the check. Right beside it sits a second option. Wait for URL scanning to complete before delivering the message. This one is easy to skip and it shouldn't be. Here's why. Without it, defender delivers the mail first and keeps scanning in the background. That means a message with a fresh link can land in the inbox. While the verdict is still pending, a fast user can click before the check finishes with the weight turned on. Delivery pauses until the scan is done. You trade a few minutes of delay for a clean verdict before anyone sees the message. Most users never notice the delay. The ones who do are usually waiting on a one time code, so tell them early. Next. Internal messages there's an option to apply safe links to mail sent between people inside your own organization. Many admins leave it off. The thinking is simple internal mail comes from colleagues, so it's safe. But think about what a compromised account does. The attacker logs in as a real employee, then sends a link to that person's contacts from the inside. The mail never crosses your perimeter, so it never gets scanned like outside mail. And it carries a name everyone trusts. That's why you turn this on. A compromised account is one of the most common ways an attacker moves sideways, and internal mail is the road they use. Now, the setting that most often gets left open, letting users click through. When Safe Links blocks a page, the user lands on a warning. Below that warning, there's an option. Do not let users click through to the original URL. If it's off, the warning has a button that says continue anyway and people press it. Of course they do. They were trying to do something. A page stood in the way and a button offered a shortcut. The warning becomes a speed bump, not a wall. Turn that option on. Once it is, the block holds. If a link is truly safe and got caught by mistake, the fix goes through the admin who can submit it for review. That's a slower path for the user, but it keeps the decision out of the hands of someone who's rushing. Then there's tracking clicks. Safe links can record which links users clicked and by whom that data is useful. When a fish gets through, you can see exactly who clicked the bad link, and you can act on those names before the day is over. Without it, you're guessing, but it's also user activity data. In some countries and in some companies with works councils collecting IT needs agreement, a policy or a data protection review. So the answer isn't automatic. Check with your privacy and legal teams before you turn. Click tracking on and write down what you decided and why. The detection value is high, but the decision needs an owner who isn't just the security team. Now, how does any of this relate to presets? If your users sit in the standard or strict preset, these choices are already made. Microsoft set them and you can't edit them. That includes the real time scanning, the Waitfor scan behavior and the click through block. For most tenants. That's good news because the preset values are the sensible ones. Custom safelinks policies are different. Every checkbox is yours, and the defaults in a new custom policy aren't always the strongest. So if you build one, go through each setting on purpose, compare it against the preset values and write down any place you chose differently. That comparison is also a quick test of whether the custom policy deserves to exist. One more thing though. Even with every box ticked correctly, the policy has one more section left, and it's the one that quietly undoes the rest. A list of links Safelinks is told to leave alone because no policy is finished without exceptions, and exceptions are where it rots. Do not rewrite lists and exception debt. Every Safe links policy has a list called do not rewrite the following URLs. It starts empty. It rarely stays that way. So why do admins fill it? Three reasons. And every one of them sounds reasonable in the moment. First, a tool breaks an internal app, sends mail with a link that carries a token, and the rewrite mangles it. The button stops working, someone opens a ticket and the fastest fix is to exclude the domain. Second assigned link. Some services sign their URLs, and the signature covers the exact address. Wrap that address and the signature fails. Document signing platforms do this a lot, so the link goes on the list. Third, a partner portal. A supplier's login page loads strangely behind the wrapper or the scan slows it down. The partner says just exclude us. So you do. Each request is reasonable by itself. The ticket gets closed. Everyone moves on. But look at what that entry actually does. It tells defender to stop checking that address at click. Not sometimes. Not for one user, for everyone. The policy covers from now on. That's the part. Nobody weighs an exclusion doesn't expire. It has no reminder attached. And it doesn't care that the person who asked has left. It stays a whole until someone deliberately removes it. And in most tenants, nobody ever does. Now think about how those entries get written. Under pressure, people reach for wild cards instead of one exact path. They type the whole domain with a star in front. It fixes the tool fast, and it covers every future problem, too. That's where attackers come in. A wild card on a trusted domain, trusts everything that lives under it, and plenty of trusted domains host content that anyone can create. File sharing sites, form builders, document platforms, marketing tools. If you excluded the whole domain of a service where any customer can publish a page, you've excluded the attacker's page. Two they sign up for a free account, host a fake sign in on the trusted domain, and send you a link that Safe Links is told to ignore. The scan that would have caught it never runs. You built the bypass yourself. So how do you stop this from piling up? Treat every exception as dead. It buys you speed today and charges interest later. And like any debt, it needs terms. Three fields written down for each entry. An owner, the named person who asked for it and answers for it. A reason specific enough that a stranger could judge it a year from now and an expiry date. A day when the entry either gets removed or gets renewed on purpose. If an entry has no owner, nobody can defend it. If it has no reason, it probably shouldn't exist. And if it has no expiry, it's permanent by default, which is exactly how holes get made. Then put the review on the calendar. Every entry on that list gets looked at during the same monthly pass where you review detections. Does the tool still exist? Does the partner still send mail? Is the entry still as wide as it needs to be? Narrow it or delete it. But the better move is to avoid the exception in the first place. When an app breaks under, rewriting the link isn't the problem. The app is a link that dies when it's wrapped usually depends on something fragile, like a token in the URL or a strict signature check. Often, the vendor has a supported fix or a setting that works through the wrapper. Sometimes the answer is to send the link a different way, or to change how the tool builds it. That takes a conversation with the app owner, and it takes longer than typing a domain into a box. But it closes the problem for good, where an exclusion only hides it. And if there's truly no other option, make the entry as narrow as you can. One exact path, one owner, one date so the links are covered. Rewriting, scanning the settings, and the exceptions that quietly undo them. But a link is only one way into a mailbox. The other is the file attached to the message, and files need a different kind of check. Safe attachments. Detonation instead of signature. Old antivirus works from a list. It holds fingerprints of malware. It has already seen a file arrives, the engine compares it against the list, and if there's a match, the file gets blocked. If there's no match, it passes. That works well on old threads. It fails on new ones because a brand new piece of malware has no fingerprint yet nobody has seen it, so nobody has written it down. And attackers know this. They change a few bytes, repack the file, wrap it in a new document, and the signature no longer matches the same payload. Dressed differently. Walks past the list every time, so Safe Attachments doesn't ask whether it recognizes the file. It asks what the file does. That's detonation. Defender takes the attachment and opens it inside a sandbox, an isolated virtual machine that has no connection to your tenant. Then it watches. Does the document launch a hidden process? Does it reach out to a server it has no reason to contact? Does it try to change the system or download something else? If the behavior is hostile? The verdict is malware. No matter what any signature list says, the file proves itself bad by acting bad. And that's the structural change. You stop judging files by their history and start judging them by their behavior. Now, what happens to the message when a file turns out to be bad? That depends on the response option you pick. In the policy, there are four.

00:45:26 Speaker: Monitor delivers the message with the attachment and records the result. The user still gets the file. You get a report. It's useful for testing because you can see what safe attachments would catch without changing anyone's mail, but it protects nobody, so it's not a place to stay. Block holds the whole message. When malware is found, the mail goes to quarantine attachment and all this is the strongest option, and it's what you want as the long term setting. Dynamic delivery sends the message right away with a placeholder where the attachment should be, and attaches the real file. Once the scan clears. If the file is bad, the placeholder stays and the file never arrives. Replace was the older version of this idea. It removes a malicious attachment, delivers the rest of the message, and drops in a note saying the file was taken out. That option has been retired from newer policies, so you'll mostly meet it in older tenants that still carry it. So which one do you pick? For most people, the choice that works day to day is dynamic delivery, and it's worth knowing why detonation takes time. Defender has to open the file, run it and watch what happens, and that can take a few minutes with plain block. The whole message waits for that scan to finish. the user sees nothing until it's done. Even an ordinary email with a harmless note and a clean spreadsheet shows up late. Dynamic delivery removes that weight. The message arrives right away so the user can read the body and see who sent it. The attachment shows up as a placeholder, and a short time later the real file drops in. People keep working while the scan runs behind them. There's one more benefit. The delay is hidden, but the protection isn't reduced. The user can't open the file before the verdict because the file isn't there yet. Even so, you'll hear complaints. Some users will say attachments arrive late and they'll be right. The question is how you explain it. Don't promise there's no delay. Tell the business what they're buying. Say that new files get opened in a safe environment before they reach anyone, and that this takes a few minutes. Then give them the contrast. Without it, a stranger could send a file that's never been seen before, and the only test would be a list that doesn't know about it yet. For the few teams who truly can't wait, like a sales desk waiting on a signed contract, don't weaken the policy for everyone. Fix the narrow case. Talk through how that mail gets sent, or put that group's handling in a documented owned exception that covers the files that arrive by email. But email isn't the only place files show up. People share them through libraries and chats all day, and none of that passes through the mail filter at all. And that's the next gap to close safe attachments for SharePoint, OneDrive, and teams. Think about where your files actually live. A lot of them never touch email. Someone uploads a spreadsheet to a SharePoint library. A partner drops a contract into a shared folder. A coworker pastes the document into a team's chat. The file goes from one place to another, and no mail filter ever sees it. That's the gap. Everything we just covered the sandbox, the detonation. The response options applies to mail. A file that arrives through collaboration skips all of it, and attackers use that path on purpose. Once a single account is compromised, uploading a poisoned file into a trusted library is easy. Everyone who opens it assumes it's safe because it sits in a place they already trust. A file that was clean when it was uploaded can also turn bad later when the signatures catch up, or when someone swaps it for a new version. So there's a separate control for this. It's a tenant wide setting. In the safe attachment settings, you'll find the option to turn on defender for office three hundred sixty five for SharePoint, OneDrive, and Microsoft Teams. One switch, and it's off until someone turns it on. Here's what happens when it's on. Files in those locations get scanned in the background using the same engine that checks mail. Nobody waits for it. Nothing changes in how people upload or share. But when a file gets flagged as malicious, it's marked as infected and Microsoft locks it. Locked means locked. Users can't open it, can't download it, can't share it. Instead, they see a notice that the file was found to be malicious. And that's the second decision the setting leaves with you. By default, users can still press ahead and download a locked file if they choose to. That's the same click through problem we saw in Safelinks. The warning exists and a person in a hurry gets past it. There's an option to prevent that. Turn on disallow people to download malicious files in SharePoint, OneDrive, and Microsoft Teams, and the block holds the file is flagged. It can't leave the library either. Without it, you've detected the threat and left the door open anyway. Turn it on. The cost is almost zero because a file confirmed as malware has no business on anyone's disk. If a file was flagged by mistake, an admin can review it and release it. Now one more layer lives on the device itself. It's worth knowing because it covers what the cloud can't. Protected view is a feature of the office desktop apps. When a file comes from the internet, from an email attachment, or from an unsafe location, it opens in a read only mode. Macros are off, editing is off. The document is just a picture of itself until the user decides to trust it. Safe documents builds on that when someone clicks. Enable editing on a file that opened in protected view. Safe documents checks the file against Microsoft's cloud before it lets the exit happen. If the file is known bad, the user can't leave protected views, so the one button people press without reading becomes a checkpoint instead. That feature needs the right licensing. It only applies to supported office clients, but where it's available, it closes the gap between a file that looks fine and a user who's ready to click. Notice the pattern across all of this mail. Attachments get detonated. Files in collaboration spaces get scanned and locked files on the desktop, get opened in a restricted view, and verified different places. Different controls. One idea nothing is trusted just because of where it sits and all of that filtering links, files, impersonation thresholds produces a single result. Messages and files that defender decided shouldn't reach a person. They don't disappear, they go somewhere and the human has to deal with what's there. The quarantine. Quarantine is a product, not a folder. Most admins treat quarantine as storage, a place where bad mail goes to sit. You open it when someone complains. Scroll a list. Release one message, close the tab. But that's the wrong model. Quarantine is where a security decision lands on a real person's desk. Everything we've covered so far ends here. The threshold, the impersonation checks, the sandbox, the link verdicts. Each one makes a call about a message, and then somebody has to live with that call. A clerk waiting on an invoice, an executive missing a reply, an analyst who needs to see what the attacker actually sent. Quarantine is the point where policy meets work, and where you find out whether your tuning helps people or just blocks them. So what actually lands there? Several different things, and they aren't the same fish is the ordinary verdict. The models think the message is a phishing attempt, but with some room for doubt. High confidence fish is the same call with almost no doubt, malware is a message carrying a file or link that proved hostile. Spam is junk mail. The filter, called bulk, is mail that's technically legitimate but unwanted, like newsletters and promotions and policy hits are messages caught by your own rules, like transport rules or data protection settings. That mix matters because each one deserves a different response. Letting a user release their own newsletter is fine, letting them release high confidence. Phish is how breaches start. Yet if you treat all of it as one pile, you'll end up with one rule for everything, and it will be wrong for most of it. Now who can see and release? Admins can see everything. They sit behind the quarantine page in the defender portal. They can search, preview, release, delete and report back to Microsoft. Users can see their own held mail, but only what the policy lets them see. And that's where the role gaps show up. A user might see a spam message, but not a fish message. Another might see the entry, but not the release button. A shared mailbox might have no owner who can check it at all. Then there's the group in between your help desk team. They get the tickets they need to look, and they shouldn't hold full admin rights to do it without a scoped role for them, you get one of two bad outcomes the help desk can't help, or everyone who touches the cube becomes a security admin by accident. Neither is good. Think about this before the first complaint arrives, not after next defaults versus what people actually need out of the box. The quarantine experience is built for the average tenant. Everyone gets the same behavior for the same verdict, but your tenant isn't. Average finance may need to see held invoices quickly. A sales team may live on mail from first time senders. A small group may handle malware samples for a living. One default can't fit all of those, and when the default doesn't fit, people root around it. They call the help desk. They ask a colleague to resend by another channel. They tell the sender to use a personal address. Each workaround quietly weakens the control you were trying to build. Then there's the failure mode that sits under all of this. A quarantine nobody reviews becomes a black hole. Mail goes in, nothing comes out. Users learn that health messages vanish, so they stop checking. Admins stop looking because the tickets slowed down. Messages expire on schedule, usually after thirty days, and with them goes the evidence. A real invoice that never got released. A real attack you could have studied. A pattern of false positives that would have told you the threshold was wrong. The Q is also a sensor. It tells you what your policies are really doing. If you never read it, you've switched off the feedback you need. So the experience of quarantine isn't fixed. It's shaped by a set of controls you can change. One verdict at a time. They decide who sees what, what users can do about it, and how they find out. Those controls are called quarantine policies, and that's where we go next. Quarantine policies and notifications. A quarantine policy answers one question. When a message gets held, what can the user do about it? You don't set that once for the whole tenant. You set it per verdict type. Spam gets one policy, fish gets another, malware gets its own. Each verdict points to a policy, and that policy decides whether the user sees the message at all, whether they can preview it and whether they can release it or only ask for release. That's the structural change. Instead of one behavior for everything that lands in the queue, you match the freedom to the risk. The portal names the two ends of the scale. Limited access and full access. Limited access is the careful setting. The user can see that a message was held and they can preview it, they can request release, which sends the request to an admin. They can delete it, but they can't release it themselves. The decision stays with someone whose job is to make it full access, gives the user more. They can release the message to their own inbox, and in some cases they can also release it to someone else. So a held message is back in front of them in a few seconds, with no ticket and no waiting. Neither one is better. They fit different Verdict's full access fits the low stakes categories. Bulk mail, ordinary spam messages where the worst outcome is an annoying newsletter, and where a wrongly held message costs the user more than a wrongly released one. Costs you let people clear those themselves. It's faster for them, and it keeps routine noise away from your team. Limited access fits the middle standard fish where the model had some doubt. Here the user can see what was held and ask for it back and an admin makes the call. That's also where the threshold work from earlier pays off, because a tighter dial catches more borderline mail, and the request path gives the clerk with a stuck invoice a way forward. Now the two verdicts where the answer is different high confidence fish and malware stay admin release only think about what those verdicts mean for high confidence fish. The models are as sure as they get for malware. The file already proved itself hostile in the sandbox. There's no real doubt left to resolve, and if a user can release one of these, the control depends on that user making the right call under pressure, which is exactly the thing the attacker is counting on. The attack runs like this. A convincing message gets caught. The user notices that something they expected didn't arrive. They find it in quarantine and the sender looks right, so they release it. One click and the filter's whole decision is undone by the person it was protecting. So don't allow it. Use the restricted policy for those two verdicts where the user can't release and can't even request release if a message truly was caught by mistake. An admin reviews it and decides that path is slower and it should be. Then there's the question of how users find out anything was held. That's the job of end user quarantine notifications. A notification is a short summary mail that tells a user which messages were held for them. It lists the sender, the subject, and a link into the quarantine page. Without it, a held message is invisible and the user only learns about it when something goes missing, you control how often it arrives. The default sends a digest every four hours, and you can change the cadence from every few hours up to once a day or once a week. More frequent means faster recovery for a real message. It also means more mail in the inbox and more chances for people to tune it out. And notifications are tied to the quarantine policy, a policy that lets users see a verdict type can also send them a notice for it. A policy that hides the verdict sends nothing. So for admin release only verdicts, the user gets no notification at all, which is the right behavior. Put these together and the help desk numbers change. Most tickets in this area say the same thing. I'm waiting on an email and it never came. If users can see held mail and if they get a digest that points to it, many of those tickets never get filed. They release the bulk mail themselves. They request the borderline ones with a click, and the admin queue shrinks to the cases that truly need judgment. Risk doesn't go up because the freedom only exists where the stakes are low. But policies only set the rules for what users can do. They don't tell you whether the decisions behind the queue were right. Every message in there is either a good catch or a mistake and somebody has to sort one from the other. And that's the daily workload, the false positive loop. Handling false positives and false negatives. Every message in quarantine is one of two things. A good catch or a mistake. And the same goes for the mail that got through. Some of it was fine. Some of it was an attack you missed. A false positive is a good message that got blocked. A false negative is a bad message that got delivered. Tuning is the work of shrinking both. And you can't shrink what you don't report. So start with the reporting path. In the defender portal, there's a page for submissions. An admin can send a message, a file, a URL, or an email attachment to Microsoft for analysis and tell them what they think it is. Say a clean invoice got held. You submit it as should not have been blocked or a fish landed in someone's inbox. You submit it as should have been blocked. That submission does two things. Microsoft's analysts and models look at it and can adjust their verdicts. So the fix reaches every tenant, not just yours. And the result comes back to you with an explanation of what the system saw and why it decided what it did. That explanation is often the most useful part, because it tells you whether the problem sits in Microsoft's detection or in your own setup. Now, when you submit a false positive, you get an option next to it. Add an allow entry that creates a rule in the tenant allow block list. And it matters that you understand how it behaves. These entries aren't permanent by default. You pick an expiry and the system also watches the entry itself. If Microsoft's own filters later learn the sender is fine, the allow entry becomes unnecessary and it's removed on its own. If the sender really is bad, the entry stays until it expires and then it's gone. That's deliberate. A temporary allow gives you a short window to keep mail flowing, while the real fix lands it's built so that a rushed decision doesn't turn into a standing hole. Compare that with the exclusion list we talked about earlier, which never expire unless you make them here. The product does some of that discipline for you. Then there's the third source, and it's the one most tenants under use the users themselves. Your people see things, your tools can't. A message that reads wrong. A sender who sounds off an invoice from a supplier who never uses that tone. If they have an easy way to say so, they become a sensor network across the whole tenant. That's the report button In outlook, users can report a message as phishing junk or not junk. It's built into the client. Or you can deploy Microsoft's report add in. You can also point those reports to your own mailbox, to Microsoft, or to both, depending on how you want triage to work. Each report lands in the submissions queue, tagged with who sent it, and that gives you two signals at once. You learn what got passed the filter, and you learn who's paying attention, which will come back to when we look at simulation results. Now the first reflex. When a good message gets blocked, someone complains a supplier's mail is stuck, the admin opens the tenant list, types in the sender and allows it. Ticket closed. Thanks all around. But look at what just happened. You told the system to stop checking one sender and you did it without asking why the message got caught. Maybe the supplier's SPF is broken, maybe their DKIM isn't signing. Maybe an aggressive threshold hit a perfectly normal invoice, allowing the sender hides every one of those causes. Next month, another supplier hits the same wall and you do it again. There's a second problem too, and allow entry for a sender can also let that sender's spoofed mail through depending on how it's scoped, you've traded a nuisance for a way in.

01:00:16 Speaker: So the first move should be to ask what failed. Check the headers, read the verdict, find out whether it's a DNS problem, a threshold problem, or a policy problem. Then fix that. Only after that should you consider a short lived allow with an expiry to bridge the gap. That's the habit that closes the loop. Every mis in either direction should end with a change to a policy, a list, or a record, not just a message moved out of a folder. Ask at each time what would have stopped this. Then change that thing. Write down why and move on. Because if the same mistake can happen twice, you haven't tuned anything. You've only cleaned up. But to ask those questions, you have to see what actually happened to each message, where it came from, what the filters decided, what happened after delivery. You can't tune what you can't see, and that's what the investigation tools are for. Threat explorer and real time detections. Threat explorer is where the portal stops summarizing and starts showing you mail every message in a searchable list who sent it, who got it, what defender decided, and what happened next. If the quarantine page is the result of a decision, this is the record of how the decision was made, and it splits the story into three groups delivered the message reached a mailbox, blocked defender stopped it before delivery. So it went to quarantine or got rejected and detected after delivery, which is the group most admins don't expect to exist. That last group exists because a verdict isn't final. A message can look clean when it arrives and turn out dirty later. A link goes live, a sender gets reported by another tenant. A new signature lands the filter that waved the mail through at nine a m knows something different at eleven, and by then the message is already in the inbox, so there's a second chance built in. It's called Zero Hour auto purge or zap. Here's what it does after delivery defender keeps reevaluating mail that's already sitting in mailboxes. If the verdict changes to fish malware or high confidence fish Zap goes back and removes the message, it moves it to junk or to quarantine, depending on your policy. And it does it whether or not the user has opened it. One limit matters here. If the message was already read or already moved to another folder, the picture gets messier. Zap acts on what it can reach, and some actions depend on where the message ended up. It narrows the window. It doesn't close it, which is why you read the verdict, not just the label. Open any message in Thread Explorer and look at two fields delivery, action and detection technology. They answer different questions. Delivery action tells you what happened to the message. Delivered, delivered to junk, blocked, replaced, and a related field delivery location tells you where it physically went. Inbox junk folder quarantine or gone detection technology tells you why. Which part of the stack made the call. It might say Phish or spoof or impersonation or malware, or a URL detonation result. It might point to mailbox intelligence or a campaign match or a reputation block. That field is the one that tells you which control actually earned its keep. Read them together. A message delivered to the inbox with a detection technology of none is a true myth. Nothing flagged it. A message delivered to junk with an impersonation tag tells you the policy fired, but the action was soft, and the message marked as removed by zap tells you the first scan failed and the second one courted. Each combination points at a different fix. A true miss sends you to thresholds or protected lists. A soft action sends you to the policy's response settings. A zap save tells you the initial verdict was too slow, which is normal, but worth counting. Now, the habit that changes how useful this tool is. Don't look at one message at a time. An analyst gets a report of one fish. They open thread explorer, find that message and deal with it. Delete it from that mailbox. Block that sender. Done. But that message wasn't alone. The same attacker sent the same lure to forty people from three different addresses, with two slightly different subject lines. If you only chase the one you were told about, thirty nine are still sitting there. So filter by campaign thread explorer groups messages that share traits like the same sender infrastructure, the same URL, or the same body pattern into a single campaign. Now you're not looking at a message, you're looking at an attack. How many people got it? How many it reached, how many clicked, which ones got removed, and which are still waiting. That's a different question to answer, not what happened to this email, but what is this attacker doing to us and how far did it get? And once you can see an attack as a unit, a bigger question opens up. What does the pattern across many attacks say about your policies? A single detection tells you about one message. The pattern across them tells you where you're weak. Campaign views IR and the response loop. Open the campaign's page in the defender portal and the unit of work changes. You're no longer reading a list of messages. You're reading a story. Each campaign has a beginning and an end. The first message that matched the last one who sent it from which infrastructure, with which lure. Then the part that matters most. How many recipients got it? How many were blocked? How many landed in an inbox, and how many people clicked? It reads like a timeline of one attack moving through your tenant. That changes the questions you ask. Not was this message caught, but who was targeted and why them? If a campaign hit only your finance team, that tells you something about the attacker's research. If it hit one executive's contacts, that tells you something about a compromised account. The shape of the targeting is evidence, and the single message can't show you shape. It also shows you where your policy leaked. Say a campaign reached sixty people and fifty four were blocked. The six who received it are the interesting ones. Which policy were they in? Were they outside the pre-set scope? Did a custom policy with a softer action cover them? The campaign hands you a list of exactly who to look at. Now seeing the attack is one thing. Cleaning it up is another, and that's what automated investigation and response does. AI for short. It's a plan two feature, and it's easy to misread. It isn't a scanner. It's a workflow that starts after something already went wrong or looks wrong. So what triggers it? A few things a user reports a message with the report button. An alert fires like a message removed by zap after delivery, or a user who clicked a link that turned out malicious, or an admin starts an investigation by hand from Threat Explorer. Any of those opens an investigation on its own. Then the system does the legwork. A person would do only faster. It looks for the same message across other mailboxes. It checks the sender, the URLs, and the files. It asks whether anyone clicked and whether any account shows signs of being compromised. At the end, it proposes actions soft delete these messages from these mailboxes. Block the sender. Block this URL. Turn off this accounts mail forwarding or flag a user for review. Notice the word proposes. That's where the next decision sits and it's the one tenants get wrong. Those remediation actions can wait for approval by default. Many of them do. They sit in the Action Center as pending with a clear list of what will happen and to whom. Nothing moves until a person says yes, and that's where things sit unread. The investigation finished in twenty minutes. The proposed fix has waited nine days. Meanwhile, forty copies of the fish are still sitting in mailboxes, and the one user who clicked still has an open session. The system did its job and the review step didn't, so treat approvals as a queue with an owner. Someone checks the Action center every working day. Anything pending gets a decision. Approve or reject with a reason. Rejecting is fine when the proposal looks wrong because that's a signal about your setup, but leaving it untouched is the one answer that helps the attacker. Some teams go the other way and automate approval for the lowest risk actions, like removing a confirmed fish from mailboxes. That's a legitimate choice as long as someone owns it and reviews what it did. Then there's the view above all of this an email attack rarely stays in email. A clicked link becomes a stolen sign in, and a stolen sign in becomes activity in other places. That's why our findings feed into defender XDR. The investigation links to an incident, and the incident collects related alerts from across products. The fish that started in exchange sits next to the suspicious sign in from intra and the endpoint alert from the device that opened the file. One incident, one timeline, one owner. Without that link, three teams look at three alerts and never learn their one attack. So the response loop closes in a clear order. See the campaign. Let air investigate, approve the fix and follow it into the incident. But all of that machinery starts after a message reached a person. And no matter how well it runs, some of them will click. So the other half of the picture is the people. Why technology alone fails the human layer. Here's a fact no policy can change. Some fish will arrive anyway. You can set every threshold to the top, protect every executive, enforce dMarc, detonate every file, rewrite every link, and the message still lands in someone's inbox. Maybe it's a lure so new nothing has seen it. Maybe it comes from a real partner account. Compromised an hour ago, so every check passes. Maybe it's just a polite request from a name that looks right with nothing in it to detect. That's not a failure of tuning. It's the edge of what filtering can do. A filter judges a message by what it can measure. Attackers write messages to measure as clean. So the real question isn't how to stop everything. It's what happens in the next 10s after the message is open and the person has to decide. And in that moment, the person is part of the control surface. Think about it. Structurally, you have controls that act on mail policies, thresholds, sandboxes, link checks. Each one reduces what reaches the user. Then there's one more control at the last step, and it's the only one that sees context. The employee knows finance never asked for gift cards. They know the supplier doesn't normally write like this. They know they weren't expecting a shared file. Today. A tool can't know any of that. A person can if they've been taught what to look for and what to do about it, which means their behavior isn't a soft spot outside the system. It's a layer inside it. And it can be tuned the same way a policy can. But most organizations don't treat it that way. What typically happens is a yearly training, a video, maybe thirty minutes long with a quiz at the end. Everyone clicks through, passes and gets a certificate, the completion rate goes into a report and the box is checked. And then nothing changes because that model measures attendance, not behavior. It tells you who sat through the video. It tells you nothing about who would recognize a fake sign in page on a Tuesday afternoon, with a deadline pressing and forty unread messages behind it. People forget a video within weeks. Worse, it teaches the lesson in a calm setting, far from the moment where the lesson is needed. There's also a quieter problem. A yearly checkbox tells people that security is an annual event, something the company does to them once and then leaves alone. That's the same old model we started with. Set once and assume safe only applied to humans. The better model works the other way around. Don't explain the attack. Let people meet it. Send them a realistic lure, the kind your tenant actually receives, and see what they do. If they ignore it or report it, that's a good result. And you can say so. If they click, they get feedback right? Then while the memory is fresh, a short, specific lesson on what gave it away delivered at the exact moment it matters. Then repeated with different lures on a schedule practice feedback practice over months. You can watch behaviour shift because you're measuring what people do, not what they sat through. That's a loop, the same shape as everything else in this video test, observe, adjust, test again. And Microsoft built that practice directly into the product. It's the plan two feature that turns this from a training department project into something. You run from the same portal as your policies attack simulation, attack simulation training, running it properly, attack simulation lives in the defender portal under email and collaboration. Same place as your policies. That matters. You're not buying a separate training product. You're running tests from the console that already holds your detection data. Start with what it can simulate. Each technique matches a real way people get hurt. Credential harvest is the classic. The user gets a message with a link to a fake sign in page. They type a password. That's the test, and it mirrors the most common attack on any tenant. Malware attachment is next. A file arrives, the user opens it, and something runs in a simulation. Nothing harmful happens. The click is simply recorded. Link in attachment mixes the two. The message carries a document and the document holds the link that one matters because people trust a link more when it sits inside a file. Drive by URL is the quietest. The user clicks a link, lands on a page, and the test ends there. No password, no file. It tells you who follows links without looking. There are a few more like OAuth consent grants where a fake app asks for permissions, but those four cover most of what you'll see. Now the choice that decides whether any of this teaches anyone the payload defender gives you a library of ready made lures, a shipping notice, a password expiry warning, a shared document request. You can also build your own and the right pick is the one that looks like mail your people already get. Look at your real data. Pull the top campaigns from the last quarter. What themes keep showing up? If attackers keep sending fake invoice requests to finance test finance with a fake invoice request. If your staff gets constant shared file notices, use one of those. Why does this matter? Because a lure that's obviously fake teaches nothing. People spot it, feel clever, and learn nothing about the one that's actually coming. A lure that matches reality builds the exact reflex you need next. Who gets it? The lazy move is to blast everyone at once. One campaign, one click, the whole tenant. It's easy and it creates two problems. First, news travels the moment a few people spot the test, they warn the rest. By the afternoon, half the company knows. And your numbers reflect gossip, not behavior. Second, a blast hides the pattern. You get one big number and no way to read it. So target by group. Start with a pilot, a small team that's good natured about it and check that everything works. Then move to departments one at a time with lures that fit their work. Stagger the sends across days, keep some groups out of rotation so you have a clean comparison and treat your priority accounts as their own. Group executives and finance approvers face sharper attacks, so they need sharper tests. Then comes the moment after the click, which is where the learning happens. Every simulation can send the user to a landing page. It shows right away what they just did and what gave the lure away the wrong sender address, the odd link, the pressure in the wording. It's short, specific, and it lands while the memory is still warm. After that, you can assign training a short module attached to the failure sent automatically. Pick modules that match the technique. Someone who fell for a credential lure gets a lesson on sign in pages, not a general overview of everything. Keep the lessons brief. A person who just got caught is paying attention for about five minutes. Spend them well. Last. What you need before you start attack simulation training is a plan two feature. That's defender for office three hundred sixty five, plan two or a Microsoft three. Sixty five license here. That includes it. You also need the right role. The attack simulation administrator role covers it, and it keeps this work separate from broader security access. And one technical detail trips people up. Simulation mail has to reach the inbox to be a fair test. Microsoft handles that for its own simulation, so you don't need to exempt anything. But if you add a third party gateway in front of exchange, check that it isn't catching the test mail first. So the launch itself is easy. Pick a technique. Pick a payload, pick a group, press go. Anyone can do it in an hour, but the numbers that come back are another matter because running simulations is easy and interpreting them is the hard part. Reading simulation results without fooling yourself. The first number everyone looks at is the click rate. Fourteen percent clicked last quarter. It was nineteen. The slide goes to leadership and the trend line points down. So everyone feels good, but that number is weaker than it looks. It tells you how many people clicked the link in one message on one day from one lure. Change the lure and the rate swings by ten points. Send it at nine on a Monday instead of four on a Friday and it swings again. A click rate measures the test as much as it measures the people, and it only counts one kind of behavior. the bad kind. It says nothing about the people who saw the message and did the right thing. That's the number you should care about more. The report rate. Who looked at the lure and used the report button? Who flagged it to security without being told to? Those people did something harder than not clicking. They noticed. They stopped and they raised their hand. Each report feeds the same submissions queue we covered earlier. So in a real attack, that behavior is what gets forty copies of a fish pulled from forty mailboxes before lunch. Watch the gap between the two numbers over time. A tenant where fewer people click and more people report has built something real. A tenant where fewer people click and almost nobody reports has just taught people to ignore mail they don't trust. That looks like progress on a slide. In an actual incident, it means silence. There's also the time dimension. How fast did the first report come in? Ten minutes is a team that acts like a sensor network. Three days means the attacker had the whole weekend. Now go one level deeper than the click. Clicking a link and handing over a password are different events. Plenty of people click out of curiosity, see a sign in page and close the tab. Others type their credentials and press enter. Only the second group would have lost an account.

01:15:26 Speaker: That's the compromise rate in a credential harvest simulation. The report shows who submitted data, not just who landed on the page. That's the figure that maps to real damage. A stolen password is a stolen identity with everything that follows from it. So split your results into three groups, clicked and left, clicked and entered credentials and reported. Each group needs a different response. The first needs a reminder, the second needs real training and maybe a closer look at their account. The third needs a thank you because positive feedback is what makes people report again. Then there's the group nobody wants to talk about repeat clickers. The same names showing up in campaign after campaign. It's tempting to build a list and send it to a manager, and some programs do exactly that. Don't. Shaming has a predictable effect. People who feel watched stop reporting mistakes. They hide the click. That was real and that's the one that would have mattered. The goal is a culture where someone who clicked on a real fish says so within minutes, not one where they stay quiet and hope so. Look at why the repeats happen. Often it's the role, not the person. Someone in accounts payable opens invoice mail all day, so an invoice lure always finds them. Someone who handles vendor requests lives in unfamiliar senders for those people give targeted training. Tighter technical controls and a calm conversation. A stricter preset for that group. A quicker route to ask whether a message is real. The aim is fewer successful attacks, not a cleaner scoreboard. And last, the trap that ruins all of the above easy campaigns. It's very easy to pick a lure that flatters you. A badly spelled message from an obvious stranger with a link that looks wrong. Nobody clicks the right drops and the program looks like a success. But you've measured nothing. You tested whether people can spot a fake that nobody would fall for. So keep the difficulty honest. Rotate lures mix in ones that match your real attack data, and sometimes pick one that's hard on purpose. If a campaign's rate jumps, don't hide it. That's the test showing you something true. Compare like with like. Same technique and similar difficulty. Or the trend means nothing because a number you can't trust is worse than no number at all. So now you have three views of the same tenant, what the policies catch, what quarantine holds, and what people do when something gets through. The next step is to bring those together and decide which numbers actually belong on one page. Metrics that show whether tuning works. A tuned policy is a claim. It says this setting makes us safer and a claim needs evidence. Or it's just a belief with a change ticket attached. So there are four places to look for evidence detection, people, operations and business. Each one answers a different question, and each one can lie to you if you read it alone. Start with detection. The first number is fish delivered to the inbox, not fish. Blocked. Blocked is the number every report loves because it's big and it only grows. Delivered is the one that matters because that's what reached a person. If you tighten a threshold or fix a protected user list, this is the number that should fall. If it doesn't, the change did nothing, no matter how good it felt to make. Next, it's time to remediate when a bad message gets through. How long until it's gone from every mailbox? Measure it from delivery to removal. Whether that came from zap, an AR action or an admin. Minutes is a system. Working days means an approval queue is sitting unread, which we talked about earlier. Then the zap rate. How many messages did zero hour auto purge pull back after delivery? A rising zap rate sounds like good news because the safety net is catching more. But read it the other way too. Every zap save is a message the first scan missed. If the number keeps climbing, your front door is getting weaker and the net is hiding it. Now the human side. We covered how to read simulation results. So here it's only about which numbers go on the page. Three of them report rate, click rate and time to report put report rate. First click rate sits beside it as context. Never alone. And time to report tells you how fast your people turn, a mistake or a suspicion into something. Your team can act on. Track all three by group, not just tenant wide. So a weak department can't hide behind a strong average then operations. This is where tuning shows its price. False positive rate comes first of everything quarantined. What share was legitimate? Tighten a threshold and this number will rise. That's expected. What you're watching for is whether it rises a little or a lot, because a big jump means you raise the dial too fast. Next, quarantine release volume. How many messages did users release themselves and how many did admins release on request? A flood of admin releases for one sender points to a broken record on their side. A flood across many senders points to a policy that's too hard on normal mail and help desk tickets count the ones that start with I didn't get an email. It's the most honest measure of how the tuning feels from the outside. If detection improves and tickets double, you haven't won yet, you've moved the cost onto someone else last. The business side. These are harder to pull and they're the ones leadership cares about. Beak attempts blocked. Not all blocked mail, only the impersonation and fraud attempts aimed at people who can move money. Incident count. Meaning how many email driven incidents reached a real investigation this quarter compared to the last and cost avoided, which is an estimate. So label it as one. Take a conservative figure for what one successful payment fraud costs. Multiply by the attempts you stopped and show your math. A number with its assumptions visible is more believable than a big number without them. So where does the data actually come from? Most of it is already in the defender portal. The Threat Protection Status report shows what was detected and delivered by threat type over time. The Mail Flow Status report shows how mail moved through filtering, including what got blocked, what got through and where it ended up, and for anything those reports don't cover. Advanced hunting lets you query the raw email events yourself. Delivered fish by recipient group. Time between delivery and zap messages that reached the inbox with no detection tag. One saved query per metric and the same question gets asked the same way every time that last part matters. The value isn't in any one number. It's in comparing this month to the last one using the same method. But a set of good metrics isn't a program yet. Pull them once and you have a snapshot. Pull them on a rhythm with names attached and decisions following, and you have a loop. Without that rhythm, these numbers become a dashboard that everyone built and nobody opens the tuning loop, a quarterly operating rhythm. A loop needs a clock without one. The metrics sit in a report, and the report sits in a folder. So give the program three speeds monthly, quarterly, annual. Each one has a different job. Mixing them up is how teams either drown in detail or never change anything. Monthly is the review of what happened. Pull the top detections from the last thirty days. Which campaigns hit you? Who they targeted? Which controls stopped them, then read the misses which matter more. Every message that reached an inbox with no detection tag gets a question what would have stopped this? Check? The exceptions to open the tenant allows block list that do not rewrite list and any custom bypass rules. Anything added this month gets an owner and a reason or it comes out. That meeting should take an hour. If it takes a day, you are fixing things inside the review. The fixes belong after it. Quarterly is where you change settings. By now you have three months of numbers. That's enough to separate a trend from a bad week. So look at thresholds. If false positives stayed low and delivered, fish stayed flat. Maybe the priority group is ready for a tighter level. If tickets spiked, maybe one step back is right. Then the protected user and domain lists who changed roles, who joined finance? Which partner started sending you payment requests? The list you built at deployment is already out of date. The quarterly pass is when you fix it last the simulation plan which groups got tested, which lures got stale? Which techniques haven't run at all? Pick next quarter's campaigns from your real attack data, not from whatever's easiest to launch. Annual is the structural question. Once a year, step back from settings and ask whether the model still fits, which custom policies earned their place, which ones exist because of an incident two years ago that nobody remembers? Could they move back under standard or strict? So Microsoft's tuning does the work and you stop carrying the drift. Also recheck licensing. Maybe a group now needs plan two features. Maybe a license is paid for and unused. This is the review where you're allowed to delete things. Now none of this runs on goodwill. Someone has to own it. One named person is accountable for the program, usually a security lead or a messaging admin who's been given the time. They run the monthly review, they bring the quarterly changes, and they sign off on every exception. If five people share responsibility, nobody has it. Then decide what that owner reports and to whom. A short written summary each month to the security manager or whoever answers for risk. Five or six numbers from the metrics we just covered. Plus what changed and why? Once a quarter, a slightly longer version goes up one more level. Keep the format the same every time. That way people compare instead of rereading from scratch. One more thing and it saves a lot of effort. You don't have to find drift by memory. Microsoft ships a configuration analyzer in the defender portal under email and collaboration policies. It compares your policies against the standard and strict recommendations setting by setting. It lists every place you've drifted below them. It shows you who changed what and when. Run it at the start of each monthly review. If a setting got loosened during an incident and never put back. This is where it shows up. It also gives you a quick way to apply the recommended value. So a fix takes one click instead of a project. That's the whole rhythm. Review. Adjust, reassess. Same questions, same data, a name on each step. But the people who fund this program don't speak in thresholds and quarantined verdicts. They ask different questions in different words. So the same story needs to be told twice. Executive view funding and governing the program. An executive doesn't fund a threshold. They fund an outcome. Fewer fraudulent payments. Fewer accounts taken over. Less time spent cleaning up after both. So the first job is translation. Every control we've covered has to turn into a sentence. A leader can approve without needing a glossary. We're tightening protection for the twenty people who can move money is a sentence we're raising the fishing threshold to level three is not same action, different audience lead with who is protected and what they're protected from. Keep the setting name for the appendix. Now what should you ask for? Three things. Each one maps to a gap we've already seen. First plan two coverage for priority accounts, not the whole tenant, unless the budget allows it. Executives, finance approvers and IT admins are the people attackers study plan two is where Threat Explorer, Automated Investigation and Attack Simulation live. Ask for the license where the targeting is sharpest. Show the campaign data that proves who gets targeted. Second. dMarc enforcement this one costs almost nothing in licensing and a lot in coordination. It needs time from DNS owners, marketing teams, and every vendor sending mail as your domain. So the ask isn't money. It's a mandate with a named sponsor who can say, move to quarantine by this date and make the other teams hear it. Third, a simulation cadence, a set rhythm with groups, lures, and follow up training agreed in advance that turns awareness from a yearly event into a funded repeating activity. Notice what's not on that list. More tools. When a program feels weak, the reflex is to shop a new gateway, another detection layer, a platform that promises to fix it. But look at what we've covered. Most tenants haven't scoped their presets correctly, haven't reviewed their exceptions, haven't read their own quarantine. Buying another product on top of that adds another set of defaults. Nobody tuned, so hold the request until you can show the current tools were measured. If the numbers say a real gap remains after tuning, then ask with evidence. Until then, the answer to do we need more is we haven't used what we have. Next, how you report leaders don't read twenty metrics. Pick three numbers that tell the whole story. Fish delivered to the inbox trending down. That's the technical result report rate trending up. That's the human result. And time to remediate trending down. That's the response result. One number from each layer shown quarter over quarter with a single sentence on what changed and why. If a number moves the wrong way, say so and say what you'll do that earns more trust than a flawless chart ever will. And then the part most programs skip, say out loud that the risk isn't zero. It can't be. We've established that some fish will arrive no matter what, so present it directly. Here's what we've reduced. Here's what remains. Here's what it would cost to reduce it further. And here's why we're choosing to stop at this point or not. Let the business accept that residual risk by name with an owner and a date to revisit it. That does two things. It stops anyone from being surprised when a real incident happens and it turns, are we secure into a better question? Are we secure enough for what we're willing to spend? A leader who has accepted a risk knowingly will back you when it happens. One who was told there was no risk will look for someone to blame. Which brings us to the ways this whole structure quietly falls apart. The failures aren't exotic. They repeat across tenants in the same order for the same reasons, and each one undoes work you thought was finished. Common failure patterns and their fixes start with the quietest one. A custom policy gets built. Someone spends an afternoon on it. Threshold set protected users added actions chosen. Then it never touches a single recipient. Maybe the scope was left empty. Maybe it was scoped to a group that got renamed, Or maybe a preset policy already covers everyone, so the custom one never gets a turn. The policy exists, the review says configured, and nobody is protected by it. The fix is a check, not a rebuild. For every custom policy, ask the portal who it applies to and confirm that at least one real recipient lands there. Run it after every scope change and keep a name next to the answer. The second pattern starts during an incident. A supplier's mail is stuck. The CFO is asking, so someone adds an allow entry or a do not rewrite exception or a bypass rule in mail flow. And the pressure lifts. Everyone moves on. Nobody comes back. Six months later, the exception is still there and the supplier's domain was compromised in March. You've been waving their mail through ever since. Incidents are when exceptions get written fastest and reviewed least. So change the rule for emergencies, not the speed. Anything added under pressure gets an expiry date on the spot, even a short one. And the monthly review we covered reads that list first every time. Third, the protected user list. It was built at deployment from the org chart as it stood that week. Twenty names carefully chosen. Then a new finance director joined the head of procurement changed. Someone got promoted into payment approval. None of them are on the list and the people who left are still on it. So the impersonation protection defends a company that no longer exists and attackers don't use last year's org chart. They read the current one off LinkedIn. The fix sits in the quarterly pass. Compare the list against who approves payments today. Who holds admin roles today? Who leads each team today? Add, remove and write down the date you checked for quarantine notifications turned off. It usually happens for a good reason. Users complained about extra mail, so someone switched the digest off. Quiet inboxes. Fewer complaints. Problem solved. But now blocked mail is invisible. A real invoice gets held and the user finds out only when a vendor calls to ask why nobody paid. Or worse, the user learns that quarantine exists at all and starts asking it to turn the filtering down. So turn the notifications back on and fix the actual complaint. Pick a calmer cadence. Limit the digest to verdicts the user is allowed to act on. Remember admin release only verdicts sent nothing, So the digest is already smaller than people expect. And fifth, the simulation run. Once a campaign goes out, the click rate comes back at eleven percent. The report goes up with the word pass on it, and the program is considered done for the year. But one run is one lure on one day to one group. It proves nothing about next quarter's lure or about the people who weren't centered. A single test is a photograph. What you need is the film. So schedule the next campaign before you present the results of the last one. Rotate techniques, rotate groups and compare like with like and report the trend. Never the pass. Look at the five together a policy. Nobody hits an exception. Nobody removes a list. Nobody updates a notice. Nobody sends a test. Nobody repeats different features. Same structure. Each one is a setting that got configured once and then trusted conclusion from configuration to measurement. So here's the shift. The old model says email security is something you set up, pick the policies, flip the switches, and the product protects you from then on. It sounds reasonable. It's also why most tenants run on defaults and call it protection. The new model says it's something you run a loop of measuring, reviewing, and adjusting with a name on every step the product ships capable. Whether it works for you depends on the habit you build around it, and the order of decisions is simple enough to keep in your head. Start with presets and let Microsoft's tuning cover the broad population. Check scope so you know who each policy really reaches. Treat every exception as debt with an owner and an expiry shape quarantine so users can act where the stakes are low and can't wear their high. Test your people with realistic simulations and read the results honestly. Then measure all of it on a rhythm so the next change rests on evidence. One fact to take with you the policy that protects you isn't the one you shipped, it's the one you reviewed last quarter. That's the difference between a tenant with controls and a tenant with protection. If this changed how you think about defender for office three hundred sixty five, leave a review for the podcast. It helps other admins and security leaders find it. And if you want to keep going, connect with me, Mirko Peters on LinkedIn. Send me the topics you want covered. Next, I read them. Share this with your team, especially if you're partway through a policy rollout right now. That's exactly when the first review date matters most. Pick it, put it on the calendar, then keep it.