TL;DR. A growing share of the phishing email landing in your users’ inboxes is not spoofed. It is being sent from a real, fully-authenticated Microsoft 365 mailbox — usually a vendor or partner whose account was hijacked — and it passes SPF, DKIM, and DMARC with a perfect score. Authentication checks alone will not save you anymore. The defense is layered: keep your own tenant out of the attacker’s pool of compromised accounts (MFA, Conditional Access, no legacy protocols), lock down Global Admin, lean on DKIM and DMARC where they still do work, and train users to be suspicious of unexpected document shares even when the sender is real.

The shift: from forged emails to compromised accounts

For years, “phishing” meant a sender pretending to be Microsoft, your bank, or a coworker, with a forged display name and a sketchy domain. Email-authentication standards — SPF (which servers can send on a domain’s behalf), DKIM (a cryptographic signature on the message), and DMARC (the policy that says what to do when the first two fail) — were designed to defeat that. They mostly do.

So attackers have moved on. The dominant pattern in 2026 is account takeover: an attacker compromises one user’s Microsoft 365 mailbox, then uses that real, fully-authenticated mailbox to send phishing to everyone in the victim’s contact list, vendor list, and recent-conversations list. Because the email is genuinely sent from the real tenant, every authentication check passes. SPF passes. DKIM passes. DMARC passes. The headers are clean. The display name is real. The reply-to address is real.

Real examples reported in just the last few months include phishing emails arriving as genuine Microsoft SharePoint share notifications from a compromised vendor tenant, and credential-harvest forms hosted on forms.cloud.microsoft — an actual Microsoft domain — that passed every authentication header with what email-security vendors call a “composite authentication score of 100.”

Why DKIM/SPF/DMARC do not catch this (and why they are still essential)

SPF, DKIM, and DMARC verify that the sender is who they say they are — not that the message is legitimate. If a real user’s real account sends a real (malicious) link, all three will pass, because the sender really is who they say they are. By design.

That does not mean DKIM and DMARC are obsolete. They still defeat the entire universe of spoofed-domain attacks (which is still the majority of attempted phishing volume), and a properly-configured DMARC p=reject policy will keep your domain from being used to phish your own customers and partners. They are necessary — just no longer sufficient.

The layered defense that actually works

1. Make sure your tenant is not the next compromised account

Most account takeovers start the same way: a user clicks a phishing link, types their credentials into a fake Microsoft sign-in page, the attacker captures the password and the resulting session, and the account is in their hands. Defenses, in priority order:

• Multi-factor authentication for every user, every sign-in. Not just admins. Microsoft’s own data shows MFA blocks the overwhelming majority of automated account-takeover attempts.
• Phishing-resistant MFA where you can. Push notifications and SMS codes can be defeated by adversary-in-the-middle (AiTM) phishing kits. FIDO2 security keys (YubiKey and similar) and platform Passkeys (Windows Hello, Face ID, Touch ID) cannot. Use them at minimum for all admin accounts.
• Block legacy authentication protocols. POP3, IMAP, SMTP AUTH, and Exchange ActiveSync without modern auth do not support MFA — which is exactly why attackers love them. Block them with a Conditional Access policy.
• Conditional Access policies. Require compliant or hybrid-joined devices for admin sign-ins. Block sign-ins from countries you do not do business in. Block sign-ins from anonymous proxies and known-bad IP ranges.
• Watch for inbox rules. The first thing an attacker does after compromising a mailbox is set up a hidden rule to forward, archive, or delete certain messages so the real user does not see replies. Review for unusual forwarding rules and have alerting on rule creation.

2. Lock down Global Admin

The single most damaging account in your tenant is the Global Administrator. If one of those gets phished, the attacker can disable MFA, exempt themselves from Conditional Access, read every mailbox, and create new admin accounts of their own. Best practice is treating Global Admin as a break-glass account — not a daily-driver:

• Two or three Global Admins, no more. Microsoft recommends 2–4. We have seen tenants with a dozen. Each extra one is another high-value target.
• Dedicated admin accounts, separate from daily-use mailboxes. Do not give Global Admin to a user’s normal sign-in. Create a separate This email address is being protected from spambots. You need JavaScript enabled to view it. account that has no licensed mailbox and no email forwarding.
• Privileged Identity Management (PIM) for any role that does not need to be active 24/7. PIM lets users elevate to a privileged role for a few hours when they need it, then drops them back to a regular account. The role assignment is logged and time-bound.
• Two break-glass accounts excluded from Conditional Access, with extremely long random passwords stored offline, and alerting on every sign-in. If MFA or Conditional Access ever locks you out of your own tenant, those are your way back in.
• Phishing-resistant MFA on every admin. Hardware key or Passkey, no exceptions.

3. Get DKIM, SPF, and DMARC right

Even though authentication does not catch compromised-account phishing, you absolutely want it tight. The biggest failure modes we still see in SMB tenants:

• SPF too loose. SPF records that include too many third-party senders, or end with +all/?all instead of ~all or -all, give attackers a free pass.
• DKIM not enabled on Microsoft 365. M365 will not sign your outbound mail with DKIM until you explicitly enable it for the domain in the Defender portal and publish the two CNAME records. Many tenants we audit have never had this turned on.
• DMARC published as p=none forever. “None” is the right starting point — it lets you collect reports without breaking anything — but it should not be the destination. After a couple of weeks of clean reports, move to p=quarantine and then p=reject. Anything less and an attacker can spoof your domain to your own customers.
• DMARC reports unread. The whole point of rua= reports is to spot legitimate senders you forgot about and unauthorized senders abusing your domain. If nobody is reading them, you are flying blind.

4. Train users to recognize the new pattern

The single most useful piece of training in 2026 is this: even a real-looking email from a real-looking sender can be a phish if the request is unexpected. Specific red flags worth drilling into staff:

• An unexpected SharePoint, OneDrive, DocuSign, or DropBox share — especially with vague language like “please review” or “invoice attached.” If you were not expecting a file, do not open it. Reply on a different channel (text, phone) to confirm.
• A login screen that asks for a password after you click a link in email — even if the page looks correct. Always go to the service’s URL directly in the browser instead.
• Anything that introduces urgency around money: a vendor saying their bank account changed, a CFO asking for a wire, an invoice that needs paying today.
• An email from someone you have communicated with before that is suddenly asking something out of character — especially if the request involves credentials, MFA codes, or money.

5. Detect and respond when something does get through

• Have a documented process for what happens the moment a user reports a suspicious email. Resetting their password and revoking sessions in the first 15 minutes is the difference between a near-miss and a tenant-wide compromise.
• Audit Microsoft 365 audit logs (Search-UnifiedAuditLog) for new inbox rules, mailbox forwarding, app consents, and sign-ins from unfamiliar countries.
• Enable mailbox auditing if it is not already on. Without it, the forensic record after an incident is much thinner.
• Know your number for reporting incidents and your bank fraud line. Speed of response matters more than any single technical control.

What we do for clients

For InfiNet’s managed Microsoft 365 clients we configure the above as a baseline: SPF/DKIM/DMARC with p=reject, MFA enforced for everyone, legacy auth blocked, Conditional Access policies in place, and Global Admin reduced to two break-glass accounts plus PIM for day-to-day admin tasks. We also subscribe clients to monthly DMARC report monitoring so we see who is trying to spoof your domain — and so you do not.

If you want a one-time review of where your tenant currently sits on all of this — we offer a M365 Security Posture review that checks Secure Score, MFA coverage, Conditional Access posture, admin-role hygiene, and email authentication, and produces a prioritized punch list. Send us a note or call 970-282-8838 to set one up.