Configure Exchange 2016 NDR with Proxmox Mail Gateway

If you want to stop backscatter while still allowing legitimate bounces, do the heavy lifting at the gateway and keep Exchange’s default NDR behavior conservative: configure Proxmox Mail Gateway to reject invalid/spam mail during the SMTP conversation and disable PMG’s own NDRs, and keep Exchange’s Default remote domain NDRs off while creating explicit RemoteDomain entries (or a transport rule) that enable NDRs only for trusted external domains. That combination (reject at SMTP + Default NDREnabled = $false + per-domain NDREnabled = $true) prevents most forged-sender bounces while allowing NDRs to partners you trust.

---

Contents

• How Exchange NDR and PMG interact
• 1) Proxmox Mail Gateway settings to avoid NDR/backscatter
• 2) Exchange 2016 configuration to suppress or limit NDRs
• 3) Allow NDRs only to a whitelist (PowerShell + GUI examples)
• 4) How PMG and Exchange settings interact — recommended step-by-step configuration
• Testing, verification and troubleshooting
• Sources
• Conclusion

---

How Exchange NDR and PMG interact

Think of PMG as the first decision point on the internet edge. If PMG rejects a connection or rejects a RCPT TO during the SMTP dialogue (554 / permanent failure), the sending server gets the rejection and no downstream system will generate an NDR that might backscatter to a forged address. If PMG accepts the message and forwards it to Exchange, Exchange treats it as accepted and will later generate any necessary DSNs/NDRs — unless you’ve configured Exchange not to send them to external domains. That’s why the best practice is: reject bad mail at PMG where possible, and on Exchange use the Default remote-domain NDR setting as a safety net and explicit RemoteDomain entries (or transport rules) to allow NDRs only for trusted partners. See the Proxmox admin guide on blocking vs rejecting and the Microsoft RemoteDomain cmdlet for the Exchange side PMG admin guide and Set-RemoteDomain.

---

1) Proxmox Mail Gateway settings to avoid NDR/backscatter

Why do this at the gateway? Because rejecting at SMTP stops forged-sender bounces before your servers ever accept the mail.

Key PMG controls and recommended settings

• Reject at SMTP (preferred). Configure PMG to verify recipients at RCPT TO and reject unknown recipients with a 5xx code. Rejecting during the SMTP dialogue prevents later bounces and is the primary backscatter prevention technique described in the Proxmox docs and product notes (reject with 554 is common) Proxmox press release: SMTP rejection approach.
• Disable PMG-generated NDRs. PMG has an ndr_on_block setting (in /etc/pmg/pmg.conf) that controls whether PMG itself sends a bounce/NDR when it blocks mail. Keep that disabled so PMG doesn’t generate bounces to potentially forged senders. The admin guide documents this behavior: disabling NDRs on block reduces RBL listings and backscatter risk PMG admin guide.
• Example (conceptual) change: edit /etc/pmg/pmg.conf and set the NDR-on-block option to disabled according to the PMG admin guide. Then apply/reload PMG configuration using the PMG-recommended method.
• Quarantine vs bounce: Quarantine (or drop to a quarantine mailbox) is safe because it avoids creating external bounces. If you must notify someone, notify an admin or the local recipient (internal UI), not the (unverified) sender address.
• Reject spam/virus with SMTP 5xx codes where appropriate. For confirmed malware and clearly forged senders, prefer a permanent SMTP reject instead of accepting and later bouncing.
• Enable recipient verification (LDAP/AD lookup) if PMG can query your directory. If PMG can confirm the recipient exists before accepting mail, it can reject unknown targets at SMTP time and drastically reduce backscatter. The Proxmox forum and docs emphasize validating recipients at connection time to prevent bounces later Proxmox forum discussion.

Quick checklist for PMG changes

• Disable ndr_on_block (via config/UI) — prevent PMG-generated NDRs.
• Turn on recipient verification (LDAP/AD) so PMG rejects unknown RCPT TO during SMTP.
• Configure spam/virus actions to reject (5xx) or quarantine — do not accept-and-bounce.
• Test by sending to a clearly invalid recipient and confirm PMG returns a 5xx at RCPT TO.

---

2) Exchange 2016 configuration to suppress or limit NDRs

