# Gmail 550 5.7.25: the PTR record Gmail requires, and IPv6 > Gmail returns 550 5.7.25 when the sending IP has no PTR record or its forward DNS does not point back to that IP. Check the exact IP in the bounce, IPv6 first. - Published: 2026-11-07 - Author: Koltrix Team - Category: Deliverability - Source: https://koltrix.com/blog/gmail-550-5-7-25-the-ptr-record-gmail-requires-and-ipv6 If Gmail bounces your mail with `550 5.7.25`, it is telling you about the IP address that connected, not about your domain, your SPF record or your message. Google's own [SMTP error reference](https://support.google.com/mail/answer/3726730) describes the error as a block because the sending IP address has no PTR record, or because its forward DNS entry does not point back to that IP. The fastest fix starts with one question: which IP did Gmail actually see? ## What does 550 5.7.25 mean? A PTR record is the reverse DNS entry that maps an IP address to a hostname. Gmail's [sender guidelines](https://support.google.com/a/answer/81126) say the public IP address of a sending SMTP server must have a corresponding PTR record that resolves to a hostname, and that the hostname must in turn have an A (IPv4) or AAAA (IPv6) record pointing back at the same sending IP. When either half is missing, Gmail rejects the message with a permanent 550. The temporary version is `451 4.7.23`. Google describes it as the same reverse DNS problem, where Gmail defers and rate limits the mail instead of refusing it. Treat a 4.7.23 as an early warning for the same fix. This is a different check from SPF, DKIM and DMARC (see [Gmail rejections 4xx and 5xx](/blog/gmail-rejections-4xx-5xx)), which prove who the message claims to be. Reverse DNS is a basic hygiene test on the connecting machine, and it runs whatever your authentication says. ## Why does it hit IPv6 senders so often? The most common cause is that Gmail connected over IPv6 and only the IPv4 address has a PTR record. Dual-stack servers try IPv6 first when the receiver publishes an IPv6 address, so a server can deliver to other providers over IPv4 and still fail at Gmail. Google's guidance says an IPv6 authorization error could mean the PTR record for the sending server is not using IPv6, and that if you use an email service provider you should confirm it uses an IPv6 PTR record. Typical situations behind it: - You added an IPv6 range to a server and set the PTR only for the old IPv4 address. - You moved to a new IPv6 prefix, and the old address still has its PTR while the new one, the one actually sending, has none. - A cloud provider assigned an IPv6 address automatically and you never saw it in the console. - Your provider set the PTR, but the AAAA record for that hostname is missing or points to a different address. Recent write-ups from deliverability practitioners also report that Gmail has become stricter about broken or missing PTR and DNS delegation than it used to be, so a setup that worked for years can start failing. That is an observation, not a published Google change, so check your own bounces rather than assuming. ## How do you find the IP Gmail saw? Read the full bounce text and the `Received` headers of a delivered test message. The IP in the bounce is the one to fix. Do not assume it is the address you think of as your server's address. On the sending server, list every global address it can use: ```bash ip -4 addr show scope global ip -6 addr show scope global ``` Then test each address the way Gmail does, in both directions: ```bash # 1. Reverse lookup: IP to hostname dig -x 203.0.113.25 +short dig -x 2001:db8:1234::25 +short # 2. Forward lookup: hostname back to the same IP dig A mail1.example.com +short dig AAAA mail1.example.com +short ``` A passing result looks like this table. The reverse and forward names agree in both directions, for both address families. | Check | IPv4 | IPv6 | |---|---|---| | Sending address | 203.0.113.25 | 2001:db8:1234::25 | | PTR (reverse) | mail1.example.com | mail1.example.com | | Forward record | A: 203.0.113.25 | AAAA: 2001:db8:1234::25 | | EHLO name | mail1.example.com | mail1.example.com | If you want the longer version of the commands, [dig commands for email](/blog/dig-commands-for-email) covers the lookups, and [reverse DNS for mail servers](/blog/reverse-dns-ptr-helo) explains FCrDNS and the EHLO name in more depth. ## How do you fix it? There are four steps, in this order: 1. **Identify the sending IP from the bounce.** Fix that address, not the one you assumed. 2. **Create the forward record first.** Add an A record for IPv4 and an AAAA record for IPv6 on the hostname you want, for example `mail1.example.com`. Many providers refuse to set a PTR until the forward record already exists. 3. **Set the PTR at whoever owns the IP.** You do not control it in your domain's DNS. The owner of the address block does: your cloud provider's console or API, your hosting company's panel or support, or your ISP. For IPv6, ask for the PTR on the exact address that sends, not just the prefix. 4. **Make the EHLO name match.** Set your mail server's HELO/EHLO name to the same hostname. If you cannot get an IPv6 PTR quickly, a common stopgap is to send over IPv4 only, either by disabling IPv6 for the mail server or by forcing it. In Postfix, `smtp_address_preference = ipv4` (or `inet_protocols = ipv4`) does that. Treat it as a bridge until the IPv6 PTR exists, not as the final setup. ## What if the DNS looks right and Gmail still bounces? The error text says "no PTR record" or "forward DNS does not match", but the cause can be broader than a missing entry. Check these before you open a ticket: - **Delegation.** The reverse zone for your IP must be delegated to nameservers that actually answer. A broken delegation or an unresponsive nameserver looks like a missing PTR from Gmail's side. - **Intermittent answers.** If only some of the authoritative servers hold the correct record, Gmail fails only some of the time. Query each nameserver directly with `dig -x @`. - **Multiple PTR records.** Keep one clear hostname per IP. Several unrelated names make the forward check ambiguous. - **Generic provider names.** A PTR such as `host-203-0-113-25.provider.example` that resolves forward is technically valid, but a name under your own domain is easier to defend and to match to the EHLO name. - **Stale cache.** A recently changed PTR can take up to the record's TTL to propagate. Re-test with `dig` against the authoritative nameservers, then resend. ## What if you send through a provider? Then the IP belongs to them, and the PTR is theirs to maintain. Your job is to confirm the failing IP is one of theirs, and send them the full bounce. Google's guidance for this case is to confirm that the provider uses an IPv6 PTR record. If you are on a dedicated IP, ask whether they offer a custom PTR under your domain. If your mail goes out through a relay that sometimes uses IPv6 and sometimes IPv4, you may see the error only on some messages. ## How do you stop it from coming back? Write the sending identity down once and test it on a schedule: - Keep one list of sending hostnames with their A, AAAA and PTR values. - Re-run the forward and reverse checks whenever you add an address, change a prefix, or move hosts. - Send a test message to a Gmail address after every infrastructure change and read the `Authentication-Results` and `Received` headers. - Watch your bounce logs for `4.7.23` as well as `5.7.25`, since the temporary code shows up first. ## Bottom line `550 5.7.25` means the IP that connected to Gmail has no usable reverse DNS, or the hostname does not resolve back to it. Take the IP from the bounce, check both IPv4 and IPv6, create the A and AAAA records, ask the IP owner to set the PTR on the exact sending address, and align the EHLO name. When the DNS looks correct and Gmail still rejects you, look at delegation and nameservers that answer inconsistently before you change anything else.