A phishing campaign uncovered by Varonis Threat Labs targeted more than 70 organizations – predominantly in the United States – by exploiting a legitimate Microsoft 365 feature in a way most security teams had not anticipated. The attack required no stolen credentials, no compromised account, and no software vulnerability in the traditional sense. It required a predictable endpoint, permissive mail routing, and an incomplete understanding of how Microsoft 365 processes mail that arrives through its own infrastructure.
That feature is called Direct Send.
What Direct Send Is Designed to Do
Direct Send is a mail flow method in Microsoft 365 that allows printers, copiers, network devices, line-of-business applications, and internal services to send email without authenticating to Exchange Online. A scanner that emails a scanned document to a user, a point-of-sale system generating a receipt, or a monitoring tool issuing an alert – these are the intended use cases.
The mechanism works through a predictable endpoint: [tenantname].mail.protection.outlook.com. Any device or application that can connect to port 25 on that address can inject email into the tenant’s mail flow without providing credentials. Microsoft designed it this way to accommodate legacy hardware and internal systems that cannot perform modern authentication.
The endpoint format is entirely predictable from the organization’s tenant name, which is typically discoverable from a domain’s public MX record.
How Attackers Turned It Into a Spoofing Vector
The Varonis campaign, active since at least May 2025, worked as follows: attackers identified target organizations’ tenant endpoints, connected to those endpoints from external IP addresses, and submitted messages with From: headers set to real employees within the target organization. Those messages then traveled through Microsoft’s own infrastructure and, under certain routing configurations, were delivered to recipients inside that same organization appearing to come from a trusted internal sender.
Because the messages transited Microsoft 365’s servers, receiving filters treated them differently from ordinary external mail. Microsoft’s own telemetry revealed the specific header combination that signals this condition: InternalOrgSender=True appearing alongside MessageDirectionality=Incoming. The message looks internally generated to Exchange Online Protection – even though it originated from an external attacker.
The SPF check fails. The sending IP is not listed in the organization’s SPF record. DKIM is absent. There is no private key to sign with. DMARC fails. SPF and DKIM both fail, so alignment cannot be established. But none of that matters if the organization has a mail flow rule that sets the Spam Confidence Level to -1 for inbound connector traffic, or if the routing configuration does not apply strict authentication validation to what Exchange Online Protection has already classified as internal-looking traffic.
Vulnerable environments show authentication headers like spf=fail and dmarc=fail action=none reason=905. Protected environments show dmarc=fail action=reject or oreject instead. That difference – action=none versus action=reject – is the difference between a message that reaches the inbox and one that is stopped.
What the Phishing Emails Look Like
Varonis documented the specific lures used in the campaign. The most common format was a voicemail notification: a message appearing to come from an internal IT system informing the recipient that a new voicemail was waiting. The email contained a PDF attachment. Inside the PDF was a QR code. Scanning the QR code directed the recipient to a phishing site built on Tycoon2FA infrastructure – a phishing-as-a-service platform that includes CAPTCHA bypass and Microsoft 365 credential harvesting pages designed to intercept session cookies and defeat standard MFA.
Microsoft’s own analysis of related campaigns documented additional lure types:
DocuSign impersonation. Messages stating that a document is awaiting the recipient’s signature, using Microsoft 365 branding and a spoofed internal sender address to establish legitimacy.
HR impersonation. Notices that a benefits enrollment deadline is approaching or that a policy acknowledgment is required, using internal HR contact names as the apparent sender.
Business email compromise. Spoofed messages purporting to come from the CEO directing accounting staff to pay fabricated invoices, complete with counterfeit W-9 forms and fake bank letters requesting ACH transfers.
All of these messages shared one visible characteristic from the recipient’s perspective: the sender address was a real colleague or recognizable internal system. The domain matched. The routing appeared internal. There was no visible signal that anything was wrong.
Which Organizations Are Exposed
Not every Microsoft 365 tenant is vulnerable. Organizations whose MX records point directly to Microsoft 365 are protected by Exchange Online Protection’s native spoofing detection, which catches the routing anomaly and blocks unauthenticated Direct Send attempts before they reach the inbox.
The attack succeeds specifically against organizations that match one or more of these conditions:
- Inbound mail is routed through a third-party secure email gateway before reaching Exchange Online (common configurations using Proofpoint, Mimecast, or Barracuda as the MX destination)
- The DMARC policy is set to
p=nonerather thanp=quarantineorp=reject - Mail flow rules assign an SCL of -1 to traffic arriving through certain connectors, effectively disabling all spam and spoofing filters for that path
- The
RejectDirectSendorganization setting introduced by Microsoft in April 2025 has not been enabled
The third-party gateway configuration is particularly common in larger enterprises, which often route inbound mail through external appliances before it enters Exchange Online. That topology creates the gap the attack exploits: the external gateway performs authentication checks against the original sending IP, but by the time the message reaches Exchange Online it carries the gateway’s forwarding signature, not the attacker’s IP – creating ambiguity that the routing rules may resolve in the attacker’s favor.
How to Close the Gap
Microsoft introduced a specific setting to address this attack class in April 2025:
Set-OrganizationConfig -RejectDirectSend $true
This command, now enabled by default for newly created tenants, rejects unauthenticated Direct Send attempts approximately 30 minutes after it is applied. Tenants created before April 2025 may not have this setting enabled and should verify their configuration in the Exchange Admin Center under mail flow settings.
That setting addresses the Direct Send vector specifically. Closing the broader class of routing-based authentication bypasses requires a layered approach:
DMARC at p=reject. The Varonis campaign was most effective against organizations with p=none policies. Moving to p=reject means a DMARC failure produces a rejection action rather than a report-only event. That protection applies only if the routing configuration actually delivers the DMARC verdict to a decision point – which leads to the next layer.
Review every mail flow connector. Each inbound connector in Exchange Online should be audited to confirm it does not apply blanket SCL:-1 settings to traffic that could be injected externally. Connector-based exceptions should be scoped to verified IP ranges only, not to connector categories.
SPF hard fail. Setting -all (hard fail) rather than ~all (soft fail) sends a stronger rejection signal and reduces the ambiguity that permissive connectors can exploit.
Phishing-resistant MFA. If an employee’s credentials are captured through a Tycoon2FA page, FIDO2 hardware keys, passkeys, or Windows Hello for Business prevent those credentials from being replayed even if the attacker holds a valid session token. Standard TOTP authenticator codes do not provide this protection against adversary-in-the-middle interception.
The Structural Gap DMARC Statistics Do Not Show
The Direct Send exploit exposes something the global DMARC adoption numbers tend to obscure: authentication records define what should happen when unauthenticated mail arrives. They do not prevent attackers from finding paths through mail infrastructure that treat malicious messages as though they were authenticated.
A p=reject DMARC policy on a domain with a non-standard MX routing configuration may never fire – because the failing message arrives through a connector path that the reject policy is never applied to. The policy exists in DNS. The protection does not exist in the mail flow.
Monitoring what your domain’s authentication layer actually does – not just what your published DNS records say it should do – is the difference between DMARC as a compliance document and DMARC as an operational defense. The Varonis campaign found that gap across 70 organizations. The technical conditions that created it are not rare.
Attackers are routing phishing through your own mail infrastructure. Excello Mail shows you what is actually happening in your domain’s authentication layer – not just what your DNS records declare. Sign up for free to Excello Mail and see the full picture of who is sending in your name and how your authentication is performing in the real world.