When a legitimate business workflow breaks because an automated security filter quarantined an urgent invoice or contract, the immediate operational temptation is to create an exception. An administrator adds a third-party domain or IP address to an allow-list, the email flows again, and the ticket is closed. However, creating loose exceptions creates a permanent security hole that attackers actively exploit to deliver malicious payloads straight into inboxes.

According to analysis from the Microsoft Security Blog, threat actors delivered millions of malicious emails spoofing trusted business platforms like DocuSign, Adobe, and SurveyMonkey. In many cases, these messages failed standard authentication checks yet were still delivered because tenant-level or user-configured overrides instructed the mail gateway to ignore detection results. This guide explains why broad email allow-lists fail, how modern evasion techniques exploit these gaps, and how to audit and harden your tenant against domain impersonation.

The Core Problem: Spoofing Legitimate Business Services

Attackers frequently impersonate widely recognized Software-as-a-Service (SaaS) providers. Instead of building lookalike domains with typosquatting, threat actors often forge the exact sender domain of trusted platforms in the email headers. A message might claim to originate directly from an electronic signature provider or file-sharing service to request an immediate signature or payment approval.

Standard email authentication relies on three protocols to verify sender identity:

  • Sender Policy Framework (SPF): Specifies which IP addresses and mail servers are authorized to send email on behalf of a specific domain.
  • DomainKeys Identified Mail (DKIM): Adds a cryptographic signature to outgoing messages, proving the email was authorized by the domain owner and wasn't altered in transit.
  • Domain-based Message Authentication, Reporting, and Conformance (DMARC): Directs receiving mail servers on how to handle incoming emails that fail SPF or DKIM validation (such as monitor, quarantine, or reject).

When an attacker forges a header without access to the legitimate provider's sending infrastructure or private keys, the email fails SPF and DKIM alignment. Under normal conditions, receiving mail servers flag the message as suspicious or drop it entirely. However, when an administrative exception exists for that brand or sender string, the security scanner honors the override and delivers the spoofed message directly to the recipient.

Why Overly Broad Allow-Lists Undermine Security

Most enterprise email platforms allow administrators to define mail flow rules (also known as transport rules) and tenant allow-lists. When configured incorrectly, these rules instruct the filtering pipeline to bypass spam checks, phishing analysis, or attachment scanning based on superficial criteria.

Security overrides typically fail due to two common misconfigurations:

  1. Matching solely on the sender address: Configuring a rule that says "if the sender address contains @service.com, bypass spam filtering." Attackers easily forge the visible From: header, triggering the rule even when the underlying message fails authentication.
  2. Allowing shared sending IP addresses: Whitelisting an entire cloud IP range or shared relay service because a vendor sends notifications through it. Threat actors can spin up their own accounts on that same service to route phishing messages through the whitelisted IPs.

Research shows that credential theft remains the primary goal of these attacks, representing more than 90% of malicious attachment activity. When an override lets a spoofed message through, users rely purely on visual inspection to identify the fraud. Because the brand name, graphics, and sender domain look legitimate, users routinely input their credentials into phishing forms.

Evasion Tactics: The Return of SVG Attachments and CAPTCHAs

In addition to relying on tenant overrides, attackers evolve file attachment formats to evade content inspection engines. While PDF and HTML files remain the most common vehicles for malicious payloads, Scalable Vector Graphics (SVG) attachments have become a popular delivery mechanism for credential harvesting.

An SVG file is not a raster image like a JPEG or PNG; it is an XML-based text file that describes shapes, lines, and text. Because it is written in XML, an SVG can embed inline JavaScript and HTML code:

<svg xmlns="http://www.w3.org/2000/svg" width="500" height="500">
  <text x="20" y="40" font-family="Arial" font-size="16">Secure Document Preview</text>
  <script type="text/javascript">
    // Embedded script redirecting to an external credential harvester
    window.location.href = "https://phishing-gateway.example.com/login";
  </script>
</svg>

Many email filtering engines treat SVG files as benign image attachments rather than executable scripts, allowing them to pass through boundary protections. When the user opens the SVG in a web browser, the embedded script executes immediately, redirecting the browser to a fraudulent login page.

To counter automated crawlers and sandboxes that analyze destination URLs, attackers also place CAPTCHA gates in front of their landing pages. Automated security crawlers cannot easily solve interactive challenges, which prevents the scanner from inspecting the final login form behind the gate. The combination of domain spoofing, SVG delivery, and CAPTCHA gating creates a path that bypasses basic static checks unless mail filters are strictly configured to inspect authentication results first.

