Most organizations have internal application servers and appliances that send emails to users or groups. Examples include copier/scanners and application servers, such as backup servers that notify admins of a completed or failed backup job.
If the organization has Exchange on-prem you would normally configure an internal relay send connector in Exchange and configure the internal resources to send emails to Exchange. But what do you do when you’ve migrated all your mailboxes to Office 365 and have decommissioned your Exchange servers?
The solution is to install an IIS SMTP relay server in your internal network, configure it to accept email from specific IP addresses, and forward emails to Office 365. You can also configure the SMTP relay for external domains, if necessary.
Here’s how to do it:
- Install the SMTP Server feature and its dependencies to a new or existing Windows server. This will be your relay server and your firewall needs to allow it to send SMTP traffic (TCP port 25) outbound to the Internet. I typically use the DirSync server, if there is one.
|Adding the SMTP Server feature and its dependencies to Windows Server 2012
- Open Internet Information Services (IIS) 6.0 Manager to configure the SMTP relay.
- Configure the properties of [SMTP Virtual Server #1] as follows:
- On the Access tab:
- Authentication: Only Anonymous access is checked.
- Relay: Only the list below. Add IP addresses or ranges of servers allowed to relay.
- Note – It’s important to only allow IP addresses you trust to relay through this server. Any IP address you enter here will be allowed to send emails on behalf of your domain.
- On the Messages tab:
- Adjust message size limits. The default message size limit is 2048 KB (2 MB). You may want to change it to 10240 KB (10 MB) or more to allow for larger messages from copier/scanners, etc.
- On the Delivery Tab:
- Outbound Security: Anonymous access only and no TLS encryption.
- Outbound Connections: Port 25
- Advanced: Leave the Smart Host field blank
- Add new remote domains:
- Right-click Domains > New > Domain and add the domain(s) hosted in Exchange Online.
- If the relay server is allowed to relay emails to other external domains add a new *.com remote domain. Repeat for *.org, *.net, etc. as necessary.
|Add Office 365 and other remote domains if required for external relay
- For properties of each domain hosted in Exchange Online:
- Check Allow incoming mail to be relayed to this domain
- Forward all mail to this smart host: smtp.office365.com
- Outbound Security: Check Anonymous access and TLS encryption
- For properties of all other remote domains (if any):
- Check Allow incoming mail to be relayed to this domain
- Outbound Security: Check Anonymous access and do not check TLS encryption.
- Restart IIS. Be aware that whenever you restart IIS, the SMTP virtual server usually stays stopped – start it.
- The SMTP Server feature can be added to any Windows 2003 or better server. I usually use the DirSync server if there is one.
- Unlike Exchange, TLS for IIS 6 SMTP servers is not opportunistic. If the virtual server or a remote domain is configured to use TLS email will not be sent if the remote domain does not support TLS. Office 365 offers TLS, so we can use it.
- The configuration above allows the IIS 6 SMTP server to send emails to the Internet for the remote domains configured, so you should add the public NAT IP address for this server to your existing SPF record to prevent non-delivery. Use http://whatismyip.com from the SMTP server to determine the NAT IP address.
- Monitor the %systemdrive%\Inetpub\mailroot\Queue folder to ensure that emails are being delivered.
- If emails are not being delivered to Office 365 users, test sending email via Telnet. The IP address may be blocked by an Exchange Online Protection (EOP) blocklist and you will see that response from EOP. If so, send a delist request from your Office 365 admin account to email@example.com letting them know the IP address that should be delisted. In my experience it takes up to 36 hours for Microsoft to delist it.
- If emails are not being delivered to external domains, ensure that you have a remote domain type (*.com, *.eu, etc.) configured for those email addresses.
- You can enable logging in the properties of the SMTP virtual server for further troubleshooting. Use the NCSA Common Log File Format. IIS does not automatically groom or delete logs like Exchange does, so turn logging off when you’re done troubleshooting.
- The best practice is to create an A record in internal DNS for smtp.yourdomain.com using the SMTP relay server’s IP, and configure all application servers and appliances to use that FQDN for email forwarding. That makes it easier to update in the future.
You may find that when you create a link to a file from your web server that Internet Explorer cannot download or open the file. When the user clicks the link, Internet Explorer returns the generic 404 error, as shown:
They also may receive an error stating, “Internet Explorer cannot download filename.ext from www.server.com. Internet Explorer was not able to open this Internet site. The requested site is either unavailable or cannot be found. Please try again later.“
This happens when IIS doesn’t understand the file extension and associated content type of the file. Examples of such file extensions are .reg or .gadget. To fix this problem you must add the extension and MIME type to IIS.
Here’s how you do it in IIS 7.0 (Windows Server 2008) and IIS 7.5 (Windows Server 2008 R2):
- Open Internet Information Services (IIS) Manager
- Expand servername > Sites > Default Web Site
- Select the website you want to configure, or select Default Web Site if you want to configure all websites on the server
- Double-click MIME Types in the IIS section of the center pane
- Click Add in the Actions pane
- Enter the extension you wish to add, including the . prefix (i.e., .reg or .gadget)
- Enter the MIME type (i.e., text/plain for .reg files or application/x-windows-gadget for .gadget files)
- Click OK
The changes go into effect immediately – there’s no need to restart IIS.
For a quick reference of MIME types, see MIME Type Detection in Internet Explorer.
This article explains how to enable reverse Domain Name System (DNS) lookup for all versions of Internet Information Services (IIS).
When reverse DNS lookups are enabled on the web server, the IP address of each web client that connects to the IIS server is resolved to a DNS name, and the DNS name instead of the web client IP address is placed in the IIS log files. Enabling reverse DNS also affects what CGI and ISAPI extensions see as a value of the Remote_Host variable.
Microsoft KB article 297795 gives a step-by-step demonstration how to enable RDNS for IIS4, IIS5 and IIS6, but all you need to do is run the following in a command prompt from the ADScripts folder:
For IIS4 run:
adsutil set w3svc/EnableReverseDNS TRUE
For IIS5 and IIS6 run:
cscript adsutil.vbs set /wesvc/EnableReverseDNS “TRUE”
In IIS7, you must install the IP and Domain Restrictions role service for the Web Server (IIS) role. You can do this in Server Manager or from the command line using the following command:
ServerManagerCMD -install Web-IP-Security
In Windows Server 2008 R2, the ServerManagerCMD.exe program is deprecated and has been replaced with the ServerManager Powershell cmdlets. The following two cmdlets are used to install the IP and Domain Restrictions role service:
Now that the role service is installed, you can configure reverse DNS lookups, as follows:
- Open Internet Information Services (IIS) Manager.
- Navigate to the Server Name in the Connections pane. If you only want to enable reverse lookups on a particular website, navigate to that website.
- Double-click IP Address and Domain Restrictions in the center pane and click Edit Feature Settings in the Actions pane.
- Put a checkmark in Enable domain name restrictions and click OK.
You will see the following warning:
Restricting access by domain name requires a DNS reverse lookup on each connection. This is a very expensive operation and will dramatically affect server performance. Are you sure you want to enable restrictions based on domains?
Clicking Yes will enable reverse lookups for all clients connecting to the web server. I have not noticed any more than a 1-2% increase in CPU performance and the websites are just as performant as before.
Each of these changes go into effect immediately. There is no need to restart IIS.