Exchange Online - Dynamic Disclaimer with User's Future Email Address for 500+ Users

Question

Exchange Online - Dynamic Disclaimer with User's Future Email Address for 500+ Users

Eaint Hmu Theint Theint 60

Hi everyone,

I'm planning a domain migration and would like to add a temporary disclaimer to outbound emails in Exchange Online.

The ideal disclaimer would look similar to this:

NOTICE** OF EMAIL ADDRESS **CHANGE Effective [Date], my email address will change to [Future Email Address]. Please continue using my current email address until then. After that date, my current email address will no longer accept incoming emails.

The challenge is that this needs to be applied to approximately 500** **users, and each user has a different future email address. The local part (username) remains the same, but the email domain changes.

My questions are:

Can an Exchange Online Mail Flow Rule dynamically populate each sender's future email address in a disclaimer?
Can disclaimer text reference Azure AD / Entra ID attributes or mailbox attributes?
Is there a Microsoft-native solution for this scenario, or is a third-party email signature solution required?
Has anyone implemented a similar email domain migration announcement for a large user population?

Thank you for any guidance or best practices.

0 comments

Answer accepted by question author

Dora-T 635 Independent Advisor

Hi @Eaint Hmu Theint Theint

Based on my research and testing, Exchange Online can add an organization-wide disclaimer to messages by using a mail flow rule. The disclaimer can also use supported sender attribute placeholders, such as %%DisplayName%%, %%FirstName%%, %%LastName%%, %%UserPrincipalName%%, and %%WindowsEmailAddress%%.

However, these disclaimer placeholders only insert the corresponding attribute values and do not perform string manipulation. For example, using %%******@newdomain.com would not remove the existing domain and replace it with the new domain. Instead, it would result in an incorrect value such as ******@******@newdomain.com.

As one possible approach, I tested using Exchange Online PowerShell together with a mailbox custom attribute.

First, retrieve the user mailboxes and specify the new domain:

$mailboxes = Get-EXOMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited
$newDomain = "newdomain.com"

Then, calculate the future email address for each mailbox by keeping the existing local part and replacing the domain:

$mailboxes | ForEach-Object {
    $currentEmail = $_.PrimarySmtpAddress.ToString()
    $localPart = $currentEmail.Split("@")[0]
    $futureEmail = "$localPart@$newDomain"

    Set-Mailbox -Identity $_.UserPrincipalName -CustomAttribute1 $futureEmail
}

In this approach, CustomAttribute1 is used to store the future email address for each mailbox. Exchange Online supports custom mailbox attributes and allows them to be managed using Set-Mailbox.

Mail flow rule conditions and exceptions (predicates) in Exchange Online | Microsoft Learn

I then configured a single mail flow rule to append the disclaimer. During testing, the same rule displayed a different future email address based on the sender. For example:

User A > ******@newdomain.com
User M > ******@newdomain.com
User C > ******@newdomain.com

User's image

Based on my testing, a separate mail flow rule was not required for each user. The future email address was prepared and stored per mailbox, while a single mail flow rule handled the disclaimer rendering.

If the disclaimer should be applied to all outgoing messages regardless of the recipient, the rule can be configured to apply to all messages. If the disclaimer should only be added to messages sent outside the organization, the rule can instead use the recipient condition outside the organization.

Note: The use of %%CustomAttribute1%% in the disclaimer above is based on testing performed in my test tenant. Microsoft documentation confirms that CustomAttribute1 through CustomAttribute15 are supported custom mailbox attributes that can be managed in Exchange Online. However, I have not found Microsoft documentation that explicitly lists %%CustomAttribute1%% as a supported disclaimer placeholder. Therefore, I recommend validating this behavior in your own environment before deploying it broadly.

I hope this information helps.

If the answer is helpful, please click "Yes". If you have extra questions about this answer, please click "Comment".

Note: Please follow the steps in the forum documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Dora-T 635 Reputation points Independent Advisor

2026-09-03T00:04:36.6366667+00:00

Hi @Eaint Hmu Theint Theint

Just checking in to see if you've had a chance to check my previous response.

If you have any other questions, please feel free to reach out again.
Eaint Hmu Theint Theint 60 Reputation points

2026-09-07T07:47:52.0266667+00:00

Hello @Dora-T ,

Thank you very much for your detailed explanation, answers, testing, and follow-up. I really appreciate the time and effort you put into testing this approach.

I just realized that I forgot to mention one important detail about our environment: the users/mailboxes we are working with are hybrid users, and their accounts are synchronized from our on-premises Active Directory to Microsoft Entra ID.

I understand that for synchronized users, attributes such as CustomAttribute1 need to be managed from the on-premises Active Directory rather than directly in Exchange Online. Therefore, I would like to know if there is a recommended way to achieve the same result in a hybrid environment—for example, by populating the required attribute in on-premises AD and then using it in the Exchange Online mail flow rule.

Thank you again for your help and for sharing your testing results. It is very helpful.
Dora-T 635 Reputation points Independent Advisor

2026-09-08T01:13:55.9533333+00:00
Hi @Eaint Hmu Theint Theint

Thank you for the additional details about your hybrid environment.

Based on my research, one possible approach for synchronized (hybrid) mailboxes is to populate CustomAttribute1 from the on-premises environment using the Set-RemoteMailbox cmdlet on your on-premises Exchange server. Microsoft documents that the configuration set on the on-premises mail user is synchronized to its associated mailbox in the service, and that the timing depends on the directory synchronization schedule.

