Fix 0X000008E3 NERR_AddForwarded alias error

Yeah, the 0X000008E3 error—"This message alias has been added but is still forwarded"—pops up when you're managing email aliases in Exchange or Active Directory. It's one of those messages that makes you refresh the console twice, hoping it'll fix itself. It won't. The alias you're trying to use is technically added, but the system sees it as still forwarded from somewhere else.

The quick fix: strip the forwarding attribute

I've seen this most often on Windows Server 2012 R2 and Exchange 2013/2016, but it also hits SBS 2011 environments. The core issue is a leftover forwarding address or targetAddress attribute pointing to the same alias. Here's what usually works:

Open Active Directory Users and Computers (ADUC). Find the user or contact with the alias.
Right-click > Properties > Exchange General tab (if you see it). Look under Delivery options for any forwarding address. Clear it.
If the tab isn't there, you need ADSI Edit. Connect to the domain, find the object, and check altRecipient and deliverAndRedirect attributes. Set altRecipient to blank, and deliverAndRedirect to FALSE.
Run this in Exchange Management Shell to force the change:

Set-Mailbox -Identity "user@domain.com" -ForwardingAddress $null -ForwardingSmtpAddress $null

If that doesn't do it, you might have a duplicate proxy address. Run this:

Get-Mailbox | Where {$_.EmailAddresses -like "*alias*"} | Format-List Name,EmailAddresses

It'll show you every mailbox using that alias. Remove the extra one. Last month I had a client with two shared mailboxes fighting over the same SMTP address—took me five minutes to find the duplicate once I looked.

Why this happens

Exchange keeps a forwarding flag on the object even after you remove the forward. It's a bug in the Exchange admin console or a remnant from a failed migration. When you add an alias that matches a forwarded address, Exchange sees the flag and throws 0X000008E3. The system thinks, "Hey, this alias is already being forwarded somewhere—can't add it again."

It's not a permissions issue or a server problem 99% of the time. It's stale data. ADSI Edit lets you reach into the object's attributes and delete the junk Exchange left behind. That's why it works when the GUI doesn't.

Less common variations

Sometimes the error shows up when creating a contact or distribution group, not a mailbox. The fix is the same but the attribute names differ slightly:

For contacts: clear targetAddress (external email address) and check msExchRecipientDisplayType — set it to 2147483648 (default mailbox user) or 1073741824 (mail-enabled contact).
For distribution groups: check reportToOwner and managedBy references that might loop back to the alias.
If the alias is for a public folder, run Set-PublicFolder with -MailEnabled $true and then remove any forward.

I had a weird one where the alias was for a resource mailbox that had been deleted but not purged. The tombstone object still held the forwarding attribute. Had to run Remove-ADObject on the deleted object first. Pain in the neck, but fixed.

Prevention

This error comes from sloppy mailbox moves or migrations where forwarding addresses don't get cleaned up. Here's how to avoid it:

Before you add an alias, run Get-Recipient | Where {$_.EmailAddresses -like "*alias*"} to check if it's already in use anywhere—even on deleted objects.
After removing a mailbox, purge it from the database: Remove-Mailbox -Identity "user" -Permanent $true. That kills the forwarding references.
Don't rely on the Exchange admin center for removing forwards on shared mailboxes. Use the shell—it's faster and doesn't leave hidden flags.

And if you're migrating from SBS 2011, check every user's forwarding address manually before you start. That platform loved to leave orphaned forwards because of its weird integration with the old Windows Small Business Server console.

Call it a day: 0X000008E3 is a data mess, not a disaster. Hit it with ADSI Edit or the shell, clear the forwarding attribute, and move on. Don't waste time rebuilding mailboxes or restarting servers—that's just noise.