Domain based restriction of SMTP relay


On-premise IT environments often require an internal SMTP server to relay mail notifications to selected recipients. Especially in hybrid clouds where the primary email services are outsourced you don’t want every single computer to communicate directly with the cloud, effectively implementing firewall restrictions to SMTP traffic.

In such case IIS 6.0 SMTP Virtual Server is a means to an end: all computer systems send their notifications through it. You can restrict relay in a manner of ways, like authentication, TLS, etc. but the most common of way is to create an IP allowed list as depicted below.

Still none of the above ways helps against data leakage: imagine a printer that sends scanned jobs as emails. The advantage at first glance is even more secure environment, when a manager wants to send a scan to his/her email instead of to default network share where all team members have access. On second thought, what if someone scans confidential emails to his/her private email?

Logically in such cases you’d want to restrict SMTP relay only to your company’s domain * Unfortunately IIS SMTP Virtual Server doesn’t offer such option out of the box. You will have to circumvent this through adding more “remote domains” on your SMTP settings. There are some caveats you should pay attention to, though!

Firstly you cannot define an all catch domain (*) as you do in Exchange 200X versions. To mitigate this you will have to add most commonly used domains as depicted below:

The list with country top level domains can get quite extensive. In such case I don’t recommend using IIS SMTP Virtual Server at all – go for a third party SMTP solution instead, as the number of top level domains increases permanently. But for small companies where you trust people and want to restrict sending ‘by mistake’ the settings work in 99% of the cases.

Secondly don’t get mislead by the disabled option “Allow incoming mail to be relayed to this domain”: in my tests the mails would still be relayed. This is why you add a fake smart host to each restricted domain. The domain name or IP address of this smart host should be non-existent.

If configured as above any email to *.com is not relayed but lands under C:\inetpub\mailroot\Badmail, which has a nice effect of control. You can either check this folder periodically or apply a script to notify you automatically when a message debarks there.