Reverse DNS (PTR)
A DNS lookup from a sending IP back to its hostname, used by inbox providers to check whether the mail server has a credible identity.
See it
What it is
Reverse DNS starts with an IP address and returns a hostname through a PTR record. For a sending server, that usually means '203.0.113.25' points back to 'mail.example.com'. The useful setup is forward-confirmed: that hostname's A or AAAA record also resolves back to the same sending IP, and the server introduces itself with a matching, sensible name in SMTP EHLO.
Set it when you operate a dedicated sending IP or your own mail server. Mailbox providers use the result as basic infrastructure hygiene and as one clue in reputation decisions. Because reverse DNS belongs to the IP address space, the cloud host, ISP, or email provider normally has to create the PTR; on AWS that means a reverse DNS request for the Elastic IP, and adding a PTR beside your ordinary domain records does nothing.
Do not expect identity proof from it. A clean PTR does not pass SPF, sign DKIM, or need to match the visible From domain. It only gives the connecting IP a stable name. Missing reverse DNS, a default cloud hostname of the 'ec2-203-0-113-25.compute-1.amazonaws.com' kind, or a PTR whose name does not resolve forward again makes a self-hosted sender look unfinished before the message content is even considered.
Ask AI for it
Write a reverse DNS setup and verification plan for a Postfix server sending from <sending-ip> as mail.example.com. Include the A or AAAA record for mail.example.com, the PTR request that must be made in the IP host's control panel, and the Postfix 'myhostname' and 'smtp_helo_name' settings needed for a consistent SMTP EHLO. Verify forward-confirmed reverse DNS with 'dig -x <sending-ip>' and 'dig A mail.example.com', and show the expected relationship without inventing an IP address. Keep SPF, DKIM, and DMARC as separate checks; do not claim that a matching PTR authenticates the From address.