Why the name attached to your sending address matters

What a PTR record is

A PTR record maps an address back to a name, which is the opposite direction to everything else in DNS. It lives in a special zone: for IPv4 the four octets are reversed and in-addr.arpa appended; for IPv6 the address is expanded to its 32 hexadecimal digits, reversed one digit at a time, and ip6.arpa appended.

An address should have exactly one PTR record. Several are permitted by the protocol and cause trouble in practice, because a receiver checking the name has no way to know which one you meant it to use.

; forward
mail.example.com.  3600 IN A    192.0.2.25

; reverse, published by whoever holds 192.0.2.0/24
25.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com.

Who controls the PTR for your sending address

The reverse zone follows the address allocation, not the domain. Whoever was assigned the address block holds in-addr.arpa for it — your hosting provider, your cloud vendor, or your ISP — and only they, or somebody they have delegated to, can publish the PTR.

This is why the record is so often wrong. Everything else in mail configuration is in a zone you administer; this one requires a support request, a control-panel field, or in some cases an entire class of hosting account. Providers that do not offer PTR control at all are common at the cheaper end, and that is a reason to choose a different provider rather than a problem to work around.

When you do not know who holds the block, a WHOIS lookup on the address returns the allocation and its abuse and technical contacts, which is where the request goes.

Forward-confirmed reverse DNS

Having a PTR is not sufficient on its own, because a PTR can name any hostname at all. What a receiver checks is forward-confirmed reverse DNS: it looks up the PTR for the connecting address, then looks up the address records of the name it got back, and confirms the original address is among them.

A one-way match fails the check. A PTR naming mail.example.com is worth nothing if mail.example.com resolves to a different address, or to no address at all, and that mismatch is what a badly maintained migration leaves behind.

RFC 1912 has recommended matching forward and reverse records for every host since long before spam filtering made it consequential. For a mail server it is now close to mandatory: some receivers refuse connections without it outright, and many more add a substantial score.

Three names that should agree

There are three names involved in an outbound connection, and a well-configured host makes all three the same: the name the sending host announces in EHLO, the name its address resolves back to through the PTR, and the name that resolves forward to the address again.

The EHLO name in particular should be a fully qualified name that resolves, not a bare hostname, not localhost and not a name only meaningful inside your network. A receiver comparing the EHLO name with the PTR is doing something the standards permit it to do, and mismatches are scored.

220 mx1.example.net ESMTP ready
EHLO mail.example.com
250-mx1.example.net Hello mail.example.com [192.0.2.25]
250-STARTTLS
250 OK

What a generic PTR signals

Providers assign a default PTR to every address, usually built from the address itself and the provider's domain. A name of that shape says the address is part of a bulk allocation with no individual configuration, and a great many filters treat it as a proxy for dynamic or residential space — the sort of address a compromised home machine sends from.

Setting a PTR to a hostname in the domain you send from replaces that signal with a specific one: this address belongs to a mail server, operated by somebody who noticed. It is a small change with an effect out of proportion to the effort, and it is also a prerequisite for the forward-confirmed check to mean anything.

A dynamically assigned address is a different matter. Where the address changes, no PTR configuration will help, and mail should be relayed through a host with a static address and a proper name rather than sent directly.

Why filters care

Reverse DNS is checked before anything else because it is available before anything else. At the moment the connection opens there is no message, no header From and no envelope — there is an address, and the only assertion available about it is the one its operator published.

It is also difficult to forge in the way header fields are. The PTR is controlled by the holder of the address block, so a matching, specific reverse name is evidence that somebody with authority over the network took a deliberate step. That is a weak signal in isolation and a useful one in aggregate, which is exactly how filters use it.

The practical consequences range from a small addition to a spam score, through greylisting that a badly behaved sender never retries past, to an outright refusal at connection time with a message naming the missing PTR.

IPv6 reverse DNS

IPv6 makes the same demand and some receivers make it more strictly, refusing connections over IPv6 from addresses without a PTR while tolerating the same host over IPv4. If a sending host has an AAAA record it will be used, so an IPv6 address with no reverse DNS turns a working sender into a failing one the day connectivity is enabled.

Reverse delegation for IPv6 is usually granted at the /64 level, and the record name is long — 32 nibbles in reverse order followed by ip6.arpa. Providers normally expose this as a form rather than a zone, but the requirement is identical: one PTR per sending address, naming a hostname that resolves back to that address.