SMTP Relay real world scenarios, the following eight scenarios cover the most common real-world situations administrators face. Each uses a different relay method or combination.
SMTP Relay Real World Scenarios
Below is 8 SMTP relay real world scenarios with step by steps solutions.
Table of Contents
SCENARIO 1 — Multifunction Printer — Scan to Email (Internal + External)
Situation: The firm’s Ricoh printer must scan documents to both internal lawyers and external clients. The printer does not support OAuth 2.0. Static public IP: 203.0.113.20.
Chosen Method: SMTP Relay with Inbound Connector (IP-based)
Why connector relay and not Direct Send? Because they need to reach external clients. Direct Send only delivers to internal M365 mailboxes. Connector relay allows full external delivery without requiring any authentication credentials on the printer.
Setup Steps
1.Configure the Printer: SMTP Server: contoso-legal-com.mail.protection.outlook.com | Port: 25 | Auth: None | TLS: STARTTLS
2.Update SPF Record in DNS: v=spf1 ip4:203.0.113.20 include:spf.protection.outlook.com ~all
3.Test: Send a scan to an external client. Verify in EAC → Mail flow → Message trace. Confirm connector name ‘Ricoh-MFP-Relay’ appears.
SCENARIO 2 — Monitoring Application — Alerting System (Internal Only)
Situation: A Linux-based Nagios server monitors 400 servers and must send alert emails to the internal IT team only. Dynamic IP — connector relay impossible.
Chosen Method: Direct Send
Why Direct Send? All recipients are internal M365 mailboxes. Dynamic public IP makes IP-based connector relay impossible. Direct Send requires no authentication and no static IP — perfect match.
Setup Steps
1.Find the MX Endpoint: M365 Admin Center → Settings → Domains → select domain → copy MX record
2.Configure Nagios SMTP: smtp_host=fabrikam-retail-com.mail.protection.outlook.com | smtp_port=25 | From: monitoring@fabrikam-retail.com
3.Update SPF (Recommended): Add monitoring server’s public IP to SPF. If IP changes frequently, use -all (softfail) rather than ~all.
WARNING Direct Send is being targeted by Microsoft for potential restriction due to spoofing abuse. Ensure DMARC p=quarantine is set for your domain.
SCENARIO 3 — ERP Application — SAP Invoice Emails (External)
Situation: SAP S/4HANA Cloud needs to send invoices to external suppliers. SAP supports OAuth 2.0 for SMTP. Dedicated shared mailbox: invoices@northwind-mfg.com.
Chosen Method: SMTP AUTH with OAuth 2.0 (Client Submission)
Why SMTP AUTH and not connector relay? SAP S/4HANA Cloud has a dynamic IP that changes with cloud infrastructure. SAP supports modern OAuth 2.0 SMTP authentication — the most secure and future-proof option.
Setup Steps
1.Create Shared Mailbox & Assign License
M365 Admin Center → Teams & Groups → Shared Mailboxes → Add: invoices@northwind-mfg.com. Assign Exchange Online Plan 1 license.
2.Enable SMTP AUTH on the Mailbox
Set-CASMailbox -Identity invoices@northwind-mfg.com -SmtpClientAuthenticationDisabled $false 3.Register App in Microsoft Entra ID
Entra Admin Center → App registrations → New registration → Name: SAP-Invoice-Relay. API Permissions → Office 365 Exchange Online → Application permissions → SMTP.Send. Grant admin consent.
4.Create Client Secret
Certificates & secrets → New client secret → Copy value immediately (shown only once). Note: Tenant ID, Application (Client) ID, and Client Secret.
5.Configure SAP SMTP Settings
SMTP Server: smtp.office365.com | Port: 587 | Encryption: STARTTLS | Auth: OAuth 2.0 | Enter Tenant ID, Client ID, Secret.
6.Verify Sending Limits
SMTP AUTH allows up to 10,000 recipients/day per mailbox. If volume exceeds this, consider Azure Communication Services Email.
SCENARIO 4 — Hybrid Environment — On-Premises App to External Recipients
Situation: A legacy .NET billing application on-premises (server IP 10.80.5.10, public IP 198.51.100.30) cannot support OAuth 2.0 but must email invoices to external customers.
Chosen Method: On-Premises Exchange as Smart Host → Exchange Online Connector
The app relays through the on-premises Exchange server (which already has a hybrid Send Connector to Exchange Online). This avoids modifying the app and keeps authentication at the infrastructure level.
1.Configure App to Use On-Prem Exchange
In the .NET app config, set SMTP host to on-prem Exchange server FQDN (e.g., exserver01.tailspin.local) on port 25. No auth needed on internal network.
2.Allow Relay on Exchange Receive Connector
On EX01, create an anonymous relay receive connector scoped to the app server’s IP (10.80.5.10). Grant ms-Exch-SMTP-Accept-Any-Recipient permission.
3.Verify Hybrid Send Connector
Confirm the Hybrid Send Connector on EX01 routes to Exchange Online via *.mail.protection.outlook.com on port 25 with TLS. Configured by the Hybrid Configuration Wizard.
4.Test End-to-End
Send a test invoice from the app → verify on-prem Exchange queues/delivers → check Exchange Online Message Trace to confirm outbound delivery.
SCENARIO 5 — Healthcare — Connector-Based Relay for Lab Results
Situation: A patient management system generates automated lab result notifications. Static IP: 198.51.100.75. Must email lab results to both staff (@hospital.com) and external referring doctors (@clinic.com). No modern auth support.
Chosen Method: SMTP Relay with Inbound Connector (IP-based, TLS required for HIPAA)
New-InboundConnector -Name 'Lab-Results-Relay' -ConnectorType OnPremises -SenderDomains 'hospital.com' -SenderIPAddresses '198.51.100.75' -RestrictDomainsToIPAddresses $true -RequireTls $true ` -TlsSenderCertificateName '*'1.Verify Port 25 Outbound
Run: Test-NetConnection -ComputerName hospital-com.mail.protection.outlook.com -Port 25. Confirm TcpTestSucceeded = True.
2.Create the Inbound Connector
EAC → Mail flow → Connectors → Add. Name: Lab-Results-Relay. Auth by IP (198.51.100.75). Enable Reject messages not sent over TLS (HIPAA compliance).
3.Configure Application
SMTP Host: hospital-com.mail.protection.outlook.com | Port: 25 | TLS: STARTTLS | Auth: None | From: labresults@hospital.com
4.Test and Validate
Send test emails to internal (drsmith@hospital.com) and external (dr.jones@clinic.com). Check Message Trace. Verify connector name ‘Lab-Results-Relay’ appears and TLS is confirmed.
SCENARIO 6 — WordPress / Web Application — Contact Form Email
Situation: WordPress site uses Contact Form 7. Submissions sent from noreply@adventure-works.com. Host has dynamic IPs — connector relay not an option.
Chosen Method: SMTP AUTH with OAuth 2.0 via WP Mail SMTP Plugin
1.Create Shared Mailbox & Enable SMTP AUTH
Create noreply@adventure-works.com. Assign Exchange Online Plan 1. Run: Set-CASMailbox -Identity noreply@adventure-works.com -SmtpClientAuthenticationDisabled $false
2.Register App in Entra ID
App registrations → New → Name: WordPress-SMTP. API Permissions → Office 365 Exchange Online → Delegated → SMTP.Send. Grant admin consent. Add Redirect URI for WP Mail SMTP OAuth flow.
3.Configure WP Mail SMTP Plugin
Install WP Mail SMTP → Settings → Microsoft 365/Outlook connector → Enter Client ID, Client Secret, Tenant ID. Complete OAuth flow. From Email: noreply@adventure-works.com.
4.Test
Send test email from WP Mail SMTP settings. Verify delivery and DKIM signing.
RESULT Contact form submissions send as noreply@adventure-works.com via authenticated SMTP AUTH. DKIM signing applied. Messages appear in Sent Items for audit purposes.
SCENARIO 7 — Python Script — Automated Report Emails with OAuth 2.0
Situation: A Python script runs nightly, generates a server health report, and emails it to internal and external board members. Migrating from Basic Auth to OAuth 2.0.
Chosen Method: SMTP AUTH with OAuth 2.0 (Client Credentials Flow)
1.Register App & Enable SMTP AUTH
Register ‘Python-Report-Sender’ in Entra ID. Grant Office 365 Exchange Online → Application permissions → SMTP.Send. Admin consent. Note Tenant ID, Client ID, Secret.
2.Enable SMTP AUTH on Mailbox
Set-CASMailbox -Identity it-reports@contoso.com -SmtpClientAuthenticationDisabled $falsePython Script (msal + smtplib)
import msal, smtplib, base64 app = msal.ConfidentialClientApplication( client_id='YOUR_CLIENT_ID', client_credential='YOUR_CLIENT_SECRET', authority='https://login.microsoftonline.com/YOUR_TENANT_ID') result = app.acquire_token_for_client(scopes=['https://outlook.office365.com/.default']) access_token = result['access_token'] sender = 'it-reports@contoso.com' auth_str = f'user={sender}\x01auth=Bearer {access_token}\x01\x01' auth_b64 = base64.b64encode(auth_str.encode()).decode() with smtplib.SMTP('smtp.office365.com', 587) as smtp: smtp.starttls() smtp.docmd('AUTH', 'XOAUTH2 ' + auth_b64) smtp.sendmail(sender, ['director@contoso.com'], msg.as_string())RESULT Fully OAuth 2.0 authenticated. No credentials stored in plain text. Future-proof beyond April 2026.
SCENARIO 8 — Legacy CRM — Cannot Support OAuth (Migration Path)
Situation: Legacy CRM sends booking confirmations via SMTP AUTH Basic Auth. April 2026 deadline approaching. Vendor cannot update to OAuth 2.0 for at least 12 months.
Method: Migration to SMTP Connector Relay (IP-based) — No Code Change Need
When an application cannot support OAuth 2.0, switch from SMTP AUTH to Connector-based SMTP Relay. The application still connects with NO credentials — Exchange Online authenticates by IP instead. No application code change needed.
1.Assign Static Public IP
Confirm CRM server has or can be assigned a static public IP. Work with ISP. Example: 185.76.10.20.
2.Create Inbound Connector
New-InboundConnector -Name ‘Legacy-CRM-Relay’ -ConnectorType OnPremises -SenderDomains ‘bluesky.com’ -SenderIPAddresses ‘185.76.10.20’ -RestrictDomainsToIPAddresses $true -RequireTls $true
3.Change CRM SMTP Configuration (2 changes only)
SMTP Host: change from smtp.office365.com → bluesky-com.mail.protection.outlook.com | Port: change from 587 → 25 | Authentication: remove username/password → None
4.Update SPF and Test
Add 185.76.10.20 to SPF record. Test by sending a booking confirmation to internal staff and an external Gmail address.
5.Disable SMTP AUTH on the Old Mailbox
Set-CASMailbox -Identity crm-sender@bluesky.com -SmtpClientAuthenticationDisabled $trueRESULT Zero application code changes. CRM continues sending to internal and external recipients. No longer affected by the April 2026 Basic Auth deprecation.
NOTE: Long-term recommendation: when the vendor releases OAuth 2.0 support, migrate back to SMTP AUTH with OAuth 2.0 for stronger identity-based authentication and better audit logging
SMTP Relay Office 365: Ultimate Expert Guide to Secure & Powerful Email Delivery
Microsoft 365 E3 vs E5: Ultimate Expert Guide to Features, Pricing & Which One to Choose
Microsoft 365 E1 vs E3 vs E5 — Expert Guide to Choosing the Right Plan
