Exchange: Allow only selected external senders to a distribution list

By default, an Exchange distribution list accepts messages only from authenticated, meaning internal, senders. If a partner, vendor, or customer should also be able to reach the list without opening it to the entire internet, there are two options: a delivery restriction on the group itself or a transport rule. Both work in Exchange Server 2016, 2019, and the Subscription Edition.

Starting point: RequireSenderAuthenticationEnabled

Whether a group accepts external messages at all is controlled by the RequireSenderAuthenticationEnabled property. If it is set to $true (the default for new distribution groups), Exchange rejects every message from an unauthenticated sender. Both of the following options therefore require this check to be disabled:

Set-DistributionGroup -Identity "Projektteam" -RequireSenderAuthenticationEnabled $false

Without further restrictions, after this step any external sender can write to the list. Restricting it to individual senders follows in the next step, ideally during the same maintenance window.

Option 1: Delivery restriction with mail contacts

The list of allowed senders (AcceptMessagesOnlyFromSendersOrMembers) accepts only objects from your own directory: mailboxes, mail users, mail contacts, and groups. You cannot enter a plain SMTP address there. Therefore, create a mail contact for each external sender. To keep the contact from appearing in the global address book, hide it:

$kontakt = @{
    Name                 = "Extern Max Muster"
    ExternalEmailAddress = "max.muster@partner.example"
    OrganizationalUnit   = "example.local/Kontakte/Extern"
}
New-MailContact @kontakt
Set-MailContact -Identity "Extern Max Muster" -HiddenFromAddressListsEnabled $true

Then add the contact as an allowed sender. The hashtable with Add appends to the existing list instead of overwriting it:

$erlaubt = @{ Add = "Extern Max Muster", "Extern Anna Beispiel" }
Set-DistributionGroup -Identity "Projektteam" -AcceptMessagesOnlyFromSendersOrMembers $erlaubt

As soon as this list contains at least one entry, Exchange rejects all other senders, including internal ones. If employees should continue to be able to write to the list, also add a suitable group, for example the distribution group itself (then all members may send) or a group containing all employees. Rejected senders receive a non-delivery report with status 5.7.1.

Check the current configuration as follows:

Get-DistributionGroup -Identity "Projektteam" |
    Format-List Name, RequireSenderAuthenticationEnabled,
        AcceptMessagesOnlyFrom, AcceptMessagesOnlyFromDLMembers

AcceptMessagesOnlyFromSendersOrMembers is a composite parameter: Exchange distributes the entries across the AcceptMessagesOnlyFrom (individual senders) and AcceptMessagesOnlyFromDLMembers (groups) properties. This is why the query shows those two properties. You can find the same setting in the Exchange Admin Center in the group properties under Delivery management.

This option is suitable when only a few external senders need to be added and the list of allowed senders should be visible directly on the group object. The disadvantage is the maintenance effort: each new sender requires a contact in Active Directory.

Option 2: Transport rule without contacts

If all internal users should still be able to write to the list and only external senders need to be restricted, a transport rule is simpler. It requires no contacts and can also apply to entire domains. RequireSenderAuthenticationEnabled must also be set to $false here.

$regel = @{
    Name                              = "Projektteam: nur freigegebene externe Absender"
    SentTo                            = "projektteam@example.com"
    FromScope                         = "NotInOrganization"
    ExceptIfFromAddressMatchesPatterns = '^max\.muster@partner\.example$',
                                         '@lieferant\.example$'
    RejectMessageReasonText           = "Sie sind nicht berechtigt, an diese Adresse zu senden."
    RejectMessageEnhancedStatusCode   = "5.7.1"
}
New-TransportRule @regel

Without anchoring with ^ and $, a pattern such as max\.muster@partner\.example would also match max.muster@partner.example.net. Add new senders with Set-TransportRule and the complete expanded list of patterns; the parameter replaces the existing list.

Limitation of both options: The sender address can be spoofed

Both options check only the sender address. Exchange does not determine whether the message actually came from the approved partner. Anyone who knows an approved sender’s address can spoof it and thus reach the list. For a list with internal participants, this is an entry point for phishing that also appears to come from a familiar address.

SPF, DKIM, and DMARC close this gap. If the partner’s domain has a DMARC policy with p=reject or p=quarantine and your mail gateway enforces that policy, spoofed messages from that domain never reach Exchange in the first place. This protection is absent for domains without a DMARC policy or with p=none.

If your gateway writes the check result to the Authentication-Results header, a second transport rule can additionally reject approved senders when DMARC has not passed:

$regel = @{
    Name                            = "Projektteam: freigegebene Absender nur mit DMARC pass"
    SentTo                          = "projektteam@example.com"
    FromScope                       = "NotInOrganization"
    FromAddressMatchesPatterns      = '^max\.muster@partner\.example$',
                                      '@lieferant\.example$'
    ExceptIfHeaderMatchesMessageHeader = "Authentication-Results"
    ExceptIfHeaderMatchesPatterns   = 'dmarc=pass'
    RejectMessageReasonText         = "Absender konnte nicht verifiziert werden."
    RejectMessageEnhancedStatusCode = "5.7.1"
}
New-TransportRule @regel

This rule works reliably only if the gateway removes or overwrites incoming Authentication-Results headers from the internet. Otherwise, a sender can supply the header with dmarc=pass themselves. Your gateway’s documentation describes which headers it sets and whether it removes foreign headers; Exchange itself does not evaluate DMARC.

Which option fits

The delivery restriction with contacts is suitable for lists with a fixed, small group of external senders and can also restrict internal senders if desired. The transport rule is suitable when all internal users may send, entire partner domains should be allowed, or no contacts should be created in Active Directory. Regardless of the option, check the DMARC policy for every approved domain and document who maintains the list of allowed senders.