Last resort: a connector to Exchange Online

This is the last resort, for an app that cannot send through a Microsoft 365 mailbox. Try connecting a mailbox first. A connector is Microsoft's SMTP relay: you create an inbound connector in Exchange Online and the app hands its mail straight to your tenant. Microsoft restricts it so tightly that, for a CRM that sends from its vendor's servers, it is usually not available at all.

Read Microsoft's warnings first

• Not for a service hosted by someone else. Microsoft says: "You can't use SMTP relay to send email from a third-party hosted service (for example, Microsoft Azure) through Microsoft 365 or Office 365." Its comparison table lists "Supports mail sent from applications hosted by a third party" as No for SMTP relay and Yes for SMTP sign-in.
• A service run by someone else must have a certificate of your own. Microsoft says such a service "must support the following requirements: A unique certificate for your organization. The certificate domain must be an accepted domain in your organization." Its examples are "You use a signature service to add signatures or disclaimers to all outbound messages." and "You use a CRM service to send email on behalf of your organization to internal and external recipients." Microsoft: updated requirements for SMTP relay
• An address shared with other customers is a mistake. In its message MC1226222, Microsoft names as one of two "anti-patterns": "When a tenant has an Inbound connector of type OnPremises and the connector does IP-based authentication, but the IP is used by other tenants On-Premises servers to connect to Exchange Online." A CRM's sending addresses are usually shared by all its customers. Microsoft adds: "We may perform internal changes, such as tenant moves, without notice, which can impact mail flow if a tenant has a bad connector configuration. This means a misconfigured connector that works today may unexpectedly stop working." Microsoft message MC1226222
• A static address nobody else uses. For an address-based connector, Microsoft says: "Don't share the IP address with anyone outside of your organization (the IP address is used for authentication on the connector)." and "Dynamic IP addresses aren't supported or allowed."
• Not for bulk mail. Microsoft says "Reasonable limits are imposed. The service can't be used to send spam or bulk mail."
• No copy in Sent Items. Microsoft's table lists "Saves to Sent Items folder" as No for SMTP relay.

Microsoft: how a device or application can send email through Microsoft 365

When a connector is reasonable

• The app runs on a server your organisation runs, such as your own website or a line-of-business program, with a fixed public address that only your organisation uses.
• The vendor documents a certificate of your own. That means a TLS certificate for your organisation whose domain is one of your accepted domains, and an envelope sender on your domain. Look for this in the vendor's own documentation. If it is not there, assume the vendor does not offer it.

When it is not

• A CRM or other cloud app that sends from the vendor's own servers with addresses it shares between its customers, and without a certificate of your own.
• An app whose vendor says it does not support Exchange Online. Salesforce, for example, says its Email Relay "doesn't support sending emails directly through Microsoft 365 Exchange (Exchange Online) to people outside" your organisation. Salesforce
• Marketing and bulk mail, which Microsoft's relay is not meant for. For bulk mail to external recipients Microsoft recommends Azure Communication Services email, which sends from its own service, so Footer365 never sees it and it is not signed. Microsoft: Exchange Online limits

If a connector is not reasonable for your app, and it cannot connect a mailbox, its mail cannot be signed by Footer365.

What Footer365 needs for the mail to be signed

1. Footer365 mail flow is set up. Footer365 sees the app's mail only because your Exchange Online routes it to Footer365 with its own transport rules.
2. The envelope sender is on one of your accepted domains. The envelope sender is the address that mail servers return undeliverable mail to, shown as Return-Path in the received message. Footer365's rules pick a message up only when that address is on your domains, and leave any other message to Exchange, which sends it on unsigned. Microsoft's relay has its own rule: the certificate domain or the envelope sender must be an accepted domain of yours, and Microsoft says that otherwise "the relay attempt ... is rejected". So an app that uses its own bounce address on another domain is either rejected by Microsoft's relay, or accepted because its certificate is on your domain and then sent on unsigned by Footer365's rules.
3. The sending address is in Footer365's directory, as a person, a shared mailbox or a mail-enabled group, with a signature rule that covers it. Microsoft lets an app relay from "any email address (including email addresses that can't receive email)" in an accepted domain, such as [email protected]. Footer365 passes on, unsigned, mail from a sender it cannot find in your directory. The signature was not added

Footer365 has not tested whether its rules pick up mail that arrives through a connector like this. Its rules match a sender who is inside the organisation, and Microsoft defines that as an address in an accepted domain set as authoritative, on a message that "was sent or received over an authenticated connection". Microsoft's pages do not say in so many words that a connector counts as one, so check one message.

Create the connector

These are Microsoft's steps, as they read on 23 October 2026. Footer365 does not create or manage this connector.

1. Go to the Exchange admin center at https://admin.cloud.microsoft/exchange#/connectors, Mail flow > Connectors, and select Add a connector.
2. For Connection from, choose Your organization's email server. Connection to is set to Office 365.
3. Give the connector a name of its own, and keep Turn it on selected. Do not select Retain internal Exchange email headers.
4. On Authenticating sent email, choose how the app is recognised:
   • A certificate, which Microsoft recommends: By verifying that the subject name on the certificate that the sending server uses to authenticate with Office 365 matches the domain entered in the text box below (recommended), then enter an accepted domain that matches the certificate's subject or alternative name.
   • An address: By verifying that the IP address of the sending server matches one of the following IP addresses which belong exclusively to your organization, then enter the app's public IP address. Use this only for a server only your organisation uses.
5. Review the connector and select Create connector.
6. Add the sending server to your SPF record, as Microsoft says, so the messages are not treated as spam.
7. In the app, set the server to your organisation's MX endpoint, such as contoso-com.mail.protection.outlook.com, port 25 with TLS enabled, and a sender address on one of your accepted domains.

Give the new connector a different name from the ones Footer365 creates, and do not change those: Footer365 Inbound and Footer365 Outbound are Footer365's. What Footer365 creates in Exchange Online

Check one message

Send a message from the app to an address outside your organisation that you can read, and open the headers of the copy you receive. Return-Path should be on your domain, and X-Footer365-Relay-Id should be present if Footer365 handled the message. Mail from your CRM and other apps

If the app's mail is refused with an error that mentions "Relay Access Denied", Microsoft's relay is refusing it, which is the situation Microsoft's warnings above describe. Salesforce's page names "Relay Access Denied ATTR36" as one such error.

Sources

Read on 23 October 2026:

• Microsoft: how a device or application can send email through Microsoft 365, dated 16 September 2026 and updated 5 October 2026.
• Microsoft: updated requirements for SMTP relay, dated 4 August 2025 and updated 3 August 2026.
• Microsoft message MC1226222, published 2 February 2026 and updated 4 February 2026, read through a third-party mirror of the Message Center because the Message Center needs a sign-in.
• Microsoft: mail flow rule conditions and exceptions, dated 11 August 2026 and updated 1 September 2026.
• Salesforce: Email Relay and Microsoft 365, published 15 May 2026.