Fix a Docker Mailserver Reverse DNS/PTR Mismatch

A recipient rejects your Docker Mailserver message because the sending address has no PTR record, its reverse DNS is generic, or the PTR hostname does not resolve back to the same address. Changing SPF or restarting the container will not fix that identity chain.

For direct delivery, aim for one coherent machine identity: the outbound IP reverses to a stable mail hostname, that hostname resolves forward to the same IP, and Postfix uses it in EHLO. Google’s sender guidelines require valid forward and reverse DNS for sending IPs. Docker Mailserver’s usage guide likewise warns that hardened receivers may reject a host whose address does not resolve correctly to its server name.

Trace the address a receiver actually sees. PTR belongs to that address owner—normally your VPS provider—not to the ordinary DNS zone where you create A, MX, SPF, or DKIM records.

What “matching reverse DNS” means

Suppose the public sending address is the documentation-only address 192.0.2.10 and the server identity is mail.example.com. The intended chain is:

192.0.2.10  --PTR-->  mail.example.com
mail.example.com  --A-->  192.0.2.10
Postfix EHLO  --------->  mail.example.com

The forward confirmation matters. A PTR that names mail.example.com while that hostname points somewhere else is still inconsistent. The mailbox’s visible domain does not have to equal the machine hostname: one mail host can legitimately serve several domains while retaining one PTR and EHLO identity.

1. Preserve the exact receiver evidence

Save the full bounce or recipient message source privately. Record the remote response, timestamp, Postfix queue ID, destination, and source address the receiver reports. Redact addresses and identifiers before sharing logs.

Distinguish these cases before editing DNS:

• No PTR: reverse lookup returns no hostname.
• Generic PTR: it returns a provider-generated name rather than your stable mail identity.
• Forward mismatch: the PTR hostname has no A/AAAA record or resolves to another address.
• EHLO mismatch: DNS is coherent, but Postfix announces a different or invalid hostname.
• Wrong egress address: NAT, a relay, or IPv6 causes the receiver to see an address you did not inspect.

2. Identify the real outbound path

Do not assume the address used for your website, inbound MX, or SSH is the address delivering mail. Search a recent Postfix transaction and compare it with the received headers or rejection. If Docker Mailserver uses a smarthost, the receiver normally sees the relay’s address and identity, not the VPS address.

# Use your actual Compose service name
docker compose logs --since 30m mailserver

# Inspect the effective relay and hostname settings
docker compose exec mailserver postconf relayhost
docker compose exec mailserver postconf myhostname
docker compose exec mailserver hostname --fqdn

If relayhost is set, follow the relay provider’s DNS and authentication requirements. Do not set a PTR for an address you do not control.

3. Query reverse and forward DNS independently

Use the actual observed source address privately. The example addresses below are reserved for documentation:

# Reverse lookup
dig +short -x 192.0.2.10 @1.1.1.1
dig +short -x 192.0.2.10 @8.8.8.8

# Forward confirmation of the returned hostname
dig +short A mail.example.com @1.1.1.1
dig +short AAAA mail.example.com @1.1.1.1

A trailing dot in a PTR answer is normal DNS notation. Check more than one public resolver after a change; your local cache can make an old answer look current.

4. Set PTR at the address owner

Create or change reverse DNS in the VPS or address provider’s console or API. Your authoritative DNS provider usually cannot write the reverse zone for provider-owned addresses. Set the PTR to the stable fully qualified mail hostname—not the bare domain, a mailbox address, a URL, or the visible From domain.

Then create the matching forward record in your normal DNS zone:

mail.example.com.  A  192.0.2.10

If Cloudflare hosts the zone, keep the mail hostname DNS-only. Cloudflare’s normal orange-cloud HTTP proxy is not an SMTP proxy and would return Cloudflare web addresses instead of your mail endpoint. An MX record should name the hostname, not an IP address.

5. Treat IPv6 as a separate sending identity

