SMTP Relay Connector Setup: Secure Routing, Testing, and Troubleshooting

SMTP relay connector setup is what you need when an application, printer, scanner, on-premises server, or inbound email gateway can create messages but cannot reliably deliver them to recipients on its own. The goal is not merely to make SMTP work: it is to establish a narrow, authenticated route that sends legitimate mail while preventing anyone else from using your infrastructure to send spam.

What an SMTP relay connector actually does

SMTP is the Internet protocol used to transfer email between mail systems. In a relay flow, one SMTP-capable system accepts a message from a trusted sender and forwards it to the next mail system, which may ultimately deliver it to the recipient mailbox. SMTP itself defines the transport conversation—commands such as EHLO, MAIL FROM, RCPT TO, and DATA—but it does not automatically make a sender trustworthy. (rfc-editor.org)

An SMTP relay connector is the policy and routing configuration that answers four operational questions:

1. Who may connect? For example, a static public IP address, a private network host, an SMTP client certificate, or authenticated credentials.
2. Where can they send? Internal recipients only, approved domains, or the public Internet.
3. Where does mail go next? A cloud email provider, a smart host, an on-premises Exchange server, or a security gateway.
4. What security rules apply? TLS, sender-domain controls, spam filtering, rate limits, and logging.

The phrase can mean slightly different things depending on the product. In Microsoft 365, SMTP relay for a device or application is authorized by an inbound connector that recognizes the sending infrastructure by certificate or static IP address. In Exchange Server, a Receive connector decides which remote hosts may open an SMTP connection and what permissions apply. In AWS SES Mail Manager, an SMTP relay is a destination resource used by a rule action to forward inbound email to another SMTP server. (learn.microsoft.com)

That distinction matters. Do not copy a configuration from a Google Workspace guide into Microsoft 365, or configure an Exchange Receive connector when your actual requirement is an outbound connector from Exchange Online to a partner. The words are similar, but the trust boundary, authentication method, and user interface differ.

When you need an SMTP relay connector—and when you do not

A connector is useful when the sender is not a normal interactive mailbox client. Common examples include:

• A multifunction printer that emails scans to employees or customers.
• A web application sending password resets, receipts, invoices, or error alerts.
• An ERP, CRM, monitoring platform, or backup appliance sending notifications.
• An on-premises mail server that must relay outbound mail through Microsoft 365.
• A mail security or archival gateway that must pass mail to another mail environment.
• A hybrid email environment where some mailboxes remain on servers you manage.

For normal person-to-person email in Exchange Online, connectors are not generally necessary: Microsoft 365 is designed to send and receive Internet mail without them. Connectors are for specific routing, security, partner, on-premises, and device/application relay scenarios. (learn.microsoft.com)

Use SMTP relay when the sender cannot safely act like a mailbox

SMTP relay is usually a sound choice when a device cannot use OAuth, cannot store a user credential safely, or needs to send from multiple approved addresses without tying every message to one person’s mailbox. A scanner is the classic example: it needs to submit a scan notification, not sign in as a human employee.

Relay is also appropriate when an application needs a central policy point. Instead of letting each system contact the public Internet directly, you can require every system to pass through one controlled route. That central route can apply encryption, sender rules, content filtering, audit logging, and rate limits.

Use authenticated SMTP submission when a real mailbox identity is available

Client SMTP submission—often called SMTP AUTH—uses a mailbox identity and is commonly associated with port 587. Microsoft documents SMTP AUTH as an authenticated client-submission method that supports OAuth as well as basic authentication, depending on the configuration and client capability. (learn.microsoft.com)

This can be simpler for one application that sends as one licensed or otherwise authorized mailbox. It is a weaker fit for a fleet of unmanaged devices because credentials can be copied, expire, or be left behind in old device settings. If you choose this path, use OAuth where the provider and application support it, restrict the account’s permissions, and do not reuse an administrator account.

Do not use direct send for external recipients

“Direct Send” in Microsoft 365 terminology means a device sends directly to your tenant’s MX endpoint without SMTP authentication. It is designed for mail to recipients in your own Microsoft 365 organization, not as a general solution for external delivery. Microsoft’s comparison explicitly shows that Direct Send cannot relay to the Internet through Microsoft 365, while SMTP relay can. (learn.microsoft.com)

If your printer only emails @yourcompany.com addresses, Direct Send may be adequate in a Microsoft-specific deployment. If it must send scans to customers, vendors, or personal addresses, plan for a properly authenticated relay method instead.

The architecture: sender, connector, relay, recipient

Before touching an admin console, draw the path one message will take. A simple model looks like this:

