About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
Direct answer: Many hosted business applications appear healthy while notifications, approvals, password resets and batch reports stop, because they depend on a one-way SMTP path that nobody monitors like the web tier. Failure modes include relay refusal, expired smart-host credentials, TLS mismatch, IP blocklisting, and recipient-side rejection under SPF/DKIM/DMARC—not “the mail server is down” in the sense staff would notice in Outlook.
Treat outbound mail as a production dependency with its own health checks and owners, not an afterthought of server build.
Why it matters
Workflow software often sends mail synchronously on a user click or asynchronously from a queue. If SMTP fails, the database transaction may still commit while the operator sees no alert. Regulatory and customer-service processes (statements, dunning, licence reminders) stall quietly. Help desks then chase “the app is broken” when the UI and database are fine.
Hosted environments compound this: applications may relay through a platform smart host, Microsoft 365, or a legacy on-premises connector. Firewall rules, DNS PTR, and authentication secrets for relay are scattered across network, identity and application teams.
How it works
Simple Mail Transfer Protocol, RFC 5321, defines message transfer between MTAs. Application code can act as a client submitting to a service. RFC 6409 reserves port 587 for message submission; port 25 is used for SMTP transfer, with cloud egress subject to provider policy. The relay applies policy: authenticated submitters, rate limits, content filters.
Common hosted stack pieces:
| Component | What the app needs | Typical failure |
|---|---|---|
| Relay endpoint | Hostname, port, TLS optional/required | Connection timeout after firewall change |
| Submission identity | Provider-supported authentication; Microsoft recommends OAuth for client SMTP submission | Authentication failures and queue growth |
| Sender identities | Distinguish envelope MAIL FROM/HELO, DKIM signing domain and visible From; check DMARC alignment | Rejected or treated as junk despite successful submission |
| Reverse DNS / egress IP | Reputation for recipient MTAs | Deferred or 550 errors |
The Microsoft 365 application-mail guidance distinguishes authenticated client SMTP submission from connector-based SMTP relay. Client submission supports third-party hosted applications, requires the documented mailbox and TLS prerequisites, and recommends OAuth. If SMTP AUTH is disabled for the organisation or mailbox, select another supported method. In contrast, the documented connector SMTP relay method explicitly cannot be used to send from a third-party hosted service, including Microsoft Azure. Tenant variation does not remove that restriction. Select a supported submission or mail-service design before planning credentials or connectors.
SPF (RFC 7208) checks authorisation for the SMTP MAIL FROM or HELO identity, not simply the visible message From field. DKIM provides a validated signing domain (d=). DMARC (RFC 7489) requires the visible RFC5322.From domain to align with an authenticated SPF or DKIM domain under the applicable alignment rules. A relay can accept mail that an eventual recipient rejects; acceptance is not final delivery.
What to choose and why
Controlled synthetic sends: use a dedicated test recipient you control and a harmless, clearly labelled payload from the actual sending host and runtime identity, with the production-equivalent supported TLS/authentication path. Do not trigger real customer, regulatory, password-reset or billing messages. Correlate submission response, queue state, bounce information and actual arrival at the controlled recipient; SMTP acceptance alone is not proof of delivery. This proposed test has not been executed here.
Separate monitoring for queue depth, oldest message age, bounces and controlled-recipient delivery evidence per application profile. Label a successful submission separately from confirmed arrival. Web availability probes do not substitute.
Document blast radius: One shared relay for twenty hosted apps means one credential expiry stops twenty workflows. Split relays or logical connectors per criticality when operational cost allows.
Change control: Firewall, DNS (MX and PTR), and certificate changes on the relay path belong on the same change record as application releases when those releases alter From addresses or connectors.
Risks and limits
Inbound mail delivery, mailbox recovery, and full mail-server disaster recovery are out of scope. This article is steady-state dependency awareness, not Exchange restore sequencing.
No SMTP submission was executed in a lab. Port 25 availability from cloud subnets is provider- and policy-dependent; confirm with current provider documentation.
Sources
Primary sources checked 14 November 2026. Procedures remain source-researched, not lab validated.
- RFC 5321
- RFC 7208
- RFC 7489
- RFC 6409
- How to set up a multifunction device or application to send email using Microsoft 365 or Office 365 | Microsoft Learn
Related future topics
Proving firewall changes for application ports; expiring secrets. Service context: Cloud hosting (related link only).
Learning notes
- SMTP failure often does not affect interactive login or the main UI.
- Client submission and connector relay have different hosting and authentication rules.
- SPF/DKIM/DMARC failures are delivery dependency failures for customer-facing mail.
- Test from application identity and subnet, not admin tools.
- Shared smart hosts concentrate blast radius across hosted apps.
This article was originally published on .