Skip to navigation

Threat reportPhishingTL-2026-5260

Phishing Campaigns Bypass Microsoft 365 RejectDirectSend via Empty SMTP Envelope Sender (MAIL FROM:<>)

highACTIVE

ReliaQuest observed phishing campaigns between September 2025 and August 2026 that send mail with an empty SMTP envelope sender (MAIL FROM:<>) to evade Exchange Online's RejectDirectSend control, so unauthenticated messages with internal-looking From addresses are accepted and delivered. Targets were executives, managers, sales, finance, procurement and customer-facing staff, using document-sharing, payment-request and SVG 'voicemail' lures. First disclosed .

Key facts

IdentifiersTL-2026-5260
Also known asEmpty Envelope Sender Direct Send Bypass, RejectDirectSend bypass, Empty envelope attacks
SeverityHIGH
First disclosed
Affected productsMicrosoft Exchange Online (Microsoft 365) - RejectDirectSend control
MITRE ATT&CK techniquesT1027.017 SVG Smuggling, T1204.001 Malicious Link, T1204.002 Malicious File, T1566.001 Spearphishing Attachment, T1566.002 Spearphishing Link, T1684.001 Impersonation, T1684.002 Email Spoofing
MotivationUNKNOWN
Target sectorsexecutive leadership, finance, procurement, sales, customer-facing
Target regionsGlobal
Detection rules9 (1 shown free)
Sources9 cited sources

Detection coverage

As of 2026-11-04, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-5260 across Splunk SPL, Microsoft KQL and Sigma, covering 2 indicator(s) of compromise. The whole corpus is readable without an account. Every threat comes with one complete detection in Splunk SPL, Microsoft KQL and Sigma, free for everyone; a free account adds daily TL Creds to unlock the rest. Paid plans add a larger daily allowance, correlation and the MCP server. Threadlinqs MCP server · View plans.

Free detection: Empty SMTP Envelope Sender (MAIL FROM:<>) Spoofing Own Domain [Splunk SPL]

Finds inbound messages with an empty envelope sender (MAIL FROM:<>) whose header From is in the recipient's own domain, the primary ReliaQuest hunting condition for the Exchange Online RejectDirectSend bypass (TL-2026-5260). NDR and DSN mail is excluded. Maps to email spoofing (T1672) and impersonation (T1656). Phase: exploitation, RejectDirectSend bypass via null reverse path.

  • Languages: Splunk SPL, Microsoft KQL, Sigma
  • ATT&CK: T1672, T1656, T1566.001, T1566.002
  • Data sources: microsoft_defender_email_events, o365_message_trace
  • Severity: high
  • Confidence: high

Splunk SPL

index=o365 sourcetype="mscs:azure:eventhub" category="AdvancedHunting-EmailEvents" properties.EmailDirection="Inbound"
| eval envelope_from=trim(coalesce('properties.SenderMailFromAddress', ""))
| eval header_from=lower('properties.SenderFromAddress'), header_domain=lower('properties.SenderFromDomain'), rcpt_domain=lower(mvindex(split('properties.RecipientEmailAddress', "@"), 1))
| where (envelope_from="" OR envelope_from="<>") AND header_domain=rcpt_domain
| where NOT match(header_from, "^(postmaster|mailer-daemon)@") AND NOT match(lower('properties.Subject'), "^(undeliverable|delivery status notification)")
| stats count AS messages dc('properties.RecipientEmailAddress') AS recipients earliest(_time) AS first_seen latest(_time) AS last_seen values('properties.Subject') AS subjects values('properties.DeliveryLocation') AS delivery_location values('properties.SenderIPv4') AS sender_ip BY header_from
| sort - messages

Microsoft KQL

EmailEvents
| where Timestamp > ago(24h)
| where EmailDirection == "Inbound"
| where isempty(SenderMailFromAddress) or SenderMailFromAddress == "<>"
| extend RecipientDomain = tolower(tostring(split(RecipientEmailAddress, "@")[1]))
| where SenderFromDomain =~ RecipientDomain
| where not(SenderFromAddress startswith "postmaster@" or SenderFromAddress startswith "mailer-daemon@")
| where not(Subject startswith "Undeliverable" or Subject startswith "Delivery Status Notification")
| project Timestamp, NetworkMessageId, SenderFromAddress, SenderMailFromAddress, SenderIPv4, RecipientEmailAddress, Subject, DeliveryAction, DeliveryLocation, AuthenticationDetails, ThreatTypes

Sigma

title: Inbound Email with Empty SMTP Envelope Sender and DMARC Failure (RejectDirectSend Bypass)
id: 3f6c1a52-8d47-4b1e-9a20-5c7e0b1d4a01
status: experimental
description: Detects inbound messages with a null reverse path (MAIL FROM:<>) that failed DMARC, the pattern used to bypass Exchange Online RejectDirectSend and deliver spoofed internal-looking mail.
references:
    - https://reliaquest.com/blog/threat-spotlight-one-blank-field-bypasses-direct-send-control/
