How mail flows through Footer365
The path a message takes from your mailbox, through the Footer365 relay and back into Exchange Online, and the headers and rules that keep it from looping.
With mail flow, Footer365 adds signatures on the server, after a message has left the sender's mailbox. Nothing is installed on anybody's computer and every mail client is covered, because the signature is added in the one place all of your outbound mail passes through: Exchange Online transport.
This is how mail flows when your organisation uses the Outlook add-in and mail flow. With the Outlook add-in only, none of it happens: there is no Footer365 rule or connector in your Exchange, no message passes through the relay, and only mail written in Outlook with the add-in is signed, while it is written. Using the Outlook add-in only
This article describes the path of a single message. The objects it mentions are described in full in What Footer365 creates in Exchange Online.
The path of a message
X-Footer365-Tenant headerX-Footer365-TenantX-Footer365-Processed: true and X-Footer365-Relay-IdX-Footer365-Processed- Someone sends a message. Exchange Online evaluates your mail flow rules. The Footer365 rule sits at the top of the list and matches mail sent from inside your organisation whose envelope sender is on one of your domains.
- The rule routes the message to the Footer365 outbound connector, which delivers it to the relay for your data region. Exchange insists on TLS and checks that the relay's certificate matches the name on the connector.
- The relay confirms the message came from your Microsoft 365 organisation, looks the sender up in your synced directory, picks the signature rule that applies and writes the signature into the message.
- The relay hands the message back to your own tenant through the Footer365 inbound connector. That connector also requires TLS and only accepts the relay.
- Back in Exchange, the Footer365 rule sees the processed header and does not match a second time. The message continues through the rest of your rules and is delivered as normal.
Mail a CRM or another app sends as one of your people follows the same path only when it is sent through your Microsoft 365 with an envelope sender on one of your domains. Mail from your CRM and other apps
If your organisation sends its outbound mail on through another email gateway, by a connector or a rule of its own, the signed message follows that route in step 5. Footer365 reads your own outbound connectors and routing rules when mail flow is set up and every night, changes none of them, and tells you where signed mail goes next. Using Footer365 alongside another email gateway
The relay never keeps a copy of the message. It is delivered back to Exchange before the relay answers the sending server, and only a processing record is kept (see Data and privacy).
Headers Footer365 adds or removes
| Header | Added by | What it is for |
|---|---|---|
X-Footer365-Tenant |
The Footer365 transport rule | A value unique to your organisation, which the relay uses to confirm the message came through your own rule. The relay removes it before the message goes back, so recipients never see it. |
X-Footer365-Processed: true |
The relay, on every message it hands back; the Outlook add-in, on messages it has already signed | Tells the Footer365 rule not to route the message to the relay again. |
X-Footer365-Relay-Id |
The relay | A unique reference for the processing record of that message. Quote it to support when asking about a specific email. |
When the relay changes the body, by writing a signature into it or by tidying the quoted part of a reply, it also removes any DKIM-Signature header the message arrived with, because a body change makes that signature fail. See SPF, DKIM and DMARC.
To check whether a received message went through Footer365, open its headers. X-Footer365-Relay-Id is only present on mail the relay handled.
Loop prevention
Every message the relay hands back carries X-Footer365-Processed: true, whether or not a signature was added. Each Footer365 transport rule has an exception for that header, so on the return pass the rule does not match and the message is not routed out again.
The relay has a second check of its own. If a message arrives that it has already processed, it hands it straight back unchanged instead of signing it twice, and writes a warning to your audit log at most once a day. Mail is still delivered, but every message is being processed twice, which almost always means the exception has been removed from a Footer365 rule. The fix is to have the rules recreated rather than to edit them; see What Footer365 creates in Exchange Online.
Messages signed by the Outlook add-in
If the Outlook add-in inserted the signature while the message was being written, it also sets X-Footer365-Processed: true. The Footer365 rule then does not route that message to the relay at all, so the signature is not added twice. If the person deletes the add-in's signature before sending, the add-in changes the header to X-Footer365-Processed: removed. The Footer365 rule matches only true, so the message goes to the relay and is signed on the way out, and the relay counts it against that person on the Coverage page. Where Outlook will not let the add-in change the header, it takes the header off instead: the message is still signed, but not counted.
A reply or forward the add-in signed that quotes an earlier message Footer365 signed, when your organisation tidies long conversations, gets X-Footer365-Processed: tidy: followed by a code instead. That is not true either, so the message goes to the relay, which tidies the quoted part as your Long conversations setting says, signs nothing, and hands it back with X-Footer365-Processed: true. What was tidied is added to the add-in's own record of the message. See Earlier signatures and banners in long conversations.
The sending alarm
The relay counts how much each person sends, so that a burst from one mailbox, such as a mail merge sent to the wrong list, is noticed in minutes rather than from the replies. It counts each sender's messages and recipients over the last 10 minutes, for mail it has accepted as your organisation's own. A message is counted once, on its first pass, whether or not it gets a signature: a message the relay has already signed and Exchange hands back, and a delivery report, are not counted.
When one person sends more than your limit of messages or of recipients in 10 minutes, Footer365 emails your Technical contact and Account owner and writes a Sending Burst Detected entry in your audit log. You are told about the same person at most once an hour. The alarm never holds, delays, rejects or changes a message, and it never pauses a signature: every message is delivered exactly as it would be without it.
- It starts on for every organisation, at 100 messages or 1,000 recipients in 10 minutes. You can change either limit, leave out mailboxes that send a lot of mail by design, or turn it off, on Account > Settings under Sending alarm. See Company details and settings.
- Each relay server counts what it receives. Your mail can be shared between more than one relay server in your data region, so the limit applies to each one rather than to all of them together, and a burst spread evenly across them is noticed later. Two servers that both notice the same person in the same hour give one alert.
- Only the counts are kept, over the last 10 minutes and in the relay's memory only. No recipient address is kept or sent: the alert names the sender, the two counts and your limits. A restart of the relay empties the counts, which can only delay an alert.
- Exchange Online has its own sending limits, and restricts a mailbox that passes them until the next day, telling your Global Administrators. The alarm is earlier than that and tells the contacts you chose, but it does not replace Exchange's limits or stop a mailbox sending.
With the Outlook add-in only, no mail passes through the relay, so nothing is counted until mail flow is added.
Internal and external mail
Footer365 creates two transport rules:
- External routing matches mail sent from inside your organisation to anyone outside it.
- Internal routing matches mail sent from inside your organisation to people inside it.
Both routes go through the same relay. The relay then decides which kind of signature applies: a message counts as internal only when every recipient's domain is one of your own domains. If any recipient is outside your organisation, or the relay cannot tell, it is treated as external. This is what lets a rule in the portal apply a different signature to internal mail; see Internal and external signatures.
When the relay does not add a signature
The message is still delivered. It is handed back exactly as it arrived, and the reason is recorded. The common reasons are listed in Which messages get a signature. If a message is held rather than delivered, the reason is in the SMTP response Exchange records; see Delivery status codes.
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.