Application or device
        |
        | SMTP connection: IP allowlist, client certificate, or credentials
        v
SMTP relay / email platform
        |
        | policy checks, TLS, sender validation, message filtering
        v
Recipient mail system
        |
        v
Recipient mailbox

For a Microsoft 365 relay connector, the device or application is typically the SMTP client, and Exchange Online is the relay. The connector establishes why Exchange Online should trust the connecting system. For an on-premises Exchange Server relay, the application connects to a restricted Receive connector, and Exchange routes accepted messages through a configured Send connector or smart host. For AWS SES Mail Manager, inbound mail first reaches an ingress endpoint, matches a rule, then a relay action forwards it to the chosen SMTP destination. (learn.microsoft.com)

The envelope sender and visible From address are not the same field

Many delivery failures come from treating these values as interchangeable.

• Envelope sender: supplied in SMTP as MAIL FROM:<bounce@example.com>. It is used for bounces and is often called the return path or 5321.MailFrom.
• Header From address: the human-visible From: header, such as Invoices <billing@example.com>. It is often called the 5322.From.

A message can show From: billing@example.com while using a different envelope sender. That is normal in some delivery architectures, but it must be deliberate. Microsoft 365 relay requirements use the accepted-domain status of the domain in the SMTP certificate or the MAIL FROM address, plus a connector match for the source IP or certificate domain. A relay attempt that does not satisfy those conditions can be rejected. (learn.microsoft.com)

For practical setup, choose an envelope-sender domain you control, have verified in the relay platform, and authenticate with SPF and DKIM where your provider supports those mechanisms. Do not invent a sender domain for a vendor, customer, or free-mail provider.

Prerequisites to collect before setup

Most failed SMTP relay connector projects fail before configuration because the team has not identified the exact sender, network path, and sender domains. Gather this information first.

Sender inventory

For every app, appliance, or server that will send through the relay, record:

A public IP allowlist is only reliable if the sender exits through a static public IP address. If an ISP changes the address, a container platform uses changing egress addresses, or several companies share the same NAT address, IP-based connector authentication becomes unreliable or unsafe. Microsoft specifically calls for a certificate or a static public IP address for its SMTP relay scenario and warns that the static address must not be shared with another organization. (learn.microsoft.com)

DNS and identity checks

Confirm these items before enabling production traffic:

• The sender domain is verified or accepted by the email provider.
• The application’s MAIL FROM domain is one you own and have configured intentionally.
• SPF reflects all authorized sending services for the domain.
• DKIM signing is enabled for the platform that performs the final send, where available.
• DMARC is monitored and aligned with the way mail is sent.

DMARC tells receiving mail systems what to do when messages claiming to be from your domain do not pass SPF or DKIM authentication. Its policy can request delivery, quarantine, or rejection. Google’s DMARC guidance recommends establishing SPF and/or DKIM before enabling DMARC enforcement and using reports to find authentication problems. (support.google.com)

An SPF record is a DNS TXT record. The exact include mechanism is provider-specific, so do not blindly paste a second SPF TXT record alongside an existing one. A domain should have one SPF record; consolidate authorized sending mechanisms into that record according to your mail provider’s documentation.

Network prerequisites

Verify outbound connectivity from the actual sender—not your laptop—to the intended relay hostname and port. A common surprise is that cloud networks restrict TCP port 25. Microsoft documents that Azure blocks outbound SMTP connections on port 25 for many VM subscription types and recommends authenticated relay services on port 587 where applicable. (learn.microsoft.com)

This creates a key vendor-specific difference:

• Microsoft 365 connector-based SMTP relay requires TCP port 25.
• Microsoft 365 authenticated SMTP submission is typically on TCP port 587.
• Google Workspace SMTP relay supports ports 25, 465, and 587; the exact TLS mode must match the device and Google Workspace configuration.

Never assume port 587 is a universal replacement for port 25. It is frequently used for authenticated client submission, but each provider defines its own relay requirements. (support.google.com)

How to set up a Microsoft 365 SMTP relay connector

The following is a practical workflow for Microsoft 365 / Exchange Online when an on-premises application or device needs to send to internal and external recipients through Microsoft 365. It is not the setup for smtp.office365.com SMTP AUTH; this is connector-based SMTP relay.

1. Choose certificate-based or IP-based trust

Use a certificate if your sending mail server supports SMTP TLS with a certificate whose subject or subject alternative name is stable and matches the connector configuration. Certificates can be a strong choice for a managed mail server.

Use an IP address if the sender is a printer, legacy app, or other system that cannot present a suitable certificate. The IP must be the public IP address Microsoft sees after NAT, not merely the device’s private address. Keep the allowlist as small as possible—ideally one dedicated egress IP.

