Blog · Deliverability
Why Your Emails Fail Gmail Because of PTR Records
Your SPF record passes. Your DKIM signature is valid. But your custom domain emails land in Gmail spam folders or get rejected entirely. If this sounds familiar, the problem is probably not your SPF or DKIM configuration. It is your PTR record.
A PTR record is a reverse DNS record. It maps an IP address back to a domain name. Gmail uses PTR records as an anti-spoofing signal. When a sending server has no PTR record, or when its PTR record does not match the domain it claims to be sending from, Gmail may treat it as suspicious and filter or reject the mail. This happens independently of SPF and DKIM, which is why you can pass both and still have deliverability problems.
What a PTR Record Is
DNS works in two directions. Forward DNS maps a domain name to an IP address (A or AAAA records). Reverse DNS maps an IP address back to a domain name. The record that makes this happen is is called a PTR record, short for pointer.
For example, if your mail server has the IP address 203.0.113.50, a PTR record for that IP might look like this in DNS:
50.113.0.203.in-addr.arpa. IN PTR mail.example.com.
That tells anyone who looks up that IP that it belongs to mail.example.com. Gmail performs this lookup every time it receives a message from your server. If the lookup fails or returns an unexpected result, Gmail notes it as a negative signal.
Why Gmail Requires a Matching PTR Record
Gmail uses PTR records as part of its sender verification system. The logic is straightforward: a legitimate mail server should have a identifiable name in reverse DNS. A server that sends email but has no PTR record, or has a PTR that does not match the domain it claims to be sending from, looks like a spoofed or untrusted source.
This check is separate from SPF and DKIM. SPF verifies whether the sending server is authorized to send for the claimed domain. DKIM verifies that the message was signed with a valid cryptographic key. Neither of those checks whether the IP address itself has a recognizable identity in DNS. PTR records fill that gap.
Here is a concrete example. Suppose your envelope-from domain is newsletters.example.com and your sending server IP is 203.0.113.50. For the PTR check to pass cleanly, the PTR record for 203.0.113.50 should resolve back to a hostname that has an A record pointing to 203.0.113.50. This is called forward-confirmed reverse DNS, or FCrDNS.
How to Check Your PTR Record
The fastest way to check a PTR record is from the command line:
bash
dig -x 203.0.113.50 +short
Replace 203.0.113.50 with your actual sending server IP. If a PTR record exists, this returns the hostname. If nothing returns, there is no PTR record for that IP.
You can also use online tools. MxToolbox offers a reverse DNS lookup tool at mxtoolbox.com/lookup reverse. WhatIsMyIPAddress.com has a similar tool. Paste your sending IP and look for the returned hostname.
If you already know your hostname but want to verify the forward resolution, check that the A record for that hostname points back to your IP:
bash
dig mail.example.com +short
If the output matches your sending IP, your FCrDNS is correctly configured.
What FCrDNS Means and Why It Matters
FCrDNS stands for Forward-Confirmed Reverse DNS. An IP has FCrDNS when the PTR record for that IP points to a hostname, and the A record for that hostname resolves back to the original IP. Both directions must match.
FCrDNS is not strictly required by the SMTP specification, but it is required by many large mailbox providers including Gmail, Microsoft, and Yahoo. Without FCrDNS, your mail may be accepted during the SMTP conversation but flagged or filtered at delivery time based on the PTR mismatch.
The Residential and Dynamic IP Problem
There is a separate but related problem: residential IP addresses.
If you are sending email from a home internet connection, a cloud VM on a residential-range IP, or any IP address assigned by a consumer ISP, you likely cannot get a valid PTR record for it. Residential IPs are assigned dynamically and ISPs typically do not allow customers to set reverse DNS for them. Even if you could, multiple customers cycling through the same IP means the PTR would constantly change.
Gmail maintains a list of IP ranges associated with residential and dynamic assignment. Sending from these ranges is a negative signal. Even with a matching PTR record, mail sent from known residential IP ranges may be filtered more aggressively.
The practical fix is to avoid sending bulk or transactional email from residential connections. Use a dedicated mail service or a cloud VPS with a static IP and proper FCrDNS instead.
Gmail Postmaster Tools: Checking Your Sending IP Reputation
If you manage a Google Workspace domain, Gmail Postmaster Tools shows you the reputation of your sending IP addresses. Log into postmastertools.google.com with your Workspace admin account, select your domain, and look at the IP reputation tab.
Gmail classifies sending IP reputation into four levels: Bad, Low, Medium, and High. If your sending IP reputation shows as Low or Bad, that is a separate problem from your PTR record and will cause filtering regardless of your DNS configuration. High reputation IPs with correct FCrDNS have the best deliverability outcomes.
If you do not use Google Workspace but send mail to Gmail users, you cannot access Postmaster Tools directly. In that case, check your IP reputation using third-party tools like Google Gmail IP reputation lookup via MxToolbox, or look up your IP range in common blocklists to see if it is listed.
Third-Party Email Services and Who Controls the PTR
If you use a third-party email service such as Brevo, SendGrid, Mailgun, or Amazon SES, the PTR record for your sending IP addresses is controlled by that service, not by you. This is one of the main reasons to use a reputable bulk email provider: they maintain proper FCrDNS for their IP ranges and have established sender reputations.
When you send through Brevo, for example, Brevo's servers send the mail. The PTR record for Brevo's sending IPs points to Brevo's own hostnames. Brevo handles the reverse DNS. Your responsibility is limited to ensuring your SPF record authorizes Brevo's sending IPs and your DKIM is correctly configured for your domain.
If you are sending through a dedicated IP that you control, you control the PTR. If you share an IP with other senders through your provider, your deliverability is partly dependent on the behavior of those other senders.
How to Set or Request a PTR Record
PTR records cannot be set in your DNS registrar the way A or MX records can. Reverse DNS is controlled by the organization that owns the IP address block, which is typically your ISP, hosting provider, or cloud platform.
To set a PTR record:
1. Identify who owns your sending IP. Run a WHOIS lookup on your IP address. Look for the organization name and the abuse contact.
2. Contact your IP owner and request a PTR record. Most hosting providers and cloud platforms let you set reverse DNS through their control panel. AWS EC2 lets you set the reverse DNS via the EC2 console or the API. DigitalOcean, Linode, and Vultr all have reverse DNS settings in their control panels.
3. Set the PTR to point to a hostname you control. For example, mail.example.com.
4. Verify the forward resolution. After setting the PTR, run dig -x
The turnaround time varies. Some providers set reverse DNS within minutes through their control panel. Others require a support ticket and may take 24 to 48 hours.
How to Monitor for PTR-Related Delivery Issues
PTR-related delivery problems are intermittent and can appear after infrastructure changes. You change hosting providers, spin up a new sending server, or get assigned a new IP range and forget to set the reverse DNS. Your mail starts failing and it is not immediately obvious why.
DMARCFlow can help here. DMARC aggregate reports tell you how Gmail is treating your mail, including authentication results. If your DMARC reports show spikes in DMARC failures or alignment errors that coincide with a new IP or hosting change, that is a signal worth investigating. A PTR mismatch will not show up directly in a DMARC report, but it does affect Gmail spam classification, which you may see as sudden drops in delivery rates.
Beyond DMARCFlow, the most direct way to catch PTR problems early is to monitor your sending IP reputation in Gmail Postmaster Tools if you have access, or to run periodic checks on your sending server IPs using dig -x and MXToolbox reverse DNS lookups.
FAQ
Does passing SPF make the PTR check redundant?
No. SPF and PTR checks verify different things. SPF checks whether the sending server IP is authorized for the claimed domain. The PTR check verifies whether the sending IP has a recognizable identity in DNS. Both are independent signals that Gmail uses. You can pass SPF and fail the PTR check, or fail SPF and pass the PTR check.
My PTR matches forward DNS but Gmail still flags my mail. What else could it be?
If your FCrDNS is correct and you still have delivery problems, check your IP reputation in Gmail Postmaster Tools. Your sending IP may be on a blocklist, may be in a residential IP range, or may have a poor reputation due to the sending behavior of other users on the same IP range. Also check whether your domain itself has a reputation problem, which is tracked separately from IP reputation.
Can I set a PTR record myself?
Only if you own the IP address block. For most users, that means asking your hosting provider, cloud platform, or ISP to set the reverse DNS for you. Some providers let you do this through their control panel without contacting support.
What if I use a third-party email service?
If you send through Brevo, SendGrid, Mailgun, or a similar service, the PTR record is controlled by that service. Your job is to ensure your SPF record authorizes their sending IPs and your DKIM is correctly configured. If you are on a dedicated IP plan with that service, you typically have control over the reverse DNS for your dedicated IPs.
How long does it take for a PTR record change to take effect?
DNS propagation for PTR records typically takes effect within minutes to a few hours for most resolvers, but can take up to 48 hours in some cases due to resolver caching. After changing your PTR record, test it with dig -x immediately, but allow up to 48 hours for all Gmail-receiving servers to see the updated record.