5.7.708 Access Denied, Traffic Not Accepted From This IP | Fix

You’ll hit this error when an app, CRM, WordPress form, scanner, or server sends email through Microsoft 365 and Exchange Online blocks the handoff. It can feel confusing because you might still be able to send a normal email from Outlook, while automated sends bounce with an NDR that shows 5.7.708.

This guide keeps it practical. You’ll learn what the code points to, how to confirm the real sending path, and which fixes tend to stick. You’ll also get a short checklist to keep mail flowing once you’ve cleared the block.

What 5.7.708 Means And Why It Appears

Exchange Online uses anti-abuse controls to protect recipients. When it sees mail coming from an IP address that’s tied to spam, compromised systems, or noisy bulk sending, it may refuse traffic from that IP. When that happens, the remote server response can include 5.7.708.

This is rarely about your message content alone. It’s mostly about the route your email takes to Microsoft, plus the history Microsoft associates with the sending IP at that moment.

Situations That Commonly Trigger This Code

• New tenant or new sending route — A fresh setup may start on a route that hasn’t built a clean record yet.
• Third-party sending services — Your CRM or plugin may send from shared infrastructure where other users hurt the IP’s reputation.
• Sudden volume spikes — A burst of mail from a “cold” mailbox or domain can look like abuse.
• Account takeover — Leaked credentials can lead to spam bursts, followed by fast blocking.

Why Outlook Can Work While Your App Fails

Outlook and Microsoft’s first-party clients often use a trusted internal route tied to your user sign-in. An app may be sending through SMTP AUTH from a different host, a different cloud region, or a shared relay pool. So the mailbox looks the same, but the sending path is not.

How To Confirm You’re Seeing The Real 5.7.708 Error

Start with the full bounce message. Many blocks use a 5.7.x pattern, and each one points to a different cause. You want the exact line so you don’t waste time on the wrong fix.

Where To Find The Code In The Bounce

