A Proxmox Mail Gateway (PMG) setup begins by deciding which messages pass through PMG and where they go next. PMG sits between the Internet and your existing mail server to inspect messages before forwarding them; it is an email security proxy, not a mailbox service.

SMTP relay is the forwarding of an email message from one mail system to another using SMTP. For email administrators, safe deployment requires a documented mail route, domains, trusted relays, DNS/MX decisions, TLS, filtering and a tested rollback. These decisions let you add inspection without replacing mailbox delivery.

This documentation-based planning guide provides checks for your own deployment; it reports no Academy mail-cutover test results. Sources were reviewed on 19 October 2026.

Key Takeaways

Keep users’ mailboxes on the existing mail server.
Document routes before installing PMG.
Separate filtering from mailbox storage.
Plan trust permissions before moving traffic.
Check actual delivery before moving production traffic.

Do not mistake a new gateway for a replacement mailbox host. Establish who controls each part of the route before deployment begins.

What a Proxmox Mail Gateway setup needs

Before installing PMG, establish who can change your organisation’s MX records and the related mail routes. A working appliance does not give you control over the systems needed to move mail safely.

Assign one accountable change owner even when technical responsibilities are split. MX ownership, firewall administration and mail server administration may sit with different teams. Record their decisions before scheduling production traffic.

Check	Record before deployment	Ready when	Accountable role
Domain and MX ownership	accepted domain names, DNS provider and authorised editor	an authorised editor can change and restore records	DNS administrator
Relay destination and approved domains	existing mail server hostname or IP, domain list and route exceptions	each approved domain has a confirmed destination	mail administrator
Firewall paths	permitted source, destination and service for each mail direction	network owner has approved each required path	network administrator
Certificates and monitoring	TLS names, renewal owner, alert destination and queue checks	certificate ownership and alert response are assigned	operations administrator
Change owner and recovery	cutover window, rollback decision maker and saved configuration location	one named person can authorise reversal	change owner

Replace role names with named individuals in the completed worksheet. One person may hold several roles, but each responsibility still needs an explicit assignment. Confirm that those people will be available during the planned change, rather than relying on access held by an absent colleague.

DNS access alone does not prove that you can change a hosted mail service’s connector configuration. Record that permission separately from the relay destination, and resolve any approval dependency before committing to a window.

For a separate read on deployment discovery, see ReadySpace Academy’s Proxmox Discovery page. Use the completed ownership and destination records to draw both message routes.

Map inbound and outbound mail flow

Follow a message addressed to your organisation’s user: an Internet sender reaches the perimeter firewall, then PMG’s untrusted SMTP listener, before PMG forwards permitted mail to the existing mail server. Inbound SMTP reception does not grant permission to send through PMG to unrelated external recipients.

Restrict trusted outbound relay to authorised sending systems. Your Proxmox Mail Gateway mail flow must separate public reception from outbound trusted relay, which belongs only to explicitly authorised sending systems.

Direction	Route	Listener and trust	Expected handling
Inbound	Internet sender > perimeter firewall > PMG > existing mail server	untrusted SMTP listener, public senders	inspect and forward only mail permitted by domain and recipient policy
Outbound	existing mail server > PMG > Internet recipient or approved upstream relay	trusted SMTP listener, authorised sending hosts	inspect and relay under the outbound policy
Unauthorised transit	Internet sender > PMG > unrelated external domain	untrusted SMTP listener, no relay authorisation	reject relay attempt

Mail clients normally retain their existing submission route to the existing mail server. Adding PMG does not automatically move users’ client connections to the gateway. The existing mail server can pass authorised outbound traffic to PMG without changing where users submit messages.

Check the destination at every hand-off. A routing loop occurs if the existing mail server sends inbound deliveries back to PMG instead of delivering them locally. Distinguish local mailbox delivery from the route used for external recipients, including any exceptions for particular domains.

Draw an approved upstream relay explicitly if outbound messages use one; do not leave that hop implied. Turn the routes into explicit domain, network and DNS decisions.

Plan DNS, relay domains and trusted networks

An MX record directs delivery; a trusted-network entry grants relay permission. Relay domains control permitted destination domains, while trusted networks identify authorised sending systems. Accepting mail for an organisation does not authorise its entire network to send arbitrary outbound mail.

Specify a stable gateway address and fully qualified domain name. The SMTP specification describes mail routing using MX information. An MX target is a mail exchanger hostname, not an IP address. Record the planned MX target and its address records so that hostname resolves to the intended gateway-facing address.

Set the default relay destination to the intended forwarding system. Record domain-specific transport routes where they override that default. Domain acceptance does not establish that an individual recipient exists: confirm a separate recipient validation method with the existing mail server.

Restrict trusted networks to necessary sending hosts, accounting for the source address PMG actually sees after NAT. A shared translated address can hide distinctions between authorised and unauthorised hosts. Require explicit firewall paths for public inbound reception, gateway-to-server delivery and authorised outbound submission, without exposing the trusted SMTP listener to the Internet.

For SMTP TLS, specify certificate names, certificate trust and renewal responsibilities. The TLS policy must fit both peers; do not assume every sender or forwarding destination can meet the same requirements.

