An Exchange transport rule — also called a mail flow rule — is the native Microsoft 365 method for appending a disclaimer or signature to every email in an organization, server-side. It is free and centralized, which makes it appealing at first. In practice, it quickly runs into concrete limits: unreliable images, a signature missing from Sent Items, restricted HTML and duplicates in reply threads. This guide shows how to create one, then explains honestly where it falls short.
What is an Exchange transport rule?
A transport rule runs on the Exchange Online servers while the message is being routed, after the user clicks "Send". You attach conditions to it (for example: the sender is in the domain, the recipient is external) and an action. For a signature, the relevant action is "Apply disclaimers", which inserts an HTML block at the bottom of the email.
Because processing happens server-side, the user never composes with the signature in front of them: it is added later, invisibly to them. That single fact explains most of the limits described below.
Create the rule step by step
The procedure takes place in the Exchange admin center, with an appropriate admin role.
- Open the Exchange admin center (
admin.exchange.microsoft.com), Mail flow then Rules. - Click Add a rule and choose "Apply disclaimers".
- Set the condition: for example "the sender is located inside the organization", optionally combined with "the recipient is located outside the organization".
- Write the HTML of the disclaimer or signature in the rich text editor. Keep the markup simple (basic tables, inline styles).
- Choose the fallback action: Wrap (attach the original message) or Reject if the disclaimer cannot be inserted, for example on an encrypted message.
- Save, enable the rule, then test a real send to an external mailbox to check how it renders for the recipient.
Propagating a new rule across the whole service can take some time; test patiently rather than stacking up edits.
Why this method disappoints quickly
The transport rule does one specific job well — appending a short text legal disclaimer to outbound mail — but it shows its limits the moment you want a real branded signature:
- Unreliable images. A logo or photo inserted by the rule is often shown as an attachment by Outlook, framed with a red "x", or blocked. There is no compose context to embed images cleanly.
- Missing from Sent Items. Because the signature is added after send, the copy kept by the sender does not contain it. The employee cannot verify what the recipient actually received.
- Limited HTML. The disclaimer editor does not faithfully reproduce complex layouts; the final rendering varies by mail client.
- Duplicates in threads. Without fine tuning, the signature is re-added to every reply and forward, stacking blocks at the bottom of long conversations.
- Coarse targeting. Tailoring the signature by department, country or person requires stacking many conditional rules, which quickly becomes unmanageable.
- Server routing. The email content is processed in transit; for an organization attentive to how data moves, insertion at the workstation is preferable.
These constraints are structural to the server-side approach: they are not fixed by better HTML, but by changing the insertion method.
Transport rule vs client-side add-in
The table below contrasts the native transport rule with an Outlook add-in that inserts the signature at compose time, on the user's device.
| Criterion | Transport rule (server) | Client-side add-in |
|---|---|---|
| Insertion moment | After send, in transit | At compose, before send |
| Image reliability | Low (attachments, blocking) | High (embedded images) |
| Visible in Sent Items | No | Yes |
| Duplicates on reply | Frequent | Avoided (single insertion) |
| Fine targeting (department, group) | Hard | Native (Microsoft 365 groups) |
| User can edit before sending | No | Yes, in the draft |
| Email content processed in transit | Yes | No |
ATOM Signatures works client-side: an add-in inserts the signature in Outlook at compose time, which fixes images, Sent Items and duplicates in one move. Targeting relies directly on Microsoft 365 groups, and fields (name, title, phone) stay up to date in real time through Microsoft Graph.
When to move to a client-side add-in
The transport rule keeps its place for a minimal need: a text disclaimer added only to external email, with no image or sophisticated formatting. It is free and already there.
It becomes time to move to an add-in as soon as any of these needs appears:
- branded signatures with a reliable logo and images;
- a signature visible in each employee's Sent Items;
- department- or group-based targeting without stacking rules;
- no duplicates in reply threads;
- insertion that does not route the email through a third-party server.
To place this shift against the other native Microsoft 365 options, see ATOM vs the native Microsoft 365 signature and the complete Microsoft 365 email signature guide.
Frequently asked questions
Can an Exchange transport rule insert a real signature with images?
In theory yes, in practice poorly. You can inject HTML with image tags, but Outlook clients often show those images as attachments or block them, and the HTML layout is limited. For a rich, reliable signature, a client-side add-in gives a far more consistent result.
Why doesn't the signature appear in my Sent Items?
Because the transport rule runs after send, on the server, while the message is in transit. Your copy in Sent Items is saved before that step, so it has no signature. The sender never sees the message exactly as the recipient receives it.
Does the rule add the signature to every reply in a thread?
Yes, and it is a known issue: without fine tuning, the signature is re-appended to each reply or forward, stacking blocks at the bottom of long threads. Keyword or regex workarounds are fragile. A client-side add-in inserts the signature once, in the right place.
When should you leave transport rules for an add-in?
As soon as you want reliable signatures with images, per-department targeting, visibility in Sent Items and no duplicates. Transport rules remain acceptable for a simple text legal disclaimer added to external mail. Beyond that, a client-side add-in fits far better.
Reliable signatures, without the server-side limits. ATOM Signatures inserts your organization's signature directly in Outlook, client-side, with reliable images, group-based targeting and 100% Canadian hosting.
Go further: ATOM vs the native Microsoft 365 signature and the Microsoft 365 email signature guide.