What is a PTR (Reverse DNS Record) record? Why do mail servers need to be configured?

　　If your self-hosted email account is consistently rejected or ends up in your spam folder, it's likely due to an incorrectly configured DNS record. The DNS resolution we're familiar with translates a domain name like mail.example.com into an IP address (e.g., 203.0.113.10), which is called forward resolution, relying on A or AAAA records.

　　PTR records do the exact opposite—they translate IP addresses back to domain names. Therefore, they are also called reverse resolution records.

　　PTR records need to be configured with your IP address provider (such as a cloud provider or data center), not added directly to your domain's DNS control panel. This is because you only have the "right to use" the IP address, not "ownership," and control of the reverse DNS zone (e.g., in-addr.arpa) belongs to the ISP.

　　Why must mail servers be configured with PTR? The reason is simple: protection.

　　1. The first line of defense against spam

　　Spam senders prefer to use dynamic IPs or IPs without registered domains to send emails, making it easy to disappear and difficult to trace. To combat this behavior, most legitimate email service providers (Gmail, Outlook, QQ Mail, etc.) mandate that the sending IP address must have a valid PTR record.

　　When your mail server sends an email to the recipient, the recipient's server performs the following actions: extracts your sending IP address → performs a reverse PTR record lookup → checks if the resolved domain name matches your HELO/EHLO identifier.

　　If a PTR record exists and matches, the email is considered legitimate and is allowed to pass.

　　If no PTR record exists, the email is rejected outright, not even reaching the spam folder.

　　If a PTR record exists but doesn't match the HELO, the email is highly likely to be flagged as suspicious.

　　2. Preventing Domain Forgery and Phishing

　　Malicious senders can easily forge the sender's domain name (From field) in the email header, but it's difficult to forge the reverse DNS lookup result of the IP address. This is because control of the PTR record is held by the ISP, and it's not as simple as just attaching any domain name. Recipients can effectively verify the sender's IP address through PTR verification.

　　3. PTR is the foundation of other email authentication protocols

　　The PTR record is the foundation of the email authentication system. Authentication mechanisms such as SPF (authorizing which IPs can send emails on behalf of your domain), DKIM (digital signature), and DMARC (policy enforcement) are all built upon successful PTR verification. An IP without a PTR, no matter how well the other mechanisms are configured, may not even be given a chance to be verified by the receiving server.

　　The correct way to configure a PTR record

　　Key requirement: Three elements must be consistent

　　PTR is not simply a matter of entering any domain name; it must satisfy FCrDNS (Forward Confirmation Reverse DNS) verification. Simply put:

　　The IP's PTR record must point to mail.example.com

　　The A record of mail.example.com must point to the same IP

　　The mail server's HELO/EHLO hostname must also be set to mail.example.com

　　These three must be interconnected and indispensable. Otherwise, the receiving server will fail FCrDNS verification.

　　Common Misconfigurations (Warning: Avoid These Pitfalls)

　　The PTR is pointing to the root domain (example.com) instead of the mail hostname (mail.example.com) – This configuration is invalid if the website and mail server are not on the same IP.

　　The default PTR provided by your service provider hasn't been changed – Many VPSs use a generic PTR format like vps12345.provider.com by default; failing to change this will result in immediate failure.

　　The server IP has been changed but the PTR hasn't been updated – The old IP's PTR is invalid, and the new IP doesn't have a PTR.

　　Multiple sending IPs configured with only one PTR – Each outgoing IP must have its own corresponding PTR record.

　　How ​​to test if the PTR is working?

　　Execute the following command in the Linux or Mac terminal:

dig -x 203.0.113.10 +short

dig mail.example.com +short

　　The domain name returned by the first command must match the IP address returned by the second command for the configuration to be considered successful.

　　FAQ

　　Q1: Is the PTR record configured at the domain registrar?

　　A1: No. The PTR record needs to be configured at the IP address's service provider ,not in the registrar's console. This is because jurisdiction over the reverse DNS zone belongs to the IP holder.

　　Q2: What happens to emails if I don't configure a PTR?

　　A2: They will most likely be rejected or sent to the spam folder. Major service providers like Gmail explicitly reject emails from IPs without a PTR record. The bounce message will usually say, "The IP address sending this message does not have a PTR record setup."

　　Q3: Will configuring a PTR guarantee emails will reach my inbox?

　　A3: Not necessarily, but without one, they will definitely not reach me. PTR is just an "entry ticket"; to actually get your mail inbox into your inbox, you need to use it in conjunction with SPF, DKIM, DMARC, and the IP's own reputation.

　　Q4: Can multiple PTR records be configured for the same IP?

　　A4: An elastic IP can only be configured with one reverse DNS lookup, but it can be associated with a maximum of 10 domains. In practice, it is recommended to only keep the most essential mail server domain.

　　Q5: How long does it take for a PTR record configuration to take effect?

　　A5: Due to global DNS synchronization delays, it usually takes several hours to several days to fully take effect. After configuration, you can use `dig -x IP` to verify that it has started to take effect.