Mail from your CRM and other apps

Many systems send email as one of your people: a CRM, a help desk, a booking system, a form on your website. Footer365 can sign that mail too, but only when it travels a particular way. This article explains which way, how to tell from one received message whether an app's mail qualifies, and how to set an app up so that it does.

Which app mail is signed

Footer365's transport rules pick up a message only when it passes through your Exchange Online and its envelope sender is on one of your organisation's accepted domains. The envelope sender is the address mail servers return undeliverable mail to. It is often not the address in the From line: an app can send a message that says it is from [email protected] while using its own bounce address, such as [email protected], as the envelope sender.

So an app's mail is signed when both of these are true:

1. It passes through your Microsoft 365, rather than leaving from the app's own servers.
2. Its envelope sender is an address on one of your domains, normally the mailbox it was sent from.

Any other message is sent on without a signature. It is never held or bounced because of Footer365: the Footer365 rules simply do not pick it up, and Exchange delivers it as it is. The reason is that Exchange Online only takes a message back from Footer365 when its envelope sender is on one of your domains, and no rule can change that address. See Which messages get a signature and What Footer365 creates in Exchange Online.

A message that does qualify is signed exactly like one sent from Outlook: the relay looks the sender up in your directory and applies your signature rules, so the person, or the shared mailbox, needs a rule that covers them.

Check one message

The quickest way to know where an app's mail stands is to look at one message it sent.

1. Have the app send a message to an address outside your organisation that you can read, such as a personal mailbox.
2. Open the received message's headers.
3. Find Return-Path. The receiving server records the envelope sender there.
4. Find X-Footer365-Relay-Id. It is only present on mail the Footer365 relay handled.

What you see tells you where the message stands:

Mail sent from a mailbox in your organisation also lands in that mailbox's Sent Items, which Microsoft documents for both Microsoft Graph and SMTP sign-in. If an app's message is not in Sent Items, the app most likely sent it from its own servers.

If an app's mail is not being signed, Mail from our CRM is not signed works through the causes in order.

Ways an app can send so its mail is signed

There are two ways, and the order matters. Sending through a mailbox in your organisation is the first choice, and the first three headings below are ways of doing it. A connector from the app into Exchange Online is the last resort, and the last heading says why. Choose how your CRM or app sends its mail helps you decide, with a diagram. Check one message whichever you choose.

A message sent from a mailbox leaves from your own Exchange Online, and Microsoft documents a copy in the mailbox's Sent Items. Nothing special is needed from Footer365 as long as the envelope sender is the mailbox's address. Microsoft says the mailbox's address appears as the sender for SMTP sign-in, and its pages do not state the envelope sender for Microsoft Graph, which is why every guide here says to check one message.

Through an app registration, with Microsoft Graph

The app is given Microsoft Graph's Mail.Send permission in your tenant and sends as a mailbox. Microsoft says of Microsoft Graph: "This method saves the message in the Sent Items folder." Many CRMs use this when they ask you to approve a Microsoft app. Approve an app's access in Microsoft 365

Through a shared mailbox

An app that sends from a shared mailbox, such as sales@ or support@, through Microsoft Graph or a sign-in to that mailbox, is signed with the signature your rules give that mailbox, not the signature of the person who triggered the message. Shared mailbox signature

Through the person's own mailbox

Most CRMs can connect each person's Microsoft 365 mailbox, usually by having them sign in with Microsoft (OAuth), and then send their one-to-one email through it. This is the route the CRM guides below recommend.

Some apps send through the mailbox with SMTP, by signing in to smtp.office365.com. Microsoft calls this SMTP AUTH client submission. The message appears from the mailbox signed in, or from another mailbox it holds Send As permission on. Things to know:

• Microsoft says SMTP AUTH is disabled for organisations created after January 2020, and that it can be turned on for a single mailbox. Turn on SMTP sign-in for one mailbox
• Microsoft limits a mailbox to 10,000 recipients a day and 30 messages a minute.
• Microsoft has announced that Basic authentication for SMTP AUTH, a user name and password, is turned off by default for existing tenants at the end of December 2026. Prefer an app that signs in with Microsoft.

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

A website form that sends through a mailbox, with Microsoft Graph or SMTP AUTH as above, is signed in the same way as any other app.

What Microsoft is switching off

Pick the Microsoft Graph or OAuth option when an app offers one, and never the one called "Exchange" or "EWS".

• Exchange Web Services. Microsoft says that in October 2026 EWS starts to be disabled globally for all organisations, and that in April 2027 it is fully disabled. Exchange Web Services is being switched off
• Basic authentication for SMTP. Turned off by default for existing organisations at the end of December 2026, as above.

Last resort: through a connector

An app or a website server can also hand mail to Exchange Online through an inbound connector you create (Microsoft calls this SMTP relay). Use it only when the app cannot send through a mailbox, and only where Microsoft's conditions are 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." A CRM that sends from its vendor's servers is a service hosted by someone else, and Microsoft asks such a service for a certificate of your own. A connector that trusts an address the vendor shares with its other customers is one of the two mistakes Microsoft names in its message MC1226222.

Its mail is signed only when the envelope sender is on one of your own domains. Many apps use a bounce address of their own instead, and then their mail is not signed. Last resort: a connector to Exchange Online sets out Microsoft's conditions and what Footer365 needs.

What is never signed

