Exchange 2013 CU 10 does not obey "ms-exch-smtp-accept-authoritative-domain-sender" setting


  • My customer is running a single (multirole) Exchange 2013 server, patched to CU 10 (build 15.1130.7), with 1 Internet-facing receive connector.  We are having a spam issue where outside (Internet) senders are sending messages to our internal users as themselves, eg receives a spam message from is one of our accepted domains.

    To prevent this, we used ADSI Edit to remove the "ms-exch-smtp-accept-autho
    ritative-domain-sender" permission for anonymous logons on the Internet-facing receive connector:

    -->ADSI Edit-->Configuration-->Services-->Microsoft Exchange-->Administrative Groups-->Exchange Administrative Group-->Servers-->[server name]-->Protocols-->SMTP Receive Connetors-->[Internet-facing Receive Connector]-->right click, view properties, go to security, select anonymous logon, uncheck "Accept Authoritative Domain Sender".

    When this is done, the only 3 remaining "Allow" checkmarks for anonymous logon are: "Submit Messages to Server", "Accept Routing Headers", and "Accept Any Sender".

    When this change is made in Exchange 2010 (we have a lab server with 2010), when we tested by sending a message using telnet from to, it works correctly and the message is refused as expected.  When we do the same thing on the Exchange 2013, the message is delivered, even if we set an explicit "deny" on "Accept Authoritative Domain Sender" instead of just unchecking it.

    At least one other company has reported this issue:

    The suggested work-around is to use Exchange's antispam filter to block anything coming from

    but this is awkward to set up and administer.

    Why doesn't 2013 obey the "ms-exch-smtp-accept-authoritative-domain-sender" permissions setting?  Would it help to update to CU 11?  How can we fix this without using a antispam filtering workaround?
    Thursday, March 17, 2016 9:38 PM


All replies

  • Internet mail senders don't authenticate to your server, so I'm surprised that ever worked for the purpose you're describing.

    If you don't want to procure a cloud, server or appliance antispam service that will do this for you, consider creating a transport rule to block inbound mail purporting to be from your own senders.

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Thursday, March 17, 2016 11:43 PM
  • Thanks, Ed.  We have on-prem Symantec Mail Security, and I think I'll create some rules that filter out the unwanted inbound messages. Transport rules would work too, thanks for the suggestion.

    It's just frustrating that a documented option for Exchange 2013 doesn't seem to work, when prior versions had no such issue.

    Thursday, March 17, 2016 11:48 PM
  • Hi,

    Sorry for any inconvenience, it's by design when CAS server is internet facing. Here's similar thread about this issue, for your reference:

    "This is a by-design behavior when your CAS server is now Internet facing. We can enable the Anti-Spam functionality on the mailbox server to perform reverse DNS lookup to prevent this issue. To enable the Anti-Spam functionality, please see

    We can use Anti-spam with SPF record to prevent spoofing.

    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact

    Allen Wang
    TechNet Community Support

    Friday, March 18, 2016 8:41 AM