Quick Introduction

In this post, I will be talking about SMTP Relay and Exchange InternalSMTPServers, and show you what can go wrong when you plan your antispam solution. Things can be tricky if you have an SMTP relay servers sitting in front of your Exchange servers, and you enabled Sender ID filter on Exchange HUB servers.

I will start by explaining the problem, and then walk you through the solution. Let us consider that your setup is like the following figure.

Exchange InternalSMTPServers

Your incoming emails are passing through smart hosts or SMTP relay servers  antispam servers]. After the message is inspected, it will be delivered to your internal transport hub Exchange servers.

Now suppose that you want to implement some of the built in Exchange transport antispam features on your internal Exchange servers, like Sender ID filter for example. To do so, you enabled such filter, and suddenly, you will see a lot of block connections perhaps.

SMTP Relay and Exchange InternalSMTP Servers

When an RFC-compliant SMTP server receives a message, the server updates the message’s Received Header with the domain name and IP address of the sender. Therefore, for each SMTP server that is between the originating sender and the Hub Transport server, the SMTP server adds an additional Received header entry.

This means that your SPF check will fail because the IP addresses of your SMPT Relay servers will be included in the message headers of the received message.

Again, SMTP Relay and Exchange InternalSMTPServers can become really tricky. To overcome this problem, you can use the Set-TransportConfig, command to add the list of your SMTP antispam servers [SMTP Relay Servers] to be ignored by the Sender ID agent, so that the SPF check will not fail.

Say that we have two antispam servers sitting in front of our Exchange Transport servers, and their IPs are 10.0.1.10 and 10.0.1.11, the command that we should use will be:

Extra Reading