If you only remember one thing from this post, make it this: phishing is still the single most common way attackers walk straight into a business. It’s the entry point for most ransomware, most business email compromise, and most of the painful regulatory disclosure calls we get on a Tuesday afternoon at Datapath1. So when a customer asks us “do we really need a written anti-phishing policy, or is the Microsoft filter good enough?”, we know exactly where to start the conversation.
In this post, we’ll walk through what a real anti-phishing policy looks like in 2026, the four layers it has to cover, and the exact playbook we use to roll it out for the healthcare practices, K-12 districts, and financial services firms we serve1.
What an “anti-phishing policy” actually is
A lot of teams conflate “anti-phishing policy” with “the spam filter.” It’s bigger than that. At its core, an anti-phishing policy is a written, signed-off commitment to protect your people from deceptive email. The UK’s National Cyber Security Centre puts it cleanly into a four-layer model: make it harder for attackers to reach your users, help users identify and report phishing, protect the organization from the effects of the ones that slip through, and respond quickly to incidents2. Our policy at Datapath follows those same four layers, in that same order.
The mission statement
Your policy should answer four questions in two sentences each: What are we protecting? Who is responsible? Which technical controls are mandatory? What does the human side look like (training, reporting, response)? Anything longer than a page is too long to remember; anything shorter than a paragraph is too vague to enforce.
Who owns it
We always recommend a single named owner - usually a vCISO or a director of IT - with a backup. Email security has no value if the alert goes to a shared mailbox nobody monitors. The owner is accountable for the DMARC reports, the simulation results, and the post-incident reviews.
The technical layer: SPF, DKIM, DMARC, and BIMI
This is where most teams stall, because the alphabet soup looks intimidating. But the model is straightforward once you put each piece in plain English.
SPF - the digital bouncer
SPF (Sender Policy Framework) is a DNS TXT record that lists the IP addresses and hosts allowed to send mail on behalf of your domain3. Picture it as a bouncer at the door with a guest list. Mail from an IP that’s not on the list either gets refused or sent to the spam folder3. We always start with SPF, because it’s both the easiest to publish and the easiest for an attacker to trip.
DKIM - the tamper-evident seal
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outbound message3. The receiving server looks up your public key in DNS, decrypts the signature, and confirms the message hasn’t been altered in transit. If a man-in-the-middle changes even a single byte, DKIM fails.
DMARC - the rule that ties them together
DMARC (Domain-based Message Authentication, Reporting & Conformance) is the policy that says what to do when SPF or DKIM fails - and it’s published as a DNS record on your domain4. There are three modes4:
p=none- the monitoring mode. We watch what fails and learn who else is sending “as” us, but we don’t block anything yet.p=quarantine- failed messages get sent to the recipient’s spam or junk folder.p=reject- failed messages are refused at the SMTP level and never delivered4.
A DMARC record is more than just p=. The serious tags you’ll see us add for a customer are:
pct- the percentage of failing messages the policy actually applies to, so we can roll out gradually (pct=10thenpct=50, then100)4.rua- where to send aggregate reports (the daily summary of who is sending as your domain)5.ruf- where to send forensic failure reports on individual suspicious messages5.adkimandaspf- DKIM and SPF alignment. Relaxed (the default) accepts a parent/subdomain match; strict requires an exact match5.
The order matters here: SPF and DKIM have to be in place first, or DMARC is a rule with no evidence behind it. You can’t set up DMARC without first implementing SPF and DKIM3.
BIMI - the icing on the cake
BIMI (Brand Indicators for Message Identification) lets your logo appear next to authenticated messages in the inbox3. It’s the visible payoff for all the work above - and for BIMI to work at all, your DMARC policy must be at p=quarantine or p=reject3. Once we hit that threshold, your customers immediately see a recognizable logo instead of an anonymous sender.
The platform layer: tuning Microsoft 365 anti-phishing policies
The technical controls above protect your domain. The platform controls protect the people who receive mail from your domain and everyone else. If you run Microsoft 365 (and most of the regulated customers we work with do), the anti-phishing policies inside Defender for Office 365 are your workhorse6. They protect against phishing attacks by detecting spoofed senders, impersonation attempts, and other deceptive email techniques6.
Spoof intelligence and the “via” tag
Spoofing happens when the From address in an email doesn’t match the domain of the actual email source6. Spoof intelligence on by default catches that. We also turn on the two visible cues an end-user can read: a ? next to unauthenticated senders, and a via tag showing the actual sending infrastructure6. Those little symbols do more for user awareness than a quarterly training video.
Impersonation protection and mailbox intelligence
The policy engine can also flag when someone inside the org pretends to be the CEO, or when an external attacker registers a look-alike domain (payra11.com instead of payroll.com). We add the protected senders and protected domains lists, and we trust the mailbox intelligence feature - AI that learns each user’s normal contact patterns so impersonation of a frequent vendor or executive is much easier to spot6.
Phishing email thresholds
Microsoft exposes a four-step sensitivity dial we tune carefully: 1 - Standard, 2 - Aggressive, 3 - More aggressive, 4 - Most aggressive6. Most customers start at 2, watch the false-positive rate for two weeks, then climb.
The human layer: training, simulation, and reporting
We learned the hard way that an air-tight technical stack and a literate user are both non-negotiable. NIST puts it bluntly: organizations should teach employees how to spot and report a phish when they have fallen victim or think they have fallen victim to a phishing attack7. You can’t outsource that to a filter.
Awareness training cadence
A once-a-year slideshow is decorative, not productive. We schedule brief, monthly micro-trainings (5 to 7 minutes, one topic) and a deeper quarterly session. The topic rotates: invoice fraud one month, credential harvesting the next, then SMS phishing (“smishing”), then vendor-impersonation.
Phishing simulations that teach, not punish
When we run simulated phishing, the goal isn’t to embarrass anyone. The goal is to make the reporting button muscle memory. A click is fine if the next step is a report. Modern guidance from serious awareness platforms is to keep cadence low enough to avoid alert fatigue, use realistic (but ethical) lures, and reward the good catches8. The metric we report to leadership is not “click rate” - it’s time-to-report.
A one-click reporting button
Whatever else you build, deploy a one-click “Report Phishing” button in Outlook and the mobile app. The NCSC’s guidance is clear here: ensure staff are familiar with the normal ways of working for key tasks (such as how payments are made), so they’re better equipped to recognise unusual requests2. Speed matters. A report that lands in the security team’s queue within sixty seconds can stop a wire transfer. A report that arrives next morning is an incident, not a save.
Compensating controls and incident response
Even great policies leak. Layer three is about what happens in the leak.
MFA, patching, and least privilege
If a credential does get phished, multi-factor authentication is the wall that keeps it from being a full takeover. We pair that with a strict patching cadence (the NCSC recommends that software and devices are always kept up to date with the latest patches2) and least-privilege admin accounts2. Phish-resistant MFA - hardware keys or platform passkeys - is now our default for any role that can move money or touch patient data.
What happens when something gets through
Every anti-phishing policy in our shop has a written, rehearsed incident runbook. The NCSC’s own guidance is that incident response plans should be practised before an incident occurs2. At Datapath, our Threat & Incident Response team handles containment (revoke the session, pull the message from every inbox via tenant-wide purge), eradication (rotate credentials, hunt for inbox-rule backdoors), and recovery (which user accounts, which clients were reached, what data left)1. CISA’s anti-phishing training program support service keeps a useful reference template if you’re standing one up from scratch9.
Rolling it out: our phased approach at Datapath
Here’s the sequence we use for almost every customer. It borrows the DMARC pct rollout pattern because it works on humans, too.
Phase 1 - monitor
Set DMARC to p=none, publish full rua reporting, and let the data show us which third parties are legitimately sending on your behalf (think marketing, payroll, EHR reminders). No user-visible disruption.
Phase 2 - quarantine
Move to p=quarantine for a small pct (start at 10, climb to 100 over four to six weeks). Stand up the Microsoft 365 anti-phishing policy at sensitivity level 2. Run the first awareness campaign. Measure reporting rate.
Phase 3 - reject
Once reporting is strong and false positives are negligible, push DMARC to p=reject4. That makes BIMI eligible3. Lock the phishing threshold to level 3. Now your domain is essentially spoof-proof at the protocol level.
Why this matters for your industry
In 2026, this is no longer optional. Google, Yahoo, and Microsoft strictly enforce DMARC, and non-compliant messages are rejected at the SMTP level10. PCI DSS v4.0, active in 2026, mandates DMARC for any company handling credit cards and other payments, as well as for financial services providers10. HIPAA, FERPA, and SOC 2 don’t write DMARC into the standard by name, but every auditor we’ll sit next to expects to see it on the same checklist as MFA, patching, and incident response1.
If you run a healthcare practice, a school district, a credit union, or any team handling regulated data - the controls in this post aren’t a competitive advantage anymore. They’re the price of admission.
Where to start tomorrow
You don’t need to do all of this at once. Here is the minimum viable anti-phishing policy we’d ship in week one:
- Publish SPF and DKIM on your primary sending domain today.
- Publish a DMARC record at
p=nonewith aruaaddress you actually read. - Turn on the
?andviaindicators in Microsoft 3656. - Deploy a one-click phishing report button.
- Schedule the first 30-minute awareness training.
From there, climb to p=quarantine, then p=reject. Layer in simulations, refine the impersonation policy, and rehearse the runbook. By the end of the quarter, you’ll have a four-layer program that matches what the NCSC, NIST, and the major mailbox providers all expect - and you’ll have the receipts to prove it2710.
That’s the work we do alongside our customers every week at Datapath. If you’d like a partner to drive it with you - not just hand you a checklist - we’d love to talk1.