• Mail an app sends from its own servers. It never passes through your Microsoft 365, so Footer365 never sees it. This includes the marketing and bulk email tools of the CRMs below, which send from the vendor's own sending network.
• Mail with the app's own bounce address. Even when it passes through your Exchange Online, a message whose envelope sender is on the app's domain is sent on unsigned, as above.
• Mail an app sends when it falls back to its own servers, for example after reaching a daily limit on the connected mailbox. The guides below note where a vendor documents this.

Place the signature with a marker

Footer365 puts the signature under what was written, and in a reply or forward above the quoted earlier message. To have it somewhere else, such as above the unsubscribe line at the foot of an app's email template, put a marker in the template where the signature should go. Footer365 then puts the signature where the marker is.

The marker says only where. The signature is the one the person would get without it, built from your directory and your signature rules, and nothing in the message changes which signature is used or what it shows. Anything Footer365 adds under the signature, such as a campaign banner or a disclaimer, goes with it; a campaign placed above the message still goes at the top.

There are two forms:

• The HTML form, <span data-footer365-signature></span>, for an HTML template: write it into the template's HTML. If a message misses Footer365, recipients see nothing, because the element is empty.
• The text form, {{Footer365 signature here}}, for a plain-text template, or an HTML editor that removes empty elements. If a message misses Footer365, recipients see the marker as it was written.

Use the HTML form wherever the app lets you edit the template's HTML and keeps the element, because it can never show. Footer365 finds the text form in any mix of capital and small letters and with extra spaces, and in HTML also where an editor has split it with formatting such as bold, or written its braces as character codes. The HTML form may carry other attributes, but nothing except spaces between its tags.

Some apps treat text in double braces as merge fields of their own, and may change or remove it before the message is sent. In such an app, use the HTML form, and check one message.

How the relay reads the markers in a message:

• Only the new part of the message counts. In a reply or forward, a marker in the quoted earlier message is never used.
• The first marker decides. The signature goes where the first marker in the new part is, and every other marker is taken out, quoted ones included, so a reply never collects a second signature.
• No marker, no change. A message without one is signed exactly as it always was.
• A marker with anything in it is not a marker. Text inside the element, a value given to its attribute, or other words between the braces, such as a name, leave it as it is, and the signature goes in its usual place.
• No marker reaches a recipient. The relay takes every marker out of a message it passes on without a signature as well, such as when no signature rule matches or your signatures are paused. Two kinds of message keep theirs: a message it passes on exactly as it arrived without opening it, such as an encrypted or digitally signed message, and a message from Outlook that carries a winmail.dat, unless the relay removes the winmail.dat to add a disclaimer or sign the message, as described in Which messages get a signature. That is another reason to prefer the HTML form.

When the audit log records a message that held a marker, its entry also says whether the signature was placed at it, and how many markers were taken out.

Markers and the Outlook add-in

The Outlook add-in never adds a marker: it puts the signature where Outlook keeps signatures. If someone types a marker into a message the add-in has signed, then when the message is sent the add-in takes its own signature out and hands the message to the Footer365 relay, which puts the signature where the marker is. The person sees the add-in's signature while writing; the recipient sees the signature where the marker was. In a message written in Outlook, use the text form: the HTML form typed into a message is only text, and is not a marker.

If your organisation uses the Outlook add-in only, no message reaches the relay, so a marker is not used: the add-in's signature stays where Outlook keeps signatures, and the marker is sent as it was typed. The HTML form cannot be seen, but the text form shows.

CRM guides

Start with Choose how your CRM or app sends its mail, then open the guide for your app. The Microsoft 365 steps that every guide shares are in Approve an app's access in Microsoft 365, Limit which mailboxes an app can send as, Turn on SMTP sign-in for one mailbox and Exchange Web Services is being switched off.

Each guide follows the same plan: what can be signed, the Microsoft 365 approval, the mailbox to choose, how to connect, how to check one message, what is never signed, what Microsoft is switching off, the limits, and the connector as a last resort. It says which of the CRM's sending options goes through the person's Microsoft 365 mailbox, and which of its mail leaves from the vendor's own servers. Each is written from the vendor's own documentation, with the date the pages were read at the foot of the guide, not from a test by Footer365, and vendors change their products: always check one message.

• Salesforce
• HubSpot
• Microsoft Dynamics 365 Sales
• Zendesk Support
• Freshsales
• SugarCRM
• Close
• Zoho CRM
• Pipedrive
• Outreach
• Freshdesk
• Help Scout
• ServiceNow
• Nutshell

These products have no way to send through a Microsoft 365 mailbox that their documentation describes, so each has a short page of what is and is not possible:

• Bullhorn
• Copper
• Insightly
• Keap

Salesloft, Apollo.io, ActiveCampaign and Jira Service Management have no guide yet. Salesloft's, Apollo's and ActiveCampaign's help pages refuse an automated reader, and the Atlassian pages that could be found for Jira Service Management describe Jira Data Center and disagree on shared mailboxes, so what they say about Microsoft 365 could not be confirmed for Cloud on 23 October 2026 and is not stated here. The vendor below has no guide of its own either. What its documentation said when it was read on 20 October 2026 is below, and its help pages could not be read again on 23 October 2026.

monday sales CRM

• monday's Emails & Activities connects Outlook. monday's help says "All emails are sent from your email client's server" and that sent mail also appears in your email account's Sent folder, which is the route Footer365 can sign. How mass email and sequences are sent is not documented on what could be read. monday: Emails & Activities, how it works