550 5.7.25: Reverse DNS (PTR) check failed

At a glance

• Type: permanent failure (class 5, RFC 3463 §2). The sending server does not retry; sending the same message again fails the same way until the cause is fixed.
• Basic code 550: “Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons)” (RFC 5321 §4.2.3).
• Enhanced code 5.7.25: “Reverse DNS validation failed” in the IANA registry (RFC 7372), in the group security or policy status (RFC 3463 §3.8).

A 5.7.25 bounce means the IP address your mail came from has no usable reverse DNS (PTR) record. The receiver will not take mail from an IP that cannot say what host it belongs to.

What it means

Reverse DNS maps an IP address back to a hostname, through a PTR record. A sound setup also maps that hostname forward to the same IP (an A record for IPv4, AAAA for IPv6). RFC 7372 §3.3 defines X.7.25, "reverse DNS validation failed", for a server that refuses mail when this check fails. With 550 in front the refusal is permanent for this attempt; once you fix DNS, new attempts can succeed.

Common causes

• A new cloud server or VPS, where the provider's default PTR is missing or generic.
• A PTR record exists, but its hostname has no A or AAAA record pointing back to the same IP.
• The server sends over IPv6, and the IPv6 address has no PTR at all, even though IPv4 is set up.
• The server moved to a new IP and the old DNS was never updated.

How providers use it

Gmail answers 550 5.7.25 when the sending IP has no PTR record. Short of a block, it may rate limit you instead, with 451 4.7.23 or 421 4.7.0; Google describes both as covering a missing PTR record or forward DNS that does not match the IP (Google's SMTP error reference). Google's sender guidelines require valid forward and reverse DNS from every sender.

Microsoft uses 5.7.25 when mail arrives from an IPv6 address without reverse DNS (Exchange Online NDR reference).

How to fix it

1. Find the sending IP in the bounce text or in the Received headers of a sent copy.
2. Look it up: dig -x followed by the IP shows the PTR name. Then look up that name and confirm it returns the same IP.
3. Set the PTR where the IP is managed. That is your hosting or cloud provider's control panel, or your ISP. You cannot set it in your own domain's DNS zone.
4. Use a hostname in your own domain, add its A or AAAA record, and have your server use the same name in EHLO. RFC 5321 §4.1.1.1 requires a fully qualified domain name there.
5. For IPv6, set a PTR for the IPv6 address too, or stop the server from sending over IPv6.
6. If you cannot get a PTR (a home connection, for example), send through your mail provider's relay.

What to do with the address

Keep it. The recipient is fine; the fix is on your server.

Related codes

• 421 4.7.0: Temporarily refused: reputation, DNS or TLS
• 501 5.5.4: Invalid HELO/EHLO or command arguments
• 550 5.7.26: Unauthenticated: SPF and DKIM failed, or DMARC rejected it

See every bounce code in the dictionary.

Many bounces from addresses that do not exist can be avoided: check an address with our free email checker, or clean a whole list before you send.

How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.