Inventory the actual path rather than the app label
“Uses SMTP” does not tell an email team how an application is permitted to send. An application may submit through a mailbox, relay through an organization’s connector, or deliver directly to a recipient system. Those routes have different identities, permissions and recipient limits. An inventory that records only a vendor name and From address can miss the condition that makes the route work.
Create one entry for each materially different application path. Capture the configured endpoint, port, transport requirements, authentication method, envelope sender, visible From address, expected recipients and queue owner. Include the hosting location and the public source IP observed by the receiving service where relevant. The machine’s private address is not evidence of the address a cloud connector sees after network translation.
Distinguish SMTP roles from provider product names
SMTP relay is a general transport role, while Microsoft’s “SMTP relay” and “Direct Send” label specific documented options. In the Microsoft 365 application setup guide reviewed on 8 November 2026, client submission uses mailbox authentication, relay uses an inbound connector, and Direct Send reaches recipients inside the cloud organization rather than providing external relay. These labels should not be transferred uncritically to another provider. Microsoft application-mail setup.
At the protocol level, the client presents an SMTP transaction and receives replies for individual steps. Successful connection does not establish permission to relay to every destination. Record the receiving role intended for the chosen endpoint before troubleshooting a rejected recipient. A public MX is an inbound destination, not an invitation to use its owner as an unrestricted outgoing service. RFC 5321, sections 2.3 and 3.3.
Put route requirements next to the inventory
For the documented Microsoft choices, record smtp.office365.com for client submission versus the tenant MX endpoint for relay or Direct Send. Relay eligibility depends on the configured certificate or eligible public-IP connector; mailbox authentication belongs to the submission route. Preserve the current guide’s constraints on hosting, sender domains, transport and recipient reach rather than copying a generic configuration recipe. Microsoft’s setup page was updated on 16 September 2026; tenant applicability still needs confirmation. Microsoft application-mail setup.
The route-to-requirement map is a documentary inventory framework. Its purpose is to expose missing evidence, not select a route automatically. If an application needs external recipients, a tenant-only path is a functional mismatch even when internal tests succeed. If the route depends on a connector, a saved hostname without a verified connector match is incomplete evidence. If authentication settings are intentionally restricted, choose an authorized supported design instead of disabling security controls to make an old recipe work.
Keep sender authorization distinct from authentication results
A service’s permission to submit mail is separate from the message’s SPF, DKIM and DMARC outcomes at a downstream receiver. Successful mailbox authentication does not prove the visible From address is authorized for that mailbox. A connector matching the source does not prove every resulting message has aligned authentication. Conversely, changing a public SPF record does not grant the SMTP service relay permission.
Record the administrative permission and the downstream identity evidence in separate inventory fields. DMARC evaluates the Author Domain against authenticated identifiers; it is not a registry of which applications hold submission credentials. A final receiver’s result should be tied to the exact message and evaluation location. RFC 9989, section 4.4. Credentials and tokens should never appear in the inventory or in a diagnostic ticket; record an approved reference to their owner and management process instead.
Use a fictional application to expose the hidden dependency
Suppose a fictional warehouse scanner sends dispatch notices to employees through a tenant MX endpoint. Its inventory says “SMTP relay,” but no connector evidence is attached. Later, a team adds an external courier address and delivery fails. The failure does not establish that the courier’s domain or the scanner’s SPF is defective. The first question is whether the route was ever authorized for external relay, or whether successful internal mail was using a different service path.
A second fictional change moves the scanner’s traffic through a new network gateway. The application settings remain identical, yet the public source seen by the service changes. If the approved route depended on that source identity, the unchanged application screen is misleading. Before any configuration change, compare the authorized connector evidence and actual network path with the previous working record. Neither scenario is a live test or an account diagnosis.
Plan a controlled acceptance test
Choose an authorized recipient for every required recipient category, a harmless uniquely identified message and a time window with an accountable operator. Record the full SMTP replies and stage, queue identifier, route and the final trusted authentication results where available. A submission acceptance response proves a handoff, not final inbox placement. The downstream server assumes transport responsibility after a positive completion response following the message data. RFC 5321, section 4.2.5.
Include negative expectations without probing unrelated recipients or public relays. Where a route is deliberately internal-only, the requirement is to document that restriction, not discover a way around it. Keep retry ownership explicit so the application does not create a second message while its mail service already has the first queued.
Keep the inventory versioned
Review the entry after network migration, certificate renewal, authentication-policy change or recipient-scope expansion. Provider documentation is dated evidence, while the actual tenant configuration is separate evidence. A deprecated authentication recipe should not be rescued by sharing passwords or weakening safeguards.
A route-to-requirement map with current provider evidence and a controlled test message. This exact requirement remains open. No tenant setting, connector, credential, network route or controlled message was inspected or changed. The supplied map and examples prepare the investigation; they do not certify that an application is configured correctly.