• Open the NDR details — Find the “Diagnostic information” or “Remote Server returned” section.
• Copy the full line — Keep the whole string, including any “AS(####)” stamp that appears.
• Save the SMTP transcript — If your tool shows a delivery log, keep it for your notes.

Find The True Sending IP Before You Change Anything

People often delist the wrong IP because they assume the office network is the sender. In many setups, the real sending IP belongs to your CRM vendor or your web host.

1. Check the app’s send method — Note whether it uses SMTP, Microsoft Graph, or a relay/connector.
2. Scan the error line for an IP — If the bounce includes an IP address, treat it as the prime suspect.
3. Compare two paths — Send one message from Outlook, then one from the app. If only the app fails, the route is the issue.

Fix 5.7.708 Access Denied, Traffic Not Accepted From This IP With Cleaner Sending

To get a lasting fix, think like a mail admin. You’re trying to move sending onto a trusted path and show Microsoft that your traffic is legitimate and steady.

Option 1: Use Microsoft Graph When Your Tool Supports It

Microsoft Graph sending is often smoother than basic SMTP because it uses modern auth and Microsoft’s preferred pipeline. It won’t save you from bad list hygiene, but it can remove problems tied to random shared SMTP routes.

• Switch the integration to Graph — Use “Sign in with Microsoft” sending when available.
• Start with low volume — Send a small batch first, then scale up in steps over several days.
• Use a real mailbox — Avoid “no-reply” patterns for workflows that need two-way replies.

Option 2: Stop Using Shared SMTP From A Plugin Or Vendor Pool

If your WordPress mail plugin or CRM sends from shared infrastructure, your mail can be blocked because someone else abused that pool. A dedicated relay or a reputable transactional provider can reduce that shared risk.

• Move to a dedicated relay — Prefer stable infrastructure over shared pools for transactional mail.
• Separate transactional and marketing — Receipts and password resets should not share the same stream as campaigns.
• Authenticate your domain — Set up SPF and DKIM so receivers can validate your domain.

Option 3: Request A Temporary Exception For New Tenants

Microsoft documents that new and trial tenants can run into this block because the sending IP is treated as low reputation. If you need mail flowing quickly and you’re in that early stage, open a ticket in the Microsoft 365 admin center and ask for an exception tied to the 5.7.708 code.

1. Create a ticket in the admin center — Include the full 5.7.708 line from the NDR.
2. Explain how the mail is sent — SMTP AUTH, Graph sendMail, connector, or relay.
3. Share your sending pattern — Rough daily count and whether it’s bursts or evenly spread.

Table Of Common Causes And The Next Fix To Try

Use this as a quick map from symptom to next action. It’s built for real-world setups where multiple tools send mail for the same domain.

What You See	Likely Cause	Next Step
Outlook sends, CRM bounces with 5.7.708	CRM uses a shared or flagged sending IP	Switch to Graph or move to a dedicated relay
SMTP sends bounce after a fresh setup	New route treated as low reputation	Open an admin center ticket and request an exception
Bounces start after odd sign-in alerts	Mailbox credentials abused for spam bursts	Reset credentials, enable MFA, then retest sending
Website forms fail, mail logs show 5.7.708	Host IP or plugin relay is blocked	Use authenticated sending with SPF and DKIM in place

Set Guardrails So The Block Doesn’t Return

Once delivery is restored, lock the basics down. Reputation blocks often come back when the original trigger is still present, just quieter and slower.

Domain Authentication That Helps Delivery

• Publish SPF — Authorize only the services you truly use to send on your domain.
• Enable DKIM — Sign outbound mail so receivers can validate integrity.
• Add DMARC — Set a policy and receive reports that show who is sending as your domain.

Account And App Security Basics

• Enable MFA — Protect mailboxes used by apps and automations.
• Rotate app secrets — If you use app registrations, keep secrets short-lived and stored safely.
• Review sign-in logs — Watch for unfamiliar locations and repeated failures.

Sending Habits That Build A Clean Track Record

Even if you only send invoices or notifications, your mail still forms a pattern. A steady pattern helps. Bursty sending hurts, even when mail is legitimate.

• Warm up gradually — Increase sending in steps and watch bounce rates.
• Clean dead addresses — Remove hard-bounce recipients so you don’t rack up failures.
• Keep subjects plain — Avoid gimmicky wording that triggers filters.

When To Escalate And What To Include In Your Admin Center Ticket

Some blocks won’t clear until Microsoft changes something on their side. That’s common when the sending route is tied to tenant status, trial behavior, or a policy decision. If you can reproduce the 5.7.708 bounce and you’ve confirmed the sending path, escalation saves time.

Details That Help A Ticket Move Faster

• Paste the exact 5.7.708 line — Include the full phrase and any “AS(####)” tag.
• Provide timestamps — Give a time window in UTC and your local time.
• Name the sending method — SMTP AUTH, Graph sendMail, connector, or relay.
• Share rough volume — Daily count and whether sending is bursty or steady.
• Describe the mail type — Transactional notices, invoices, password resets, or one-to-one mail.

If a third-party tool is involved, open a ticket with the vendor too and ask direct questions. Which IPs do they send from. Do they offer Graph sending. Can they move you off shared pools. If you control the sending route, a dedicated path often ends repeat blocks.

After each change, run a fresh test and write down the result. A simple “change + outcome” log keeps later troubleshooting quick when more than one system sends mail for the same domain.

5.7.708 access denied, traffic not accepted from this ip can feel like a wall, but it’s often a signal to clean up the sending route. Once mail runs through a trusted method and your domain is authenticated, delivery gets steady.

5.7.708 access denied, traffic not accepted from this ip also becomes far less common when sign-ins are locked down and sending ramps up gradually instead of spiking.

5.7.708 Access Denied, Traffic Not Accepted From This IP With Quick Self-Checks

Before you swap providers or rebuild integrations, run these checks. They catch the simple issues that can stack up into reputation trouble.

1. Confirm mailbox licensing — Make sure the sending mailbox has the right Exchange Online license for the method you use.
2. Verify SMTP auth settings — If you rely on SMTP AUTH, confirm it’s enabled for the mailbox and allowed by policy.
3. Review outbound volume — Look for bursts tied to a workflow, a plugin change, or suspicious sign-ins.
4. Test from a second route — If one network fails and another works, your outbound IP may be part of the problem.
5. Recheck SPF and DKIM — If either is missing or wrong, fix it before you ramp sending again.

This error is designed to stop risky traffic fast. Treat it as a signal to tighten routing, authenticate your domain, and keep sending steady. When you do that, the same mailbox usually sends without drama.