A domain authentication policy does not authorize an application to use your mail relay. Relay authorization controls who can submit mail and where it can go; SPF, DKIM and DMARC help receivers evaluate the resulting message identities. Both are needed. A route that signs beautifully but accepts arbitrary senders is still an operational and abuse risk.
Select a supported route
Record the application, tenant, submission endpoint, authentication method, intended From identity and recipient classes. Microsoft distinguishes client SMTP submission, connector-authenticated SMTP relay and Direct Send. Its documented Direct Send route does not relay to internet recipients through Microsoft 365, while supported SMTP relay can. These are product-specific distinctions, not universal SMTP terminology. Microsoft application email guidance.
Choose the current supported method for the actual workload. Avoid copying an old device configuration into a different tenant or treating an IP allow condition as permanent proof of application identity. Record who owns credentials, certificates, network restrictions and connector changes. Do not disclose secrets in the test evidence or expand persistent access merely to simplify troubleshooting.
Separate submission from final authentication
The SMTP transaction shows which stage accepted or refused a command. A rejection at RCPT TO differs from a failure after message data, and a final successful DATA response means the receiver accepted responsibility for the message rather than proving inbox placement. RFC 5321. Preserve the complete reply code, enhanced code where present, text and timestamp instead of reducing every failure to blocked.
Then inspect an authorized received message for its actual envelope and signing domains. A relay can rewrite an identity or apply a signature that changes the alignment result. SPF evaluates the relevant connecting route, not the user's belief that a sender belongs to the company. Do not assume a submission success is a DMARC pass or that a pass is evidence of recipient consent.
Compare three hypothetical stage outcomes
Use a written acceptance ledger with three independent cases: an unapproved external-recipient request is expected to be denied at RCPT TO; an approved external route is expected to reach an accepted final DATA response; and an approved internal route is checked separately. Illustrative replies might be 550 5.7.1 at recipient refusal, or 250 at RCPT TO, 354 for DATA and 250 after the final dot on an accepted transaction. These are hypothetical reply sequences, not captured loopback or Microsoft transcripts.
A client’s EHLO name is not proof of authorization. Real relay permissions must use the supported authentication and connector controls for that deployment. No credential validation, connector lookup, local socket, TLS session or provider send was executed here. Record actual response codes and context in a future authorized test rather than treating these expected examples as observed results.
Test both allowed and denied cases
For an approved deployment, use controlled recipients to test the intended internal and external paths. Include an explicitly authorized negative test from a client that should not relay, without probing unrelated systems. Retain sanitized transcripts and provider logs while keeping original evidence under access control. Confirm that denial occurs where expected and cannot be bypassed through an alternate application route.
Check throttling, queue behavior and retry ownership before a critical workflow depends on the relay. A transient refusal should not cause a rapid retry storm, while a permanent configuration failure needs an accountable repair. Document fallback requirements without authorizing an unrestricted bypass.
Close the change with separate results for relay access, supported recipient scope, final message authentication and application success. Mark missing observations as unresolved. This prevents a team from declaring the application working merely because DNS looks correct or one SMTP command returned a successful code.
Source and execution boundary
RFC 9989 Sections 4.4, 5.3.5 and 5.4 distinguish authentication, alignment and handling; a pass does not endorse message content. The operational decisions here are scoped recommendations and explicitly hypothetical examples, not new tests of a customer, provider or historical fixture. Any real change requires its own authorized scope, retained evidence and accountable decision.