Using Transport Rules to Restrict Users from Sending Email to External Recipients

I frequently see questions such as this one about how to restrict users on the network from being able to send emails to external recipients.

I actually wrote an article on the subject about four years ago, though it deals with one specific scenario of “deny most, allow some”, and even though it was written when Exchange Server 2007 was the latest version it still demonstrates how Transport Rules can be used to achieve various restrictions on what email senders can do.

In this article I will specifically answer the question of how to restrict a small number of specific users from being able to send emails to recipients outside of the organization.

The first step in this method is to create a distribution group. The members of this group will be the users who are restricted from sending external emails. It does not need to be a security group, but it does need to be universal in scope.

Next, create a new Transport Rule with the following configuration.


  • From a member of a distribution list (and choose the distribution group you created above)
  • Sent to users that are inside or outside of the organization, or partners (and choose “Outside”)


  • Send rejection message to sender with enhanced status code (I set the status code to 5.7.1 and configure a message such as “You are not authorized to send email to recipients outside of this organization”)

Exceptions: (optional)

  • Except when a recipient’s address matches text patterns (and add any domain names or email addresses they should still be allowed to send to)

After the new rule has taken effect the members of that distribution group will not be able to send to external recipients, whether they use the To, CC, or BCC fields to do so, and will still be able to send to those domains or email addresses you configure as an exception to the rule (even if the message includes other recipients that will get blocked, the permitted ones will still receive the email).


About Paul Cunningham

