Error guide / 550 5.7.708 Access denied, traffic not accepted from this IP
550 5.7.708 Access denied, traffic not accepted from this IP
550 5.7.708 is a bounce from Exchange Online, the mail system behind Microsoft 365. The text reads "5.7.708 Access denied, traffic not accepted from this IP", sometimes with "Service unavailable" in front. It appears when mail goes out through Microsoft 365, directly or through an app connected to your account, and Exchange Online refuses to take it from the IP address it came from. The recipient, the content and the address are not the problem here. It is a permanent 550 error, so the sending server does not retry, and the message stays undelivered until the cause is removed.
Check your site
What causes it
Microsoft's documentation ties this code to sending from an IP address with low reputation and says it hits new customers most, such as tenants on a Microsoft 365 trial. In practice it shows up in three situations. A new or trial tenant, before Exchange Online licenses are assigned, whose mail Microsoft does not yet trust. Mail that a third-party tool submits on your behalf: a CRM, a cold email platform, a website contact form or a scanner relaying through your Microsoft 365 account, where Microsoft judges the tool's IP, not yours. And an on-premises server or other relay that routes mail into Exchange Online through a connector from an IP with a poor history, such as a shared hosting IP or one that has sent spam. Microsoft's reputation data is its own and is not published, so a public blacklist check is a strong hint, not the final word.
How to fix it
- Find the IP that Microsoft refused. Open the bounce and its headers: the IP is usually named in the diagnostic text or in the last Received line before Microsoft's servers. If sending from Outlook or Outlook on the web works while the same mailbox fails through an app, it is the app's IP that is being refused.
- Run the check on this page with that IP. It looks the address up in public blacklists such as Spamhaus, SpamCop and Barracuda. A listing means the IP has a spam history that other mail systems see too: stop whatever sent the spam, then request delisting, as described in the guide on removing an IP from a DNSBL, or it will simply be listed again. A clean result does not clear you with Microsoft, whose data is separate, but it rules out the most common reason.
- Check your domain's authentication with the email check on this site. SPF must include every service that sends for you, the third-party tool included, DKIM should be turned on in Microsoft 365 for your domain, and a DMARC record should exist. This does not lift the block by itself, but weak authentication keeps the reputation low on every system your mail reaches.
- If a third-party tool sends through your Microsoft 365 account, ask its support whether it relays from shared IPs and whether it can connect to Microsoft 365 with OAuth or the Graph API instead of relaying over SMTP from its own servers. Bulk and cold outreach is better moved to a service built for it, with its own warmed-up IPs and your domain authenticated there.
- On a new or trial tenant, Microsoft says only an email admin can fix this. The admin opens a support request in the Microsoft 365 admin center and asks for an IP address exception, which applies until Exchange Online licenses are assigned. Include a Message-ID and the full bounce text. Microsoft's wording ties the block to the trial state, so assigning paid Exchange Online licenses to the sending mailboxes is part of the fix.
- For an on-premises server or relay that sends through a connector, make sure it is not an open relay and has not been compromised: a sudden queue of outgoing mail you did not send is the sign. Give its IP a PTR record that resolves back to the same address, and once the source is clean, ask Microsoft support to review the block.