Exchange 2013 backscatter issue - recipient validation without Edge


  • Hello all,

    It looks like there is a flaw by design in Exchange 2013 recipient validation, which in turn causes backscatter issues. I failed to find a way around it, maybe someone could help.

    The Design: 2 x Exchange 2013 CAS + MBX servers (hardware NLB & DAG)

    Version: Exchange Server 2013 Cumulative Update 3 (CU3) (Version 15.0 (Build 775.38)  )

    The issue:

    Recipient validation has a flaw, which is documented (probably that should make it a "feature", but it doesn't): 
    In short - Recipient validation on Mailbox servers blocks message to all recipients, if at least one of them is non-existent.

    As there is no way to explain the logic of blocking e-mails to valid recipients if at least one of them is invalid to a customer, the Recipient validation on Mailbox servers becomes unusable and is disabled.

    But if the recipient validation is disabled, the Exchange design without Edge servers or other perimeter SMTP servers that could block e-mails to non-existent recipients, becomes vulnerable to backscatter SPAM attacks, since Exchange will always send out NDR to the FROM address.

    According to the answer in the thread mentioned above, other antispam features should prevent it, but as always with antispam - it's not even close to 100% effective, as recipient validation would be. The result - an entry in

    Question: How to prevent backscatter in Exchange 2013 without Edge servers, and without loosing valid e-mails due to recipient validation bug ("feature")?

    Thank You for Your help.

    • Edited by Vincas R Tuesday, July 22, 2014 1:52 PM
    Monday, July 21, 2014 7:54 AM


All replies

  • Hello,

    Thank you for your question.

    I am trying to involve someone familiar with this topic to further look at this issue.

    If you have feedback for TechNet Subscriber Support, contact

    Simon Wu
    TechNet Community Support

    Wednesday, July 23, 2014 2:34 AM
  • Hi Vince,

    According to this article, it is a by design behavior.

    Please see the Note.

    Wednesday, July 23, 2014 4:27 AM
  • Hi Richard,

    Thanks for the information.

    Any way to prevent backscatter in Exchange 2013 without Edge servers, and without losing valid e-mails due to recipient validation feature?


    Simon Wu
    TechNet Community Support

    Wednesday, July 23, 2014 8:05 AM
  • Hi, it seems to be a feature on anti-spam.

    For example:

    Wednesday, July 23, 2014 9:38 AM
  • Hi Richard and Simon,

    Thanks for the replies from both of You.

    Richard, as fas as I know, Forefront Protection is for Exchange 2010, and is not available for Exchange 2013. The article above about backscatter filter You have provided a link to, is also meant for Forefront for Exchange 2010.

    Exchange 2013 native antispam protection has no settings, and I'm not even sure, if it has backscatter filter (at least I cannot find it documented anywhere), or am I missing something?

    Are You saying, that I need a third party anti-spam solution to prevent backscatter, if I do not have Edge or other perimeter SMTP servers?

    Because it would be much much easier to install some VERY BASIC perimeter SMTP, that would do just recipient filtering to achieve this goal. I was just hoping to avoid extra servers ..


    Wednesday, July 23, 2014 10:00 AM
  • Hi Vince,

    Yes, Forefront is for Exchange 2010. And in Exchange 2013, this feature is based on Edge server.

    If we don't have an edge role, I think it's hard to prevent backscatter. Maybe we need an anti-spam software.

    Thursday, July 24, 2014 6:01 AM
  • Hi Richard,

    Thanks for an honest answer. I was hoping I've missed something, because this looks like a serious design flaw, since almost all small-medium business Exchange 2013 deployments that do not have perimeter SMTP will be producing SPAM via backscatter.

    I was hoping for something crazy simple, like some sort of Exchange transport rule or maybe a custom transport agent I can download.
    If nobody else offers some other possible solution soon, I will have to accept Richards answer.


    Thursday, July 24, 2014 7:06 AM