Paul is a Microsoft Exchange Server MVP and publisher of Exchange Server Pro. He also holds several Microsoft certifications including for Exchange Server 2007, 2010 and 2013. Connect with Paul on Twitter and Google+.


  1. Paul

    Great article, i only wanted a specific user to be able to send internal emails. I followed your instructions to the T and they worked perfectly, however i have now removed the specific user from the distribution group (only user in the group) but it still blocks any outgoing emails, i have logged the user off and on again, restarted the pc, re-added a dummy account to the dissolution group, logged the user off and on again and waited for a couple of hours and its still being blocked.

    Is there a period of time for how long it takes to update all the setting in Exchange 2010 SP2 and 2008 R2 AD when removing users from distribution groups?

    Also for another user is it possible to block specific email address and domains.


    • Yes there is a delay, I believe up to 4 hours, for changes like this to kick in. Hopefully by now your change has worked :)

      • Thanks for the reply and yes all is working as normal after the 4hrs. Not sure if its possible to lower the refresh time from 4hrs to 5mins.


    • Hi Paul,

      How can I configure it in 2007 Except when a recipient’s address matches text patterns option is not available there in exchange 2007 .Is there any option to add this in exchange2007.
      Because of the same users can able to send mails to external world if they put it in cc or bcc.

  2. Joerg Renggli says:

    Hi Paul,

    Is it possible to Limit the “Maximum numper of recipients” only on outgoing Mails, but not for internal Mails?

    Thanks you

  3. Forgive my denseness, but is there a way to set a user up so that they can only send emails to one specific external domain?

    We have students from an external organisation who need to send timesheets back to their host employer. I have currently got one of our email address for them to use but I don’t want them to be able to send anywhere else other than anyone at “”.

    Is there an easy way to do this?

    • Transport rules should allow you to do this. Each rule has a criteria, action, and exceptions. So the criteria would be “From user X” (or a group), action would be “Reject” or similar, and exceptions would be “Unless recipient is in domain Y”.

      I’m only vaguely describing it there, but if you explore the New Transport Rule wizard and do some testing you’ll see what I mean.

  4. Hi Paul,

    I have the rule and want to add 200 members to restrict sending emails to internet. Instead of adding users i am planning add one securtiy group and merge it in to existing Group which is being used by transport rule for external email blocking.

    Please suggest me what happened if we add groups in TR instead of users. Will TR takes time to process the action?

  5. I’m just a new here.
    I want my DL of exchange user sending to specify domain.
    e.g; i want some DL to allow ” * ” ” * ”

    With my regards,

  6. Paul

    That was very useful as I am now able to configure and edit the transport hub effectively.

    But I am now looking to configure the relay to restrict/allow mail from my code but i am getting the following error

    I get this error message: ‘Mailbox unavailable. The server response was: 5.7.1 Unable to relay’


  7. Hey Paul,

    is it possible to get the powershell command for that ? We wanna deny one user in one specified org to send emails.

    Greetings Oliver

  8. ■Except when a recipient’s address matches text patterns option is not available there in exchange 2007 .Is there any option to add this in exchange2007.

  9. Thanks for sharing this, Paul. Any links or pointers that you can share, to add custom rules via C# or something ,would be helpful. Am looking to create a new custom rule that looks for specific patterns in the to and from email addresses.



  10. Dear Paul,

    is possible to deny permission to send outside the organization for a user not owner of the mailbox but that has ‘send as permission’?
    We have a transport rule for deny permission to send out for user in a specific group but if an user has ‘send as’ permission for a mailbox whose owner isn’t in the group he can send out from this shared mailbox, and we want to avoid this situation.
    Thank for any suggest!

    • Not possible as far as I know.

      Send As is a powerful right that you grant to somebody. If you can’t trust them with it then don’t grant it to them.

      • Christian says:

        Thanks Paul,

        but is not a problem about trusting or not a user but just be aligned with a organization policy. The annoying thing is that in 2003 ( before migration to 2010) the ‘delivery restriction ‘ setting in the SMTP connector did exactly what we wanted: the delivery restriction deny all except who is in a security group. With this configuration only the user in the group can send (with ‘send as’ permission’) outside from a mailbox it does not own.
        My guess is that in exchange 2003 the ‘smtp delivery restriction’ looked permissions not only for the owner of the mailbox but also the ‘send as’ or ‘on behalf to’ user permissions.
        This behaviour is changed in 2007/2010 with transport rules but there is no technical explanations from Microsoft documentation of this change.

  11. Hey there I am so thrilled I found your site, I really found you by
    error, while I was browsing on Google for something else, Nonetheless
    I am here now and would just like to say thanks a lot for a marvelous post and a all round
    entertaining blog (I also love the theme/design), I
    don’t have time to read it all at the minute but I
    have bookmarked it and also added in your RSS feeds, so when I have time I will be
    back to read much more, Please do keep up the superb job.

  12. Maybe if Is just a few users – set the delivery option for maximum number of recipients to zero.

  13. Hi Paul,

    Thanks for sharing. However I am having the same problem as Tom, I couldn’t find the “Except when a recipient’s address matches text patterns option” in my Exchange 2007 Version: 08.03.0298.001.

    I want to restrict a user to send email to certain email address only.
    I’m currently using “except when a text pattern ( appear in a message header (TO)” but it doesn’t perfectly meet my requirement.

    Appreciate if any help can be provided.

  14. Hi,

    To elaborate further, it does not meet my requirement because from what I have tested,
    this text pattern exception will allow the email to go thru when there are multiple recipients, and one of them is permitted.

    Thank you.

    • I agree with Nick…

      The user can simply CC themselves and send to any external recipient. The rule doesn’t trigger because one of the “users” is internal, so pretty easy to get around.


  15. Sundaresan says:

    I have set this transport rule. But the thing is, if i give individual email id, the mail gets blocked for that user to external domains immediately i click apply for the rule settings. But if i do this for a distribution group, it does not apply this rule and i didn’t get any bounced mail. Mail gets delivered successfully.

    So is the delay what you talk about is for applying rule from a distribution group? but not for an individual id?

    • Sundaresan says:

      I got it. Its the same 4 hrs frequency applied even for the first time when we add any user to a distribution group.

      Only individual mail id rules are applied instantly..


  16. Is there a power shell command that will hide all distro groups within the GAL or deny the sending to all Distribution Groups from 1 Distribution group?

    In other words, I have 1 Distribution group, that I do not want to be able to send to any other Distribution groups, nor do I want them to see Distribution Groups within the GAL.


    • You can use transport rules to create ethical walls between DLs.

      GAL visibility is a different matter. You would probably need to use Address Book Policies to achieve what you’re asking for there.

Leave a Comment


We are an Authorized DigiCert™ SSL Partner.