What Footer365 creates in Exchange Online

When mail flow is set up in step 4 of the setup wizard, Footer365 creates four objects in your Exchange Online organisation: two connectors and two transport rules. You watch them tick off in the wizard as Creating the inbound connector, Creating the outbound connector, Creating the transport rule for external emails and Creating the transport rule for internal emails. There is nothing for you to create, and no PowerShell to run.

Object names

Every object name starts with Footer365, so sorting or searching by "Footer365" in the Exchange admin centre finds all four.

The connectors

Footer365 Outbound takes mail from your tenant to the Footer365 relay. It is scoped to transport rules only, so it carries nothing unless a Footer365 rule sends a message to it. It does not use MX records: it delivers to the Footer365 relay host for your data region, with TLS set to domain validation, which means Exchange checks the relay's certificate chain and name before it sends anything.

Footer365 Inbound accepts the signed message back from the relay. It is an OnPremises connector, which is what lets Exchange treat the returning message as your organisation's own mail and deliver it onwards to the internet. It requires TLS, and it only accepts the Footer365 relay, identified either by the relay's certificate name or by the relay's IP addresses. Footer365 keeps this setting up to date itself when the relay's certificate is renewed.

The transport rules

Both rules have the same shape. Only the recipient condition and the priority differ.

Priority 0 is the top of the list, so the Footer365 rules run before your own rules on the way out. Exchange moves your existing rules down to make room. The reasons for this order, and how it interacts with encryption rules, are in Encryption and rule priority.

The exception on X-Footer365-Processed is what stops a signed message being routed to the relay a second time. See How mail flows through Footer365.

The exception on message size keeps anything over 24 MB away from the relay, so Exchange sends it on unsigned rather than the relay refusing it and the message being returned to its sender. Rules created before 18 October 2026 are given this exception automatically by the daily check that keeps the Footer365 rules in line.

The three sender conditions make the rules pick up only mail whose envelope sender, the address mail servers return undeliverable mail to, is on one of your organisation's accepted domains. Exchange Online only takes mail back from the relay when that address is on one of your domains, and no rule can change it, so any other message could never come back from Footer365. Examples are mail an app sends with its own bounce address on another domain, and automatic replies and delivery reports, which have an empty envelope sender. Those messages are now left to Exchange and sent on without a signature. The sender's domain condition matches each domain, and the address pattern makes sure it is the domain itself and not a subdomain of it. Footer365 adds the conditions straight after creating a rule, and the daily check adds them to rules created before 20 October 2026 and keeps the list of domains in line with your accepted domains, which it also does straight away when the domain sync finds a domain added or removed. If Exchange refuses the address patterns, the rule keeps the domain condition alone, and if your organisation has so many domains that even the list does not fit in a rule, the rule carries no sender conditions and works as it did before; both are recorded in your audit log.

The internal rule also leaves calendar messages alone: meeting requests, responses and cancellations between your own mailboxes stay inside Exchange, so room and resource mailboxes book exactly as they would without Footer365. The daily check adds this exception to internal rules created before 18 October 2026 too.

Both rules are wanted for every organisation on mail flow. If the internal rule is missing, because Exchange refused it when mail flow was set up or because someone deleted it, Footer365 tries again after setup, and the daily check creates it again and records that in your audit log. When Exchange refuses it again, that is recorded once, with Exchange's own message, and not every day. A missing internal rule does not stop mail to people outside your organisation being signed.

Organisation settings Footer365 may change

With the Exchange Administrator role in place, Footer365 also checks a small number of organisation-wide settings. With the Outlook add-in only it holds no role and checks none of them: Using the Outlook add-in only shows how to check and change them yourself. The settings are:

• Event-based add-ins. If DisableEventBasedActivationAddIns is True, Footer365 sets it to False, because otherwise the Outlook add-in's compose event never fires.
• Modern authentication. If OAuth2ClientProfileEnabled is False, Footer365 sets it to True, because the Outlook add-in cannot sign in without it.
• People's own Outlook signatures, only if you chose to turn them off in the wizard or later. Footer365 sets PostponeRoamingSignaturesUntilLater to True in the organisation configuration and SignaturesEnabled to False on the OwaMailboxPolicy-Default policy. Custom Outlook on the web mailbox policies are not changed, and classic Outlook for Windows needs a separate Group Policy or Intune setting on the device. See Keep or turn off Outlook signatures.

