Skip to content

RTFM · Networking

Reverse DNS and forward-confirmed reverse DNS

Mail reputation begins with the public IP that actually sends mail. That address should reverse to a mail hostname, and that hostname should resolve forward to the same address.

Saphira Linux dragon mascot

The two-direction identity

IPv4 and IPv6 FCrDNS
203.0.113.25
    │ PTR
    ▼
mail.example.test
    │ A record
    ▼
203.0.113.25

2001:db8:100::25
    │ PTR
    ▼
mail.example.test
    │ AAAA record
    ▼
2001:db8:100::25

PTR records are controlled by the organisation that owns the public address block: usually an ISP, hosting provider, or datacentre. You can publish the forward A/AAAA records in your normal authoritative DNS, but you usually cannot create the reverse record yourself unless the provider delegates that authority. Private addresses such as 192.168.1.50 never need public PTR for mail delivery.

Manual DNS proof
dig -x 203.0.113.25 +short
dig +short A mail.example.test

dig -x 2001:db8:100::25 +short
dig +short AAAA mail.example.test

# Compact answer output when diagnosing.
dig +noall +answer -x 203.0.113.25

Use MailDragon's check-reversedns.sh

MailDragon's script checks IPv4 and IPv6 PTR and performs forward confirmation locally with DNS tools. The primary path is deliberate manual input: type the public IP or the mail hostname. Optional address discovery through helper endpoints is convenience only; a working mail deployment must remain testable without it.

MailDragon reverse-DNS checks
# From the MailDragon source tree, or use the installed command path on your host.
./scripts/check-reversedns.sh 203.0.113.25 mail.example.test
./scripts/check-reversedns.sh 2001:db8:100::25 mail.example.test

# Resolve every A and AAAA address for the hostname and test each round trip.
./scripts/check-reversedns.sh --hostname mail.example.test

# Optional convenience only; never a deployment dependency.
./scripts/check-reversedns.sh --service mail.example.test
Script outcomes
Exit statusMeaningOperator response
0PTR and requested checks passRecord the tested public address and continue with mail DNS.
1A reverse-DNS problem was foundFix PTR ownership, forward A/AAAA, or identify the real public sending address.
2PTR exists but does not match the expected nameCorrect the provider PTR or use the correct outbound mail hostname.
3No address found or invalid useSupply a real public IP or resolvable mail hostname.

Turn an IPv6 /64 into the correct reverse-zone name

IPv6 reverse DNS lives below ip6.arpa and is written one hexadecimal digit, or nibble, at a time in reverse order. A /64 has exactly 16 hexadecimal digits of network prefix, so its reverse zone ends after those 16 reversed nibbles. Do not reverse groups of four digits as units: reverse every individual hexadecimal character.

Worked IPv6 reverse-zone derivation
IPv6 address:        2a02:8012:bc57:c0ff::1/64

1. Keep the /64 prefix (the first four groups):
   2a02:8012:bc57:c0ff

2. Remove colons: 
   2a028012bc57c0ff

3. Reverse every hexadecimal digit:
   f.f.0.c.7.5.c.b.2.1.0.8.2.0.a.2

4. Append ip6.arpa.:
   f.f.0.c.7.5.c.b.2.1.0.8.2.0.a.2.ip6.arpa.

That is the reverse zone for 2a02:8012:bc57:c0ff::/64.

5. Within that zone, ::1 has host nibbles 0000000000000001. Reverse them:
   1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0

Full PTR owner:
   1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.f.f.0.c.7.5.c.b.2.1.0.8.2.0.a.2.ip6.arpa.
The /64 reverse-zone record
$ORIGIN f.f.0.c.7.5.c.b.2.1.0.8.2.0.a.2.ip6.arpa.
$TTL 3600
@ IN SOA ns0.example.net. hostmaster.example.net. (
  2026082701 3600 600 1209600 3600
)
  IN NS ns0.example.net.
  IN NS ns1.example.net.

; 2a02:8012:bc57:c0ff::1
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail.example.net.

The abbreviation in the address is only a display convenience. For reverse DNS, expand it to all 32 hexadecimal digits first. The address owner must delegate the /64 reverse zone above before this zone can be public. A /48 ends after 12 nibbles, a /56 after 14, and a /64 after 16: these clean nibble boundaries are why those prefix sizes are practical for IPv6 reverse delegation.

Verify the exact IPv6 PTR
dig -x 2a02:8012:bc57:c0ff::1 +noall +answer

# If you operate the delegated /64, query the generated PTR owner directly.
dig @ns0.example.net 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.f.f.0.c.7.5.c.b.2.1.0.8.2.0.a.2.ip6.arpa. PTR +noall +answer

Having a routed /64 does not automatically give you authority over its reverse DNS. Your ISP, tunnel provider, or datacentre must either set the PTR or delegate the corresponding ip6.arpa zone. Forward AAAA control and reverse-zone control are separate contracts.

The public sender may not be the mail backend

Behind NAT, HAProxy, or several routed networks, first identify the public IP that outbound SMTP recipients see. That—not the internal MailDragon address and not necessarily the HAProxy inbound address—needs the correct PTR. If it is unclear, send a controlled message to a mailbox you operate and inspect the received headers, then verify that public address.

  • No PTR: ask the address owner to set it to the mail hostname.
  • PTR points at an old provider hostname: request a change; you cannot repair that mismatch with SPF alone.
  • A record is right but AAAA is wrong: IPv6-capable recipients may use the wrong identity, so correct both families or do not publish the unusable AAAA.
  • The script finds a private address: stop and trace outbound NAT; private RFC1918 addresses are not public mail identities.