2. Create the connector in Exchange admin center

In the Exchange admin center, go to Mail flow and then Connectors, then create a connector for mail coming from your organization’s email server to Microsoft 365. Microsoft describes connectors as instruction sets that customize mail flow, including relaying messages from devices, applications, and other non-mailbox entities through Microsoft 365. (learn.microsoft.com)

In the connector wizard:

1. Give the connector an operational name, such as SMTP Relay - Warehouse Apps - 198.51.100.42.
2. Select the authentication method that matches your design: sender IP address or TLS certificate.
3. Add only the approved static public IP address or the exact certificate domain.
4. Save the connector, but do not treat “created” as “working.” It must be validated and enabled.

Avoid broad ranges such as an entire office subnet after NAT unless every machine using that address range is governed and monitored. A connector that trusts too many systems can become a path for unauthorized relay.

3. Configure the device or application

Use the MX endpoint for one of your accepted Microsoft 365 domains as the SMTP smart host. It normally has a form resembling:

yourdomain-com.mail.protection.outlook.com

Do not substitute smtp.office365.com for this connector-based relay method. That hostname is associated with authenticated client submission, whereas Microsoft 365 SMTP relay uses your MX endpoint and port 25. (learn.microsoft.com)

A representative device configuration looks like this:

SMTP server / smart host: yourdomain-com.mail.protection.outlook.com
Port:                    25
SMTP authentication:     Off (connector/IP or certificate authenticates the connection)
TLS / STARTTLS:          Enable if supported by the sending system
From address:            scanner@alerts.example.com
Envelope sender:         scanner@alerts.example.com

The exact labels vary by device. Some printers call the field “SMTP server,” some call it “outgoing mail server,” and some expose only a “Use SSL” switch rather than an explicit STARTTLS choice. Consult the device documentation before choosing encryption mode. STARTTLS is an SMTP extension for negotiating TLS after the SMTP session begins. (rfc-editor.org)

4. Use an accepted envelope-sender domain

Ensure that alerts.example.com or example.com is an accepted domain in Microsoft 365 and that it appears in the SMTP certificate or MAIL FROM address as required by the relay rules. Since November 1, 2023, Exchange Online no longer requires the visible From: header domain to be the matching accepted domain for this relay scenario, but the certificate or envelope sender and connector identity still matter. (learn.microsoft.com)

This is particularly important for software that uses a default envelope sender such as noreply@vendor.invalid, root@localhost, or a cloud-provider domain. Change it before production use. A visible From address that looks correct does not rescue a relay request with an invalid envelope-sender configuration.

5. Validate, enable, and monitor

Microsoft’s connector validation process is designed to test a connector before it is turned on. In the connector screen, use the validation option where available, provide an active mailbox address in the relevant environment, and turn the connector on after validation succeeds. (learn.microsoft.com)

Then send two live tests from the actual device:

1. One to an internal mailbox in your organization.
2. One to an external mailbox at a different provider.

This dual test is essential. A configuration can appear healthy because internal mail arrives, while external relay is still rejected or filtered.

Worked example: relay scan alerts through Google Workspace

Consider a small company with a network scanner at private IP 10.20.4.18. Its firewall translates outbound traffic to static public IP 198.51.100.42. The company uses Google Workspace for example.com, and the scanner must send scan links to employees and external accountants.

Step 1: define the intended identity

Use these values:

Visible From:       Operations Scanner <scanner@example.com>
Envelope sender:    scanner@example.com
Approved egress IP: 198.51.100.42
Recipients:         Internal and external

The scanner should not use an employee’s personal mailbox password. Its identity is operational, clear in logs, and easy to retire if the device is replaced.

Step 2: create the Workspace SMTP relay rule

In the Google Admin console, configure the SMTP relay service for the organizational unit that contains the relevant users or devices. Google documents its SMTP relay service as the recommended option for devices and applications, using IP-address authentication so they can send to recipients inside or outside the organization. (support.google.com)

Configure the rule to:

• Allow only the static public IP address 198.51.100.42.
• Require a secure connection when the scanner supports it.
• Allow only senders from your domain, such as @example.com.
• Permit external recipients only because this scanner has that real business need.

The exact option names can change in Google Workspace, so treat the security intent—not a screenshot—as the durable configuration: identify the source narrowly, restrict allowed sender domains, and permit only the necessary recipient scope.

Step 3: configure the scanner

On the scanner’s SMTP settings page, enter:

SMTP host:           smtp-relay.gmail.com
Port:                587
Encryption:          STARTTLS / TLS, if supported by the device
Authentication:      Match the Workspace relay rule; use IP authentication for this example
From address:        scanner@example.com