Exchange’s RemoteDomain objects control whether Exchange will send NDRs to external addresses. The Default remote domain is the catch-all for destinations that don’t have a specific RemoteDomain object. Typical strategy: keep Default NDRs disabled, and enable NDRs only for explicit, trusted remote domains.

Important cmdlets and behavior

• Disable NDRs globally (Default):
• Set-RemoteDomain -Identity "Default" -NdrEnabled $false
• Verify with: Get-RemoteDomain | Format-Table Name,DomainName,NDREnabled
• Many admins use that exact command to stop Exchange from sending NDRs to arbitrary external senders; the AuthSMTP article references exactly this approach for Exchange 2016 AuthSMTP Exchange 2016 guide.
• Create per-domain RemoteDomain entries for trusted partners:
• New-RemoteDomain -Name "Partner-Example" -DomainName "partner.example"
• Set-RemoteDomain -Identity "partner.example" -NdrEnabled $true
• Specific RemoteDomain entries override the Default object, so a whitelist entry for partner.example will permit NDRs to that domain while the Default blocks NDRs for everyone else (see Microsoft docs for Set-RemoteDomain behavior) Set-RemoteDomain documentation.
• Transport-rule (fallback) option:
• You can create a mail flow rule (Exchange Admin Center → Mail Flow → Rules) that matches message type “Non-Delivery Report” and deletes or blocks it unless the recipient domain is whitelisted. That’s a belt-and-suspenders measure if you want to be extremely strict, and it’s handy when you can’t modify the gateway immediately.
• GUI example: New rule → Apply if: The message type is: Non-Delivery Report → Except if: Recipient domain is (add whitelisted domains) → Do the following: Delete the message without notifying anyone.

Caveats

• If Default is already False (your current output shows Default False), incoming NDRs you’re seeing may originate from PMG or another upstream system, not from Exchange. Verify the NDR source before changing Exchange again.
• Disabling NDRs can mask legitimate delivery problems that external senders should see; use per-domain whitelists to enable NDRs for partners who rely on them.

---

3) Allow NDRs only to a whitelist (PowerShell + GUI examples)

Goal: keep all external NDRs off by default, but allow them for partner domains such as partner.example and vendor.example.

PowerShell example (step-by-step)

1. Confirm current state:

• Get-RemoteDomain | Format-Table Name,DomainName,NDREnabled

2. Disable Default if needed:

• Set-RemoteDomain -Identity "Default" -NdrEnabled $false

3. Create a RemoteDomain for a trusted partner and enable NDRs:

• New-RemoteDomain -Name "Partner-Example" -DomainName "partner.example"
• Set-RemoteDomain -Identity "partner.example" -NdrEnabled $true

4. Verify:

• Get-RemoteDomain | Format-Table Name,DomainName,NDREnabled

GUI example (Exchange Admin Center)

1. EAC → Mail flow → Remote domains.
2. Ensure the Default entry has “Send NDRs” set to off (or NDREnabled = false).
3. Click + to add a new remote domain:

• Domain name: partner.example
• Options: enable non-delivery reports (check the box)

4. Save and test.

Transport rule whitelist alternative (GUI)

1. EAC → Mail flow → Rules → + → Create new rule.
2. Name: “Drop outbound NDRs except partners”.
3. Apply if: “A message type is” → choose “Non-Delivery Report”.
4. Except if: “The recipient domain is” → add partner.example, vendor.example.
5. Do the following: “Delete the message without notifying anyone”.
6. Save, test carefully.

Notes

• RemoteDomain entries are cleaner and intended for this use. Use transport rules only if you need additional conditions (message headers, sender IPs, etc.).
• For large partner lists, script the creation of RemoteDomain objects in PowerShell.

---

4) How PMG and Exchange settings interact — recommended step-by-step configuration

Practical sequence to deploy safely in a production environment:

Step A — Harden PMG first (edge)

1. Enable recipient verification (LDAP/AD) so PMG rejects unknown RCPT TO at SMTP time. This is the single best move to reduce backscatter.
2. Disable PMG’s NDR-on-block behavior (set ndr_on_block to disabled) so PMG doesn’t generate bounces for blocked mail; see the PMG admin guide for where to change that setting PMG admin guide.
3. Configure spam/virus policies:

