There is a particular kind of infrastructure conversation that comes up every few weeks in operations teams. Someone points at a billing system, an ERP installation or an internal tool and asks whether it is finally time to "modernize the email layer." Almost always, the right answer is no — what needs modernizing is the transport underneath, not the application on top. An SMTP relay does exactly that, and it remains the cleanest way to keep legacy and billing systems delivering mail reliably while the rest of the business moves on other priorities.
Key takeaways
- Billing platforms, ERP suites, helpdesk tools and monitoring agents mostly speak SMTP with a username and password. Rewriting them to speak HTTP rarely pays off; fixing the transport underneath usually does.
- An SMTP relay gives legacy systems TLS, DKIM signing, bounce classification and suppression without touching the application code. Those are the four capabilities most legacy apps cannot produce on their own.
- Microsoft 365's deprecation of Basic Authentication for SMTP AUTH is the single biggest 2023 migration trigger. Tenants without a relay plan are running on borrowed time.
- Credential hygiene for SMTP-speaking legacy systems is worse than most teams realize. A cleanup pass often surfaces plaintext passwords sitting in configuration files from 2016.
- Even at modest volumes, a properly configured relay improves deliverability measurably because inbox providers penalize unsigned, unauthenticated traffic more aggressively each year.
Why this still matters in 2023
The temptation to treat SMTP as legacy is understandable. Modern sending platforms prefer HTTP APIs with JSON payloads. Vendor marketing leans in that direction. Conference talks reinforce it. For a developer who started in 2018, SMTP can feel like a protocol from a history book.
The reality on the ground is different. A substantial share of business-critical email still originates from applications that only know how to open a TCP connection to a hostname on port 587 or 465, say EHLO, authenticate with a username and password, and hand over a message. Those applications are not going away. They are running your accounts receivable, your order fulfillment, your helpdesk ticketing and half of the background jobs that send operational alerts at three in the morning. They have been doing it reliably for years.
What has changed is the environment around them. Mailbox providers have raised the bar for what they accept. Hyperscalers have started turning off the authentication mechanisms those applications rely on — Microsoft 365's Basic Authentication deprecation is the most visible example, and it is actively disabling SMTP AUTH in tenants where it was unused. Regulatory frameworks like PCI DSS 4.0, published in March 2022, now explicitly require controls around email authentication. The applications have not moved, but the ground under them has. Teams planning a deliberate cutover will also find value in our migration planning guide, which covers the sequencing side of the move.
The systems that never stop needing SMTP
The population of systems that rely on SMTP is larger and more diverse than teams realize until they start an inventory. The table below is representative of what most mid-sized organizations find when they actually look.
| Category | Examples | Typical output | Why they stay on SMTP |
|---|---|---|---|
| Billing / invoicing | WHMCS, FreshBooks, QuickBooks Desktop, custom billing | Invoices, receipts, payment reminders, dunning | Native SMTP field; no HTTP outbound alternative exposed |
| ERP suites | SAP, Business Central, NAV, Oracle EBS, Odoo | Purchase orders, shipping notices, vendor confirmations | SMTP driver built in; custom integrations expensive and risky |
| Helpdesk / ticketing | OTRS, osTicket, older Zendesk installs, Spiceworks | Ticket acknowledgements, status changes, agent notifications | Email is the primary channel; SMTP is how they output it |
| Monitoring and alerting | Nagios, Icinga, Zabbix, PRTG, cron jobs with mail | Uptime alerts, threshold breaches, report completions | Unix tradition; sendmail interface is the API. For the operational side of this category specifically, see SMTP relay for operational alerts. |
| Content management | WordPress (with SMTP plugin), Drupal, Joomla, Magento | Form submissions, password resets, user registration | PHP mail() is unreliable; SMTP plugin is the standard fix |
| Scanners / printers | Office MFPs from Xerox, Ricoh, Canon, Konica Minolta | Scan-to-email, print-job notifications | Firmware often supports SMTP only; OAuth support is patchy |
| Internal line-of-business apps | Custom payroll, HR tools, legacy .NET or Java applications | Pay stubs, HR notifications, internal reports | Written before HTTP email APIs existed; no rewrite budget |
| CI/CD and DevOps | Jenkins, GitLab runner notifications, deployment agents | Build failures, deployment confirmations, security alerts | SMTP is the lowest-friction integration; already configured |
Every row above is the same conversation: the application already speaks SMTP, changing that conversation is expensive, and nothing about the application's job changes if you improve the transport it uses. The SMTP relay is the component that absorbs all the improvements without touching the application.
One under-appreciated consequence: these systems are often the ones that send the most operationally important mail. Invoices that do not arrive cost money. Password resets that do not arrive produce support tickets. Deployment failure alerts that get filtered to spam extend outages. The systems that people dismiss as legacy are frequently the systems whose email matters most.
What an SMTP relay actually provides
An SMTP relay sits between your application and the outbound MTA that delivers mail to the internet. From the application's perspective, the relay looks exactly like any other SMTP server: a hostname, a port, credentials, TLS. From the receiving world's perspective, the relay looks like a professional outbound operation with warm IPs, proper DKIM signatures and aligned authentication. The application does not know the difference, and that is the point.
The capabilities the relay adds fall into four buckets. Understanding each one makes the value clear without the marketing fog.
| Capability | What it means for the legacy app | Who usually had to handle this before |
|---|---|---|
| Modern TLS on outbound connections | TLS 1.2+ to every receiving MX, even if the app only knows how to do STARTTLS | The application, often poorly |
| DKIM signing per domain | Every outgoing message signed with the right selector for the From domain | Usually not handled at all |
| Bounce classification and suppression | Hard bounces trigger automatic suppression; soft bounces retry intelligently | The application, if at all |
| Rate limiting and throttling | Per-domain and per-ISP limits respected; spikes queued rather than rejected | Almost never handled; "spray and hope" |
| Per-ISP queue management | Gmail, Yahoo, Microsoft each get the backoff behavior they expect | Not handled; legacy apps just retry until they give up |
| Authentication credential isolation | Legacy app has its own scoped credential that cannot send as other domains | Handled inconsistently, often with shared credentials |
Read the right column as the honest answer to "what would we need to build if we tried to do this without a relay?" The answer is a lot of code, maintained by someone who understands inbox providers, integrated into a system that was designed to do something else. That trade is rarely worth it. The relay is cheaper and more reliable for the same outcome.
The authentication layer you cannot skip
Using a relay does not exempt a sender from publishing SPF, DKIM and DMARC. It makes that publication easier, because the relay provides the canonical IP list for SPF and handles DKIM signing under the hood, but the domain owner still has to publish the records. Without them, the relay's work is invisible to receiving systems.
The minimum record set for each sending domain
DNS# SPF — authorize the relay (and any other legitimate sources) on this domain
billing.example.com. IN TXT "v=spf1 include:spf.authorizehosting.com -all"
# DKIM — the relay will provide a selector and the TXT record to publish
ahk1._domainkey.billing.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
# DMARC — start at monitoring, progress through quarantine to reject
_dmarc.billing.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
Three details deserve attention. First, SPF and DKIM records apply per domain or subdomain. A billing system sending from billing.example.com needs its own records; the parent domain's records do not cover it automatically. Second, DMARC does inherit to subdomains unless overridden, so a well-configured root DMARC covers the billing subdomain too — but the inheritance only helps if SPF or DKIM align, which brings us back to point one. Third, the DMARC policy should start at p=none for a new setup, move to p=quarantine once you have confirmed every legitimate sending source, and eventually reach p=reject. Jumping straight to a strict policy with legacy systems in the mix usually produces surprises. For organizations with multiple sending domains that need to share a coherent policy posture, authentication alignment for multi-domain senders covers the coordination side.
Why this matters more in 2023 than it did three years ago
Inbox providers have been gradually raising the filtering cost of unauthenticated mail. A message that would have landed in the inbox in 2019 with no SPF might land in the spam folder in 2023 even if nothing else about it changed. The trajectory is clear: authentication is becoming a filtering prerequisite rather than a bonus signal. Legacy applications that were running fine without authentication a few years ago are the ones most exposed to this quiet tightening.
The Microsoft 365 Basic Auth problem
Of all the forcing functions pushing organizations toward a proper SMTP relay in 2023, the most concrete is Microsoft 365's ongoing deprecation of Basic Authentication. The timeline has moved a few times, but the direction has not: Basic Auth for SMTP AUTH against Exchange Online is being retired, and any application that still uses username-and-password authentication to send through Microsoft 365 is on borrowed time.
Microsoft began disabling Basic Auth in early 2021 for tenants with no recorded usage. In early 2023, the disabling extended to tenants that had previously requested extensions. Office 365 Operated by 21Vianet began its own disabling on March 31, 2023. The direction is one-way: every few months, another slice of the ecosystem loses access to the authentication mechanism legacy applications depend on.
- Inventory the tenant. Identify every application authenticating against Microsoft 365 with a username and password. The sign-in logs under Microsoft Entra ID (formerly Azure AD) expose this directly — filter by client app "IMAP, POP, SMTP" for the last seven days.
- Classify each source. Is the application a candidate for OAuth migration (modern enough to support it), or is it a legacy system that will never speak OAuth (most scanners, most older line-of-business apps)?
- Route the OAuth-capable sources to modern auth. Microsoft Graph, Azure Communication Services Email, or SMTP AUTH with OAuth 2.0 are the supported paths. Each one is more work than the Basic Auth setup was, but they future-proof the sender.
- Route the non-OAuth sources through an SMTP relay. This is where the relay earns its place. The relay absorbs the Basic Auth conversation from the legacy system on one side and presents a modern, authenticated, TLS-secured outbound posture on the other. The legacy system never has to change.
- Plan the cutover before the disable happens. When Microsoft disables a tenant's Basic Auth, there is no grace period. Mail stops flowing, and there is no emergency re-enable. Deadlines should be earlier than the disable date, not right at it.
The common mistake we see is treating this as a Microsoft-only problem. Every mailbox provider is moving in this direction; Microsoft is just the one doing it most visibly. A relay-based architecture isolates the organization from that trajectory regardless of which provider moves next.
A concrete WHMCS relay configuration
Every operations team has had the same conversation about WHMCS at some point: the billing platform sends invoices, receipts, payment reminders and support ticket notifications, and all of it runs through whatever SMTP server is configured in the Mail tab of General Settings. When those emails start going to spam or not arriving, the answer is almost always relay configuration, not WHMCS itself.
The configuration pattern is exactly the same as for any SMTP-aware application — hostname, port, username, password, SSL/TLS mode — but getting the values right matters.
WHMCS Mail SettingsMail Type: SMTP
SMTP Host: smtp.authorizehosting.com
SMTP Port: 587
SMTP Username: ahk_whmcs_billing
SMTP Password: [generated per-application credential]
SMTP SSL Type: TLS
From Email: billing@billing.example.com
From Name: Example — Billing
Debugging: OFF in production; ON briefly for troubleshooting
Three details that catch people out. First, the SMTP username should be a per-application credential, not a shared master. If the billing system is ever compromised, that credential gets rotated without affecting the help desk, the scanner or any other sender. Second, the From email and the relay's authentication username do not need to match, but the From domain and the relay's DKIM selector do. The relay signs with a key associated with billing.example.com; WHMCS just has to use an address at that domain in the From field. Third, port 587 with STARTTLS is the standard path. Port 465 with implicit TLS works equally well for most relays. Port 25 with no TLS should never be used outside a tightly controlled internal network.
Troubleshooting the first send
The first message from a new WHMCS relay setup is the most likely one to fail, because any of a dozen small details can be wrong. Enable debugging briefly — it writes detailed SMTP conversation logs to Configuration → System Logs — send a test invoice to a mailbox you control, and read the log. Real errors in the log include authentication failures (credential typos or scope issues), TLS mismatches (wrong SSL type), or silent success where the message left WHMCS but got filtered downstream. Each one tells you exactly where to look next.
Credential hygiene for legacy systems
Legacy applications store SMTP credentials in whatever the framework of the day considered normal when they were built. That usually means plaintext in a configuration file, occasionally obfuscated in a registry key, rarely in something resembling a proper secret store. A credential audit across a few dozen legacy systems is almost always more revealing than the team expects.
The checklist every serious operation runs
- Enumerate every system. A spreadsheet with columns for application name, host, environment, credential storage method, last rotation date, and owner. The spreadsheet is boring. It is also what keeps the operation from forgetting about a scanner in the finance department's back office.
- Give each application its own credential. Shared SMTP credentials across multiple applications is how credential rotation becomes impossible. Each legacy app gets its own username, its own password, its own per-app scope at the relay.
- Rotate on a schedule. Annual rotation is the minimum for SMTP credentials that live in configuration files. Every rotation is also a chance to re-verify that the application is still in use.
- Constrain the credential. The relay should let you bind a credential to allowed From domains and optionally to source IP ranges. A WHMCS credential that can only send from
billing.example.comand only from the billing server's IP range is much harder to misuse. - Monitor for unexpected use. The relay's audit log should surface authentication attempts from unexpected IPs or with unexpected From domains. Those events are signals — a compromised credential, a misconfigured new deployment, or an abandoned system someone forgot about.
- Plan for the "orphaned credential" case. When a credential has not been used in 60 days, either the system has been decommissioned or something is broken. Both cases deserve investigation; neither deserves ignoring.
Operational patterns that prevent surprises
A relay is only as reliable as the operational discipline around it. Three patterns separate programs that run smoothly from programs that have preventable incidents.
Monitoring the relay, not just the applications
Most teams monitor their billing system for uptime and their ERP for transaction volume. Fewer teams monitor the relay that carries both their outbound mail. A minimum monitoring surface for the relay itself includes:
- Daily accepted volume, per credential, with alerting on unexpected drops (a legacy system went silent) or spikes (a loop in an application).
- Bounce rate by credential, with a threshold above which the credential is automatically paused for investigation.
- Authentication failure rate, which flags compromised or rotated credentials that a legacy system has not picked up.
- TLS version distribution on outbound connections, which catches the slow drift of old applications that silently fall back to weaker ciphers.
- Queue depth and tail latency, which reveal throttling pressure before it turns into a capacity problem.
Treating the relay configuration as code
The credentials, From-domain allowlists, rate limits and DKIM key associations that make a relay work are configuration, and configuration drifts. The programs that avoid surprises keep the relay's configuration in version control — a YAML file, a Terraform module, whatever the environment expects — and change it through the same review process as any other infrastructure. The diff tells you exactly what changed when something starts behaving differently.
A quarterly review cadence
Every quarter: read the list of active credentials, cross-reference with the application inventory, and retire anything that should have been turned off. Check DMARC reports for the relay's sending domains; make sure no new unauthorized source has started impersonating. Review bounce and complaint patterns per credential, flag outliers, and work through them. This takes a deliberate half-day, and it prevents the slow accumulation of small issues that eventually collide into an incident.
When relay is not enough
Relay covers an enormous share of legacy and billing workloads, but it has limits. The table below summarizes the situations where the relay stops being the best fit and a different kind of infrastructure enters the conversation.
| Situation | Why relay is insufficient | Typical next step |
|---|---|---|
| The application needs per-message events (opens, clicks, delivery webhooks) | Relay exposes bounces; not engagement events | Add an Email API for the event-rich workload |
| Multi-tenant SaaS with per-tenant suppression | Relay credentials do not scope cleanly to tenants | API with tenant-aware event streams |
| Sustained volume above 5-10 million messages per month | Shared relay pools can become a bottleneck; reputation benefit of isolation grows | Dedicated IPs, possibly a dedicated MTA like PowerMTA |
| High-stakes transactional SLAs requiring sub-second routing decisions | Relay has queue dynamics that HTTP APIs avoid | Email API with the right provider |
| Cold outreach workloads | Relay can send it, but cold needs dedicated domains and stricter isolation | Dedicated cold email infrastructure |
Notice what the table does not say: it does not say "at some volume, relay stops working." A well-run relay can handle large sustained volumes. The right-side-of-the-table situations are about capability fit, not capacity.
Frequently asked questions
Can we use our office Microsoft 365 mailbox as our SMTP relay for all applications?
Technically yes, in limited scenarios, but it is usually the wrong choice. Office 365 mailboxes have strict per-mailbox send limits (10,000 recipients per day in most plans), throttling that does not behave well under burst load, and the looming Basic Auth deprecation that makes the configuration fragile. A dedicated relay product is the correct tool for multi-application SMTP traffic.
Do we need DKIM if our mailbox provider already signs mail?
The mailbox provider signs mail it sends on behalf of your users. Legacy applications relaying through a separate SMTP relay produce mail that needs to be signed by the relay, not the mailbox provider. The two signing paths are independent, and both need to align with DMARC. Do not assume one covers the other.
What is the right port?
Port 587 with STARTTLS is the standard submission port for authenticated SMTP. Port 465 with implicit TLS is a widely-supported alternative. Port 25 is for server-to-server delivery and should never be used for authenticated submission. Legacy applications that only offer port 25 typically can also be configured for 587; if not, they are unusually old, and a network-layer workaround is in order.
How many credentials should we create?
One per application, minimum. The cost of creating a credential is trivial; the cost of having to rotate a shared credential across nine applications in a hurry is significant. Most mid-sized organizations end up with 10-30 credentials across their legacy portfolio.
Should we move all of this mail to an HTTP-based Email API instead?
For applications you control and plan to keep investing in, maybe. For legacy systems you have no appetite to rewrite, almost never. The effort to convert an SMTP-speaking legacy app to an HTTP API usually exceeds the effort of configuring a relay by two orders of magnitude, and the operational outcome is the same.
How does this interact with hybrid Exchange environments?
If you have an on-premise Exchange server in a hybrid Microsoft 365 configuration, it can serve as an internal relay for legacy systems that cannot speak modern authentication. This is a valid pattern while you migrate off Basic Auth, but it is an interim choice; a cloud-based SMTP relay is simpler to operate long-term than maintaining on-premise Exchange purely for legacy SMTP.
Closing perspective
The framing of this conversation matters. Legacy and billing systems are not a problem to be modernized away. They are infrastructure that works, and their continued working is usually more valuable to the business than any hypothetical rewrite could be. The job is to improve the environment around them so they can keep doing what they do without being undermined by changes outside their control.
An SMTP relay is the component that does that. It absorbs authentication modernization, TLS upgrades, DKIM signing, bounce management and per-ISP throttling on behalf of the legacy application, and it presents the same SMTP conversation to the application that the application has always expected. The split is clean: legacy stays legacy, and the modern operational surface lives in the relay.
The 2023 trigger that pushes most teams to finally act is Microsoft 365 Basic Auth retirement, because it creates a concrete deadline rather than a vague "should get around to it." That deadline is a useful gift. Once the relay is in place for the Microsoft 365 side, the same relay typically handles every other legacy application in the environment for no additional work — scanners, ERP, help desk, cron jobs. The cutover forced by one provider becomes the consolidation moment for everything else.
The programs that handle this well end up with a clean operational architecture: one relay layer, credentials per application, authentication per domain, monitoring per credential, and a quarterly review that keeps the whole thing honest. The programs that delay usually end up doing the same work under pressure, with their billing system sending invoices into the spam folder until someone fixes it. Doing the work deliberately is cheaper than doing it reactively, and that is the whole argument for taking this seriously in 2023 rather than leaving it for later.