Tag: DistributionGroup

  • Marked in Time — Fixing a “Sender not allowed” DL (redacted)

    Excerpt
    Our all-hands list rejected internal senders after we allowed two external addresses. Here’s what happened, how to fix it cleanly in Exchange Online, and a PowerShell snippet you can reuse.


    Intro
    Two days ago, I could email everyone@[redacted].com just fine. Today, my message bounced: “this group only accepts messages from people in its organization or on its allowed senders list.” We’d recently added two partner addresses (s@[partner].com, j@[partner].com) so they could email the DL. That change flipped the DL into strict allow-list mode—blocking even internal senders who weren’t explicitly listed. Here’s the minimal, durable fix.


    Straight line (what happened)
    • Symptom: NDR when sending to everyone@[redacted].com from an internal account.
    • State check showed:
    – RequireSenderAuthenticationEnabled: False
    – AcceptMessagesOnlyFromSendersOrMembers: {} (and earlier, it contained only the two partner GUIDs).
    • Root cause: Delivery management was saved in “only these senders” mode; membership/ownership doesn’t matter in that state.
    • Goal: Let all internal, authenticated users send; allow only specific externals; block the rest.


    Fix (clean model)

    1. Let internal, authenticated users send to the DL (no hard allow-list on the group).
    2. Enforce external restrictions with a transport rule that allows only the partner exceptions.

    Commands (PowerShell — Exchange Online)

    Connect

    Connect-ExchangeOnline -ShowBanner:$false
    

    Allow internal, authenticated senders (clear hard allow-list)

    Set-DistributionGroup everyone@[redacted].com `
      -AcceptMessagesOnlyFromSendersOrMembers $null `
      -RequireSenderAuthenticationEnabled:$true
    

    Create the external block rule with an allow-list

    # remove if an older copy exists (safe if none)
    Get-TransportRule "Block external to Everyone (except allow-list)" -ErrorAction SilentlyContinue |
      Remove-TransportRule -Confirm:$false
    
    New-TransportRule "Block external to Everyone (except allow-list)" `
      -FromScope NotInOrganization `
      -AnyOfToHeader "everyone@[redacted].com" `
      -ExceptIfFrom "s@[partner].com","j@[partner].com" `
      -RejectMessageReasonText "External senders are not allowed for this list."
    

    Verify

    Get-DistributionGroup everyone@[redacted].com |
      fl PrimarySmtpAddress,RequireSenderAuthenticationEnabled,AcceptMessagesOnlyFromSendersOrMembers
    
    Get-TransportRule "Block external to Everyone (except allow-list)" |
      fl Name,State,FromScope,AnyOfToHeader,ExceptIfFrom
    

    Update the allow-list later

    # add another partner
    Set-TransportRule "Block external to Everyone (except allow-list)" `
      -ExceptIfFrom @{Add="newuser@[partner].com"}
    
    # remove a partner
    Set-TransportRule "Block external to Everyone (except allow-list)" `
      -ExceptIfFrom @{Remove="j@[partner].com"}
    

    Smoke tests
    • Internal sender → everyone@[redacted].com: delivers.
    • External sender (not on list): NDR with “External senders are not allowed…”
    • Allowed partner (s@[partner].com or j@[partner].com): delivers.


    Why not leave the DL in allow-list mode?
    Because it’s brittle. Every internal sender must be explicitly added, which guarantees future bounces and admin toil. Using RequireSenderAuthenticationEnabled for internal mail + a transport rule for externals gives you clarity and control.


    Final reflection
    Small toggles can have outsized effects. DL delivery settings look simple, but one checkbox can silently change who’s “allowed.” The durable pattern is: authenticate inside, whitelist outside, and verify with a quick trace.


    Pocket I’m keeping
    • Always snapshot DL settings before/after a change.
    • Prefer transport rules for external policy; don’t hard-gate internals via allow-lists.
    • Add a ready-to-run “add/remove external exception” snippet to the runbook.


    What I hear now
    Clarity beats cleverness. Make the rule obvious enough that the next admin can read it and know exactly who can send and why.

    © 2012–2025 Jet Mariano. All rights reserved.
    For usage terms, please see the Legal Disclaimer.

  • Fixing “Sender not allowed” to an internal group (Exchange Online) — a quick forensic + runbook


    POST BODY

    When a partner emailed our all-hands list, they got an NDR:
    “the group only accepts messages from people in its organization or on its allowed senders list… sender not allowed.”

    We’d solved this once before and didn’t capture the steps. This time we did.


    Forensic summary (redacted)

    • group: all@[corp-redacted].com
    • external sender: firstname.lastname@[partner-redacted].com
    • symptom: NDR “sender not allowed”
    • root causes:
      1. the group required authenticated (internal) senders only, and
      2. the external wasn’t on the group’s allowed-senders list
    • gotcha we hit: New-MailContact failed with ProxyAddressExists — an existing MailUser already owned the external SMTP, so we reused it instead of creating a new contact

    Straight line (what fixed it)

    1. identify group by SMTP and check whether it’s a DL or a Microsoft 365 Group
    2. locate the external as an existing MailContact/MailUser (include soft-deleted objects)
    3. add that object to the group’s AcceptMessagesOnlyFromSendersOrMembers list
    4. allow the group to accept external senders (keeps the allow-list in effect)
    5. test and confirm with Message trace

    Reusable runbook (PowerShell, redacted)

    # 0) Connect
    Connect-ExchangeOnline
    
    # 1) Variables (edit these)
    $GroupSmtp = "all@[corp-redacted].com"
    $ExternalAddresses = @("firstname.lastname@[partner-redacted].com")
    
    # 2) Resolve the group (works for DL or M365 Group)
    $grp = Get-EXORecipient -Filter "PrimarySmtpAddress -eq '$GroupSmtp'"
    $grp | fl Name,RecipientTypeDetails,PrimarySmtpAddress,Identity,ExternalDirectoryObjectId
    
    # 3) Ensure each external exists as a recipient we can allow (MailContact/MailUser).
    #    If already present (or soft-deleted), reuse it.
    $recips = @()
    foreach ($addr in $ExternalAddresses) {
      $r = Get-EXORecipient -ResultSize Unlimited -IncludeSoftDeletedRecipients `
           -Filter "PrimarySmtpAddress -eq '$addr'"
      if (-not $r) {
        try { New-MailContact -Name $addr -ExternalEmailAddress $addr | Out-Null
              $r = Get-EXORecipient -Filter "PrimarySmtpAddress -eq '$addr'" }
        catch { Write-Host "Contact already exists somewhere: $addr" }
      }
      $recips += $r
    }
    $recips | ft Name,RecipientTypeDetails,PrimarySmtpAddress -AutoSize
    
    # 4) Add externals to allow-list AND allow external senders
    if ($grp.RecipientTypeDetails -eq "GroupMailbox") {
      # Microsoft 365 Group (Unified Group)
      foreach ($r in $recips) {
        Set-UnifiedGroup -Identity $grp.ExternalDirectoryObjectId `
          -AcceptMessagesOnlyFromSendersOrMembers @{Add=$r.Identity}
      }
      Set-UnifiedGroup -Identity $grp.ExternalDirectoryObjectId -AllowExternalSenders:$true
      Get-UnifiedGroup -Identity $grp.ExternalDirectoryObjectId |
        fl DisplayName,PrimarySmtpAddress,AllowExternalSenders,AcceptMessagesOnlyFromSendersOrMembers
    } else {
      # Distribution Group / Mail-enabled Security Group
      foreach ($r in $recips) {
        Set-DistributionGroup -Identity $grp.Identity `
          -AcceptMessagesOnlyFromSendersOrMembers @{Add=$r.Identity}
      }
      Set-DistributionGroup -Identity $grp.Identity -RequireSenderAuthenticationEnabled:$false
      Get-DistributionGroup -Identity $grp.Identity |
        fl DisplayName,PrimarySmtpAddress,RequireSenderAuthenticationEnabled,AcceptMessagesOnlyFromSendersOrMembers
    }
    
    # 5) Message trace (adjust window)
    Get-MessageTrace -SenderAddress $ExternalAddresses[0] -RecipientAddress $GroupSmtp `
      -StartDate (Get-Date).AddHours(-2) -EndDate (Get-Date) |
      ft Received,Status,RecipientAddress,MessageId
    

    Common pitfalls we saw (and how we handled them)

    • ProxyAddressExists on New-MailContact → an existing MailUser/Contact already holds that SMTP; reuse it (or permanently remove the soft-deleted recipient first).
    • group can’t be found by display name → target by SMTP with Get-EXORecipient -Filter "PrimarySmtpAddress -eq '...'".
    • delivery still blocked after allow-list → the DL still required authenticated senders; set RequireSenderAuthenticationEnabled:$false (DL) or AllowExternalSenders:$true (M365 Group).

    Click-path (EAC, if you don’t want PowerShell)

    • Recipients → Contacts → add/find the partner’s contact
    • Recipients → Groups → open the group → Delivery management → “Accept messages from” → add the contact
    • For DLs: turn off “Require sender authentication”
    • For M365 Groups: enable “Allow external senders”

    Prevention / hygiene

    • keep an “Authorized External Senders — all” mail-enabled security group; allow that group on the DL/M365 Group, then just add/remove partner contacts over time
    • document the NDR verbatim and the message trace ID when you close an incident

    Redaction note

    All addresses and names are redacted. Replace with your real SMTPs when running the script.

    © 2012–2025 Jet Mariano. All rights reserved.
    For usage terms, please see the Legal Disclaimer.

error: Content is protected !!