Google Workspace lists smtp-relay.gmail.com as the SMTP relay hostname and supports ports 25, 465, and 587. Select the combination that matches the device’s TLS implementation and the Workspace relay rule; do not enable a TLS mode the device cannot negotiate. (support.google.com)

Step 4: test and inspect headers

Send a message to an external test mailbox. Confirm all of the following:

• The scanner shows an SMTP success response rather than simply returning to its home screen.
• The test message arrives in Inbox rather than Spam.
• The visible From address is scanner@example.com.
• The recipient can reply if replies are intended to be monitored.
• The received message headers show the expected relay path.
• SPF, DKIM, and DMARC results are not failing for the domain.

Google Workspace documents a relay limit of up to 10,000 recipients per user per day for its SMTP relay service. That is not a capacity target for a scanner; it is a reason to monitor message volume and investigate a sudden spike, which can indicate a misconfigured application or compromise. (support.google.com)

Security rules that prevent an open relay

An open relay accepts email from untrusted Internet senders and forwards it onward. It can be abused for spam, phishing, and reputation attacks. The fundamental rule is simple: authenticate the connecting system and authorize only the mail it is supposed to send.

Apply these controls:

• Allowlist explicit sources. Use one static public IP, a tightly scoped private range, or a verified client certificate—not 0.0.0.0/0 and not a broad office range by default.
• Restrict sender domains. Permit @example.com, not arbitrary envelope senders.
• Restrict recipient scope. If a system only sends internal alerts, do not grant external relay.
• Require TLS where supported. TLS protects the SMTP connection between the sender and relay; it does not replace authentication or domain alignment.
• Use least privilege. Give a printer only printer-relay access. Do not use a global admin account or a universal connector for every application.
• Log every relay. Keep enough detail to identify the source IP, envelope sender, recipient, SMTP response, and message ID.
• Alert on anomalies. Unexpected recipient domains, a flood of recipients, repeated authentication failures, or new sender addresses deserve review.

For an on-premises Exchange Server, create a dedicated Receive connector for relay rather than modifying the broad default connector. Microsoft’s guidance for anonymous relay uses a custom Front End Transport Receive connector on TCP 25 with specified remote IP addresses; the most specific remote-IP match takes precedence. (learn.microsoft.com)

Do not grant anonymous relay rights on a connector exposed to arbitrary sources. Restrict the device IPs first, then assign only the permissions needed for those devices to relay.

SMTP relay connector troubleshooting: what fails and why

Connection timeout or cannot reach server

Likely causes: firewall egress rules, incorrect hostname, blocked port 25, DNS failure, or a cloud provider restriction.

How to diagnose: From the same network as the application, test DNS resolution and TCP connectivity to the relay host and selected port. Confirm that the public egress IP matches the IP configured in the connector. If the sender is in Azure or another cloud environment, explicitly verify its SMTP egress policy instead of assuming port 25 is open. (learn.microsoft.com)

Fix: Open the correct outbound rule, use the provider-supported port and relay mode, or move to an authenticated relay service appropriate for that environment.

“Unable to relay,” 5.7.x rejection, or access denied

Likely causes: the source IP is not on the allowlist, the source is using a different NAT address, the certificate does not match, or the envelope sender uses an unaccepted domain.

How to diagnose: Compare the connector’s authorized IP or certificate name with the relay logs. Check the actual MAIL FROM value sent by the application—not only the visible From address. In Exchange Online relay, the connector identity and accepted-domain conditions must both be met. (learn.microsoft.com)

Fix: Correct the NAT/allowlist, configure a valid client certificate, or set the software’s envelope sender to an accepted and authenticated domain.

TLS handshake failure

Likely causes: the sender expects implicit TLS but the server expects STARTTLS, the device has an old TLS stack, a certificate-chain issue, or a middlebox is interfering with the connection.

How to diagnose: Read the server and client logs for the precise handshake error. Check whether the vendor calls the setting SSL, TLS, STARTTLS, or “secure connection”—those labels are not always used consistently by old devices.

Fix: Match the provider’s documented port and encryption mode. Update the device firmware if possible. If the legacy device cannot support a secure, supported configuration, place a managed internal SMTP relay in front of it rather than weakening the Internet-facing relay policy.

Internal mail works, external mail does not

Likely causes: you configured internal-only routing, used Microsoft Direct Send instead of SMTP relay, sender-domain authentication is failing, or the relay service blocks external recipients by policy.

How to diagnose: Test one internal and one external recipient, inspect the SMTP response and delivery logs, and check the message headers at the external mailbox.