Each change is recorded in your audit log.

Automatic replies, only when Out of office is on

If a Super Admin turns on Out of office, Footer365 also reads each mailbox's automatic reply every night with Get-MailboxAutoReplyConfiguration, and sets or turns one off with Set-MailboxAutoReplyConfiguration when someone does so on the Out of office page. It creates nothing: a reply between two times that blocks the calendar adds an event called "Out of office" to that person's calendar, as Outlook would. DeclineEventsForScheduledPeriod is never set, so no meeting already in a calendar is declined or removed. Every reply set or turned off is recorded in your audit log. With Out of office off, which is how every organisation starts, Footer365 never reads or changes an automatic reply. See Set automatic replies for your people.

The default compose font, only when a Super Admin sets one

If a Super Admin sets a Default compose font on the Add-in settings page, Footer365 sets DefaultFontName and DefaultFontSize with Set-MailboxMessageConfiguration on the mailbox of each person it is for, and reads them back with Get-MailboxMessageConfiguration. It sends nothing else, so the rest of each mailbox's message settings are left as they are. It never puts a font back, because it does not know what the mailbox had before. Every mailbox it could not set is recorded in your audit log. With the setting for nobody, which is how every organisation starts, Footer365 never reads or changes a mailbox's font. See Set the default compose font.

How to see them

In the Exchange admin centre:

• Mail flow, then Connectors, lists the two Footer365 connectors.
• Mail flow, then Rules, lists the two Footer365 rules at the top.

In Exchange Online PowerShell:

Get-InboundConnector | Where-Object Name -like "Footer365*"
Get-OutboundConnector | Where-Object Name -like "Footer365*"
Get-TransportRule | Where-Object Name -like "Footer365*" | Format-List Name,Priority,State,Mode

Never edit them by hand

The reasons are specific:

• Footer365 recognises its objects by name as well as by their Exchange ID. A renamed object can be missed when mail flow is set up again, and a second one created beside it.
• Removing the header exception causes loops. Every signed message comes back to the relay a second time. Mail is still delivered, but everything is processed twice.
• Lowering the priority lets other rules act first. An encryption rule that runs before the Footer365 rule protects the message, and a protected message cannot be signed.
• Changing the header value stops your mail being verified. The relay uses X-Footer365-Tenant to confirm a message came from your organisation. Footer365 checks this value every day and puts it back, and mail that does not carry it can be refused.
• Disabling or deleting a rule stops signatures for that kind of mail.

If something looks wrong, contact support. The rules and connectors can be checked and recreated from the Footer365 side without you touching Exchange.

When your subscription ends

On the day your subscription ends, Footer365 removes the connectors and rules above, and undoes the change to people's own Outlook signatures:

1. It turns your users' own Outlook signatures back on, whether or not you had turned them off.
2. It removes both transport rules, so your mail no longer goes to the relay.
3. Once both rules are confirmed gone, it removes both connectors.
4. It checks that no Footer365 rule or connector remains.

Each step counts as done only when Exchange confirms it, and each is recorded in your audit log. A step that is not confirmed is tried again every day. Your account owner and technical contact are emailed the result. If Footer365's access to your tenant was removed first, it cannot make these changes, and the email lists what to remove by hand. Removing Footer365 gives the order to do it in.

A subscription that ends is not the same as a pause. When Footer365 pauses an account, it removes the rules and switches the connectors off but keeps them, so they can be switched back on. When a subscription ends, the connectors are deleted, and mail flow is set up again from the start if you come back.

With the Outlook add-in only there is nothing here to remove, and each of these steps is recorded as nothing to do.

When you remove mail flow

A Super Admin can move your organisation from mail flow to the Outlook add-in only with Remove mail flow on Getting started, while the subscription carries on. Footer365 then takes the same steps as when a subscription ends: it turns your users' own Outlook signatures back on, removes both transport rules, removes both connectors once the rules are confirmed gone, and checks nothing remains. Each step counts as done only when Exchange confirms it, and a step that is not confirmed is tried again every day. The Exchange Administrator role stays assigned, because Footer365 cannot change directory roles. Using the Outlook add-in only