author: Threadlinqs Team
date: 2026-11-04
tags:
    - attack.initial-access
    - attack.t1566.001
    - attack.t1566.002
    - attack.defense-evasion
    - attack.t1672
    - attack.t1656
logsource:
    product: microsoft365defender
    service: emailevents
detection:
    selection_envelope:
        EmailDirection: 'Inbound'
        SenderMailFromAddress:
            - ''
            - '<>'
    selection_auth:
        AuthenticationDetails|contains: '"DMARC":"fail"'
    filter_ndr:
        SenderFromAddress|startswith:
            - 'postmaster@'
            - 'mailer-daemon@'
    condition: selection_envelope and selection_auth and not filter_ndr
falsepositives:
    - Non-delivery reports and auto-replies from remote systems that fail DMARC
    - Legitimate bulk senders that use a null return path
level: high

Known false positives:

  • Legitimate non-delivery reports and delayed-delivery notices use a null reverse path
  • Multi-domain tenants where internal systems relay between accepted domains
  • Auto-replies and calendar systems that send with an empty envelope

Tuning notes: Exclude known NDR/DSN subjects and mailbox-provider bounce senders, scope to your accepted domains if the tenant has several, and alert only when DeliveryLocation is Inbox or the message was not quarantined. Field names assume the Defender streaming API via Event Hub (properties.* prefix); adjust to your extraction. Pair with an IP-restricted inbound connector to block the path outright.

8 more detection rules (Splunk SPL, Microsoft KQL, Sigma) · unlock with TL Creds. Sign up free to unlock the detection rules or query them with the Threadlinqs MCP server (Purple)
  • Empty SMTP Envelope Sender (MAIL FROM:<>) Spoofing Own Domain [Sentinel KQL] · unlock with TL Creds
  • Authentication-Failed Mail Delivered to Inbox Under Filtering Override [Sentinel KQL] · unlock with TL Creds
  • SVG Voicemail-Lure Attachment and Browser Launch [Sentinel KQL] · unlock with TL Creds
  • Empty SMTP Envelope Sender (MAIL FROM:<>) Spoofing Own Domain [Sigma] · unlock with TL Creds
  • Authentication-Failed Mail Delivered to Inbox Under Filtering Override [Sigma] · unlock with TL Creds
  • SVG Voicemail-Lure Attachment and Browser Launch [Sigma] · unlock with TL Creds
  • Authentication-Failed Mail Delivered to Inbox Under Filtering Override [Splunk SPL] · unlock with TL Creds
  • SVG Voicemail-Lure Attachment and Browser Launch [Splunk SPL] · unlock with TL Creds

Indicators of compromise

As of 2026-11-04, Threadlinqs Intelligence tracks 2 indicators of compromise for TL-2026-5260.

2 indicators of compromise · unlock with TL Creds. Compare plans

Technical analysis

Microsoft introduced the tenant-wide RejectDirectSend control (Set-OrganizationConfig -RejectDirectSend $true; public preview announced 2025-04-30, general availability rolling out from early September 2025) to reject unauthenticated mail that claims to come from a tenant's accepted domains but does not arrive through a trusted connector. Rejected mail receives the error 550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources. ReliaQuest found that the control evaluates the domain of the SMTP envelope sender (MAIL FROM) against the tenant's accepted domains rather than the visible From header. When the envelope sender is empty (the null reverse path, MAIL FROM:<>), there is no domain to compare, so the check does not fire. In ReliaQuest's controlled tenant reproduction, a message with the tenant domain in the envelope sender was rejected, while the same message sent with MAIL FROM:<> was accepted and queued.

Because the visible From header is left unchanged, recipients see an internal address such as 'IT Support <it-support@VICTIM_DOMAIN>'. In ReliaQuest's testing the messages showed spf=none, dkim=none, dmarc=fail action=oreject and compauth=none, with X-MS-Exchange-Organization-AuthAs: Anonymous and an SCL of 9 (maximum spam confidence). Most such messages landed in Junk Email, but those matching a filtering exception reached inboxes: ReliaQuest cites a message that failed every sender authentication check and was classified as high-confidence phishing but still reached the inbox because the spoofed executive address was listed as an allowed sender. The technique needs no stolen credentials, no registered lookalike domain and no dedicated sending infrastructure, and ReliaQuest assessed it is likely to remain usable for the next 6-12 months. ReliaQuest says Microsoft was made aware through multiple attempts; Microsoft's position, as quoted, is that this is not a software vulnerability but a limitation in the scope of the control. No CVE has been assigned.

