How to set up email signatures across a Microsoft 365 tenant (mail flow rules, user signatures, and the traps)

The request is always simple as stated. Marketing has a new logo, or the business has moved office, and every staff member needs the same signature by Monday. What makes it awkward is that Microsoft 365 has two different mechanisms for putting text at the bottom of an email, they behave nothing alike, and the one most administrators reach for first is the one that produces the most complaints.

This guide covers both. First the organisation-wide route through a mail flow rule, which applies centrally and cannot be turned off by users. Then the per-user route, which now behaves differently to how it did for years. Then the traps, because a signature project rarely fails on configuration; it fails on the behaviours nobody warned the business about.

Two different jobs, two different mechanisms

Deciding which mechanism you need takes about a minute and saves a fortnight.

• A per-user signature is composed by the user in Outlook or Outlook on the web and is inserted into the message as they write it. They can see it, edit it, and choose a different one. It appears in the copy saved to Sent Items. It is also entirely under their control, which is the point and also the problem.
• An organisation-wide disclaimer, footer or signature is applied by a mail flow rule as the message passes through Exchange Online. It is centrally controlled and users cannot remove it, but it is added after the message leaves the mailbox, which drives most of the behaviour people find surprising.

A useful rule: if the business needs a guarantee that a legal footer or a confidentiality notice is on every outbound message, use a mail flow rule. If the business wants a well-designed branded signature that behaves the way staff expect a signature to behave, a mail flow rule alone will disappoint, and the honest options are per-user signatures with a standard template or a dedicated signature product.

Method 1: an organisation-wide signature or disclaimer with a mail flow rule

This is the built-in, no-extra-cost route, and it is the right answer for a legal disclaimer, a confidentiality notice or a compliance footer.

1. 1Sign in to the Exchange admin center at admin.exchange.microsoft.com with an account holding the appropriate mail flow permissions.
2. 2Open Mail flow, then Rules, then select Add a rule and choose Apply disclaimers.
3. 3Give the rule a clear name. Future you, or the next administrator, needs to know what it does without opening it.
4. 4Set the condition. Choosing the recipient is external or internal and then selecting outside the organisation limits the disclaimer to outbound mail. Selecting apply to all messages applies it to everything entering and leaving, which is rarely what a business wants.
5. 5Under the action, keep apply a disclaimer to the message and append a disclaimer, or switch to prepend if the text needs to sit at the top instead.
6. 6Enter the disclaimer text. It accepts HTML and inline CSS, and images can be included with an IMG tag.
7. 7Set the fallback action, which decides what happens when the rule cannot modify the message. This matters more than it looks; see below.
8. 8Add an exception so the disclaimer is not repeated down a long thread. The standard approach is an exception where the subject or body matches distinctive text from the disclaimer itself, so the second and third replies do not each add another copy.
9. 9Choose the rule mode. Enforce turns it on immediately; testing without policy tips logs the outcome without changing messages, which is the sane way to start.
10. 10Review and finish, then send yourself both an HTML and a plain text test message that match the conditions, plus one that should not match, and confirm each behaves correctly.

The equivalent in Exchange Online PowerShell is a single cmdlet, which is the better route if the rule needs to be reproducible across tenants or held in version control:

That check is one command in Exchange Online PowerShell:

Making the disclaimer personal: tokens, and the directory behind them

A disclaimer rule does not have to be identical for everyone. The disclaimer text supports tokens that pull values from the sender's directory attributes, which is how one rule produces a per-person signature block. The available tokens include the sender's display name, first name, last name, initials, job title, department, company, office, street address, city, state or province, postal code, country or region, phone, mobile phone, home phone, fax, pager, manager, notes, user principal name and email address.

This is where most organisation-wide signature projects come unstuck, and it is not a Microsoft 365 problem. It is a data problem. The tokens are only as good as the directory behind them, and in most businesses that directory has been filled in inconsistently since the tenant was created.

• An empty attribute produces nothing at all, so a staff member with no job title recorded gets a blank line, and a layout built as name, pipe, title, pipe, phone produces stray punctuation with nothing between it.
• Phone numbers entered in six different formats across the business will appear in six different formats in the signature. Australian mobile numbers written variously as 0412 345 678, +61412345678 and 0412345678 are the usual example.
• Office and street address attributes are frequently blank or still carry the previous office, which is exactly the field a signature rollout is often meant to correct.

The fix is to audit and correct the directory attributes before the rule goes anywhere near Enforce. Export the relevant fields for every user, clean them in a spreadsheet against an agreed format, and write them back. Then design the layout so a missing field degrades quietly rather than leaving visible debris, and appoint someone to own the fields on an ongoing basis, because a new starter with no job title recorded will send email with a broken signature from day one otherwise.

Method 2: per-user signatures, and how they roam now

For years an Outlook signature was a set of files in a folder on the individual computer, which meant a new laptop or a second device meant a signature rebuilt from scratch, and it is why signature deployment scripts exist.

