The "Masquerade Domain" setting in Exchange 2003 and what it REALLY does.

Posted on 2006-05-19
Last Modified: 2012-06-21
I was having trouble understanding what a Masquerade Domain setting in Exchange 2003 was for because the help file explanation was very short.  After a good hard search on the net I’ve found a LOT of confusion between what Masquerading Domain means and what the actual setting in exchange 2003 really DOES.  The setting in exchange 2003 does NOT do what it sounds like.  The true “masquerading domain” is really done on the setting right below that (Fully-qualified Domain Name field).  

Here is what I came up with:

-From the Exchange 2003 internal Help File for "Masquerade Domain" field:
Use this text box to type an alternate domain for other SMTP servers to use when sending non-delivery reports (NDRs). NDRs will be returned to the alternate domain specified, instead of the domain from which the e-mail message originated.

-From the Exchange 2003 internal Help File for “Fully-Qualified Domain Name” field:
Use this text box to type the fully qualified domain name (FQDN) of the virtual server. You can specify a FQDN other than the one used by this computer.

-From Microsoft:  (;en-us;314331&sd=tech)
Note:  The SUMMARY says: “A masquerade domain replaces the local domain name in any Mail From lines in the message header.”

This definition is correct, but what the actual SETTING does is different!!!  The “fully-qualified domain name” box does that.  Later in the article, it says: “in the Masquerade Domain box, type the domain name that should receive any nondelivery reports.”  And then “If you want to override the default FQDN, type a new value in the Fully-qualified Domain Name box, and then click Check DNS to ensure that you have entered the correct value and that DNS resolution is configured properly.”

-From the book Sybex Exchange Server 2003:
A masquerade domain is an alternate domain to which other SMTP hosts send their nondelivery reports.

The problem is “Masquerade Domain” definition means one thing, but the actual setting in Exchange 2003 is really for something else.  I can’t believe how badly labeled that field is.

On another note, you should really have your REVERSE DNS FQDN in the “Fully-qualified Domain Name box” and make sure your mx record IP address gets reverse-dns’ed to that FQDN.  This is really for any mail server that is checking Reverse DNS info to make sure you are not a possible spammer and have that you have the correct entries.

Why would someone even USE the "Masquerade Domain" Field in exchange 2003 in the first place?  I can’t figure out the benefit.

Am I correct in coming up with these conclusions?

- Ginel Lipan
Question by:vrmanrtell
    LVL 104

    Accepted Solution

    I Can't remember the last time I set the masquerade domain on any server that I have configured to date.
    That is probably because I always use a real domain name - not a .local in all of my deployments.

    It was my understanding that you would set that option if you were using a domain name that wasn't valid on the Internet, so that all the information in the headers was correct.

    The field below is used in the SMTP banner so should match the preferably both the forward and the reverse DNS of the server on the Internet as that information is used as an antispam feature.
    However in a recent update for the best practises tool, having that option set to something else other than the server's real name was throwing a critical error - it does cause problems in very set circumstances which most people will never see, so after complaints from the MVPs the item was changed.


    Expert Comment

    This explanation came from a MS Support Escalation Engineer:

    What masquerade domain setting does is it will change the return path of your exchange users address to the Domain you configured in that settings.  So when a NDR is to be sent to the original sender it will use the masquerade domain as the return path and not the actual senders smtp address of the sender.

    Example Header

    Thread-Topic: test 1:56
    Thread-Index: Acr7anbdkExvHA52TsyQU57CMFXM+w==
    From: "User Two" <usertwo@STD.LOCAL>
    Content-class: urn:content-classes:message
    x-mimeole: Produced By Microsoft Exchange V6.5
    To: <>

    In the above sample the information is
    1)      Sender email address = usertwo@std.local
    2)      Return-Path =

    So in this example the senders Actual email domain is STD.LOCAL but and NDR’s for this user will be sent to MASQUERADE.COM.   This will not change the FQDN being used to connect to the remote server.

    Hope this answers your question.


    Ed B. | Support Escalation Engineer | Exchange Connectors

    Featured Post

    Are your corporate email signatures appalling?

    Is it scary how unprofessional your email signatures look? Do users create their own terrible designs and give themselves stupid job titles? You can make this a lot easier for yourself by choosing an email signature management solution from Exclaimer today.

    Join & Write a Comment

    Suggested Solutions

    Easy CSR creation in Exchange 2007,2010 and 2013
    Find out how to use Active Directory data for email signature management in Microsoft Exchange and Office 365.
    In this video we show how to create a Resource Mailbox in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: Navigate to the Recipients >> Resources tab.: "Recipients" is our default selection …
    This video discusses moving either the default database or any database to a new volume.

    746 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    19 Experts available now in Live!

    Get 1:1 Help Now