Exchange Online refuses anonymous inbound mail over IPv6 from addresses without reverse DNS. 5.7.25 means the connecting IPv6 address had no PTR record, which Microsoft requires before it will accept unauthenticated IPv6 connections.
Most common causes
- The sending IPv6 address has no PTR record
- The outbound mail path recently moved to IPv6 without matching reverse DNS
- The PTR exists for a different address than the one used for delivery
What to verify next
- Run Reverse DNS & HELO Auditor for the sending IPv6 address
- Confirm the outbound IP shown in the rejection or message trace
- Publish and verify the appropriate PTR through the IP-space provider
- Confirm the forward hostname and SMTP identity are consistent after the change
IPv6 has stricter identity rules
Because IPv6 address space is effectively unlimited, receivers cannot rely on address history the way they can for IPv4. Microsoft, like Google, therefore requires that an IPv6 sender have a PTR record that resolves, and rejects connections that lack one.
The failure often appears after infrastructure gains IPv6 connectivity by default — a new server, a cloud instance, or an upgraded gateway — and outbound mail starts preferring IPv6 before anyone published reverse DNS for it.
Confirm the address and its PTR
Take the IPv6 address from the NDR or from your outbound logs and run the Reverse DNS & HELO Auditor. It reports whether a PTR exists, whether it resolves forward to the same address, and whether the HELO name is consistent.
PTR records are published by whoever controls the address block — usually the hosting provider — not in your own DNS zone. Request it there with a hostname under your domain.
- Confirm the exact IPv6 address from the NDR.
- PTR is set by the address-block operator.
- The PTR hostname should resolve forward (AAAA) to the same address.
Two ways to resolve it
Publish a proper PTR and matching AAAA record for the sending address, then retest. Or, if IPv6 sending was unintentional, configure the mail server to prefer IPv4 for outbound delivery until IPv6 identity is in place.
Authenticating the mail with DKIM does not exempt the connection from the PTR requirement; the check happens at the connection stage.
Best diagnostic path
Mail Failure Doctor
Classify the complete rejection and preserve provider-specific diagnostic context.
Open analysis → Live analysisReverse DNS & HELO Auditor
Check reverse identity, forward confirmation and SMTP greeting consistency.
Open analysis → Live analysisEmail Infrastructure Digital Twin
Map the domain’s public mail infrastructure and provider relationships before remediation.
Open analysis →Known limits
- PTR publication depends on the hosting provider’s process and can take time.
- Some providers assign generic PTR names that satisfy the check but signal unconfigured infrastructure.
Common questions
We did not enable IPv6. Why is it used?
Modern systems prefer IPv6 when available. Your server or platform gained an IPv6 route and started using it for outbound SMTP.
Can I set the PTR myself?
Only if you control the address block. Otherwise your provider publishes it on request.
Does IPv4 have the same rule?
Less strictly. IPv4 without PTR is penalized but not refused outright by this code.
Why the exact message matters
The same status family can be triggered by different conditions, and providers frequently add diagnostic text that narrows the issue. Use the complete rejection text rather than treating the numeric code as a complete diagnosis.
Provider reference
For the provider-defined meaning and current requirements, review Microsoft Exchange Online NDR reference.