Skip to main content
Relaymetry

Outlook 5.7.25 Fix: Sending IPv6 Address Must Have a Reverse DNS Record

An Outlook 5.7.25 bounce means Microsoft refused your message at connection time because you connected over IPv6 and the sending IPv6 address has no reverse DNS (PTR) record. The full text is “Access denied, the sending IPv6 address must have a reverse DNS record,” and per Microsoft the sending IPv6 address must have a reverse DNS record to send email over IPv6. This is an IPv6 reverse-DNS requirement, not an authentication or content problem, so SPF, DKIM, and DMARC can all pass while the message is still refused. The fix is to publish a PTR record for the sending IPv6 address through whoever owns the IP block, or to send that mail over IPv4 instead, which Microsoft treats less strictly.

Quick answer

An Outlook 5.7.25 bounce means Microsoft refused your message at connection time because you connected over IPv6 and the sending IPv6 address has no reverse DNS (PTR) record. The full text is Access denied, the sending IPv6 address [<ipv6>] must have a reverse DNS record, and per Microsoft the sending IPv6 address must have a reverse DNS record to send email over IPv6. This is an IPv6 reverse-DNS requirement, not an authentication or content problem, so SPF, DKIM, and DMARC can all pass while the message is still refused. The fix is to publish a PTR record for the sending IPv6 address through whoever owns the IP block, or to send that mail over IPv4 instead, which Microsoft treats less strictly.

What the 5.7.25 code means

Microsoft's NDR table defines 5.7.25 Access denied, the sending IPv6 address [<ipv6>] must have a reverse DNS record as "The sending IPv6 address must have a reverse DNS record to send email over IPv6." The check is applied to the IPv6 address that actually opened the SMTP connection to Microsoft, the machine that connected, not necessarily the domain in your visible From address.

The angle that catches most senders out is that this requirement only exists on IPv6. When you connect to Exchange Online or Outlook.com over IPv6, Microsoft enforces stricter inbound requirements than it does over IPv4. Per Microsoft's "Support for anonymous inbound email messages over IPv6" guidance, a message sent over IPv6 must have a valid PTR (reverse-DNS) record on the sending IP and must pass either SPF or DKIM. A missing PTR on the sending IPv6 address produces 5.7.25; the same host, connecting over IPv4, would not face the PTR requirement.

It helps to separate 5.7.25 from the other "access denied" codes you might see from Microsoft, because they have different causes and different fixes:

  • 5.7.25 — the sending IPv6 address has no reverse DNS (PTR) record. Publish a PTR for the IP, or fall back to IPv4.
  • 5.7.23 — the message failed SPF. Fix the SPF record for the sending domain.
  • 5.7.509 — the message failed DMARC under a reject/quarantine policy. Align SPF or DKIM with the From domain.
  • 5.7.511 — the sending IP was banned as a reputation block. Remediate and request delisting.

A 5.7.25 is the IPv6-rDNS member of that group. Knowing the scope tells you where to look: a reverse-DNS requirement points at the outbound mail server's IP and the PTR zone of whoever owns that IP block, not at your domain's SPF, DKIM, or DMARC records.

Why Outlook returns 5.7.25

Microsoft applies the reverse-DNS requirement specifically to IPv6 connections as a baseline anti-abuse measure, because IPv6 address space is so large that IP reputation alone is weak. Requiring a PTR record forces the sending IP to be deliberately published in DNS by its owner. The common causes are:

  • A sending host with no PTR on its IPv6 address. The host has working forward DNS and connects over IPv6, but the IP's owner never published a reverse-DNS record for it, so Microsoft refuses the connection.
  • A cloud or hosting provider that assigns IPv6 without default rDNS. Many providers give you an IPv6 address but leave its PTR empty until you request one, while IPv4 addresses arrive with a PTR already set.
  • An email platform routing you over IPv6 from an IP whose reverse DNS is missing or generic, where the PTR is the platform's to set, not yours.
  • A dual-stack server that prefers IPv6 for the outbound connection, so mail that delivered fine over IPv4 starts bouncing once IPv6 is in the path.

Because the check is made on Microsoft's side at connection time, sender-side authentication changes alone do not clear it. You have to give the sending IPv6 address a PTR record, or take IPv6 out of the sending path.

How to diagnose a 5.7.25

Start by finding the IPv6 address Microsoft named. The NDR text includes the sending IPv6 address in brackets, and the diagnostic line states the reverse-DNS requirement explicitly. If you only have the bounce, read the full message source: the Received: headers and the NDR diagnostic text carry the connecting IPv6 address. Do not assume it is your domain's MX or your office IP; when you send through a platform, the connecting IP is usually one the platform owns.

Once you have the IPv6 address, confirm whether it has a PTR record by running a reverse-DNS lookup against it. If the lookup returns no PTR, that is the cause. A DNS lookup on the sending host also tells you whether its forward DNS and mail-related records are otherwise in order, so you can see whether reverse DNS is the only gap or part of a broader DNS problem.

