5.7.708 means Microsoft refused traffic from the sending IP address. The reason is reputation: the address is new with no history, has recently sent traffic Microsoft associates with abuse, or belongs to a range with a poor record. The fix is on the infrastructure, not in DNS.
Most common causes
- The sending IP has low reputation
- The IP is new and has little positive history
- The outbound path changed to an unexpected IP
- The sending infrastructure is associated with abusive traffic
What to verify next
- Confirm the actual outbound IP in message and SMTP evidence
- Verify PTR, authentication and sender identity consistency
- Review whether the IP recently changed or was newly introduced
- Follow Microsoft’s remediation path when infrastructure is otherwise legitimate
Identify the actual sending address
The IP named in the rejection is the one that connected to Microsoft. It may not be the address you expect: a change of outbound gateway, a new node in a sending pool, or a platform that rotated infrastructure all change the connecting address without changing anything visible in your configuration.
Confirm it from SMTP logs or from a delivered header’s Received chain. The Reverse DNS & HELO Auditor shows whether that address has forward-confirmed reverse DNS and a sensible HELO identity, both of which Microsoft weighs.
Why an address is not accepted
New addresses have no reputation and are throttled or refused until history accumulates. Addresses that recently sent a burst, hit spam traps or generated complaints are refused for longer. Shared or hosting ranges inherit the behaviour of their neighbours.
Missing PTR, a HELO that does not resolve, or an address on a public blocklist each make the refusal more likely and are cheap to fix.
- New IPs need gradual warm-up.
- PTR, HELO and blocklist status all affect acceptance.
- Shared ranges carry shared reputation.
Remediation path
Verify PTR and HELO, check public blocklists, and review recent sending from the address for anything abusive. Then use Microsoft’s sender support process for Outlook.com and the delist portal if the address is blocked outright. If the infrastructure is otherwise legitimate, warm the address up with gradually increasing volume to engaged recipients.
If the address belongs to a sending platform, the platform is the party that has to act; report the rejection to them with the full NDR.
Best diagnostic path
Mail Failure Doctor
Classify the complete rejection and preserve provider-specific diagnostic context.
Open analysis → Live analysisEmail Infrastructure Digital Twin
Map the domain’s public mail infrastructure and provider relationships before remediation.
Open analysis →Known limits
- Microsoft’s reputation model is not public; the rejection confirms the outcome, not the exact scoring.
- Delisting restores acceptance but not reputation; volume should ramp gradually afterwards.
Common questions
We changed nothing. Why did this start?
The connecting IP probably changed — a gateway, a pool node, or a platform rotation. Confirm the address from the NDR and logs.
Is 5.7.708 permanent?
No. It reflects current reputation. Fix the causes, request delisting if applicable, and ramp volume.
Does SPF help here?
Not directly. This is IP-layer reputation. Authentication remains necessary but does not override a refused address.
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.