After a mailbox migration, recreation or cross-organisation move, new messages to the user’s SMTP address may work while replies to old messages fail with a 5.1.1 NDR containing an address that begins with IMCEAEX.

That pattern often means the old message is not addressing the recipient by SMTP address. It contains a legacy Exchange distinguished name that no longer belongs to the new recipient object.

The durable repair is usually to preserve the old identity as an X500 proxy address on the correct current recipient.

Confirm the signature

Do not apply this fix to every “recipient not found” bounce. Look for all of these:

  • a reply, forwarded old message, old meeting or autocomplete entry fails;
  • a freshly composed message to the current SMTP address works;
  • the NDR recipient begins with IMCEAEX or names a legacy Exchange address;
  • the error is consistent with a changed LegacyExchangeDN; and
  • the intended current recipient is known unambiguously.

If new messages also fail, investigate recipient existence, accepted domains, mail flow, address policy and directory synchronisation first.

Understand why it happens

Exchange has historically used LegacyExchangeDN as an internal recipient identity. Outlook autocomplete entries, old messages and calendar items can retain that value.

When a mailbox is deleted and recreated, migrated without the old identity, or represented by a new object, the current SMTP address can remain the same while the old legacy distinguished name changes. Replies then target an identity Exchange no longer resolves.

Clearing one person’s autocomplete may make a new message work, but it does not repair old messages, meetings or other users’ cached entries. Adding the historic address to the intended recipient lets Exchange resolve those references centrally.

Preserve the NDR and identify the recipient

Save the complete NDR through an authorised support route. Record the failed recipient, reporting system, time, original message and the intended current mailbox.

Before changing anything, verify the current object by multiple properties:

  • display name and current primary SMTP address;
  • recipient type;
  • immutable or migration mapping evidence where available;
  • owner/user confirmation; and
  • whether a duplicate or soft-deleted object exists.

Do not attach the legacy address to the first similar display name.

Decode the IMCEAEX value exactly

Microsoft’s current support article explains how to convert the encoded IMCEAEX recipient from the NDR back into an X500 address. Use the full failed address and follow that mapping precisely.

Conceptually, the result changes from an SMTP-safe encoded form such as:

IMCEAEX-_O=..._OU=..._CN=RECIPIENTS_CN=...@example.invalid

to a legacy distinguished name beginning:

X500:/O=.../OU=.../CN=RECIPIENTS/CN=...

The ellipses are placeholders, not usable syntax. Do not guess missing components, use smart quotes, retain the trailing routing domain, or normalise case/characters without following the documented conversion.

Check for collisions before adding it

Search all relevant active and recoverable recipients for the exact X500 proxy address. If another object already owns it, stop and reconcile identity history.

An X500 address is not a second SMTP address and should not replace the current primary SMTP address. Export the recipient’s existing email-address collection before mutation.

Add the address without replacing existing proxies

With current Exchange Online PowerShell and suitable least-privilege authority, the additive pattern is:

$recipient = 'current.user@example.com'
$legacyAddress = 'X500:/O=EXAMPLE/OU=EXCHANGE ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=PLACEHOLDER'

Set-Mailbox -Identity $recipient -EmailAddresses @{Add=$legacyAddress}

The X500 value above is deliberately fictional. Use the exact decoded value from the NDR and the cmdlet appropriate to the actual recipient type. A mail user, contact or group may require a different recipient cmdlet.

Do not use a command that assigns a new complete EmailAddresses array unless you have deliberately reconstructed every existing proxy. An additive change reduces the chance of deleting the primary or aliases.

Read back the result

Query the same recipient again and confirm:

  • the existing primary SMTP address is unchanged;
  • all prior proxy addresses remain;
  • the exact new X500 value appears once; and
  • no other recipient owns it.

Allow for documented directory or client propagation where relevant, but do not keep adding variants while waiting.

Test the stale paths

Use synthetic content and test:

  1. reply to the original message that failed;
  2. send from the original autocomplete entry;
  3. update or respond to an affected old meeting where applicable;
  4. compose a fresh message to the current SMTP address; and
  5. test from another user who had the old recipient cached.

Inspect message trace and any NDR. Success from a newly typed address alone does not validate the X500 repair.

Repair migration process, not only one mailbox

If one migrated user has the problem, review the migration mapping for others. Preserve historic LegacyExchangeDN values as X500 proxies during recipient moves or recreation, and include old-message reply and calendar tests in acceptance.

Do not mass-add values from an unverified spreadsheet. Each legacy address must map uniquely to the intended current object.

If the pattern does not match

Stop the X500 path when:

  • the NDR references an ordinary SMTP address;
  • fresh mail fails too;
  • the current recipient is missing or inactive;
  • the decoded address already belongs elsewhere;
  • the failure is external DNS/routing; or
  • the message trace identifies a different policy or transport failure.

An X500 proxy restores continuity for a particular Exchange identity history. It is elegant when the evidence matches—and irrelevant when it does not.