How to Audit and Harden Email Flow Rules

Eliminating blind spots requires auditing your mail rules to ensure that exceptions never bypass sender authentication checks. Follow these steps to audit your environment.

Step 1: Identify Insecure Transport Rules

Review all transport rules in your cloud mail tenant that set the Spam Confidence Level (SCL) to -1 (bypass filtering). In Exchange Online, for example, you can audit these rules using PowerShell:

Connect-ExchangeOnline

Get-TransportRule | Where-Object {
  $_.SetSCL -eq "-1" -or $_.BypassSpamFiltering -eq $true
} | Select-Object Name, From, FromAddressContainsWords, SetSCL

Examine any rule that matches external domains or non-corporate sender addresses. If a rule grants an SCL bypass based only on a domain name without verifying authentication status, mark it for immediate remediation.

Step 2: Require Explicit Authentication for Any Exemption

If a critical third-party vendor experiences deliverability issues and temporarily requires an override, never create an unconditional bypass rule. Instead, combine the domain match with an authentication check requiring an explicit SPF pass or DKIM signature match.

Ensure your rule conditions evaluate the message authentication headers:

# Example: Ensure the rule checks that the message passed authentication
# Header 'Authentication-Results' must contain 'dmarc=pass' or 'spf=pass'

If the message claims to come from partner.com but the Authentication-Results header shows dmarc=fail or spf=softfail, the transport rule must reject or quarantine the message rather than honoring the bypass.

Step 3: Restrict Executable and Scripted Attachments

Review allowed attachment policies at your secure email gateway. Unless your organization has an explicit, verified workflow requiring inbound SVG files, treat them with increased scrutiny.

  • Block or sanitize incoming SVG attachments from external senders, or route them to a cloud sandbox for deep content inspection.
  • Ensure inspection engines parse internal XML structures inside vector images for embedded <script> tags and external redirect commands.
  • Block legacy or uninspected archive formats (such as ISO, VHD, or encrypted ZIPs) that conceal credential-stealing binaries like Agent Tesla.

Step 4: Audit End-User Safe Senders Lists

Tenant-level administrators are not the only ones who can configure overrides. End users can add addresses to their personal "Safe Senders" list inside desktop email clients, which may override junk mail handling depending on your global policy.

Use administrative policy controls to prevent user-configured safe senders from overriding anti-phishing verdict levels. A personal safe sender rule should never deliver an email flagged with high-confidence phishing or authentication failure.

Common Pitfalls to Avoid

Securing mail flow requires balancing operational uptime with defensive hygiene. Avoid these common mistakes:

  • Using allow-lists to fix vendor DMARC failures: If a partner's email fails DMARC because their DNS records are misconfigured, do not add an unconditional bypass rule. Notify the partner's IT team to correct their SPF/DKIM records. An exception on your end exposes you to anyone spoofing their brand.
  • Relying on display name filters alone: Threat actors alternate between spoofing the actual header domain and using generic display names on free mail providers. Defense requires inspecting both the envelope sender (RFC 5321) and the header sender (RFC 5322).
  • Failing to document and expire exceptions: Temporary overrides often become permanent security gaps. Every mail flow override should have a documented business owner, a technical justification, and a mandatory expiration date for review.

Defensive Hardening Checklist

Use this operational checklist to maintain strong email controls and prevent domain spoofing bypasses across your organization:

  • [ ] Audit mail flow rules: Verify that no active transport rules grant unconditional SCL bypasses (SCL -1) based purely on sender domain strings.
  • [ ] Enforce strict DMARC policies: Set your inbound DMARC handling to respect sender policies and reject or quarantine unauthenticated emails.
  • [ ] Restrict SVG and script delivery: Audit email gateway attachment rules to inspect, strip, or sandbox vector graphics and script-bearing formats.
  • [ ] Disable user-level phishing overrides: Ensure administrative security configurations supersede mailbox-level safe sender lists for malicious and phishing verdicts.
  • [ ] Review third-party relay IPs: Remove shared, non-dedicated cloud IP ranges from explicit IP allow-lists.
  • [ ] Schedule regular exception reviews: Conduct a monthly review of all active tenant-level overrides and decommission obsolete rules.