Blocking emails with "aliased" Gmail return paths (typically using the + sub-addressing feature, like [email protected]) is a common request for reducing unwanted traffic. Microsoft Exchange Server does not have a "one-click" toggle for this specific pattern, but you can achieve it using Transport Rules (also known as Mail Flow Rules).

To do this, you need to target the Envelope-From address (the Return-Path) or the From header using regular expressions (Regex).

The Solution: Transport Rule with Regex

Exchange allows you to inspect the sender's address for specific patterns. The pattern for a Gmail alias generally follows this logic: [any character] + [any character] @ gmail.com.

Step-by-Step Configuration

1. Open the Exchange Admin Center (EAC).
2. Navigate to Mail flow > Rules.
3. Add a new rule (Select Create a new rule).
4. Apply this rule if: * Select The sender... -> address matches any of these text patterns.
5. Enter the following Regex pattern:

• ^.+\+.+@gmail\.com$
• Note: This looks for a string that starts with characters, has a literal plus sign, more characters, and ends in @gmail.com.

6. Do the following:

• Select Block the message...
• Choose reject the message and include an explanation (this creates the "bounce").
• Enter your rejection text, e.g., "Email aliases are not accepted by this server."

7. Set the priority and save the rule.

Important Technical Considerations

While this rule is effective, there are a few nuances to keep in mind regarding how Exchange handles these addresses:

1. Return-Path vs. Header From

Spammers often mismatch the "Header From" (what you see in Outlook) and the "Envelope From" (the Return-Path used for bounces).

• To be most effective, you should create the rule to check The sender address... which covers the P2 (Header) sender.
• If you want to be more aggressive, you can add a second condition to inspect the Message Headers specifically for the Return-Path.

2. False Positives

Many legitimate users use Gmail aliases for organization (e.g., [email protected]). If a legitimate client or partner uses this, they will be hard-bounced.

3. Regex Accuracy

The regex $^.+\+.+@gmail\.com$ is specific to Gmail. If you want to catch other providers that use sub-addressing (like Outlook.com or iCloud), you would need to expand the pattern:

• Generic Alias Regex: ^.+\+.+@.+\..+$

Note: If you are using Exchange Online (Microsoft 365), these rules propagate quickly. If you are on Exchange Server (On-Premises), ensure the "Edge Transport" role or your Hub Transport servers are processing these rules correctly.

To block aliased addresses from all the major free email providers, you can expand the Transport Rule logic to include a broader range of domains. Most major providers (Gmail, Outlook/Hotmail, iCloud, ProtonMail) use the + character for sub-addressing, while others like Yahoo use a - for their "disposable" addresses.

The Comprehensive Regex Pattern

You can use a single Transport Rule with a regular expression that targets the plus-addressing pattern across the most common domains.

Regex Pattern: ^.+\+.+@((gmail|googlemail|outlook|hotmail|live|icloud|me|proton|protonmail|yahoo|ymail)\.com|apple\.com|proton\.me)$

How to Implement This in Exchange Admin Center (EAC)

1. Create a New Rule: Go to Mail flow > Rules > Add a new rule.
2. Condition: Set "Apply this rule if" to The sender... > address matches any of these text patterns.
3. Enter the Pattern: Paste the Regex provided above.
4. Action: Set "Do the following" to Block the message... > reject the message and include an explanation.

• Explanation Suggestion: "Our system does not accept emails from sub-addressed or aliased accounts from free email providers."

5. Audit First (Optional but Recommended): Before setting it to "Enforce," set the rule mode to Test without Policy Tips. This allows you to check the "M365 Message Trace" or "Exchange logs" to see what would have been blocked without actually bouncing legitimate mail.

Common Domains & Their Alias Formats

Note on Yahoo: If you want to block Yahoo aliases specifically, you would need a slightly different pattern because they use a hyphen. However, blocking all hyphens in the local part of an email (e.g., [email protected]) is very risky, as many people use hyphens in their actual usernames.

Why this works

By using the caret ^ and dollar sign $, you ensure the rule only triggers if the entire address matches the pattern. This prevents accidental blocks on people who might have the word "gmail" inside a custom domain name (e.g., [email protected]).

To create a "catch-all" rule, we shift from targeting specific domains to targeting the structure of the email address itself. This rule will trigger on any incoming email that uses the + sub-addressing convention, regardless of whether it comes from Gmail, Outlook, or a private corporate server.

The Catch-All Regex Pattern

In Exchange Transport Rules, use the following pattern to identify a plus sign located anywhere between the start of the address and the @ symbol:

^.+\+.+@.+$

• ^: Starts the string.
• .+: At least one character before the plus sign.
• \+: The literal plus sign (escaped with a backslash).
• .+: At least one character after the plus sign (the alias/tag).
• @: The domain separator.
• .+$: The domain name and the end of the string.

