An application that sends through Microsoft 365 needs a supported mail route as well as correct authentication. Client SMTP submission, connector-based SMTP relay and Direct Send use different trust and recipient models.
Identify the route before changing SPF, DKIM or DMARC. DNS can describe a sending dependency, but it cannot turn an unsupported route into an authorised relay or make Direct Send deliver to external recipients.
Record what the application needs to do
Identify the application's hosting location, sender identity, intended recipients and supported authentication and transport features. Record the responsible business service and administrator.
Distinguish a device inside the organisation from a third-party hosted application. Check the current Microsoft guidance for that hosting model rather than assuming every product can use the same connector.
Include a separate test for external recipients when they are part of the business workflow. An internal-only success does not establish an external delivery route.
Compare the supported routes
Microsoft's current setup guide distinguishes the following approaches:
Client SMTP submission uses an authenticated cloud mailbox and supports internal and external recipients.
SMTP relay uses an inbound connector and can relay externally when its prerequisites are met.
Direct Send is internal-recipient delivery, not Internet relay.
High Volume Email is a separate internal-recipient service using an HVE account, not an external-delivery alternative.
Treat this comparison as a selection aid, not the full configuration or licensing specification. Recheck applicable authentication support, network access, limits and prerequisites in the current first-party instructions.
Do not enable a deprecated or unsuitable authentication method just because an older device guide shows it. Choose a route the application and current service actually support.
Understand connector trust before using SMTP relay
Microsoft documents certificate-based or public-IP-based authentication for its SMTP relay arrangement. The network and hosting requirements matter.
A certificate-based route needs the appropriate accepted-domain relationship in the certificate configuration. An IP-based route depends on the public address visible to Microsoft, not a private address shown on the device.
Microsoft’s current guide excludes third-party-hosted applications, such as Azure-hosted services, from this SMTP relay arrangement. Where IP authentication is used, the address must be static and not shared with another organization. Review shared-address and hosting restrictions carefully. Creating an IP connector for infrastructure shared outside the organisation can create a different trust scope from the one the administrator intended.
Use Microsoft's generated or verified MX endpoint and current connector procedure. Do not invent an endpoint from a shortened domain name or copy another tenant's settings.
Do not confuse Direct Send with external relay
Direct Send does not provide delivery to recipients outside the cloud-based organisation. Microsoft's guidance treats it as an option for advanced customers with relevant mail-server responsibilities and suitable limitations.
In a synthetic example, a scanner sends successfully to an employee but fails when the workflow adds a customer's external address. That symptom is consistent with a route whose recipient scope does not include external relay.
Adding an SPF include cannot change that recipient scope. Reassess the route and application requirements before editing unrelated records.
Verify identity after the selected route
References: RFC 9989 §4.4.
Once the supported route is configured, inspect received messages from the actual application. Record the visible From, evaluated SPF identity, relevant DKIM signatures and trusted DMARC outcome.
A connector's acceptance of a connection and a recipient's aligned authentication result establish different things. An outbound gateway or additional relay may also affect the final result.
Use the Microsoft 365 authentication guide for the domain's setup, and alignment diagnosis for a raw-pass mismatch.
Retain a route-specific acceptance record
Keep the chosen method, hosting model, trust mechanism, recipient scope, owner and representative results. Include the exact provider instructions and configuration date so later administrators can identify changed requirements.
Record authentication and delivery failures separately. A rejected connection, an unsupported recipient route and a received message that fails alignment can require different corrections.
The complete result is a supported application route with accountable trust and verified messages, not merely a valid TXT record or a successful internal test.