Fix: Use a relay method that explicitly supports external recipients, authorize that recipient scope, and fix SPF/DKIM/DMARC alignment where authentication results show failure.

Message is accepted but lands in spam

Likely causes: weak domain authentication, a misleading From address, a new or poor sending reputation, content that resembles phishing, or a mismatch between the visible sender and the authenticated sending service.

Fix: Make the sender recognizable, authenticate the sending domain, use a consistent envelope sender, avoid sudden high-volume bursts, and inspect recipient-side headers. Before testing a customer address, you can use an email address verification tool to catch malformed or non-deliverable test recipients, but address validation does not prove inbox placement.

Choosing among SMTP relay, an email API, and a local relay server

SMTP relay is often the fastest option because most business software already supports SMTP. But it is not always the best architecture.

SMTP relay

Choose SMTP relay when you must support printers, scanners, legacy software, monitoring appliances, or third-party systems with only SMTP fields. It is interoperable and works without changing application code.

The downside is limited application-level observability. Some devices offer little more than a generic “send failed” screen, and credential or IP management can be awkward at scale.

Email API

Choose an email API for software you control, especially transactional product email. APIs can provide structured authentication, message identifiers, templates, webhooks, idempotency patterns, and granular event data that legacy SMTP often cannot provide.

Use the SMTP path when compatibility is the priority; use the API path when your engineering team needs reliable product-email workflows and detailed delivery telemetry. Review the provider’s email API reference and setup guides before changing a production application’s delivery method.

Local SMTP relay or gateway

A local relay is useful when many legacy devices share a site or private network. Devices submit to a managed internal host; that host enforces policy, negotiates modern TLS upstream, queues mail during transient outages, and connects to the external relay provider using one controlled identity.

This reduces the number of systems exposed to external mail configuration. It does add infrastructure to patch, monitor, back up, and secure. Treat it as a mail server, not as a disposable utility VM.

How to know the connector is working

A green status in an admin console is not the full definition of success. A working SMTP relay connector has evidence across the connection, policy, delivery, and security layers.

Use this acceptance checklist:

1. Connection succeeds from every approved sender and fails from an unapproved test host.
2. Sender restrictions work: an approved sender domain is accepted and a deliberately unauthorized sender is rejected.
3. Recipient restrictions work: if the connector is internal-only, an external test is denied; if external delivery is intended, the external test is accepted.
4. TLS behaves as designed: logs show encryption where required, and insecure fallback is not silently accepted when policy forbids it.
5. Internal and external messages arrive with the correct visible From name, address, and reply behavior.
6. Authentication results are healthy in received headers: SPF/DKIM/DMARC should align with the sending design.
7. Logs are traceable: you can map a message from application event to SMTP response to provider trace to recipient mailbox.
8. Failure handling is tested: a deliberately invalid recipient creates a visible bounce or application error rather than disappearing silently.

Document the connector owner, source systems, approved IPs or certificate names, sender domains, recipient scope, and renewal/review date. The most dangerous SMTP relay connectors are not necessarily the ones configured incorrectly on day one; they are the ones nobody revisits after networks, vendors, certificates, or applications change.

FAQ

What is the difference between an SMTP relay and an SMTP connector?

SMTP relay is the act of forwarding email through another mail system. A connector is the configuration that controls a mail-flow relationship: who may connect, how they are authenticated, where mail is routed, and what restrictions apply. Different products use different connector names and models.

Which port should an SMTP relay connector use?

Use the port required by the specific service and method. Microsoft 365 connector-based SMTP relay requires port 25, while Microsoft SMTP AUTH is typically port 587. Google Workspace SMTP relay supports 25, 465, and 587. Match the port with the required encryption and authentication mode; do not select a port based on convention alone. (learn.microsoft.com)

Can I use an SMTP relay connector to send as any address?

You should not. Restrict the connector to sender domains and addresses your organization owns and has authorized. The envelope sender must meet your provider’s relay conditions, and the visible From address should be recognizable and aligned with domain-authentication policy.

Do I need SPF, DKIM, and DMARC for SMTP relay?

You need a domain-authentication plan if the relay sends mail externally as your domain. SPF and DKIM help receivers authenticate mail, while DMARC tells them what to do when authentication does not pass. Start with monitoring and correct alignment before moving to a strict DMARC policy. (support.google.com)

Why does my scanner send internally but not to Gmail or customer domains?

You may be using an internal-only method such as Direct Send, your relay policy may block external recipients, or the sending domain may fail authentication. Test both recipient types, inspect the SMTP response, and review received message headers to identify whether the failure occurred at relay authorization, routing, or recipient filtering.