Lesson 003 · Linux MTA Operations Learning Path

Mail Server DNS, PTR, Firewall and SELinux on RHEL

Anil Jalela · Published Sep 3, 2026 · 10 min read

Publishing an MX record and opening a firewall are production changes, not setup chores. They decide where other systems send mail and which untrusted clients can reach Postfix. This lesson exposes only server-to-server SMTP after forward DNS, reverse DNS, routing, firewall ownership and SELinux state are independently verified. Submission and mailbox ports remain closed until their authentication and TLS lessons.

Prerequisites and inherited lab checkpoint

Start from the Lesson 2 checkpoint: Postfix is installed, validated and bound to loopback with no broadened relay trust. Obtain an approved public hostname and static address only for an authorized Internet-facing build. The worked values use example.test and documentation addresses, so they must not be published as real DNS.

Confirm who controls the forward zone, reverse zone, network firewall, host firewall and cloud security policy. PTR records are normally controlled by the address provider, not by the domain registrar. Decide whether IPv6 is genuinely supported end to end; an AAAA record creates a real delivery path and reputation identity.

Install and prepare the required components

sudo dnf install -y bind-utils firewalld policycoreutils-python-utils
sudo systemctl enable --now firewalld
sudo firewall-cmd --get-active-zones
nmcli -f NAME,DEVICE,TYPE connection show --active
getenforce
sestatus

• policycoreutils-python-utils supplies SELinux diagnostic and management utilities on current RHEL. Verify package availability and ownership on the installed release.
• Do not start firewalld blindly on a host governed by another approved firewall manager. Inventory ownership first and preserve console access.
• Opening smtp in firewalld affects only the selected zone. Cloud ACLs, provider filters, routing and Postfix binding remain separate layers.
• DNS changes need rollback TTL planning. Lowering a TTL after publishing an incorrect record does not immediately shorten cached copies.

Publish identity and expose only the reviewed SMTP path

The authoritative zone conceptually needs one MX target and address record. The address owner publishes the PTR. In a real deployment replace every example with approved values and omit AAAA unless IPv6 sending and receiving are fully operated.

example.test.       3600 IN MX 10 mail1.example.test.
mail1.example.test. 3600 IN A 192.0.2.25
mail1.example.test. 3600 IN AAAA 2001:db8::25
25.2.0.192.in-addr.arpa. 3600 IN PTR mail1.example.test.

On the host, change Postfix from loopback to the intended interfaces, validate, then add SMTP only to the active public-facing firewalld zone:

sudo postconf -e 'inet_interfaces = all'
sudo postfix check
sudo systemctl reload postfix
sudo firewall-cmd --zone=public --add-service=smtp
sudo firewall-cmd --zone=public --add-service=smtp --permanent
sudo firewall-cmd --reload

Apply the runtime rule first from a retained administrative session, test it, then persist it. This ordering makes a mistake easier to reverse. If the interface belongs to a different zone, correct the reviewed zone mapping rather than opening every zone.

Verify the working path

dig +noall +answer MX example.test
dig +noall +answer A mail1.example.test
dig +noall +answer AAAA mail1.example.test
dig +noall +answer -x 192.0.2.25
sudo ss -lntp | grep ':25 '
sudo firewall-cmd --zone=public --query-service=smtp
sudo firewall-cmd --zone=public --list-all
getenforce
sudo ausearch -m AVC,USER_AVC -ts recent

• Run DNS queries against the authoritative servers and at least two independent recursive resolvers. A local resolver answer alone can hide split DNS or cache differences.
• Forward-confirmed reverse DNS means the sending IP has a PTR and that PTR hostname resolves back to the same IP. It is operational identity evidence, not a guarantee of inbox placement.
• Test TCP/25 from outside the destination network. A local connection cannot prove upstream routing or perimeter policy.
• No unexplained AVC denials should accompany SMTP tests. Investigate with timestamps and labels before creating any custom policy.

Production decisions before continuing

Treat reachability, routing and sender identity as separate layers

MX controls inbound routing for a recipient domain. PTR contributes to the identity of an outbound IP. Many receiving systems expect a meaningful PTR and forward confirmation, but no DNS record purchases reputation or overrides filtering. SPF, DKIM and DMARC are added later because publishing them before the signing and sending paths are known can create false failures.

Host reachability crosses the sender route, provider policy, perimeter controls, RHEL firewalld, SELinux port/type rules, Postfix binding and smtpd policy. Record evidence from both ends. A timeout, connection refusal and SMTP 5xx reply are different failure classes and must not be described as one “port issue.”

SELinux remains enforcing. Standard Postfix paths and ports usually work with packaged policy. Custom ports, storage paths or sockets require inspection of existing labels and booleans before any change. A generated allow rule can conceal a wrong path or compromised behavior, so it is a last reviewed step, not the first diagnostic command.

