PTR Records and Email Deliverability

A bad PTR record can stop good mail cold

You can have clean copy, real opt-ins, and a healthy domain, then still see mail rejected because one IP does not point back to a proper host name. That is what a PTR record does. It is reverse DNS for the server that sends your mail.

Mailbox providers check the sending IP during the SMTP handoff. For Gmail, sending domains or IPs need valid forward and reverse DNS records. In practice, the sending IP should have a PTR record that resolves to a host name, and that host name should have an A or AAAA record that resolves back to the same IP. This is often called forward-confirmed reverse DNS.

If that chain is missing or mismatched, Gmail can limit sending rates, block messages, or mark messages as spam. Microsoft 365 can also use PTR as a fallback authentication signal, but Microsoft says it is not a substitute for SPF, DKIM, or DMARC alignment.

• Find the IP that actually sends the message. Check the message headers, your SMTP logs, or your email service provider.
• Run a reverse DNS lookup on that IP. It should return a real host name, such as mail.example.com.
• Run a forward lookup on that host name. It should return the same sending IP.
• Use a host name in a domain you control or one clearly tied to your provider. Avoid generic cloud names when you can.
• If you use shared sending, ask the provider to confirm their PTR setup. You usually cannot change PTR for a shared IP yourself.

PTR is an IP trust check, not domain authentication

A PTR record does not prove that your From domain owns the message. It proves that the sending IP has sane reverse DNS. You still need SPF, DKIM, and DMARC.

SPF is a TXT record that lists the servers allowed to send for your domain. Keep one SPF record at the domain. Include every real sender, remove old services, and watch the 10 DNS lookup limit from RFC 7208. The include, a, mx, ptr, exists, and redirect terms count toward that limit. Too many lookups can make SPF return a permanent error. Use ~all while you are still finding senders. Use -all only when you are sure the list is complete.

DKIM signs the message with a key tied to a selector, such as selector1._domainkey.example.com. Turn DKIM on in each sender, publish the public key they give you, and make sure the message is actually signed. DKIM is useful because it can survive some forwarding paths better than SPF.

DMARC checks whether SPF or DKIM passes and aligns with the visible From domain. Start with p=none and a rua reporting address so you can see who sends as you. Move to p=quarantine or p=reject only after your real mail is passing. RFC 7489 defines those policies. Google requires DMARC for senders that send more than 5,000 messages per day to personal Gmail accounts.

• SPF: one TXT record, no stale senders, no more than 10 DNS-querying terms, sensible all mechanism.
• DKIM: enabled for every mail stream, current selector published, messages signed.
• DMARC: record at _dmarc.yourdomain, aligned SPF or DKIM, reports turned on.
• MX: present for domains that receive replies. Bad MX records can break replies and abuse handling.
• PTR: reverse lookup and forward lookup match the live sending IP.

How to fix PTR record email deliverability

The fix depends on who controls the sending IP. DNS for your domain and reverse DNS for the IP are often managed in different places.

If you run your own mail server on a dedicated IP, set the PTR record with the IP owner. That is usually your cloud host, data center, or ISP. Set it to a stable mail host name, then create the matching A or AAAA record in your normal DNS zone. Use the same name in your mail server greeting when possible.

If you send through Google Workspace, Microsoft 365, Mailgun, SendGrid, Postmark, Amazon SES, or another provider, do not invent a PTR record in your DNS. Ask the provider which IP pool sends your mail and whether it has valid reverse DNS. Dedicated IP plans usually let you request branded reverse DNS. Shared pools are managed by the provider.

After the PTR chain is fixed, send a fresh test message. Read the headers. Look for SPF, DKIM, and DMARC pass results. Then check whether the sending IP or domain appears on major blocklists. A PTR fix will not erase a bad reputation by itself, but it removes one hard technical failure.

You can also run a free InboxRadar domain check to catch SPF, DKIM, DMARC, MX, and related drift before it turns into a delivery problem.

• Do not point many unrelated customers to the same branded host name.
• Do not use a host name that lacks an A or AAAA record.
• Do not expect a CNAME to fix reverse DNS. PTR must be set by the IP owner.
• Do not ignore bounce text. Codes such as 5.7.x often tell you whether DNS, auth, or policy caused the failure.
• Do not change DMARC to reject until reports show your real mail is aligned.

Why the message can still land in spam

PTR is one gate. Inbox placement also depends on authentication, reputation, complaints, list quality, content, and sending patterns.

Gmail says unauthenticated messages are more likely to be rejected or marked as spam, and its sender rules include valid forward and reverse DNS. Microsoft guidance covers SPF, DKIM, DMARC, PTR fallback, sender history, recipient history, and other signals. That means a correct PTR record helps, but it is not a promise of inbox placement.

If DNS is clean and mail still goes to spam, check the next causes in order. Confirm the domain is not on a blocklist. Check Google Postmaster Tools if you send enough mail to Gmail. Separate transactional mail from marketing mail. Remove unengaged contacts. Make unsubscribe easy for bulk mail. Keep the From address stable. A sender that looks consistent is easier for filters to trust.

For source rules, use the official docs: RFC 7208 for SPF, RFC 6376 for DKIM, RFC 7489 for DMARC, Google sender guidelines, and Microsoft email authentication guidance.