Skip to content
SendPoint / Education
Gmail deliverability

How to fix Gmail 550 5.7.25 PTR errors

Check the sending IP, reverse DNS and forward DNS, then send the right evidence to the infrastructure owner.

By Pavel IvanishchevUpdated 3 min read

Gmail's 550 5.7.25 response points to the sending IP's DNS: its PTR record is missing, or the hostname's forward lookup does not lead back to that IP. Save the complete response before changing anything. Source: Gmail SMTP errors and codes.

Find the IP Gmail actually saw

Ask your sending provider for the public connecting IP from the failed transaction. Your website's IP, your inbound mail server and your outgoing mail server can be different systems. A successful check against the wrong IP will not explain the failure.

Record the timestamp, affected stream and whether the route used IPv4 or IPv6. If only some messages fail, compare the connecting IPs before concluding that DNS is intermittently broken.

Check the two directions

Google requires the sending IP to resolve to a hostname through PTR, and that hostname to resolve back to the sending IP through an A record for IPv4 or an AAAA record for IPv6. Source: Gmail sender requirements.

Run these commands in Bash with dig installed. Enter the real connecting IP from the failed transaction and the hostname returned by its PTR lookup.

read -r -p "Connecting IP from the SMTP log: " sending_ip
dig +short -x "$sending_ip"
read -r -p "Hostname returned by PTR: " ptr_hostname
dig +short A "$ptr_hostname"
dig +short AAAA "$ptr_hostname"

Compare the A answer for an IPv4 connection or the AAAA answer for an IPv6 connection. If the PTR query returns no hostname, investigate that result before performing the forward lookup. Check each returned hostname if there is more than one.

The forward answer should include the original connecting IP. Preserve the full DNS response when an answer is empty or fails; a timeout, a missing record and a server failure need different investigations.

Send the fix to the right owner

Start with the provider responsible for the sending IP when the PTR is absent or incorrect. The team managing the returned hostname's DNS can correct its A or AAAA record. With an ESP, send both findings to support so it can identify which part it controls.

Use a compact handoff: connecting IP, UTC timestamp, complete Gmail response, PTR answer, forward answer, and whether other sending IPs succeed. Ask the provider to confirm both directions for the failing route.

Verify a fresh transaction

After the owner confirms the correction, repeat the DNS checks and send a new controlled test through the same route. If the error persists, compare the new transaction's IP and timestamp with the repaired configuration.

Treat a successful test as evidence for that route. Check the remaining active sending IPs before marking an incident affecting several routes resolved. Keep the DNS fix separate from any other errors that still appear.

Gmail SMTP error codes: what they mean and how to fix them

Sources