After the CustomAttribute1 value is synchronized to Exchange Online, you may evaluate whether it can be used in the mail flow rule. However, since I do not have access to a test environment that matches your hybrid configuration, I have not been able to verify whether %%CustomAttribute1%% can be referenced in the mail flow rule for a hybrid configuration. Therefore, I recommend reviewing the following Microsoft documentation and testing the approach in your environment before applying it broadly.

References:

Set-RemoteMailbox (ExchangePowerShell) | Microsoft Learn

Cloud-based management of Exchange attributes for Remote Mailboxes in hybrid environments | Microsoft Learn

I hope this information helps.

1 additional answer

Your answer

Dora-T 635 Reputation points Independent Advisor

2026-09-03T00:04:36.6366667+00:00

Hi @Eaint Hmu Theint Theint

Just checking in to see if you've had a chance to check my previous response.

If you have any other questions, please feel free to reach out again.
Eaint Hmu Theint Theint 60 Reputation points

2026-09-07T07:47:52.0266667+00:00

Hello @Dora-T ,

Thank you very much for your detailed explanation, answers, testing, and follow-up. I really appreciate the time and effort you put into testing this approach.

I just realized that I forgot to mention one important detail about our environment: the users/mailboxes we are working with are hybrid users, and their accounts are synchronized from our on-premises Active Directory to Microsoft Entra ID.

I understand that for synchronized users, attributes such as CustomAttribute1 need to be managed from the on-premises Active Directory rather than directly in Exchange Online. Therefore, I would like to know if there is a recommended way to achieve the same result in a hybrid environment—for example, by populating the required attribute in on-premises AD and then using it in the Exchange Online mail flow rule.

Thank you again for your help and for sharing your testing results. It is very helpful.
Dora-T 635 Reputation points Independent Advisor

2026-09-08T01:13:55.9533333+00:00

Hi @Eaint Hmu Theint Theint

Thank you for the additional details about your hybrid environment.

Based on my research, one possible approach for synchronized (hybrid) mailboxes is to populate CustomAttribute1 from the on-premises environment using the Set-RemoteMailbox cmdlet on your on-premises Exchange server. Microsoft documents that the configuration set on the on-premises mail user is synchronized to its associated mailbox in the service, and that the timing depends on the directory synchronization schedule.

After the CustomAttribute1 value is synchronized to Exchange Online, you may evaluate whether it can be used in the mail flow rule. However, since I do not have access to a test environment that matches your hybrid configuration, I have not been able to verify whether %%CustomAttribute1%% can be referenced in the mail flow rule for a hybrid configuration. Therefore, I recommend reviewing the following Microsoft documentation and testing the approach in your environment before applying it broadly.

References:

Set-RemoteMailbox (ExchangePowerShell) | Microsoft Learn

Cloud-based management of Exchange attributes for Remote Mailboxes in hybrid environments | Microsoft Learn

I hope this information helps.

Answer 1

Yes. Exchange Online mail flow rules can add organization-wide disclaimers and can insert sender-based tokens into the disclaimer text. For this scenario, the practical Microsoft-native approach is to use a mail flow rule and build the future address from sender attributes that are already available.

Supported points:

A mail flow rule can add a disclaimer to outbound mail.

In Exchange Online, disclaimers/signatures are implemented by a mail flow rule.
To make it outbound-only, add a condition such as recipient is outside the organization.

Disclaimer text can use sender attribute tokens.

Exchange Online supports tokens such as %%DisplayName%%, %%FirstName%%, %%LastName%%, %%Department%%, %%UserPrincipalName%%, and %%WindowsEmailAddress%%.
The values come from the sender’s Microsoft 365 or Office 365 account.

There is no context support for a token that directly returns a separate “future email address” field.

The supported tokens listed in the documentation do not include a dedicated future-address attribute.
Based on the supported tokens, a native rule can dynamically insert only the available sender attributes.

For the domain migration case where the local part stays the same, the native option is:

Store or rely on a sender attribute that already contains the username needed by the rule, such as %%WindowsEmailAddress%% or %%UserPrincipalName%% if it matches the current local part format.
In the disclaimer text, append the new domain as static text.

Example pattern:

Effective [Date], my email address will change to %%FirstName%% ... is not sufficient for the address itself.
If the local part is preserved, use an attribute that exposes the sender identity and combine it with the new domain in the disclaimer text. The exact disclaimer text must be written using only supported tokens and static text.

What is not supported by the provided documentation:

Reading an arbitrary custom Entra ID or Azure AD attribute for disclaimer text.
Referencing a dedicated mailbox attribute specifically for a future email address unless it is one of the supported disclaimer tokens.
A documented Microsoft-native feature in the provided material that computes a transformed address from another attribute.

Best-practice implementation for 500+ users:

Create one mail flow rule in Exchange admin center: Mail flow > Rules > Add a rule > Apply disclaimers.
Scope it to outbound mail only, for example recipients outside the organization.
Add the disclaimer text using supported sender tokens and static text.
Add an exception that matches unique text in the disclaimer to avoid duplicate insertion in message threads.
Start in Test without Policy Tips before switching to Enforce.
Verify with both plain text and HTML messages.

If the requirement is to pull a unique future address per user from a separate attribute that is not one of the supported disclaimer tokens, the provided Microsoft documentation does not show a native way to do that in a mail flow rule. In that case, the context does not provide a Microsoft-native solution beyond the supported tokens.