That changed. In current Outlook builds using a Microsoft 365 account, signatures are stored in the mailbox rather than only on the device, and they synchronise across the Outlook clients signed in to that account. The practical consequence for a service desk is that the last saved default signature becomes the active one everywhere, so a staff member editing their signature on a laptop changes what goes out from their desktop too. That is usually welcome, and occasionally the cause of a confusing ticket.

The realistic way to standardise per-user signatures without a third-party product is to supply staff with an approved block they paste in once, published somewhere they can find it on the intranet, with a short set of rules about what may and may not be added. It is not enforcement, and it should not be described to a client as enforcement, but for a business under about thirty people it usually costs less than the alternative and produces a better result than a transport rule.

Method 3: a dedicated signature service

Third-party signature management exists because the built-in options each solve half the problem. These products centrally manage the signature design, vary it by department or location, add and expire campaign banners, and handle replies and forwards properly rather than dumping a second block at the bottom of a thread.

There are two broad architectures and the difference is worth understanding before committing.

• Transport-side services apply the signature as the message passes through mail flow, in the same place a disclaimer rule works. Coverage is complete, including mobile devices, but the message the sender keeps in Sent Items does not show what the recipient received, and the mail path now depends on another provider.
• Client-side services add the signature inside Outlook via an add-in, so the sender sees the real signature while composing and it appears correctly in Sent Items. Coverage depends on the add-in being available in the clients staff actually use, which is the question to ask about mobile.

Some vendors offer both and switch between them. The decision hinges on whether accurate Sent Items matters more than complete coverage of every device, and that is a business question rather than a technical one.

The behaviours that make a central signature look broken

Nearly every complaint about an organisation-wide signature traces back to the same fact: a mail flow rule modifies the message after it has left the mailbox. Set expectations on these before rollout, not after.

• The sender never sees it. It is not there while they compose, and it is not in the copy saved to Sent Items, because that copy was saved before the rule ran. Staff routinely conclude it is not working and add their own signature on top, producing two.
• On a reply, an appended disclaimer lands at the very bottom of the whole message, underneath the quoted history, not under the reply the recipient is reading. There is no setting that changes this, which is the main reason a transport rule makes a poor everyday signature.
• Without an exception, every reply in a thread adds another copy, so a long conversation accumulates the same block a dozen times.
• Images have to be referenced by an IMG tag pointing at a publicly reachable HTTPS address. They are linked, not embedded, and many mail clients block remote images by default, so the logo shows as a blank space or a broken image placeholder for a meaningful share of recipients.
• Plain text messages will not render HTML, so anything that depends on layout falls apart.
• Encrypted messages cannot be modified, so those hit the fallback action.
• Mobile clients keep adding their own line, so 'Sent from my iPhone' stacks on top of the corporate block unless it is turned off on the device.

What belongs in an Australian business signature

Signatures grow. A rollout is the opportunity to shrink them, and shorter signatures perform better on mobile, where a large share of email is now read.

• Name, position, and the organisation's trading name. If the legal entity differs from the trading name and the business invoices by email, include the ABN.
• One phone number. Two numbers means the recipient picks the wrong one.
• One address, and only if it is genuinely useful to the recipient.
• The website. Social icons are a design decision, not a requirement, and each one adds a remote image that may not load.
• Nothing else. Award logos, environmental requests and lengthy confidentiality notices are the three items that make a signature longer than the message it is attached to.

Two Australian points worth being straight about. A confidentiality notice at the bottom of an email is convention rather than a shield; it does not by itself create an obligation on somebody who received the message by mistake, and it should not be sold internally as a legal control. And the obligations that apply to marketing email in Australia, identifying the sender accurately and providing a working unsubscribe, are properties of the sending platform and the campaign, not something a signature rule addresses. Treat those as separate work.

One accessibility point that costs nothing: keep the phone number and address as text. Putting contact details inside the logo image means they disappear entirely for the recipients whose client blocks remote images, and for anyone using a screen reader.

A rollout order that avoids the usual mess

1. 1Agree the design and the exact fields it uses, on paper, with whoever owns the brand.
2. 2Audit the directory attributes those fields depend on and correct them, including the format of phone numbers.
3. 3Decide which mechanism does the job: a mail flow rule for a compliance footer, per-user signatures with a supplied template for a branded block, or a dedicated product where the business needs both centrally enforced and properly behaved.
4. 4Build the rule in test mode, or the template on a handful of pilot users, and send real mail internally and externally from desktop, web and mobile.
5. 5Check what a reply looks like three messages deep, which is where transport-applied text reveals itself.
6. 6Communicate the behaviour to staff before enforcing, specifically that a centrally applied footer will not appear in their Sent Items, so the service desk does not field the same ticket forty times.
7. 7Enforce, then re-test with a small group the following week and again after the next new starter joins.