After migrating mail to a cloud service, a layer remains in the company that nobody thought about: the applications, devices and scripts that send notifications. The ERP system sends confirmations, the printer sends scans, monitoring sends alerts, a scheduled job on a server sends a report. All of them do it the way they were taught in 2009: port 25, no encryption, no password, to the address of a mail server that no longer exists.
Why they cannot simply be repointed
A cloud mail service requires one of two things: an authenticated, encrypted connection on port 587, or a connector accepting mail from specific public addresses, also encrypted. An older application often does not support encryption, has no password field, or has one but stores the password in a configuration file in plain text. A printer from 2015 knows only outdated versions of the encryption protocol that the service no longer accepts.
The common reaction: a cloud connector with a list of exceptions, a mailbox account with a password typed into twenty configurations, basic authentication enabled “temporarily” for one account. Every exception is a separate risk and a separate thing to remember at password rotation time.
The internal relay
A solution known for decades: one mail server in the server segment whose only job is to accept mail from internal systems and forward it in the way the cloud service requires.
On the application side, the relay accepts connections:
- only from a list of internal IP addresses, specific servers and devices, not the whole network,
- on ports 25 and 587, with encryption optional, because some clients cannot do it,
- without authentication, because the address list is the authentication,
- with sender domains restricted to the company’s own and a per-source hourly message limit.
On the cloud service side, the relay leaves through one properly configured connection: a connector with the company’s public address and enforced encryption, or authenticated submission with a single service account whose password lives in one place.
What the relay gives beyond repointing
A queue. A link or cloud service outage does not mean lost notifications. Messages wait in the queue and leave once the connection is restored. An application sending directly gets an error and usually does not retry.
Logs per application. One log file answers whether the ERP system sent today’s invoice and what happened to it. Without a relay the answer requires searching the cloud service’s logs and the application’s logs, if the application has any.
An inventory. After a week, the relay logs show the full list of systems sending mail, including those nobody knew about. That list is the basis for the SPF record and for cleaning up.
One place for changes. A change of mail service, rotation of the service account password, a new encryption requirement: one configuration instead of twenty.
Rollout rules
- The relay in the server segment, with a network policy: accepts from the internal address list, leaves only towards the mail service.
- The firewall blocks port 25 from the internal network to the internet from every address except the relay. An application bypassing the relay stops working, which is intended and visible.
- The relay’s address in DNS under a name that will not change when the server is replaced.
- Monitoring: queue length, number of rejected connections, age of the oldest queued message. Alert when the queue grows.
- The SPF record and DKIM signing account for the path through the relay, otherwise notifications land in spam.
- Applications migrated one by one, according to the inventory list, with a documentation entry: system, source address, sender domain, owner contact.
Summary
Application mail will not disappear and will not learn new protocols. The internal relay accepts it as it is, only from the internal network and only from an address list, and leaves in the way the cloud service requires: with a queue, logs and one place for changes. Twenty exceptions in the cloud become one configuration that can be audited.