Then confirm the message also passes SPF or DKIM. Microsoft's IPv6 rule requires both a valid PTR and a pass on SPF or DKIM, so a host with a PTR can still be refused over IPv6 if neither authentication method passes. Check that at least one of SPF or DKIM aligns and passes before you re-test, so the message meets the full IPv6 requirement and not just the reverse-DNS half.

One thing a public lookup cannot do is publish the PTR for you. Reverse DNS for an IP is controlled by whoever owns the IP block, so a missing PTR is fixed by the IP's owner, not in your domain's DNS zone.

How to fix a 5.7.25

The fix is to give the sending IPv6 address a reverse-DNS record, then re-test. If you cannot get a PTR on that IP, the practical alternative is to keep the mail on IPv4.

  1. Identify the sending IPv6 address from the NDR diagnostic line (the address in brackets) and the message Received: headers.
  2. Confirm the PTR is missing by running a reverse-DNS lookup against that IPv6 address; no PTR returned is the cause.
  3. Ask the IP owner to add the PTR. Reverse DNS is set by whoever owns the IP block — your hosting or cloud provider, or your email platform — not in your domain's DNS zone. Request a PTR record for the exact sending IPv6 address.
  4. Ensure the message also passes SPF or DKIM, because Microsoft's IPv6 rule requires a PTR and a pass on at least one of SPF or DKIM. Align and validate one of them before re-testing.
  5. Re-test by sending to the Outlook.com or Exchange Online recipient again and confirming the message is accepted over IPv6.
  6. Fall back to IPv4 if no PTR is possible. If the IP's owner cannot set a PTR, send that mail over IPv4, which Microsoft treats less strictly, or move to a sending platform whose IPv6 IPs already have correct reverse DNS.

What this does not prove

A public DNS lookup confirms whether the sending IPv6 address has a PTR record and whether the host's forward DNS, SPF, DKIM, and DMARC records are in order. It cannot publish a missing PTR for you, confirm that a specific past message was refused for this exact reason, or guarantee that Microsoft will accept the connection once a PTR is added. Microsoft applies the IPv6 reverse-DNS and authentication checks on its side at connection time.

Relaymetry checks the public DNS signals that this requirement rests on. It does not control the reverse DNS of an IP you do not own, your sending platform's IPv6 routing, or the exact filtering decision Microsoft applied to a given connection.

Frequently asked questions

What does Outlook 5.7.25 mean?

Per Microsoft, 5.7.25 "Access denied, the sending IPv6 address [<ipv6>] must have a reverse DNS record" means you connected over IPv6 from an address that has no reverse DNS (PTR) record. Microsoft requires the sending IPv6 address to have a reverse DNS record to send email over IPv6. It is a connection-time requirement, not an authentication or content failure, so SPF, DKIM, and DMARC can all pass while the message is still refused.

Why does this only happen over IPv6 and not IPv4?

When you connect to Exchange Online or Outlook.com over IPv6, Microsoft enforces stricter inbound requirements than over IPv4. Per Microsoft’s guidance on anonymous inbound email over IPv6, a message sent over IPv6 must have a valid PTR (reverse-DNS) record on the sending IP and must pass either SPF or DKIM. The same host connecting over IPv4 is treated less strictly and does not face the PTR requirement, which is why mail that delivered over IPv4 can start bouncing once IPv6 is in the sending path.

Who controls the PTR record for the sending IPv6 address?

Reverse DNS for an IP is controlled by whoever owns the IP block, not by your domain’s DNS zone. That is your hosting or cloud provider, or your email platform, depending on who owns the address you send from. You cannot add a PTR for an IP you do not own from your own DNS panel; you have to request it from the IP owner. Many providers leave IPv6 reverse DNS empty by default even when the matching IPv4 address already has a PTR.

Can I just send over IPv4 instead of fixing the PTR?

Yes. If the IP owner cannot set a PTR on the sending IPv6 address, sending that mail over IPv4 is a valid fallback, because Microsoft treats IPv4 connections less strictly and does not impose the IPv6 reverse-DNS requirement. You can disable IPv6 on the outbound path, or move to a sending platform whose IPv6 IPs already have correct reverse DNS. Sending over IPv4 sidesteps 5.7.25, though you should still keep SPF, DKIM, and DMARC aligned for general deliverability.

Is 5.7.25 the same as 5.7.23, 5.7.509, or 5.7.511?

No — they are different causes. 5.7.25 is an IPv6 reverse-DNS (PTR) requirement at connection time. 5.7.23 is an SPF failure, 5.7.509 is a DMARC failure under a reject or quarantine policy, and 5.7.511 is a reputation ban on the sending IP. They also differ from the separate Gmail 5.7.25, which is likewise a PTR requirement but enforced on Gmail’s side. Read the code carefully: only 5.7.25 from Outlook points at the IPv6 address’s missing reverse DNS.

Other Outlook issues

References