Every IP address that sends your mail should have a PTR (reverse DNS) record naming a host, and that host’s A or AAAA record should point back to the same IP. This is forward-confirmed reverse DNS, FCrDNS. Gmail documents it as a requirement, and without it you can see 550 5.7.25 or 451 4.7.23. The PTR is set by whoever owns the IP address block, usually your hosting provider or ISP, not by the DNS host of your domain. Check yours with the reverse DNS lookup.
What FCrDNS means
Sending IP: 203.0.113.25
PTR: 25.113.0.203.in-addr.arpa. IN PTR mail.example.com.
Forward: mail.example.com. IN A 203.0.113.25
The IP maps to a name and the name maps to the same IP. The addresses above are documentation examples. RFC 1912 §2.1 asks for this: “Make sure your PTR and A records match”, “For every IP address, there should be a matching PTR record in the in-addr.arpa domain”, and PTR records “must point back to a valid A record, not a alias defined by a CNAME”. For IPv6 the reverse zone is ip6.arpa.
Who sets the PTR
Reverse zones follow IP ownership, not domain ownership. The in-addr.arpa zone for your address is delegated to the organization that holds the block. That is why adding a record in your domain’s DNS panel never creates a PTR.
| Where the mail server runs | Who sets the PTR |
|---|---|
| VPS or dedicated server | Hosting provider, through a control-panel field or a support request |
| Cloud instance | Cloud provider, often a setting on the address or instance; check the provider’s documentation |
| Office line or business ISP | The ISP, on request |
| Hosted mail (Google Workspace, Microsoft 365) | The provider manages it for its own sending IPs |
If you use a hosted mail service, you generally have nothing to configure. Microsoft’s article on this topic states that the sending IPs used by Microsoft 365 have forward-confirmed reverse DNS records, and also that their HELO names do not always match the PTR of every address. The procedure is for self-hosted servers and some relays.
What Google and Microsoft say
Google’s email sender guidelines say the public IP of a sending server must have a PTR record that resolves to a hostname, and that “the sending IP address must match the IP address of the hostname specified in the Pointer (PTR) record.” They add that if you do not meet the requirements, mail “might not be delivered as expected, or might be marked as spam.” Google also lists IPv6 PTR problems as a cause of rejection.
Microsoft’s learn.microsoft.com article “Cannot send emails to an external recipient” describes the receiving side: some recipient servers require the HELO name to have a matching PTR, and rejects look like “host name does not match IP address”. For mail to Outlook.com and Hotmail mailboxes, check Microsoft’s Outlook.com postmaster pages for the current sender requirements.
Errors you may see
- 550 5.7.25 (Gmail): permanent rejection, the sending IP has no PTR or the forward entry does not match.
- 451 4.7.23 (Gmail): the temporary version of the same problem, Gmail defers the message.
Set it up
- Choose a hostname in a domain you control, such as
mail.example.com. Using the same name as the server’s HELO/EHLO greeting avoids a second mismatch. - Create the A (and AAAA, if you send over IPv6) record for that hostname at your DNS host.
- Ask the IP owner to set the PTR to that hostname, or set it in their panel.
- Look up the IP with the reverse DNS lookup and the hostname with the DNS lookup. The loop must close.
- Configure the mail server to announce the same name in HELO/EHLO.
Trade-off: one PTR per IP is the norm. If one IP sends for many domains, the PTR can only match one name; that is acceptable since receivers check the loop, not whether the PTR domain equals the From domain. Do not use a CNAME as the PTR target, and avoid generic provider names like 203-0-113-25.static.provider.example when you can: they pass a loop check but look like consumer space to some filters.
PTR does not replace SPF, DKIM and DMARC. It is a baseline. The provider setup check covers authentication records.
FAQ
Can I set a PTR at my domain registrar? No. Registrars manage the domain, not the IP’s reverse zone.
Does every sending IP need one? Yes, each IP that connects to receivers. RFC 1912 §2.1 says multi-homed hosts need a PTR for every address.
Is a PTR needed if I use Google Workspace or Microsoft 365? Not for mail sent through their servers; they manage their own addresses.
Sources
- RFC 1912, §2.1 Inconsistent, Missing, or Bad Data: https://www.rfc-editor.org/rfc/rfc1912#section-2.1
- Google, Email sender guidelines: https://support.google.com/a/answer/81126
- Microsoft Learn, Cannot send emails to an external recipient: https://learn.microsoft.com/en-us/exchange/troubleshoot/antispam-and-protection/cannot-send-emails-to-external-recipients