If the host can send over IPv6, it needs its own PTR and matching AAAA record. A perfect IPv4 identity does not repair a message delivered from an unconfigured IPv6 address.

2001:db8::10  --PTR-->  mail.example.com
mail.example.com  --AAAA-->  2001:db8::10

2001:db8::/32 is documentation space. Either configure and verify IPv6 completely or deliberately prevent Postfix from using it until you can. Do not publish an AAAA record merely because the VPS has an address; it advertises a route that must work for SMTP, TLS, reverse DNS, and firewall policy.

6. Align Docker Mailserver’s hostname and EHLO

Docker Mailserver derives its FQDN from the container hostname unless OVERRIDE_HOSTNAME is set. In Compose, the conceptual configuration is:

services:
  mailserver:
    hostname: mail.example.com

Use the current Docker Mailserver documentation and the configuration style appropriate to your pinned image. Avoid having hostname:, OVERRIDE_HOSTNAME, and a custom Postfix override disagree. Check the effective result rather than trusting one file:

docker compose exec mailserver postconf myhostname smtp_helo_name
docker compose exec mailserver postconf -n | less

If smtp_helo_name is unset, Postfix normally uses myhostname. Change only the setting responsible for the mismatch, then recreate or restart according to the Docker Mailserver version’s documented workflow.

7. Verify the SMTP and TLS identity

After DNS is public and the service is reloaded, test the public SMTP endpoint from outside the server network:

openssl s_client -starttls smtp \
  -connect mail.example.com:25 \
  -servername mail.example.com -crlf

Confirm the SMTP banner/EHLO identity is expected and the certificate is valid for mail.example.com. A matching PTR does not require the certificate subject to be the PTR itself in every theoretical mail flow, but using one coherent operational hostname reduces avoidable ambiguity for clients and administrators.

8. Send one fresh message and inspect what arrived

Send a new, ordinary message to a mailbox you control. Do not reuse an old header because it records the old route. In the received source, confirm:

• the connecting address is the one whose PTR you fixed;
• the receiving server records the intended reverse hostname;
• Postfix used the intended EHLO name;
• SPF and DKIM pass for the actual message;
• at least one mechanism aligns so DMARC passes;
• the Docker Mailserver log shows the matching queue ID and remote result.

PTR is necessary infrastructure, not an inbox guarantee. Reputation, complaint history, authentication alignment, wanted content, rate and recipient policy still matter.

Common wrong turns

• Adding a PTR-looking TXT record: TXT in your forward zone does not create reverse DNS.
• Changing MX only: MX controls where inbound mail goes; it does not assign reverse DNS to outbound addresses.
• Using a different PTR for every hosted domain: the PTR identifies the sending machine, not each mailbox domain.
• Proxying the mail hostname through Cloudflare: ordinary Cloudflare web proxying does not expose SMTP.
• Checking IPv4 while Postfix sends over IPv6: validate the address present in the receiver evidence.
• Forcing EHLO to hide a broken DNS chain: the hostname still needs valid forward and reverse resolution.
• Repeatedly sending tests: make one controlled change, wait for public DNS, then send one fresh message.
• Expecting PTR to fix DMARC: PTR, SPF, DKIM and DMARC answer different identity questions.

Compact recovery checklist

1. Save the receiver’s exact error and observed source address.
2. Determine whether delivery is direct, relayed, NATed, IPv4, or IPv6.
3. Query the observed address’s PTR through public resolvers.
4. Set PTR at the address provider to one stable mail FQDN.
5. Make that FQDN resolve forward to the same address; keep it DNS-only.
6. Align Docker Mailserver’s effective hostname and Postfix EHLO.
7. Verify banner and TLS externally.
8. Send one fresh message and confirm the actual route, authentication, alignment, and queue result.

For implementation details, see Docker Mailserver’s current usage guide, environment-variable reference, and outbound-interface guide. Google’s email sender guidelines state the forward/reverse DNS requirement. Use the documentation matching your pinned Docker Mailserver release.