The PTR record is not in your zone
Forward DNS follows names, reverse DNS follows address allocation. The record for8.8.4.4 is called4.4.8.8.in-addr.arpa, and authority for that name is delegated down the same path the IP block was: IANA to a regional registry, registry to your ISP or hosting provider, and only then — sometimes — to you.
So you set reverse DNS in your VPS provider's control panel, on the Elastic IP or instance that holds the address, or by asking your ISP. Adding a PTR-shaped record toyourdomain.com's zone file does nothing at all: nobody ever queries that name. The lookup above shows which zone actually answers and which nameserver is primary for it, which is usually enough to tell you who to ask.
Why home connections cannot send mail
Residential ISPs assign generic reverse names across whole address pools —host86-128-1-1.range86-128.example-isp.net — and those names are formulaic on purpose. Receiving servers read the embedded octets and thedsl, dyn,cable or pool tokens as evidence that the address is a dynamically assigned end-user line, not a mail server.
That reverse name is often technically valid and will even pass the confirmation check above, yet the mail is still refused: the same ranges are listed on Spamhaus's Policy Block List, and most ISPs block outbound port 25 outright. Passing FCrDNS with a generic name is necessary, not sufficient — you need an address whose reverse name you control.
What confirmation proves
A forward-confirmed pair proves that whoever controls the reverse zone for the IP and whoever controls the forward zone for the hostname agree with each other. Since those are usually two different parties, agreement is hard to fake from a hijacked address or a botnet host, which is exactly why receivers like the signal.
It proves nothing about the message. It does not authenticate the envelope sender or theFrom: header — that is SPF, DKIM and DMARC — it does not prove the sending domain is related to the PTR hostname, and a patient spammer with their own IP block can set it up correctly. Treat it as a floor to clear, not a reputation.
Why a missing PTR gets your mail deferred
When a server connects to deliver mail, the receiver looks up the reverse name of the connecting IP before the conversation gets very far. In Postfix terms,reject_unknown_reverse_client_hostname rejects a client with no PTR at all, and reject_unknown_client_hostname goes further and requires the forward lookup to confirm — the check this page runs. Both default to a450 temporary failure rather than a hard550, which is why the symptom is rarely a clean bounce. Your mail queue fills with deferrals, retries stretch out over hours, and some of it eventually expires. A well-behaved sender is supposed to retry, so you often discover the problem days later from a recipient who never got the message.
The convention worth following is that three things agree: the PTR name for your IP, the name your server announces in HELO/EHLO, and a forward A or AAAA record for that name pointing back at the same IP. Mismatches between the HELO name and the reverse name are a common scoring signal in SpamAssassin and in commercial filters, even when each half is individually valid. If you run mail on IPv6, set the AAAA reverse record too: several large providers are markedly stricter over IPv6 than IPv4 and will refuse mail from an IPv6 address with no reverse name even when the IPv4 path works fine.
One practical note on timing. Reverse zones are frequently served with long TTLs — a day is common — and negative answers get cached as well. After your provider sets a PTR, this tool may keep reporting the old value, or none, until Cloudflare's cache expires. That is a caching artefact, not a failed change.
