How do you handle forwarding emails when a client moves to a new domain?

thecomputerguy

Well-Known Member
Reaction score
1,326
I've been curious about this for awhile... Here's the scenario ... pretty simple actually.

Client owns contoso.com with email at O365
Client purchases acme.com

acme.com is added into O365 as an owned domain

Client wants to rebrand the company from contoso.com to acme.com

Client has 10 email accounts all using O365 Business Standard for Mailboxes & Office licensing at contoso.com

10 New identical email accounts with O365 Business Standard are created under acme.com, mailbox data is migrated from contoso.com to acme.com

WHAT NOW?

Obviously we want all emails sent to contoso.com to get forwarded to acme.com so admin@contoso.com gets forwarded to admin@acme.com

BUT

We are now left with 10 accounts that are essentially dummy forwarding accounts that we are now overpaying for, since we don't need office licensing, and we don't even need the mailbox, we just need anything sent to be forwarded.

Is it as simple as enabling domain forwarding to external domains, converting the mailboxes to shared mailboxes inside the account, then forwarding?
 
You've made a fine mess of a simple process...

If the customer wants a straight up rebrand. ZERO migration is required.

All you have to do:
1.)add the new domain to the tenant,
2.)configure it as the default domain,
3.)go through the mailboxes and add the new domain's addresses to each account,
4.)set the new addresses as default on each account. (This is breaking)

This changes the user's login name and breaks all their stuff, but all they have to do is login again on their junk with the new email address (same password they had because same account) and BOOM mailbox is intact, all data is still there... but Outlook and whatnot is replying off the new name. All permissions in SharePoint intact... Teams intact... EVERYTHING. Because accounts are numbers, not addresses and you can rename them easily.

When you're done, pick a date in the future to schedule the old domain's demise, remove it and the associated address aliases from the tenant.

But from where you are, if you've already moved everything over... just delete the old mailboxes and put the old addresses on the new mailboxes as aliases. And pray you don't have any retention policies in the way... Converting them to shared mailboxes to forward from there would be a bit safer actually... so that's not a bad idea. But it's unnecessary complexity.

Never forget, mailbox != SMTP address, Exchange mailboxes can have as many SMTP addresses as you want or need! You made something that was so simple into a huge chore, and spent so much time on this... and you didn't need to! And nowhere in this process did you need to license again...

So go forth with a scalpel of knowledge, and put away the sledge hammer of ignorance. The good news is the way out is pretty quick and painless too... but there's nothing to be done to get back the time you lost manually reconfiguring things that didn't need reconfigured. Chalk it up to a learning experience, and be grateful you didn't step in it hard enough for your customer to be hurt or notice.
 
Last edited:
You've made a fine mess of a simple process...

If the customer wants a straight up rebrand. ZERO migration is required.

All you have to do:
1.)add the new domain to the tenant,
2.)configure it as the default domain,
3.)go through the mailboxes and add the new domain's addresses to each account,
4.)set the new addresses as default on each account. (This is breaking)

This changes the user's login name and breaks all their stuff, but all they have to do is login again on their junk with the new email address (same password they had because same account) and BOOM mailbox is intact, all data is still there... but Outlook and whatnot is replying off the new name. All permissions in SharePoint intact... Teams intact... EVERYTHING. Because accounts are numbers, not addresses and you can rename them easily.

When you're done, pick a date in the future to schedule the old domain's demise, remove it and the associated address aliases from the tenant.

But from where you are, if you've already moved everything over... just delete the old mailboxes and put the old addresses on the new mailboxes as aliases. And pray you don't have any retention policies in the way... Converting them to shared mailboxes to forward from there would be a bit safer actually... so that's not a bad idea. But it's unnecessary complexity.

Never forget, mailbox != SMTP address, Exchange mailboxes can have as many SMTP addresses as you want or need! You made something that was so simple into a huge chore, and spent so much time on this... and you didn't need to! And nowhere in this process did you need to license again...

