Exchange Online 550 5.7.708 Access Denied: Fixing Blocked Mail Flow

#Context: what a 5.7.708 rejection tells you

A 550 5.7.708 response, reported with wording along the lines of service unavailable, access denied, traffic not accepted from this IP range, is a permanent-class SMTP rejection issued at the Exchange OnlineThe KBY LexiconExchange OnlineExchange Online is Microsoft's cloud-hosted email, calendar and contacts service, delivered through Microsoft 365 as hosted mailbox infrastructure. Read Full Context edge. The important reading is that the decision concerns the connecting IP address, not the mailbox, the message content or the recipient. Nothing about the message was evaluated in the way a content filter would evaluate it; the connection or session was refused because of where it came from.

That framing shapes the whole investigation. Operators often start by inspecting the message, the sender address or recipient policies, and lose hours there. The more productive questions are which IP address Microsoft’s service actually saw, whether that address is one you intended to send from, and whether anything about its recent behaviour could have caused the service to stop accepting traffic from it.

Two directions of flow produce this error in practice. In the first, an external or on-premises system sends to Exchange Online and receives the rejection in its own queue or bounce message. In the second, Exchange Online is the sender and a remote system rejects it; those cases are different and use a different diagnostic path. This article covers the first: your sending infrastructure, relay or partner connects to Microsoft 365The KBY LexiconMicrosoft 365Microsoft 365 defined at plain and technical depth, with architecture, operational relevance, an example and a common misunderstanding for practitioners. Read Full Context and is refused. Confirm the exact enhanced status text in the non-delivery report or SMTP transcript, because similar 5.7.x codes have different meanings and different owners.

Scope and assumptions: the guidance assumes a Microsoft 365 tenant with Exchange Online, administrative access to the Exchange admin centre and to the sending system’s logs, and a non-production way to test a send. Microsoft’s published documentation is the authority for the precise definition of the code, current thresholds and any delisting process, and those details change. Confirm them in the Microsoft 365 documentation at learn.microsoft.com/en-us/microsoft-365/ before acting. Facts below are labelled as documented behaviour, observation or recommendation where the difference matters.

#Architecture: where the decision is made

Inbound mail to Exchange Online arrives at the service edge, where connection-level checks occur before a message is accepted into the transport pipeline. Those checks consider the connecting IP, and accepted mail then proceeds to authentication, filtering and routing. A 5.7.708 rejection is consistent with a failure at the connection stage, which is why neither mailbox rules nor transport rules can influence it.

Four elements are relevant to a mail path you operate:

• The sending system: an on-premises mail server, a third-party relay, a line-of-business application or a bulk-mail provider.
• The egress path: NAT gateways, proxies or shared outbound addresses that determine the source IP the service observes. This is frequently different from the address the application believes it uses.
• The Exchange Online connector configuration: inbound connectors that identify partner or on-premises sources by certificate or IP, and the mail flow rules attached to them.
• The service’s view of the source IP: its reputation and any block applied to it or to its wider range.

The error text refers to an IP range, which is an inference worth testing rather than assuming: it suggests that the problem may not be confined to a single address, and that neighbouring addresses in the same allocation, such as a shared hosting or cloud provider block, may be affected. Whether a block is on your own address or on a shared range changes who can resolve it. If the range belongs to a cloud or hosting provider, you may need that provider rather than your own team to make changes.

#Implementation: a bounded diagnostic sequence

Work through the steps in order, recording evidence at each one. All of them are read-only or reversible, and none require changes to production routing until the cause is known.

#

Step 1: capture the rejection precisely

Collect the full SMTP response from the sending system’s logs or from the bounce message, including the timestamp with time zone, the full enhanced status code and the text, and any diagnostic headers. Note the recipient domain, which should be your Exchange Online tenant domain, and the sending host name. Without a timestamp and the observed source IP, a support case cannot be actioned efficiently.

#

Step 2: establish the real source IP

Identify the public IP address that reaches Microsoft, not the internal address. Check the egress device’s logs or translation table. In environments with several NAT addresses or failover paths, record every candidate address, because the rejected one may only be used on a secondary path or by one application. A common observation in shared-egress estates is that one compromised or noisy workload damages the reputation of the address that every other workload also uses.

#

Step 3: check the address against public reputation sources

Query reputable public blocklist and reputation lookup services for the source IP and its surrounding range, and check the reverse DNS record. These are secondary sources and cannot state why Microsoft refused a connection, but a listing or a missing reverse DNS record is a useful signal of a sender-side hygiene problem. Treat results as supporting evidence only, and do not conclude that a clean result means Microsoft has no block.

#

Step 4: review sender-side behaviour

