Managing Relay in Exchange Server 2013 (Part 1)

If you would like to read the next part in this article series please go to Managing Relay in Exchange Server 2013 (Part 2).


The relay component has been part of the Exchange ecosystem since Exchange 5.5 and sometimes it is overlooked during transitions and migrations. On new releases of Exchange the documentation is updated with all procedures to configure relay however we usually do not visualize the big picture where the Exchange is a requirement for several applications to send messages to internal and external recipients for network printers to send scanned documents and so forth.

Looking from that perspective we will work on a simple method where we can configure relay to be consistent during the regular life cycle of servers where they can be added or removed from the Exchange organization, and also during transitions between Exchange versions.

The goal of this article is to make sure that key applications/network devices are not impacted when a transition or migration occurs, and from the administrator perspective we just need to switch a simple configuration. Please use the information here and adapt to your environment, some administrators may feel comfortable following 100% of this article, others just a few portions of it.

Initial scenario…

In order to develop this article, we are going to start with a simple scenario (Figure 01), where we have a single Domain Controller (, and a single Exchange Server ( The Active directory has a single domain (, and we show possible clients for the relay service including workstations, servers/applications and network devices.

Figure 01

Configuring DNS…

Some administrators try to reserve an IP for the relay, and configure all sort of devices and applications to use that IP. It may work, but let’s be honest, an IP is not going to be easily remembered by someone out of the core server infrastructure. Using an IP may bring problems when transitioning between versions. It will create some outages when moving the IP from one version to the new one. There is also a problem when high availability is required later on, because it may not be that easy to move that exact IP to the Load Balancer.

The key component to make all this work is the DNS. The easiest approach is to create an entry, the thing that is crucial is the communication among all your teams to start using that new DNS entry. Sometimes the relay may be just a thing for infrastructure guys, however it touches a lot of people, including Infrastructure/Servers, Operations/Service Desk and most important Applications Team. Here are some of the details that each team will have to work on to get the new relay working:

  • The Operations/Service Desk Teams are usually responsible to configure the vast majority of your network devices such as scanners and printers. Those devices must be configured with the proper DNS settings, proper FQDN suffix to guarantee that DNS resolution works properly, and on the SMTP settings you need to enter our new relay which on this series is going to be
  • The Infrastructure/Server Teams must configure the on all servers that are responsible to send messages, a few examples: DPM Server, Firewall reports and etc.
  • The Applications Team must buy the idea, especially because they may have developers performing testing and they need to start using the DNS name instead of an IP. If they use the same name, then any application built on test/development will not have any issues during their life cycle.

The key takeaway of this exercise is to keep consistency and force all relay related systems/devices to use the DNS instead of IP or server name.

The DNS portion is fairly easy to achieve, open DNS Manager, and create right-click on your internal zone (in our article and click on New Host (A or AAAA)… and in the new window assign a name and the IP address (in our scenario we are using the IP ending with 205 which is not in use at this moment and the name will be relay), as shown in Figure 02.

Figure 02

Outbound mail security…

An important point to take into consideration when planning a relay solution is to define which computers are able to send messages to the Internet, and using a consistent relay improves that scenario.

Some companies allow several devices to go to the Internet to send e-mails directly (including workstations, network devices etc.), as shown in Figure 03. That is not a best practice and this kind of scenario may get your domain in a black list.

It is recommended whenever possible, one Public IP for Exchange traffic and another one for regular connections from the clients (web surfing and etc.). By doing that, an infected machine will not have a chance to use the same Public IP of Exchange when sending messages out, thus reducing the chances to create issues on your Exchange environment.

Figure 03

The recommendation is to allow only Exchange Servers at the Firewall level to send messages to the Internet (TCP protocol, port 25 outbound), and all other clients that require to send messages to the internet should use the Exchange Server.

If the organization is using EOP (Exchange Online Protection) from Microsoft or any other mail provider, the Firewall rule should be more restrictive and allow connections only from your service provider for inbound and outbound traffic.

If there is a firewall between the clients/servers and Exchange Server, then the administrator need to open the 25 TCP port between those locations and Exchange.

How it works?

The goal is to keep it simple, so we will use a second adapter on the Exchange Server(s) and that adapter will have its own IP address and it will be used just for relay purposes. The DNS entry that was recently created will be pointing out to that specific address.

The configuration proposed was planned to be simple and it will cover most of the challenges of a regular organization, such as: how to allow printers/scanners to send content to the mailboxes without using administrator/operations time? How to allow applications to send messages to the Internet?

Some of the companies that I support for the first time have several Receive Connectors and they overlap each other and it is hard to manage. Using this article series we will be able to address those issues and avoid some of them by using just a single Receive Connector.


In this first article we covered some key aspects of the relay component, and the goal was to keep it simple, using DNS and a couple of settings on Exchange Server the administrator can keep the environment simple and consistent.

If you would like to read the next part in this article series please go to Managing Relay in Exchange Server 2013 (Part 2).

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top