So go forth with a scalpel of knowledge, and put away the sledge hammer of ignorance. The good news is the way out is pretty quick and painless too... but there's nothing to be done to get back the time you lost manually reconfiguring things that didn't need reconfigured. Chalk it up to a learning experience, and be grateful you didn't step in it hard enough for your customer to be hurt or notice.

Good info ... thanks I will add this to my notes! Good news is this client doesn't use SP/Teams/OneDrive

I can definitely see how my way still works and essentially ends up at the same outcome, but I also understand what you mean by sledgehammering it.
 
I've been curious about this for awhile... Here's the scenario ... pretty simple actually.

Client owns contoso.com with email at O365
Client purchases acme.com

acme.com is added into O365 as an owned domain

Client wants to rebrand the company from contoso.com to acme.com

Client has 10 email accounts all using O365 Business Standard for Mailboxes & Office licensing at contoso.com

10 New identical email accounts with O365 Business Standard are created under acme.com, mailbox data is migrated from contoso.com to acme.com

WHAT NOW?

Obviously we want all emails sent to contoso.com to get forwarded to acme.com so admin@contoso.com gets forwarded to admin@acme.com

BUT

We are now left with 10 accounts that are essentially dummy forwarding accounts that we are now overpaying for, since we don't need office licensing, and we don't even need the mailbox, we just need anything sent to be forwarded.

Is it as simple as enabling domain forwarding to external domains, converting the mailboxes to shared mailboxes inside the account, then forwarding?
What I would suggest is a two step process.

1. I would set up so that all emails going to the old address be automatically forwarded to the new one.
2. I would set up an autoresponder so that the sender gets a message that says their email has changed, gives them the new email address and asks them to send all future emails to the new address.

I would have this set up for about three months then close down the old email addresses.
 
You've made a fine mess of a simple process...

If the customer wants a straight up rebrand. ZERO migration is required.

All you have to do:
1.)add the new domain to the tenant,
2.)configure it as the default domain,
3.)go through the mailboxes and add the new domain's addresses to each account,
4.)set the new addresses as default on each account. (This is breaking)

This changes the user's login name and breaks all their stuff, but all they have to do is login again on their junk with the new email address (same password they had because same account) and BOOM mailbox is intact, all data is still there... but Outlook and whatnot is replying off the new name. All permissions in SharePoint intact... Teams intact... EVERYTHING. Because accounts are numbers, not addresses and you can rename them easily.

When you're done, pick a date in the future to schedule the old domain's demise, remove it and the associated address aliases from the tenant.

But from where you are, if you've already moved everything over... just delete the old mailboxes and put the old addresses on the new mailboxes as aliases. And pray you don't have any retention policies in the way... Converting them to shared mailboxes to forward from there would be a bit safer actually... so that's not a bad idea. But it's unnecessary complexity.

Never forget, mailbox != SMTP address, Exchange mailboxes can have as many SMTP addresses as you want or need! You made something that was so simple into a huge chore, and spent so much time on this... and you didn't need to! And nowhere in this process did you need to license again...

So go forth with a scalpel of knowledge, and put away the sledge hammer of ignorance. The good news is the way out is pretty quick and painless too... but there's nothing to be done to get back the time you lost manually reconfiguring things that didn't need reconfigured. Chalk it up to a learning experience, and be grateful you didn't step in it hard enough for your customer to be hurt or notice.

I just went through this process again and I just realized how much work I made for myself by doing it the way I described in OP... like ... WAY more work. Thanks again for the information.
 
You've made a fine mess of a simple process...

If the customer wants a straight up rebrand. ZERO migration is required.

All you have to do:
1.)add the new domain to the tenant,
2.)configure it as the default domain,
3.)go through the mailboxes and add the new domain's addresses to each account,
4.)set the new addresses as default on each account. (This is breaking)

This changes the user's login name and breaks all their stuff, but all they have to do is login again on their junk with the new email address (same password they had because same account) and BOOM mailbox is intact, all data is still there... but Outlook and whatnot is replying off the new name. All permissions in SharePoint intact... Teams intact... EVERYTHING. Because accounts are numbers, not addresses and you can rename them easily.

