r/sysadmin • u/morph9494 • 1d ago

Any help appreciated

We've migrated an email domain from one M365 tenant to another but an old exists on the 'old' tenant. This app sends messages via a mailbox in the tenant using EXO and M365 mail routing. However, the mailbox sends as a temporary domain (given the real domain is in the new tenant). How can we rewrite the domain on the way out with M365 or relay through an external SaaS solution that would send on the email and rewrite back to the old domain

0 Upvotes

20% Upvoted

6 comments sorted by

2

u/deepthought16 1d ago

Does the email need to be in the new or old tenant?

2

u/blud_13 1d ago

You can't do this inside M365. A domain can only be an accepted domain in one tenant at a time, and EXO connectors wont let you overwrite the sending address on the way out. If the envelope sender isn't an accepted domain in that tenant Exchange rewrites it with SRS to the tenants primary domain, which is what you are looking at. MS has the relay requirements at https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/updated-requirements-smtp-relay

Two ways out. 1) Point the app at an external SMTP relay and authenticate the old domain there with DKIM. Nothing about that needs the domain to live in the old tenant, its all DNS. 2) Move the app to send through the NEW tenant where the domain actually is and stop maintaining two of everything.

Also, if you relay, watch SPF. The new tenant owns that DNS now so somebody has to add the include or your mail is in junk immediately.

We run into this on every tenant-to-tenant we do, ping me if you want specifics.

2

u/PacificTSP 1d ago

SMTP2GO

•

u/Lurker-1983-12 15h ago

This is the way to go. Reconfigure the app to use SMTP2GO en you are set. Remember to add SMTP2GO to SPF record and read up on their setup documentation.

•

u/AnypostHQ 16h ago

Disclosure: we are a transactional email API, so take the last paragraph as a vendor angle.

The "rewrite it on the way out in M365" approach isn't really fixable the way you'd want. A domain can only be Accepted/DKIM-verified in one tenant at a time, so once it's live in the new tenant, the old tenant loses the ability to DKIM-sign as that domain. A transport rule can rewrite the From header text, but it can't fix the signature, so you'll fail DMARC alignment even if the header looks right.

Your second idea, relaying through an external service that sends and rewrites back to the old domain, is the actual fix, because that service's authority comes from DNS records you control, not tenant ownership. Point your old-tenant connector (or better, point the app directly) at an SMTP relay/API where you've added your own SPF, DKIM, and DMARC records for the domain, and it's independent of which M365 tenant currently holds it.

Worth doing regardless of the migration: Microsoft's rolling out a hard 2,000-external-recipient-per-24h limit on EXO mailboxes, fully enforced Oct 1, 2026, and it can't be turned off. If this app sends any real volume, mailbox-as-relay is going to become a wall you hit again anyway. This is a good excuse to get app mail off Exchange Online for good instead of just patching the domain issue.

(This is what we built Anypost for, happy to answer questions if useful)