Azure SQL Managed Instance Send Via On Prem SMTP

A SQL Managed Instance wasn't sending mail via an on-premises SMTP server. The error suggested a network connectivity failure. NSG rules and on-prem firewall rules both looked correct — the primary IP of the managed instance was allowed through.

Investigation

The managed instance could send mail through an internet-hosted mail relay without issue, which confirmed the problem was specific to the on-prem path.

Checking the on-prem firewall logs revealed that no traffic from the managed instance's primary IP (10.67.254.222) was ever hitting the SMTP rule — which explained why it wasn't being allowed. Traffic was arriving from a completely different IP: 10.67.254.205.

The Cause

Azure SQL Managed Instance uses a /27 subnet (in this case 10.67.254.192/27, giving the range 10.67.254.193–10.67.254.222). The instance's primary IP is 10.67.254.222, but SMTP traffic was originating from 10.67.254.205 — an address within the subnet that doesn't appear in the managed instance's settings, DNS records, or any Microsoft documentation.

This secondary IP appears to be used internally by Azure for certain outbound connections, but it isn't surfaced anywhere obvious.

The Fix

Allow the entire managed instance subnet in the on-prem firewall rule rather than individual IPs:

Source: 10.67.254.192/27
Destination: <SMTP server IP>
Port: 25
Action: Allow

Once the subnet was allowed rather than a single host, SMTP delivery started working immediately.

Takeaway

If you're configuring on-premises firewall rules for Azure SQL Managed Instance connectivity, allow the whole /27 subnet — don't rely on the primary IP address alone. The managed instance may initiate connections from other addresses within the subnet that aren't documented or surfaced in the portal.