When you're done, pick a date in the future to schedule the old domain's demise, remove it and the associated address aliases from the tenant.

But from where you are, if you've already moved everything over... just delete the old mailboxes and put the old addresses on the new mailboxes as aliases. And pray you don't have any retention policies in the way... Converting them to shared mailboxes to forward from there would be a bit safer actually... so that's not a bad idea. But it's unnecessary complexity.

Never forget, mailbox != SMTP address, Exchange mailboxes can have as many SMTP addresses as you want or need! You made something that was so simple into a huge chore, and spent so much time on this... and you didn't need to! And nowhere in this process did you need to license again...

So go forth with a scalpel of knowledge, and put away the sledge hammer of ignorance. The good news is the way out is pretty quick and painless too... but there's nothing to be done to get back the time you lost manually reconfiguring things that didn't need reconfigured. Chalk it up to a learning experience, and be grateful you didn't step in it hard enough for your customer to be hurt or notice.

I assume outlook profiles have to be recreated after this right? Kind of a pain due to the NK2 (.dat) file needing to be re-imported since most users think their NK2 (.dat) file are their contacts.

But it is what it is.
 
I assume outlook profiles have to be recreated after this right? Kind of a pain due to the NK2 (.dat) file needing to be re-imported since most users think their NK2 (.dat) file are their contacts.

But it is what it is.

No... because again accounts are numbers not names. Yes, the login needs changed, but because the SID of the account stayed the same, and that's what the Outlook Profile is based on (just like Windows user accounts), it should just pop up.

And stop supporting bad habits... it'll give you an ulcer.
 
I assume outlook profiles have to be recreated after this right? Kind of a pain due to the NK2 (.dat) file needing to be re-imported since most users think their NK2 (.dat) file are their contacts.

But it is what it is.
NK2 files haven't been a thing for a long time and the Autocomplete list follows the user in Office 365.
 
You've made a fine mess of a simple process...

If the customer wants a straight up rebrand. ZERO migration is required.

All you have to do:
1.)add the new domain to the tenant,
2.)configure it as the default domain,
3.)go through the mailboxes and add the new domain's addresses to each account,
4.)set the new addresses as default on each account. (This is breaking)

This changes the user's login name and breaks all their stuff, but all they have to do is login again on their junk with the new email address (same password they had because same account) and BOOM mailbox is intact, all data is still there... but Outlook and whatnot is replying off the new name. All permissions in SharePoint intact... Teams intact... EVERYTHING. Because accounts are numbers, not addresses and you can rename them easily.

When you're done, pick a date in the future to schedule the old domain's demise, remove it and the associated address aliases from the tenant.

But from where you are, if you've already moved everything over... just delete the old mailboxes and put the old addresses on the new mailboxes as aliases. And pray you don't have any retention policies in the way... Converting them to shared mailboxes to forward from there would be a bit safer actually... so that's not a bad idea. But it's unnecessary complexity.

Never forget, mailbox != SMTP address, Exchange mailboxes can have as many SMTP addresses as you want or need! You made something that was so simple into a huge chore, and spent so much time on this... and you didn't need to! And nowhere in this process did you need to license again...

So go forth with a scalpel of knowledge, and put away the sledge hammer of ignorance. The good news is the way out is pretty quick and painless too... but there's nothing to be done to get back the time you lost manually reconfiguring things that didn't need reconfigured. Chalk it up to a learning experience, and be grateful you didn't step in it hard enough for your customer to be hurt or notice.

I actually just went back to this method instead of using the accounts that I migrated over ... everything worked absolutely perfect, the only issue I have is that Outlook still displays the old email address as the name for the mailbox/data file. I'm doing some looking but it looks like renaming that isn't really an option.

Edit: It appears when you send mail from the mailbox it changes the display name ... still waiting to verify other mailboxes.
 
Last edited:
Back
Top