For outbound mail, review the actual egress IP, its PTR record, SPF authorisation, and responsibility for DKIM signing and DMARC alignment. Reverse DNS is normally controlled by the address provider, so an editable forward DNS zone is not enough.

For hosted services, supported routing and connector restrictions are prerequisites. Exact ports and settings depend on the matching official manual and your local architecture; the PMG Administration Guide 9.1.1 is further reading for that configuration work. Do not substitute generic firewall or SMTP commands for the documented design. Once these dependencies are documented, choose the appliance placement and administrative access model.

Choose deployment and administration boundaries

Separate the machine carrying email traffic from the workstation used to administer it: PMG runs on the deployed appliance, while your workstation provides management access. Public SMTP does not justify making the management interface publicly reachable.

PMG is an open-source software appliance that can run as a virtual appliance. The Proxmox Mail Gateway overview describes its web-based management interface and high-availability clustering. Choose a placement that supports the approved traffic paths and keeps web administration within your management boundary.

Select the supported installation method and size CPU, RAM and storage against workload and the matching manual.
Reserve the hostname and stable network configuration.
Prepare installation media, administrative credentials and recovery access.
Restrict web administration to approved management paths and assign certificate handling.
Record backup, restoration, patching and any clustering requirements.

Complete operating system installation first, then configure the network and mail proxy. Keep recovery access usable if a network change makes the browser interface unreachable. An administrator’s normal login path should not be the only way to recover a configuration mistake.

High availability is a resilience design decision, not a substitute for routing and recovery planning. Decide how traffic reaches surviving capacity and how you restore service after failure. Move from a reachable administration interface to controlled tests of actual message handling.

Validate filtering, quarantine and delivery

A message accepted by PMG is not yet proof of delivery to the intended mailbox. A successful SMTP acceptance response proves acceptance at that hop, not final mailbox delivery. Require evidence from both PMG and the existing mail server.

The official PMG overview describes ClamAV integration, filtering methods and message tracking. Filtering can address spam, malware and phishing risk, but handling depends on configuration and operational maintenance. Use controlled messages with agreed expected outcomes, not assumptions about what a default policy should do.

Send a small inbound message to a known valid recipient and trace delivery through PMG to the intended mailbox.
Address a controlled message to a deliberately invalid recipient and verify the configured rejection behaviour.
Attempt unauthorised relay from an untrusted test host and expect refusal, not acceptance for an external destination.
Send a small outbound message from an authorised host; check final delivery and relevant authentication headers.
Use a harmless dedicated test rule to place a message in spam quarantine; verify authorised review and release.
Correlate timestamps, message IDs, SMTP responses and queue state across PMG and the existing mail server.

Invalid-recipient handling depends on the chosen recipient validation method. Understand whether rejection occurs before acceptance and which system makes that decision. Check antivirus service and signature-update health, review blocklist policy and false-positive risk, and assign quarantine access and release responsibility.

Record the expected outcome, observed outcome and owner for each case as future test evidence. For further configuration reading, use the Proxmox Mail Gateway documentation. Use the results to decide whether the mail routes are ready for cutover.

Prepare DNS cutover and rollback checks

DNS cutover is a routing change that must remain reversible. Pause or reverse for failed valid-recipient delivery, unexpected relay permission or sustained queue growth. Agree on these failure conditions before changing traffic.

Save current DNS, routes and relevant configurations, and confirm rollback authority.
Adjust TTL in advance where appropriate, and keep the previous path available during transition.
Change the planned MX and outbound routing controls while monitoring external delivery, rejection patterns, quarantine and queues.
Reverse the relevant changes if agreed failure conditions occur, and reconcile messages accepted on either path.

The DNS specification describes the lifetime of cached records. Caches can retain old MX answers until their cached TTL expires. Changing a TTL does not shorten the lifetime of answers already cached, so rollback checks must cover both routes.

An MX rollback alone does not undo an outbound smart-host change. Restoring DNS also leaves accepted messages in gateway queues; mail queue monitoring must track their disposition rather than assume reversal delivered them. Have someone monitor both paths until delivery is stable.

PMG setup questions and discovery support

Does PMG replace the existing mail server?

No. In this design, PMG filters and forwards messages while the existing system continues to hold mailboxes and deliver mail to users. Confirm the supported routing arrangement for any hosted service involved.

Does changing MX prevent every route around the gateway?

No. Review every published exchanger and any direct SMTP path to the existing mail server. Where the architecture permits it, restrict delivery sources so the intended inspection path cannot be bypassed.

Does an accepted test message prove final delivery?

No. Follow it through the gateway and existing mail server to the intended mailbox. Check queue state and message-tracking records if delivery is deferred or fails.

Before moving traffic, resolve connector restrictions, relay permissions and recovery responsibilities. Keep the route map and test findings available to the people handling the change.

For a focused discussion of your proposed deployment, use ReadySpace Academy’s Proxmox Discovery. Bring the inbound/outbound route map and the questions still unresolved, with credentials and sensitive message contents removed.

Proxmox Mail Gateway Setup: Mail Flow and Deployment Planning