Reverse DNS and Email Deliverability: PTR Fixes

Reverse DNS is a quick trust check

A missing PTR record can make a clean mail server look like a throwaway box. That matters when Gmail, Outlook, and other mailbox providers decide whether to accept mail, place it in the inbox, or send it to spam.

Reverse DNS maps the sending IP address back to a hostname. For email, the useful test is forward-confirmed reverse DNS. The loop should close like this: the sending IP has a PTR record, the PTR points to a real hostname, and that hostname has an A or AAAA record pointing back to the same sending IP.

Google's sender guidelines say sending domains or IPs should have valid forward and reverse DNS records. They also say the sending IP should match the IP address of the hostname in the PTR record. Outlook.com says it may reject mail from senders that fail reverse DNS. Microsoft 365 can also use PTR as a fallback signal when SPF and DKIM do not give a clear pass. A PTR fix can remove a clear warning sign, but it does not promise inbox placement by itself.

• Find the public IP your mail server uses to send SMTP traffic.
• Look up the PTR for that IP. It should return a stable hostname, such as mail.example.com.
• Look up A or AAAA for that hostname. It should resolve back to the same IP.
• Use a hostname you control where your provider allows it, not a random cloud host string.
• Ask the IP owner to set the PTR. That is usually your ISP, cloud host, or email service provider, not your DNS registrar.

When PTR problems hurt delivery

PTR trouble is most common on self-hosted mail, dedicated SMTP servers, and cloud VMs. It is less common with Google Workspace, Microsoft 365, and major email service providers because they manage the sending IPs.

If you send through a shared email platform, you may not control reverse DNS at all. In that case, check the platform's documentation and focus on your domain records. If you run Postfix, Exchange, or another SMTP server on your own IP, verify PTR before you send real mail.

Do not put every brand name into the PTR. Use one hostname per sending IP. Keep it stable. Make sure the server's SMTP greeting is sane too. The HELO or EHLO name should be a real hostname, and it should not pretend to be gmail.com, outlook.com, or another provider.

• No PTR record: ask the IP owner to create one.
• PTR points to a generic host: change it to a mail hostname you control if your provider allows it.
• PTR points to a hostname with no A or AAAA record: add the forward record.
• Forward record points to a different IP: fix the A or AAAA record, or change the PTR target.
• Multiple sending IPs: check each IP. One clean IP does not cover the rest.

PTR is only one sender signal

Mailbox providers do not grade reverse DNS in a vacuum. They compare it with authentication, reputation, message quality, and user complaints.

SPF is the DNS TXT record that lists which servers may send for your domain. Publish one SPF record, include every real sender, and avoid extra includes. RFC 7208 limits SPF evaluation to 10 DNS lookup mechanisms and modifiers, including include, a, mx, ptr, exists, and redirect. If evaluation exceeds that limit, receivers return a permanent error. Use ~all while you are still finding senders. Move to -all only after you are sure the list is complete.

DKIM signs mail with a private key and publishes the public key in DNS under a selector, usually like selector._domainkey.example.com. The selector lets you rotate keys and let different services sign mail. Turn DKIM on in each sender, then confirm real messages show a passing DKIM result with your domain in the d= value.

DMARC tells receivers how your domain wants them to handle mail that fails aligned SPF or aligned DKIM. Start with p=none and a rua reporting address so you can see who is sending as your domain. After the reports look clean, move toward p=quarantine or p=reject. DMARC alignment means the visible From domain lines up with the SPF domain or the DKIM signing domain. That alignment is why SPF and DKIM alone do not prove the visible From domain is authorized.

• SPF: one TXT record, no duplicate SPF records, under the 10-lookup limit.
• DKIM: enabled for each sender, with current selectors and passing signatures.
• DMARC: a record at _dmarc.example.com with policy, alignment, and rua reports.
• MX: valid receiving records so replies, bounces, and abuse reports can reach you.
• Blocklists: check the sending IP and domain if delivery suddenly drops.

A practical order of work

Fix the hard failures first. Then watch whether the domain stays clean.

Start with the sending IP. Confirm PTR and forward DNS. Then check SPF, DKIM, and DMARC against a real message, because DNS can look correct while the mail stream still uses the wrong sender, wrong selector, or wrong return-path. After that, check MX and blocklists. If all of those pass, look at complaint rate, list quality, sending volume changes, and content.

For a fast read, run your domain through the free InboxRadar scorecard. It checks live SPF, DKIM, DMARC, and MX records and points you to the record that is most likely to hurt delivery. For the formal rules, use the source documents: RFC 7208 for SPF, RFC 6376 for DKIM, and RFC 9989 for current DMARC. Older provider docs may still point to RFC 7489, which RFC 9989 replaced. Also check the current Google sender guidelines, Outlook.com sender support, and Microsoft 365 email authentication guidance.