All blogs & guides

PRACTICAL OUTREACH

PTR and Reverse DNS: Check Your Email Server Identity

By TransmitInbox team
Published September 24, 2026 · Updated October 14, 2026

Your email authentication looks correct, but delivery responses still mention reverse DNS or a PTR mismatch. If you run your own sending server, the missing piece may be the relationship between its public IP address and the hostname that address points back to.

What the two-way DNS check means

Forward DNS looks up a hostname to find an IP address. Reverse DNS starts with an IP address and looks up its hostname through a PTR record. For email sent to personal Gmail accounts, Google requires valid forward and reverse DNS for the sending infrastructure. Gmail sender guidelines

Google describes the expected relationship this way: the public sending IP has a PTR hostname, and that hostname has an A record for IPv4 or an AAAA record for IPv6 pointing back to the same IP. Google’s infrastructure requirements

Think of it as checking both directions of the same address book entry. Looking up the IP gives you a name; looking up that name must take you back to the sending IP.

This check does not replace SPF, DKIM, or DMARC. Those answer different authentication questions. If you need to review them, use our email authentication troubleshooting checklist rather than treating a working PTR record as a complete setup.

Nor does a correct match guarantee inbox placement. It resolves one infrastructure check, while recipient interest, provider policies, and other delivery factors still need attention.

Start with the IP that actually delivered the message

Do not assume your website’s IP is your sending IP. Your campaign may use a hosted mailbox, a separate SMTP service, or a server whose outbound traffic passes through another address.

Use the sending service’s logs or a representative message’s receiving headers to identify the public outbound IP. If several routes exist, record them separately. An administrator should confirm which address is relevant before changing anything.

Create a short inventory:

• Sending service or server.
• Public outbound IP address.
• Current PTR hostname.
• Forward DNS result for that hostname.
• Owner responsible for each side of the configuration.

For hosted mailbox users, ask the provider to investigate an infrastructure error. Purchasing a domain does not give you control over the mail provider’s outbound addresses. Avoid editing your website DNS on the assumption that it will repair the provider’s PTR record.

If you operate an SMTP server yourself, that ownership question becomes part of your day-to-day work. Our KumoMTA guide explains the wider operational responsibilities of running delivery infrastructure.

Run the reverse lookup, then look forward again

An administrator can use dig to inspect the records. The commands below use a documentation-only IP and example hostname; substitute the actual values from your sending inventory.

First run dig -x 192.0.2.10 +short to inspect the PTR answer. If it returns mail.example.com., run dig mail.example.com A +short to inspect that hostname’s IPv4 addresses. For an IPv6 sending address, check the hostname’s AAAA answers instead.

Read the pair of results together. A PTR answer alone does not establish the forward match. Likewise, an A record for your chosen mail hostname does not prove that the sending IP has the appropriate reverse record.

Suppose, in a hypothetical server migration, the PTR still points to mail.example.com, but that hostname resolves only to the old server address. The name looks familiar and both records exist, yet the relationship needs correction.

Keep the lookup output and timestamp in your incident notes. If results differ between checks, investigate DNS caching, the record change, and the actual sending route with the administrator. Do not repeatedly change values to chase a single inconsistent lookup.

If command-line checks are unfamiliar, Google links its Admin Toolbox Dig tool from the sender guidelines. Share the findings with the infrastructure owner rather than interpreting an unfamiliar result alone. Google’s DNS checking reference

Ask the right provider to make the correction

Check your hosting provider’s reverse DNS procedure. The PTR setting may live in the server or IP management panel rather than the ordinary DNS zone used for your website.

For example, Amazon EC2 lets customers update reverse DNS for an Elastic IP through its management controls and requires a corresponding forward A record first. That is an AWS-specific workflow; use your own provider’s instructions. EC2 reverse DNS setup

When requesting help, include the public sending IP, requested hostname, current forward answer, and complete delivery response. Ask who controls reverse DNS if your server reseller and IP provider are different organisations.

Avoid vague tickets such as “Please fix email DNS.” A specific request makes it easier for support to confirm whether it can change the PTR and whether the forward record is ready.

Also review what happens when the address changes. A server replacement, IP reassignment, or new outbound route should trigger another two-way check. Record the configuration in your infrastructure inventory so the next migration does not rely on memory.

For teams serving North America and Europe, keep this handover accessible across working hours. Someone should know how to reach the provider even when the usual administrator is offline.

Quick checklist after the change

Before closing the incident, confirm:

• The checked IP is the one used for outbound delivery.
• Its PTR lookup returns the intended hostname.
• The hostname’s forward answer includes that sending IP.
• Every active outbound route has been reviewed where relevant.
• A fresh delivery check no longer produces the original DNS error.
• The corrected values and responsible owners are documented.

Use an authorised test through the actual sending route and preserve the response. If the error remains, give the administrator the new evidence rather than assuming the DNS change must have solved it.

A PTR check is small enough to overlook and specific enough to troubleshoot methodically. If your team needs help coordinating server settings, provider tickets, and delivery evidence, a managed cold email service can help. Ask who owns infrastructure checks and how they verify a correction before sending resumes.