To stop an unauthenticated telnet session from spoofing your internal domain (e.g., using MAIL FROM: [email protected] to send to rcpt to: [email protected]), you need to address how Exchange handles anonymous permissions.

By default, the **Default Frontend ** receive connector listens on Port 25 and has NT AUTHORITY\ANONYMOUS LOGON assigned to it. This is necessary to receive legitimate mail from external servers on the internet. However, an anonymous connection is granted the extended right ms-Exch-SMTP-Accept-Any-Sender, which allows it to claim any sender address-including your own internal domains.

Here are the two best ways to fix this.

Method 1: Stripping Anonymous "Send-As" Rights for Internal Domains (Recommended)

You can tell the inbound internet receive connector that anonymous connections are allowed to deliver mail, but they are not allowed to claim they are coming from an authoritative internal domain.

Run the following command in the Exchange Management Shell (EMS):

Get-ReceiveConnector "YOUR_SERVER_NAME\Default Frontend YOUR_SERVER_NAME" | Remove-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "ms-Exch-SMTP-Accept-Authoritative-Domain-Sender"

What this does:

If someone opens a telnet session from a remote IP and types MAIL FROM:<[email protected]>, Exchange will instantly reject the command or block the message at submission with a 550 5.7.60 SMTP; Client does not have permission to send as this sender error.

Critical Exception Warning: If you have internal applications, scanners, or printers that rely on sending anonymous mail using your local domain, stripping this permission globally from the default connector might block them. If you have these, implement Method 2 instead.

Method 2: Isolating Untrusted Remote IPs with a Dedicated Connector

If you want to enforce this restriction strictly for specific remote IPs or external subnets without breaking internal apps, you can use Exchange's "most specific IP match" logic.

Exchange evaluates incoming IP connections and maps them to the connector with the narrowest matching IP range.

1. Create a Secure Internal/Partner Connector

Create a dedicated connector for your legitimate internal apps, printers, or trusted external gateways (like Mimecast or Proofpoint) so they can still relay securely:

New-ReceiveConnector -Name "Trusted Internal Relay" -TransportRole FrontendTransport -Usage Custom -Bindings 0.0.0.0:25 -RemoteIPRanges 192.168.1.0/24, <Your_Secure_Gateway_IPs> -AuthMechanism TLS, Integrated -PermissionGroups ExchangeUsers, ExchangeServers

2. Lock Down the Default Frontend Connector

Once your trusted devices are safely shifted to their own connector, you can strip the dangerous anonymous rights or explicitly use Exchange Anti-Spam features on the Default Frontend connector to reject internal domain spoofing from untrusted external spaces.

Ensure the native Anti-Spam agents are installed:

& $env:ExchangeInstallPath\Scripts\Install-AntiSpamAgents.ps1
Restart-Service MSExchangeTransport

Then, enable internal domain validation:

Set-SenderFilterConfig -BlockedDomainsAndSubdomains yourdomain.com -InternalMailEnabled $true

Verification Testing

To verify it is successfully blocked, open a command prompt or terminal from the remote IP and replicate the attack via telnet:

telnet mail.yourdomain.com 25
HELO remoteattack.com
MAIL FROM: [email protected]

If configured correctly, you should receive a 554 or 550 permission denied error immediately after typing the MAIL FROM line, closing the spoofing gap entirely.