Understand the component before configuring it

Build it step by step

1. Inventory authority. Name owners for forward DNS, reverse DNS, network perimeter and host controls.
2. Prepare DNS. Publish MX and address records with deliberate TTL; request PTR from the address provider.
3. Verify from outside. Compare authoritative and recursive answers over both enabled address families.
4. Bind Postfix deliberately. Change interfaces, validate and reload while the host firewall still limits reachability.
5. Open one service. Add SMTP to the exact active firewalld zone and leave submission, IMAP and POP closed.
6. Test positive and negative behavior. Accept a valid local recipient only when configured, deny third-party relay and retain transcripts.
7. Inspect policy evidence. Confirm SELinux enforcing with no unexplained denials and record the final external path.

Operate and inspect the component

dig +trace MX example.test
dig @AUTH_SERVER example.test MX +noall +answer
dig @1.1.1.1 example.test MX +noall +answer
dig @8.8.8.8 example.test MX +noall +answer
traceroute 192.0.2.25
nc -vz 192.0.2.25 25
firewall-cmd --get-zone-of-interface=INTERFACE
semanage port -l | grep smtp
ausearch -m AVC -ts recent | audit2why

• Replace placeholders only after resolving exact authoritative servers and interfaces. Do not paste example addresses into a live change.
• dig +trace is useful for delegation diagnosis but differs from the cached view most senders use. Check both.
• audit2why helps interpret AVC records; it does not authorize blindly installing generated policy.
• Unsafe: broad packet capture or Internet scans may cross privacy and authorization boundaries. Limit targets to systems you own or have permission to test.

Evidence and acceptance criteria

An AAAA record can silently create a second production service

A team validates IPv4 delivery, then publishes an AAAA record copied from the VM inventory. Some remote senders prefer IPv6, but the provider blocks inbound IPv6 TCP/25 and no PTR exists for outbound IPv6. Delivery becomes intermittent by sender and outbound identity fails basic reputation checks. The IPv4 tests remain green, hiding the second path.

The operator compares MX address answers over both families, tests from an external IPv6 host and identifies the timeout before Postfix. The approved short-term correction removes the AAAA record with planned cache awareness. The long-term option is to provision routing, firewall, PTR, monitoring and reputation for IPv6 before republishing it. Disabling IPv6 inside Postfix alone would leave a published unreachable address.

Troubleshooting by symptom

Unsafe operations and recovery boundaries

• Unsafe: setenforce 0 converts a diagnosable policy denial into an unprotected service and is not an acceptable fix.
• Unsafe: opening 0-65535/tcp or every firewalld zone to troubleshoot SMTP expands the attack surface and destroys layer evidence.
• Unsafe: publishing an AAAA record without a complete IPv6 operational path makes real senders select an untested route.
• Unsafe: creating SELinux policy directly from unreviewed AVC output can authorize behavior caused by a wrong label or compromised process.

Rewritten knowledge checks

Can an MX record point directly to an IP address?

No. Its target is a hostname, which then resolves through A and optionally AAAA records.

Who usually controls PTR records?

The organization or provider controlling the IP address block and reverse DNS delegation.

What is forward-confirmed reverse DNS?

The IP resolves to a PTR hostname and that hostname resolves back to the same IP.

Does PTR guarantee inbox placement?

No. It is basic infrastructure identity; authentication, reputation, complaints and content behavior still matter.

Why can AAAA cause intermittent delivery?

Some senders prefer IPv6, creating a separate route whose firewall, PTR or listener may be incomplete.

What is the difference between timeout and refusal?

A timeout usually indicates a dropped or unreachable path; refusal shows the host was reached but no service accepted the connection.

Why check the active firewalld zone?

A correct service rule in the wrong zone has no effect, while an overbroad zone can expose unintended interfaces.

Should SELinux be disabled for a custom mail path?

No. Diagnose labels and policy, use supported locations where possible, and add only a reviewed minimal rule if required.

Why query independent recursive resolvers?

They show what external senders observe and expose delegation, cache or split-view differences.

Which ports should be public after this lesson?

Only TCP/25 for the reviewed server-to-server SMTP path; authenticated and mailbox ports wait for their controls.

Cumulative lab checkpoint

1. Create a DNS change plan using reserved example values, including MX, A, optional AAAA, PTR, TTL and rollback timing.
2. Verify authoritative and recursive views and explain any cache difference.
3. Change Postfix to the intended lab interface, validate and retain the before/after effective configuration.
4. Open SMTP only in the exact lab firewalld zone while retaining console access.
5. From the second VM, distinguish successful connection, refusal and timeout using controlled tests.
6. Confirm SELinux enforcing, no relevant AVC denial, closed future-service ports and the relay boundary, then snapshot Lesson 3.

Primary references

• RHEL 10 deploying mail servers
• RHEL 9 deploying mail servers
• Postfix documentation