Examine outbound volume and error rates from that address over the days before the first rejection. Look for compromised accounts or hosts, open relay behaviour, bursts of mail to invalid recipients, and applications retrying aggressively after temporary errors. Behavioural abuse is a plausible cause of reputation damage; the evidence supplied for this article does not document the precise criteria Microsoft applies, so confirm the current criteria in Microsoft’s documentation.

#

Step 5: review connector configuration

In the Exchange admin centre, inspect inbound connectors for the on-premises or partner source. Confirm which identification method is configured, certificate subject or sender IP addresses, and that the IPs listed match the real egress addresses found in step 2. A stale list after an egress change is a common source of failed or misclassified mail, although a connector mismatch typically presents differently from an IP-range block. Treat connector review as a way to eliminate a self-inflicted configuration cause and to document your intended topology for Microsoft support, not as the presumed fix.

#

Step 6: choose the remediation path

If the address is yours and shows sender-side abuse, fix that first: contain the compromised host or account, close any open relay, and then request review through the process Microsoft documents. If the address belongs to a shared provider range, involve the provider. If everything on your side is clean, open a Microsoft support case with the evidence set from steps 1 to 5. Interim mitigation can be routing through an alternative sending path with a different, properly configured IP, but only when that path is authorised, authenticated and meets your security policy. Do not route around a block through an unreviewed relay.

#Validation: how you know it worked

Define success before you change anything. Observable success is a controlled test message from the formerly rejected source IP being accepted by Exchange Online, appearing in the recipient mailbox, and the sending system’s logs showing a 250-class response rather than 550 5.7.708. Run the test from the exact egress path, not from a laptop or a different server, because a test from a different IP proves nothing about the blocked one.

Then confirm sustained recovery rather than a single success: queued mail drains, no new 5.7.708 entries appear across at least a full business cycle of normal volume, and message trace in Exchange Online shows expected inbound delivery for the affected sender. Record the timestamp of recovery so that support can correlate it with their action. Validate on a small, low-risk volume first, and only restore full volume once those tests are clean.

#Failure modes

• Wrong IP investigated. The team checks reputation on an internal or former address. Response: re-derive the egress IP from NAT logs and re-test.
• Shared range block. Your address is clean but the range is not. Response: escalate to the hosting provider and Microsoft with the range evidence.
• Underlying abuse not fixed. A delisting request succeeds, then the block returns because the compromised host is still sending. Response: contain and verify before requesting review.
• Misattributed error. The code is actually a different 5.7.x condition, such as an authentication or policy rejection. Response: re-read the exact enhanced status code and use the matching documentation.
• Retry storm. The sender retries rapidly after rejection, worsening its own behaviour profile. Response: back off the queue with a bounded retry schedule.
• Unsafe workaround. Mail is rerouted through an unauthenticated relay to meet a deadline. Response: refuse it, and escalate the business impact to the approving owner instead.

#Security

A block on a sending IP is sometimes the first visible sign of compromise, so treat it as a security signal as well as a deliverability fault. Apply least privilege during the investigation: read-only roles are sufficient for message trace and connector review, and connector edits should be performed by a named administrator under change control. Do not loosen connector restrictions, such as accepting mail from broad IP ranges, to make an error disappear, because that widens the attack surface and can allow spoofed mail to bypass intended checks. Keep SPF, DKIM and DMARC records accurate for every legitimate sending source, and keep credentials and private tenant data out of tickets and out of the evidence you send to third parties. Residual risk remains after remediation: reputation can be damaged again by the same cause, and a block you did not originate may recur if you share infrastructure. The privilege boundaries are consistent with the approach in the tiered admin model for limiting lateral movement, and bounded change habits are discussed in bounded Enterprise IT Management operations in Microsoft 365.

#Recovery and Readiness for 5.7.708 Blocks

Recovery should be reversible at every step. The diagnostic work above changes nothing. If you adopt an alternative sending path, document the previous routing first, keep the old path available but disabled, and be ready to revert if mail fails authentication or loops. If you edit a connector, export or screenshot the existing settings before editing so you can restore them exactly. Stop and escalate to a human owner if test mail fails on the new path, if you cannot identify the source IP with confidence, or if any step requires weakening a security control.

Operational readiness reduces the next incident’s cost. Alert on spikes in outbound volume and rejection rates from each egress IP, keep an inventory of every system that sends mail to Exchange Online with its public address, and review that inventory whenever network egress changes. Retain SMTP logs long enough to reconstruct events. Evidence of these controls also supports audit work, as described in continuous control monitoring for SOC 2 audits. Operational excellence guidance from Microsoft Learn emphasises observability, automation, safe deployment and operational readiness, and each applies directly here.

The next safe decision depends on what the evidence shows. If the source IP is yours and a sender-side cause is found, contain it, validate with a low-volume test and request review. If the range is shared or the cause is unclear, open a Microsoft support case with the timestamp, source IP, full SMTP response and your connector configuration, and confirm current criteria and processes in the Microsoft 365 documentation.