ReliaQuest identified numerous instances of the empty-envelope pattern across September 2025 to August 2026. Per press coverage of the report, 40% of phishing emails sent with an empty envelope and a spoofed From header impersonating the victim's own domain went to senior leaders and 25% to managers and sales. Targets also included finance staff who process invoices and payments, procurement teams handling bids, and customer-facing mailboxes. Lures, by frequency, were document and file-sharing notifications, payment and remittance requests, procurement invitations, loan and investment offers, and meeting invitations. Some messages carried SVG attachments disguised as voicemail recordings; SVG files can trigger browser redirection rather than behave as plain images, and security products handle them inconsistently. Neither source publishes network indicators, file hashes, sender addresses or the downstream credential-harvesting infrastructure, and no threat actor is attributed.

Defensive guidance from ReliaQuest: configure an IP-restricted inbound connector that permits only inventoried devices and applications needing unauthenticated sending (in testing it blocked every Direct Send attempt regardless of envelope sender); review every setting that can override a filtering verdict (allowed senders, allowed sender domains, Tenant Allow/Block List entries, spam-score overrides), especially for executives; and hunt for an empty envelope sender paired with a header From in an accepted domain, alerting on messages that failed SPF, DKIM or DMARC but were delivered under an override. Empty envelope senders are legitimate for non-delivery reports, so blanket blocking can disrupt mail flow.

MITRE ATT&CK techniques by tactic:

Defense Evasion

T1027.017 SVG Smuggling; T1684.001 Impersonation; T1684.002 Email Spoofing

Execution

T1204.001 Malicious Link; T1204.002 Malicious File

Initial Access

T1566.001 Spearphishing Attachment; T1566.002 Spearphishing Link

Remediation

Immediate actions

  • Hunt for messages with an empty envelope sender (MAIL FROM:<>) and a header From in an accepted domain
  • Alert on messages that failed SPF, DKIM or DMARC but were delivered under an override
  • Review every setting that can override a filtering verdict: allowed senders, allowed sender domains, Tenant Allow/Block List entries, spam-score overrides
  • Remove allowed-sender exceptions covering executives and other frequently impersonated users

Workarounds

  • Configure an IP-restricted inbound connector permitting only inventoried devices and applications that require unauthenticated sending
  • Enable RejectDirectSend (Set-OrganizationConfig -RejectDirectSend $true) as a baseline, understanding it does not cover the empty-envelope case
  • Use a secure email gateway with IP-restricted inbound connectors in front of Exchange Online

Longer-term hardening

  • Treat filtering exceptions as high-risk trust decisions and review allow-list rules for privileged accounts
  • Monitor for authentication failures combined with inbox delivery
  • Train executives, managers, sales, finance, procurement and customer-facing staff to verify unexpected payment and document requests through known channels

Affected and fixed versions

  • Microsoft — Exchange Online (Microsoft 365) - RejectDirectSend control
    Vulnerable versions: Tenants relying on RejectDirectSend without an IP-restricted inbound connector
    Fixed in: No vendor fix; Microsoft states this is a limitation in the control's scope

Timeline

  • Microsoft introduces the RejectDirectSend tenant control for Exchange Online in public preview (MC1093237), rejecting unauthenticated mail from accepted domains that does not arrive via a trusted connector (550 5.7.68).
  • RejectDirectSend general availability begins rolling out (early September 2025, Worldwide/GCC/GCC High); ReliaQuest's observation window for empty-envelope phishing begins the same month.
  • End of ReliaQuest's September 2025 - August 2026 observation window, during which numerous empty-envelope phishing instances were identified; 40% of spoofed-domain messages went to senior leaders and 25% to managers and sales.
  • ReliaQuest assesses empty-envelope attacks will likely remain viable for the next 6-12 months because they need no credentials, compromised domains or dedicated infrastructure.
  • ReliaQuest publishes 'Threat Spotlight: One Blank Field Bypasses Direct Send Control', showing MAIL FROM:<> messages accepted by Exchange Online despite RejectDirectSend; Microsoft calls it a limitation in the control's scope, not a vulnerability.
  • Cybersecurity News publishes technical coverage of the empty-envelope technique, mitigations (IP-restricted connector, removing filtering exceptions) and detection guidance.
  • KnowBe4 publishes an awareness article on the technique, the document-sharing, payment and SVG voicemail lures, and the allowed-sender case where a high-confidence phish still reached the inbox.

Sources cited

Previous and next in phishing

Drafted by the Threadlinqs research pipeline from 9 sources; published ; last updated —.

Threadlinqs Intelligence — Real-Time Threat Detection Platform

// threat_feed
$ sort --newest
Showing all threats

Live intelligence console

Threat level

Latest Threats