Mail from our CRM is not signed

Symptom: email your people send from Outlook is signed, but email sent as them from your CRM, help desk or another app arrives without a signature.

Footer365 signs an app's mail only when it passes through your Microsoft 365 with an envelope sender on one of your domains. Anything else is delivered without a signature, never held or bounced because of Footer365. Mail from your CRM and other apps explains why, and Choose how your CRM or app sends its mail helps you pick the way to send.

Read one message's headers

1. Have the app send a message to an address outside your organisation that you can read.
2. Open the received message's headers.
3. Note the Return-Path, which is the envelope sender, and whether there is an X-Footer365-Relay-Id header.
4. Look in the sending mailbox's Sent Items for the message.

Then work down the fixes below. The first one that matches is the cause.

1. The app sent it from its own servers

Check: Return-Path is on the app's own domain, there is no X-Footer365-Relay-Id, and the message is not in the sending mailbox's Sent Items.

The message never passed through your Microsoft 365, so Footer365 never saw it. This is how every CRM's marketing and bulk email tools send, and how some CRMs send everything until a mailbox is connected.

Fix: switch the app to an option that sends through the person's own Microsoft 365 mailbox, usually by connecting each person's inbox with a Microsoft sign-in. Choose how your CRM or app sends its mail explains the choice. The guides for Salesforce, HubSpot, Microsoft Dynamics 365 Sales, Zendesk Support, Zoho CRM, Pipedrive, Outreach, Freshdesk, Help Scout, ServiceNow, Nutshell, Freshsales, SugarCRM and Close say which option that is. Marketing email cannot be moved this way, and stays unsigned.

2. The app relays through your Exchange Online with its own bounce address

Check: Return-Path is on the app's own domain, there is no X-Footer365-Relay-Id, but the app sends through a connector into your Exchange Online rather than from its own servers.

Exchange Online only takes a message back from Footer365 when its envelope sender is on one of your domains, so the Footer365 rules leave this message to Exchange, which sends it on unsigned.

Fix: in order of preference:

• Switch the app to sending through each person's mailbox, as in fix 1. A connector is the last resort, and Microsoft says SMTP relay cannot be used for a service hosted by someone else. Last resort: a connector to Exchange Online
• If the app documents a setting for its envelope sender or return path, set it to an address on your own domain.

3. The app fell back to its own servers

Check: some of the app's messages are signed and others are not, and the unsigned ones match fix 1.

Some apps send through the connected mailbox until something stops them, then carry on from their own servers. Freshsales switches to its own sending after a daily number of messages through the connected mailbox, and Zoho CRM's Email Relay sends through Zoho's servers when its mail fails to deliver from your relay server. Freshsales

Fix: keep sending within the limit, or reconnect the mailbox if the app shows it as disconnected. Close, for example, says a disconnect on sending usually means SMTP sending is not turned on for the mailbox. Close

4. The message went through Footer365 but was not signed

Check: the message carries X-Footer365-Relay-Id.

The relay handled it and passed it through unsigned for one of its usual reasons. The commonest for app mail are a sending mailbox that no signature rule covers, such as a shared mailbox the app sends from, and a sending address that is not in your synced directory.

Fix: work through The signature was not added, and see Which messages get a signature for the full list. Quote the X-Footer365-Relay-Id value if you contact support.

5. The return path is on your domain, but the message did not go through Footer365

Check: Return-Path is on your domain or a subdomain of it, there is no X-Footer365-Relay-Id, and the message is not in Sent Items.

Some marketing tools ask you to add DNS records so that their return path is on your own domain, while still sending from their own servers. Pipedrive Campaigns and Dynamics 365 Customer Insights - Journeys both work this way. The message never passed through your Microsoft 365.

Fix: none for that mail: it cannot be signed. Send the messages that must carry a signature through a person's mailbox, as in fix 1.

6. The app was never approved in Microsoft 365

Check: the app shows its Microsoft connection as failed, and the person who tried to connect it saw a message such as "Need admin approval" or "Administrator approval required". The words differ from one vendor to the next.

Until someone approves the app, it cannot send through the mailbox. Depending on the app, mail then either does not send or leaves from the app's own servers, as in fix 1.

Fix: approve the app, or let people approve it themselves. Approve an app's access in Microsoft 365

7. The app connects with Exchange Web Services

Check: the app's connection to Microsoft is called "Exchange" or "EWS", and its mail stopped sending, or stopped being signed, after October 2026.

Microsoft is switching Exchange Web Services off. It starts to be disabled in October 2026 and is fully disabled in April 2027.

Fix: reconnect each mailbox with the app's Microsoft Graph or "Office 365 (OAuth)" option. Exchange Web Services is being switched off

8. The app signs in to SMTP with a username and password

Check: the app sends with the server smtp.office365.com and a stored password, and it stopped working, or shows an authentication error.

Microsoft has announced that Basic authentication for SMTP is turned off by default for existing organisations at the end of December 2026, and Authenticated SMTP must also be turned on for each mailbox that signs in.

Fix: turn Authenticated SMTP on for the mailbox, and move the app to a Microsoft sign-in if the vendor offers one. Turn on SMTP sign-in for one mailbox

9. The mail should come from a shared mailbox that the app cannot connect

Check: the mail is meant to come from an address such as sales@ or support@, but the vendor connects only a person's own mailbox.

Several vendors connect only a person's own mailbox, and say so in their documentation. The guide for the app says what its vendor documents.

Fix: where the vendor does support sending as a shared mailbox, make sure a Footer365 signature rule covers it. The wrong signature is used for a shared mailbox or delegate Where it does not, the mail cannot be signed by Footer365 from that mailbox.