Decoding M365's '550 5.7.708' NDR: A Tenant-Level Outbound Block Explained

It’s 9 AM. The CFO’s executive assistant is on the phone, and they sound frantic. The final term sheet for a merger, due an hour ago, is bouncing. Every attempt to send it to the acquiring firm’s legal counsel returns a Non-Delivery Report (NDR). Your ticket queue starts to light up with the same complaint from sales, marketing, and HR. Outbound email is failing, but only to some recipients.

You scan the NDR and see the line that will ruin your morning: `550 5.7.708 Access denied, traffic not accepted from this IP`. Your first instinct might be to check if one of Microsoft's outbound IPs has landed on a public Real-time Blackhole List (RBL). That's a logical first step, but with this specific error, it's almost always a red herring.

This isn't a simple IP block. This is Exchange Online Protection (EOP) putting your *entire tenant* in the penalty box. Microsoft has detected a high volume of spam originating from your tenant and has shunted all your outbound mail flow to a high-risk delivery pool. IPs in this pool are throttled and have such a poor reputation that most receiving mail servers will reject their connections outright. You're not just blocked; you're designated untrustworthy.

Is It Microsoft's Problem or a Public Blacklist?

Before you can fix the problem, you have to correctly diagnose it. The `708` error code is your biggest clue. It specifically relates to Microsoft's internal reputation systems. A general RBL listing on a platform like Spamhaus or Barracuda would typically result in a different, more generic `550` error code from the *recipient's* mail server, not from Microsoft's own infrastructure.

Verifying the Outbound IP

First, you need to identify the IP address mentioned in the NDR. Grab the full, original NDR message and open the attached headers. Find the IP referenced in the diagnostic information. It will look something like this:

Remote Server returned '550 5.7.708 Access denied, traffic not accepted from this IP [x.x.x.x]. For more information please go to http://go.microsoft.com/fwlink/?LinkId=526653' — NDR Diagnostic Information

Once you have that IP address, run it through a public RBL checker like MXToolbox or the Spamhaus Project's checker. In over 90% of `708` cases, you will find the IP is clean. This is the confirmation you need. The problem isn't a public listing that anyone can see; it's a private, internal classification made by Microsoft about your tenant's behavior. Stop wasting time trying to delist from public RBLs and focus your attention inward.

Requesting Removal from Microsoft's High-Risk Pool

Microsoft provides a self-service portal for exactly this situation. Navigate to `https://sender.office.com/`. This is the Office 365 Anti-Spam IP Delist Portal. It's important to understand what this tool does and does not do. It does not instantly fix your problem. It submits a request to the EOP team to re-evaluate the traffic from the IP and, by extension, your tenant.

You will need the blocked outbound IP address from the NDR and an email address that can receive the verification code. The portal will send a link to this address, which you must click to confirm your request.

Do not submit this request until you have conducted a thorough investigation and have contained the source of the spam. If you request delisting while your tenant is still actively spewing malicious mail, your request will be denied, and future requests may face more scrutiny. The portal is an appeal for parole, not a get-out-of-jail-free card. You must prove you've done the work.

The Forensic Hunt: Compromised Accounts vs. Rogue Connectors

The block is a symptom. The disease is a compromised resource inside your tenant. Your primary job now is to find it. The source is almost always one of two things: a user account with stolen credentials or a misconfigured/compromised Exchange Online connector.

Hunting a Compromised Mailbox

A compromised user account is the most common culprit. A threat actor uses password spray or phishing to gain access, then uses the mailbox to send thousands of spam or phishing emails. Your first stop should be the Exchange admin center (EAC) and the Message Trace tool. Run a trace for all outbound mail over the last 24-48 hours. You're not looking for a needle in a haystack; you're looking for a haystack of needles.

Sort the results by sender. Is there one account with thousands of sent items, far exceeding their normal baseline? Look at the subject lines. Are they generic lures like 'Invoice Due' or 'Action Required'? Examine the recipients. Are they a random assortment of addresses from different domains? This is your patient zero. Once identified, immediately reset the user's password, revoke all their sign-in sessions via the Azure AD portal, and check for any inbox rules or forwarding rules the attacker may have created to maintain persistence.

Investigating a Malicious Connector

If your message trace doesn't reveal a single compromised user, the next suspect is an outbound connector. These are often used to allow on-premises applications, multifunction printers, or legacy systems to relay mail through Exchange Online. If a connector is configured to accept mail from any IP address on your internal network (a common but dangerous practice), a compromised web server or workstation can become an internal spam bot.

In the EAC, navigate to Mail flow > Connectors and review your outbound connectors. Check their configuration. Are they properly scoped to specific IP addresses or certificate names? If not, that's a huge red flag. You can use an extended message trace (or PowerShell with `Get-MessageTrace`) to filter for messages sent using a specific connector (`-ConnectorId`). This will help you determine if one of your connectors is the firehose. Lock down the connector to only allow relay from the specific, known IPs of the devices that need it. This is non-negotiable.

Preventative Controls: Hardening Your Outbound Policies

Getting delisted is only half the battle. Preventing a recurrence is how you win the war. The default Exchange Online Protection settings are designed for broad compatibility, not for high security. You need to tune them.

Start with your outbound spam policy, found in the Microsoft 365 Defender portal under Policies & rules > Threat policies. The default policy is often too permissive. Create a new, more restrictive policy with a higher priority. Lower the external recipient limit per hour and per day from the defaults. While 10,000 recipients a day might be fine for some tenants, it's a massive window for an attacker to exploit. A value between 200 and 500 is a much safer starting point for a typical user. You can always create a separate, more permissive policy for specific groups like marketing if they have a legitimate business need.

Next, configure the automatic forwarding rules. By default, users can auto-forward mail to any external domain. This is a classic tactic for data exfiltration. Change this setting to 'Off' or 'On - Only to allowed domains' to severely limit an attacker's ability to siphon data.

Finally, set up your early warning system. In the same threat policies section, you'll find alert policies. Ensure that alerts like 'A user has been blocked from sending email' and 'Suspicious email sending patterns detected' are enabled and configured to notify your security team immediately. This shifts your posture from reactive—waiting for user complaints and NDRs—to proactive. You'll know about a potential compromise minutes after EOP detects it, not hours later when the damage is done.

The takeaway

The `550 5.7.708` error is more than a technical problem; it's a vote of no confidence from Microsoft about your tenant's security hygiene. It's a signal that your outbound traffic poses a risk to the entire M365 ecosystem. Following the delisting process is the immediate fix, but it's a temporary reprieve.

The real solution is a forensic deep dive to find the root cause and a systematic hardening of your outbound mail policies. This isn't just about getting the mail flowing again. It's about rebuilding trust with Microsoft's platform and ensuring you're not the source of the next major spam campaign. Tools that correlate sign-in logs, email headers, and user activity, such as MailSleuth.AI, can significantly reduce the time it takes to connect the dots during these high-pressure investigations.