PTR Readiness for Dedicated Sending IPs

PTR, or reverse DNS, maps a sending IP address to a hostname. For a dedicated sending IP, confirm who controls the PTR, what hostname will be used, and whether the sending system identifies itself consistently. This is a readiness check, not a promise that any receiver will accept your mail.

Establish ownership

The IP provider or cloud host commonly controls the reverse zone. Ask for the exact process, approval, and expected evidence rather than editing your normal domain DNS. Record the IP, intended PTR hostname, region or provider, and whether IPv4 and IPv6 are both active. The shared-versus-dedicated IP guide explains why the address choice is an operating decision.

Verify forward and reverse answers

After PTR is published, query the reverse name and confirm it returns the intended hostname. Then query that hostname and confirm the expected A or AAAA address. Forward-confirmed naming helps avoid an obvious mismatch, but it does not constitute a universal receiver requirement. Use DNS records for email to document the lookup evidence.

Check the actual SMTP path. Capture the EHLO or HELO hostname, TLS and response evidence, source IP, and provider event. Confirm the sending service uses the same intended identity and does not unexpectedly route through another address. Test IPv6 separately if it is enabled; a correct IPv4 PTR does not repair an IPv6 path.

Decide before launch

If the provider cannot set or document PTR, treat that as an infrastructure constraint. Do not compensate by changing unrelated SPF or DKIM records. Receiver policies vary, and email infrastructure fundamentals should be reviewed alongside reputation, authentication, and monitoring. Record the owner, verification date, and rollback or disable path.

Related resources

Use the Email Infrastructure academy for IP and DNS decisions.

This workflow should be checked against the cited standards and current provider documentation 1.

Validate PTR as a dependency chain

A provider hostname is not sufficient. The IP needs PTR, that hostname must resolve forward to the intended IP, and HELO/EHLO must be deliberate. Record provider ticket, IP, PTR, A/AAAA answer, HELO, timestamp, and resolver. Shared or IPv6 infrastructure may have different controls.

Use RFC 1912 and the Google sender guidelines. They describe checks, not placement guarantees. Query multiple resolvers after TTL expiry. Do not proceed if PTR control is unclear or HELO changes between retries; branch into authentication, rate, content, and reputation evidence instead of repeatedly changing PTR.

References