You're sending email from your own server, SPF and DKIM are set up, but Gmail returns the message with 550-5.7.25 or sends it straight to spam. The Postfix log shows nothing because the problem isn't on your side. The problem is that your IP doesn't point to any name in reverse DNS, and the receiving server has no way to verify the sender's identity.
The PTR record is the answer that comes back when someone queries your IP in reverse. Without it, every modern anti-spam policy sees you as suspicious, even if your email content is completely clean.
What exactly does a PTR record solve
When Gmail's server receives an email from your IP, it first does a reverse query: dig -x 203.0.113.45 +short. If the answer is empty or points to a name that doesn't resolve back to the same IP, the sender reputation score drops to zero. This check happens before SPF and DKIM; meaning even a correct signature won't save you.
A point many people don't know: PTR must be Forward-Confirmed. That is, if dig -x 203.0.113.45 returns mail.example.com, then dig mail.example.com must also return the same 203.0.113.45. If these two don't match, the PTR is worthless. This is called FCrDNS, and most email testing tools check it separately.
Who sets the PTR
This is where most admins get stuck. You don't set the PTR in your domain's DNS panel. The PTR is in the Zone file of the ISP or data center you got the IP from. You can only request it.
If you have a dedicated server or VPS from an Iranian provider, you can usually set rDNS through a support ticket or the server management panel. If you're on shared hosting, the PTR is usually set on the provider's own server name and you don't have access. In this case, sending transactional email from a personal domain on shared hosting is always risky.
For servers you manage yourself, if you use Linux hosting, the rDNS section is usually configurable in the same panel.
Setting PTR in practice: where do I start
First, find your server's public outbound IP. On the server, run:
curl -4 ifconfig.me
ip -4 addr show scope globalThen check whether a current PTR exists or not:
dig -x 203.0.113.45 +short
host 203.0.113.45If the output is empty, you need to request rDNS. In the request, write these two things precisely: the IP and the desired FQDN. For example, mail.example.com. The name you choose must have a valid A Record pointing to the same IP.
The correct pattern in the Zone file
In your domain's Zone, these records must exist:
mail.example.com. IN A 203.0.113.45
example.com. IN MX 10 mail.example.com.
example.com. IN TXT "v=spf1 mx -all"And on the ISP side, the PTR should be set like this:
45.113.0.203.in-addr.arpa. IN PTR mail.example.com.Order matters. Set the A Record first, let DNS propagate, then request the PTR. If you set the PTR before the A Record, FCrDNS fails and email testing tools will warn you.
How to verify it's working correctly
After it's set, run this command:
dig -x 203.0.113.45 +short
dig mail.example.com +shortBoth must confirm each other. For a final test, send an email to check-auth@verifier.port25.com. The reply you get back includes the status of SPF, DKIM, and rDNS. If the rDNS section says did not find a PTR record, it means it's not set yet or propagation hasn't completed.
Mistakes I've actually seen
Here's where people go wrong: they set the PTR on the main domain, not on the mail subdomain. That is, they set example.com as the PTR, while the MX points to mail.example.com. The result is that FCrDNS fails and Gmail still sees the email as suspicious. The sign is that all tests show green but the email still goes to spam.
Second mistake: multiple domains on one IP, all with one PTR. If you host ten sites on one server and they all send email from one IP, the PTR can only point to one name. The rest of the domains become inconsistent from an FCrDNS standpoint. The correct solution is a dedicated IP for each domain that sends transactional email.
Third mistake, which is seen less often but is painful: they set the PTR but later change the A Record and forget to update the PTR. A week later, emails silently go to spam and no one understands why. If you change your server's IP, re-check the PTR too.
PTR isn't enough: the full trust chain
PTR is just one link in the chain. If you have PTR but no SPF, you'll still be rejected. If you have SPF but no DKIM signature, some receivers will flag the message. If you don't have DMARC, you won't know who's spoofing your domain.
| Record | What it proves | If missing |
|---|---|---|
| PTR | IP points to a valid hostname | Rejection at connection stage |
| SPF | Server is authorized to send | Soft-fail or Reject |
| DKIM | Message hasn't been tampered with | Higher spam probability |
| DMARC | Anti-spoofing policy is defined | No reporting or control |
Follow the setup order: first A Record, then PTR, then SPF, then DKIM, and finally DMARC. If you go in reverse, each step makes testing harder.
When you can't set the PTR
On shared hosting, the PTR isn't in your hands. If you have transactional email (contact form, password recovery, order confirmation), you have two options: either use a transactional email service that manages its own IP with a proper PTR, or get a small VPS and use it only for sending email.
The first option is faster and less hassle. The second gives more control but you have to manage SPF, DKIM, and DMARC yourself. For most WordPress sites, the first option is the right choice. If you're on WordPress and your system emails aren't arriving, before anything else check the WordPress wp-cron problem; sometimes the problem isn't PTR at all and cron isn't running.
If you want to know where your emails are being rejected, free tools from ServerNet include DNS testing and record checking. For a better understanding of server errors, the HTTP status code guide is also a good reference.
Frequently asked questions
Why do my emails go to spam while I have SPF and DKIM?
Because you don't have PTR or FCrDNS isn't confirmed. The receiving server checks your IP's identity before checking SPF and DKIM. If the PTR is empty or points to a name that doesn't resolve back to the same IP, the sender reputation score drops and the message goes to spam.
Check both with dig -x IP and dig mail.example.com. If either is empty or doesn't match the other, that's where the problem is.
Should I set the PTR record myself in my domain's DNS panel?
No. The PTR is in the ISP's or data center's Zone file, not in your domain's DNS. You can only request rDNS through a ticket or server panel. In your domain's DNS panel, you only set A Record, MX, and TXT.
If you're on shared hosting, you usually don't have access to rDNS and should use a transactional email service.
How many domains can share one PTR?
Only one. A PTR points to only one hostname. If multiple domains send email from one IP, only the domain the PTR points to has valid FCrDNS. The rest become suspicious from the receiving servers' perspective.
The correct solution is a dedicated IP for each domain that sends transactional email. If the number of domains is large, a transactional email service is more cost-effective than managing multiple IPs.
How long does it take for PTR to take effect after setting it?
Propagation usually takes between a few minutes and a few hours, depending on the record's TTL. If you've set the TTL to 300 seconds (5 minutes), you'll see it faster. For records with higher TTL, it may take up to 24 hours.
After it's set, send a test email to check-auth@verifier.port25.com and read the reply. If rDNS is confirmed, the problem is elsewhere and you should check SPF and DKIM.
Comments 0
No comments yet — be the first!