Choose how your CRM or app sends its mail
Which of the two ways to send an app's mail so that Footer365 signs it suits your app, why connecting a Microsoft 365 mailbox comes first, why a connector into Exchange Online is the last resort, and what neither way can sign.
Footer365 signs the mail an app sends only when that mail passes through your Microsoft 365. There are two ways to make it do so. Connecting a Microsoft 365 mailbox is the first choice. A connector from the app into Exchange Online is the last resort, and for most CRMs Microsoft says it is not available at all.
This article is about mail flow. If your organisation uses the Outlook add-in only, no mail an app sends is signed, however the app sends it. Only mail written in Outlook with the add-in is. Using the Outlook add-in only
The short answer
- If the app can send through a Microsoft 365 mailbox, use that. Look in the app's email settings for "Microsoft 365", "Office 365", "Outlook" or "Microsoft Graph", with a Microsoft sign-in. The message then leaves from your own Exchange Online, as the person whose mailbox it is, and Footer365 signs it with nothing extra to set up.
- Only if the app cannot, and only if Microsoft's conditions are met, use a connector. Microsoft says an SMTP relay connector cannot be used for a service hosted by someone else, which is what a CRM is. Last resort: a connector to Exchange Online
- Marketing and bulk email is signed by neither way. Apps send it from their own servers, and it never reaches your Microsoft 365.
Why connecting a mailbox comes first
- The message leaves from your own tenant. Your own sending rules, SPF record, DKIM key and DMARC policy apply to it, as they do to mail written in Outlook.
- A copy is kept in Sent Items. Microsoft says of Microsoft Graph: "This method saves the message in the Sent Items folder." Microsoft's comparison of the ways a device or application can send lists "Saves to Sent Items folder" as Yes for SMTP sign-in and No for a connector. Microsoft: user: sendMail
- It is allowed for an app hosted by someone else. The same comparison lists "Supports mail sent from applications hosted by a third party" as Yes for SMTP sign-in and No for a connector. Microsoft: how a device or application can send email through Microsoft 365
- It is what Microsoft recommends. Microsoft says: "Other options for sending authenticated mail include using alternative protocols, such as the Microsoft Graph API." Microsoft: deprecation of Basic authentication
- There is nothing of Footer365's to run. The only limits are Microsoft's own for a mailbox: 10,000 recipients a day and 30 messages a minute. Microsoft: Exchange Online limits
Footer365's rules pick a message up by its envelope sender, the address mail servers return undeliverable mail to, which must be on one of your domains. For SMTP sign-in Microsoft says: "The email address of the mailbox appears as the message sender." For Microsoft Graph the pages Microsoft publishes do not say which envelope sender Exchange Online writes, so each guide here is based on the vendor's documentation and has not been tested by Footer365. Check one message, as the guide for your app describes.
Which option to pick in the app
- Pick the Microsoft Graph, "Microsoft 365", "Office 365" or "Outlook" option that opens a Microsoft sign-in. The person, or an administrator, approves the app's access once. Approve an app's access in Microsoft 365
- Never pick "Exchange" or "EWS". Microsoft starts switching off Exchange Web Services in October 2026 and finishes in April 2027. Exchange Web Services is being switched off
- Avoid a username and password for SMTP. Microsoft has announced that Basic authentication for SMTP sign-in is turned off by default for existing organisations at the end of December 2026. If an app only offers SMTP settings, it can still work if it signs in with Microsoft's OAuth. Turn on SMTP sign-in for one mailbox
An app that connects with an application permission, such as Mail.Send consented for the whole organisation, can send as any mailbox unless you limit it. Limit which mailboxes an app can send as
When connecting a mailbox is not possible
- The vendor connects only people's own mailboxes, and the mail must come from a shared mailbox. Several vendors say shared mailboxes are not supported. The guide for the app says what its vendor documents.
- The vendor offers only a connection Microsoft is switching off, such as Exchange Web Services or a stored username and password.
- The app has no Microsoft sign-in and cannot reach
smtp.office365.comon port 587 with TLS 1.2 or later. Microsoft says an application that defaults to port 465 "doesn't support the required versions of TLS for client SMTP submission".
None of these makes a connector the answer. It only means the mailbox route cannot be used for that app.
The connector, as a last resort
A connector is an inbound connector you create in Exchange Online so that the app can hand its mail to your tenant directly. Microsoft's conditions are strict, and for a CRM that runs on its vendor's servers they are usually not met:
- 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."
- For a service run by someone else, Microsoft says the service "must support the following requirements: A unique certificate for your organization. The certificate domain must be an accepted domain in your organization." Its example of such a service is "You use a CRM service to send email on behalf of your organization to internal and external recipients." Microsoft: updated requirements for SMTP relay
- A connector that trusts an address the vendor shares with its other customers is the second of two mistakes Microsoft names in message MC1226222: "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." Microsoft adds that a connector like that "may unexpectedly stop working".
Read Last resort: a connector to Exchange Online before you create one.
Compare the two ways
| Connect a mailbox (first choice) | Connector into Exchange Online (last resort) | |
|---|---|---|
| What the app needs | A Microsoft sign-in with Microsoft Graph or OAuth, or SMTP settings for smtp.office365.com |
SMTP settings that point at your Microsoft 365, from a server only your organisation uses or with a certificate of its own |
| What you do in Microsoft 365 | Approve the app's access, and for SMTP switch on Authenticated SMTP for the mailbox | Create a connector, and add the sending server to your SPF record |
| Who the message is from | The person, or the shared mailbox, whose mailbox it is | Any address on your accepted domains |
| A copy in Sent Items | Yes, where Microsoft documents it | No: Microsoft lists "Saves to Sent Items folder" as No |
| An app hosted by someone else | Allowed | Microsoft says it cannot be used |
| Limits | Microsoft's mailbox limits | Microsoft says "Reasonable limits are imposed" and the service "can't be used to send spam or bulk mail" |
| A shared mailbox | Many vendors do not support it | Not applicable: no mailbox is involved |
| Needs Footer365 mail flow | Yes | Yes |
Decide in four questions
What neither way signs
- Mail an app sends from its own servers, which includes the marketing and bulk email tools of the CRMs in this group. Footer365 never sees it.
- Mail whose envelope sender is not on one of your domains, such as an app that uses its own bounce address. Exchange sends it on as it is. Mail from your CRM and other apps
- Mail an app sends from its own servers when a limit is reached, such as after a daily number of messages through the connected mailbox. The guide for the app says where its vendor documents this.
Next
- Mail from your CRM and other apps
- Mail from our CRM is not signed
- The guide for your app, in this group.
Still stuck?
Tell us what you were trying to do and what you saw. Include the sender, a recipient and roughly when a message was sent, and we can trace it.