Using Footer365 alongside another email gateway

Many organisations already send their outbound mail through a third-party gateway such as Mimecast, Proofpoint or Barracuda, or through some other outbound connector. Footer365 is designed to sit in front of that routing rather than replace it. This article explains how, based on exactly what the Footer365 rule and connectors do, so you can judge how it fits your own setup.

If your organisation uses the Outlook add-in only, Footer365 creates no rule or connector, so your gateway's routing is untouched and none of this applies. Using the Outlook add-in only

What the Footer365 objects actually do

The details are in What Footer365 creates in Exchange Online. The parts that matter here:

• The Footer365 outbound connector is scoped to transport rules. It carries nothing on its own. Only a message a Footer365 rule routes to it goes to the relay, so it does not compete with your existing outbound connectors for ordinary mail.
• The Footer365 rules run first. They sit at priority 0 and 1, match mail sent from inside your organisation, and have "Stop processing more rules" set. On the first pass, no rule below them runs.
• The returning message is excepted. When the relay hands a message back, it carries X-Footer365-Processed: true, the Footer365 rules no longer match, and the message is processed by the rest of your rules as if for the first time.
• The return comes in as your own mail. The inbound connector is of the OnPremises type, so Exchange treats the signed message as mail from your organisation and sends it on by its normal outbound route.

The order this produces

The signature is therefore already on the message before it reaches your gateway. That is usually what you want: the gateway's own scanning, archiving, disclaimers and DKIM signing see the finished message.

What Footer365 tells you at setup

Once mail flow is set up, Footer365 reads your own outbound connectors, and those of your transport rules that route mail to a connector, to see where signed mail goes next. It only reads them: it never changes a connector or a rule of yours. Its own connectors and rules are left out.

• In the setup wizard. When step 4, Set up mail flow, shows that mail flow is live, a note under it says what was found. For a connector of yours that sends mail for every domain, or for named domains, it names the connector and where it sends mail, because the signed message follows it as before. For a rule of yours that routes to a connector, it says the rule acts on the signed message when it comes back from Footer365. If nothing was found, or your connectors and rules could not be read, step 4 shows no note.
• A rule that skips signed mail. If a rule of yours that routes to a connector has an exception for the header X-Footer365-Processed, which every message Footer365 signs carries, the rule never acts on signed mail, so signed mail does not go out through that connector. Step 4 then shows Check your rule and a warning naming the rule. Remove that exception from the rule in the Exchange admin centre.
• Every night. Footer365 reads your connectors and rules again every night, and whenever its own connectors are rebuilt. When a rule of yours starts skipping signed mail, your technical contact is emailed once about that rule, or your account owner if no technical contact is set. The email says what the rule does and how to remove the exception. Nobody is emailed about the same rule again unless it is put right and later changed back.

A connector of yours that is turned off is not mentioned in the wizard. With the Outlook add-in only nothing is read, because Footer365 holds no Exchange Administrator role to read with.

None of this means a gateway product has been tested with Footer365. It describes your own Exchange objects as Footer365 found them.

Things to check in your own setup

How your gateway routing is triggered. If your outbound connector to the gateway applies to all recipient domains, the signed message simply follows it on the return pass. If your routing to the gateway is itself done by a transport rule, that rule will not match on the first pass (the Footer365 rule stops processing) but should match on the return pass. Check that your rule has no condition that the returning message would fail, and that it does not also except X-Footer365-Processed.

Other rules that change the message. Rules that add disclaimers, apply encryption or modify the subject run on the return pass, after the signature is added. For encryption this is the order you need; see Encryption and rule priority.

Gateway-side signatures or disclaimers. If your gateway also adds a signature or disclaimer, recipients will see both. Decide which system owns each piece of text before going live.

Journaling and archiving. A copy taken inside Exchange before the return pass holds the unsigned message. A copy taken by a gateway after Exchange holds the signed one.

Inbound mail. Footer365 only handles mail sent from inside your organisation. Mail arriving from the internet, including through a gateway in front of your MX records, does not match the Footer365 rules.

Things not to do

• Do not move your own rules above the Footer365 rules, or give any rule a higher priority than 0. A rule that runs first and stops processing, routes the message elsewhere, or protects it, means the message never reaches Footer365 or cannot be signed.
• Do not add the Footer365 relay to your gateway's configuration or point any connector of yours at it. Footer365 connects to your tenant only through its own two connectors, and the relay only accepts mail from Exchange Online.
• Do not edit the Footer365 connectors or rules to fit around your gateway. Footer365 checks and repairs them, and an edit can cause loops or unsigned mail.

SPF and DMARC with a gateway

Your SPF record needs to authorise every system that sends for your domain. Adding the Footer365 include does not replace your gateway's own SPF entry. See SPF, DKIM and DMARC and Update your SPF record.

Before you go live

Send a test from a mailbox covered by a Footer365 rule to an address outside your organisation, then look at the received message:

• the signature is present;
• the headers include X-Footer365-Relay-Id, showing the relay handled it;
• the headers also show your gateway handled it, if it should have;
• SPF, DKIM and DMARC results in the Authentication-Results header are what you expect.

If any of these is not what you expect, contact support with the message headers before changing anything.