• For confirmed malware: reject with a 5xx SMTP code.
• For high-confidence spam you don’t want to reject outright: quarantine it (no external NDR).

4. Make sure PMG returns SMTP 5xx at RCPT TO for invalid recipients; do not accept-then-bounce.

Step B — Configure Exchange safety net

1. Confirm Default remote domain NDRs are disabled:

• Set-RemoteDomain -Identity "Default" -NdrEnabled $false

2. Decide your whitelist of external partners that must receive legitimate NDRs. For each partner:

• New-RemoteDomain -Name "Partner" -DomainName "partner.example"
• Set-RemoteDomain -Identity "partner.example" -NdrEnabled $true

3. Optionally add a transport rule to drop any outbound NDR messages unless the recipient domain is on your whitelist (EAC mail flow rules). This is a fallback in case PMG or another device slips through.

Step C — Test and validate

1. On PMG: send a test to a non-existent mailbox — confirm RCPT TO returns 5xx (no acceptance).
2. From a whitelisted partner address, send a test to a deliberately broken internal target and confirm Exchange returns an NDR (if allowed).
3. From a non-whitelisted address, cause a delivery failure and confirm no NDR is sent.
4. Use PMG and Exchange logging during tests. On Exchange use Get-MessageTrackingLog and on PMG check mail logs. If you see an NDR that shouldn’t have been sent, inspect headers to determine which host generated it.

Why this order?

• If you configure Exchange first but PMG keeps accepting forged mail and generating NDRs, you’ll still get backscatter. Fix the gateway first (it’s the entry point), then tighten Exchange as a second line of defense.

---

Testing, verification and troubleshooting

Quick checks to identify who is generating NDRs

• Examine the headers of the NDR message. The topmost Received: lines and the From:/Return-Path/Diagnostic-Code fields usually identify the MTA that created the bounce.
• On Exchange, run message tracking for the affected message or recipient:
• Get-MessageTrackingLog -Recipients "user@yourdomain.com" -Start "<time>" -End "<time>" | where {$_.EventId -match "FAIL|DEFER|SEND"}
• On PMG, check /var/log/mail.log or the PMG GUI logs for entries showing a bounce or NDR generation.
• If the socket-level dialog returned a 5xx at RCPT TO, the upstream sender should not generate an NDR from you — it was rejected.

Common root causes and fixes

• PMG is accepting mail (2xx) and then later bouncing: enable recipient verification or change spam/virus policies to reject/quarantine.
• Exchange is sending NDRs despite Default False: verify you have RemoteDomain exceptions or transport rules that might be allowing specific cases; check whether the NDR originates from Exchange or from an upstream host.
• A third-party relay or an upstream ISP is generating a bounce on your behalf: inspect Received headers to find that host, then fix the relay configuration or contact the relay owner.

Additional monitoring

• Watch for sudden increases in outbound bounce volume — that’s often the first sign of backscatter and potential listing on RBLs.
• Keep logs for a week after changes to ensure legitimate NDRs aren’t being suppressed unexpectedly.

---

Sources

1. Exchange 2016 - Disable non-delivery reports (NDR / DSN)
2. Proxmox Mail Gateway Administration Guide
3. Backscatter IP Blacklist due to NDRs — Proxmox forum
4. Set-RemoteDomain (ExchangePowerShell)
5. Reddit r/exchangeserver thread: Exchange backscatter / disable NDRs
6. Solved: Exchange 2016 BackScatter configuration — Experts-Exchange
7. Proxmox Mail Gateway 6.2 press release — rejecting during SMTP dialogue
8. Procedures for DSNs and NDRs in Exchange Server
9. Remote domains: Exchange 2013 Help
10. How to block outgoing emails with mail flow rules in Office 365 (pattern for transport rules)

---

Conclusion

Reject bad mail at the edge and be conservative on Exchange: configure PMG to verify recipients and return 5xx at SMTP time, disable PMG’s NDR-on-block behavior, and set Exchange’s Default RemoteDomain NdrEnabled = $false. Then create explicit RemoteDomain entries (or a narrowly-targeted transport rule) to enable NDRs only for trusted external domains. That two-layer approach—gateway rejection plus per-domain Exchange exceptions—minimizes backscatter while preserving legitimate bounce behavior for partners.