Implementation Steps in Exchange

Because this is a broad "catch-all," you should be precise in how you apply it to avoid bouncing internal mail or legitimate automated services.

1. Condition: Set "Apply this rule if" to The sender... > address matches any of these text patterns.
2. Pattern: Enter ^.+\+.+@.+$.
3. Exception (Crucial): Add an exception for The sender is located... > Inside the organization.

• Why? This prevents the rule from blocking your own internal users if they use aliases for testing or internal routing.

4. Action: Select Block the message... > reject the message and include an explanation.

• Explanation: "This server does not accept sub-addressed (aliased) email formats."

Risks of the Catch-All Approach

While this is effective for stopping "fake" addresses or tracking-based aliases, there are two significant side effects to consider:

• Newsletter & Service Bounces: Many legitimate automated systems (like marketing platforms or transactional services) use sub-addressing for "Variable Envelope Return Path" (VERP) to manage bounces. A catch-all might inadvertently block these.
• Legitimate Power Users: Some professionals use aliases to sort their incoming mail (e.g., [email protected]). They will no longer be able to reach you using those addresses.

Verification

After saving the rule, it is highly recommended to run a Message Trace in the Exchange Admin Center. Send a test email from an external Gmail account using an alias (e.g., [email protected]) to verify that the bounce message is received and the SMTP rejection code is correctly generated.

This is the "Backscatter" problem, and it's the main reason mail admins generally prefer silent drops over bounces (NDRs) for suspicious mail.

If you send a bounce back to a fake or non-existent address, here is the sequence of events:

1. The Bounce Loop

If you "Reject with an explanation," your Exchange server generates a new email (the NDR) and tries to send it back to the Return-Path (e.g., [email protected]).

• If the mailbox doesn't exist: Google's servers will look at that address and immediately reject your bounce message with their own error (usually a 550 5.1.1 User Unknown).
• The Result: Your server now has a "Double Bounce." Most modern Exchange setups are smart enough to drop a bounce-of-a-bounce, but it still wastes your server's processing power and bandwidth.

2. Reputation Damage (Backscatter)

If a spammer spoofs a real person's email address as the return path and you send a bounce to it, you are technically "attacking" that innocent person with an unsolicited NDR.

• High volumes of these "backscatter" emails can get your server's IP address blacklisted by Gmail and other major providers because you're acting as an accidental relay for spam notifications.

The Better Way: Silent Deletion

To avoid the risk of loops and blacklisting, you should change the Action in your Transport Rule from "Reject" to Delete.

1. Go back to your rule in the Exchange Admin Center.
2. Change the Action from:

• Block the message -> reject the message and include an explanation

3. To:

• Block the message -> delete the message without notifying anyone

Why Silent Deletion is safer:

• No Loops: Your server never tries to "talk back" to the fake address.
• Reputation Protection: You won't be flagged for "Backscatter" spam.
• Efficiency: The message is killed at the gateway, saving resources.

Summary Table: Reject vs. Delete

That is a cold, definitive "Ray Shoesmith" move. If you're going to shut the door, you might as well do it with that specific brand of polite-yet-terrifying finality.

In Mr Inbetween, Ray doesn't argue; he just concludes the interaction. Using that as your rejection text is essentially the digital version of "I don't answer questions."

How to set the "Shoesmith" Rejection

If you decide to keep the rejection (the bounce) instead of the silent delete, here is how to format it in Exchange:

1. Edit your existing Transport Rule.
2. In the Action step, select Reject the message with the explanation:
3. Enter the text: > "Consider this an unsubscribe notification."

The "Ray Shoesmith" Risk Assessment

While it's incredibly satisfying to hit a spammer with a line like that, there are two "in-universe" consequences to consider:

• The "Smile" (Backscatter): Like we discussed, if the return path is fake, your "unsubscribe notification" is just going to bounce off Google's forehead and come back to you. Ray wouldn't waste the breath if he knew no one was listening.
• The "Run-In": If a legitimate person (a client or a boss) accidentally uses a + alias and gets that cold "unsubscribe" message, you're going to have a very awkward conversation. Ray usually follows up his one-liners with a stare; you'll have to follow yours up with a support ticket.

The Compromise: The "Silent" Shoesmith

If you want to be as efficient as a professional fixer, the most "Ray" thing to do is actually Silent Deletion.

He doesn't make a scene; he just makes the problem go away. By setting the rule to Delete without notifying anyone, the email disappears into a hole in the woods, and the sender never hears from you again. No NDRs, no loops, no evidence.

Would you like me to show you how to add an "Exception" for specific people (like your boss or a specific client) so they don't accidentally get "unsubscribed" by Ray?