Why are Microsoft email addresses bouncing? How do I fix being flagged as spam? 554 5.7.0

AI responses clearly do not consider all of the specific parameters included on the email.

Just for jollies:

This is one of the private domain bounces...

Generating server: DM6PR19MB3802.namprd19.prod.outlook.com

******@seattle.gov ugw1-etp-mta-inbound-edge-prd10-03.cso.fireeye.com Remote server returned '554 5.7.0 <ugw1-etp-mta-inbound-edge-prd10-03.cso.fireeye.com #5.7.350 smtp;550 5.7.350 Remote server returned message detected as spam -> 550 ETP102 recipient rejected by downstream MTA. Reason: [ 5.4.1 Recipient address rejected: Access denied. For more information see https://aka.ms/EXOSmtpErrors [DS1PEPF00017E07.namprd09.prod.outlook.com 2026-05-13T21:58:44.280Z 08DEADBE7A6B055A] ] - 3z9swlF-20009-10g67CB65021020550A655a7403>'

The 554 5.7.0–style bounces and consistent spam flagging indicate that sending IPs or domains have a poor reputation or are being blocked by Microsoft (and possibly others). Resolution focuses on sender reputation, DNS/authentication, and, if needed, delisting.

Follow these steps:

1. Check the exact bounce/NDR message
   When a message bounces, review the full Non-Delivery Report (NDR). For Microsoft 365/Outlook recipients, NDRs often include text like:

   550 5.7.606-649 Access denied, banned sending IP [x.x.x.x]; To request removal from this list please visit https://sender.office.com/ and follow the directions.

   If the NDR says the IP is blocked or the sender is banned, follow the instructions in the NDR. For Microsoft 365, use the delist portal as documented in “Use the delist portal to remove yourself from the blocked senders list.”
2. Ensure the sending IP is routable and correctly advertised
   Microsoft might not accept email from senders that fail reverse DNS or that advertise themselves as non‑routable IPs (for example, 192.168.x.x, 10.x.x.x, 172.16–31.x.x). Confirm with the internet provider or mail host that:
   • The sending IP has a valid reverse DNS (PTR) record.
   • The server does not identify itself as a private/non‑routable IP when connecting to Microsoft 365.
3. Fix and harden DNS and authentication (SPF, etc.)
   Microsoft’s spam filtering (SmartScreen) and other systems rely heavily on:
   • Sending IP reputation
   • Domain authentication (SPF in particular)
   • List accuracy and complaint rates
   Ensure:
   • SPF is correctly configured for the domain that appears in the From: address and includes all legitimate sending IPs.
   • DNS is correctly set up for the sending domain (A/MX records and reverse DNS).
   • If using new IPs, they are added to SPF so they can inherit some of the domain’s reputation.
4. Reduce complaint rates and “spammy” patterns
   Microsoft notes that one of the main drivers of poor reputation is junk email complaint rate. To improve this:
   • Send only to recipients who have explicitly requested messages.
   • Remove addresses that bounce or never engage.
   • Avoid bulk‑like patterns (frequent messages to many recipients, especially if some mark them as junk).
   • Avoid content that looks like phishing or mass marketing if the intent is personal communication.
5. Check for antivirus or gateway interference
   Some sender‑side antivirus or firewall products can interfere with SMTP and cause deliverability issues. Microsoft specifically calls out settings like “Internet Email Auto Protect” or “Internet Email Protection” on SMTP servers or firewalls. If such settings are enabled on the sending server, disable them and test again.
6. Verify that systems are not compromised or doing “namespace mining”
   Microsoft blocks IPs that perform “namespace mining” (probing addresses without sending real mail). If any sending IP is blocked for this reason:
   • Check that machines or accounts are not compromised and being used to harvest addresses.
   • Ensure any address‑validation process does not use namespace mining techniques.
7. If messages land in Junk instead of bouncing
   When messages are delivered but go to Junk in Microsoft 365:
   • Work with recipients to mark messages as “Not junk” and, where applicable, submit them to Microsoft as false positives using the reporting tools described in “Report messages and files to Microsoft.”
   • Recipients can also add the sender to Safe Senders in Outlook.com or Microsoft 365.
8. If Outlook.com/Hotmail sending is affected (consumer accounts)
   For deliverability problems specifically with Outlook.com/Hotmail consumer services:
   • Review Microsoft’s sender policies and troubleshooting guidance in “Sender Support in Outlook.com.”
   • If email complies with policies and problems persist, use the Outlook.com sender support troubleshooting form (linked in that article) to contact support about deliverability issues to @outlook.com, @hotmail.com, @live.com, or @msn.com addresses.
9. If IP/domain reputation is the core issue
   • Gradually rebuild reputation by sending smaller volumes of legitimate mail, keeping complaint rates low, and maintaining clean lists.
   • Avoid sudden spikes in volume or large recipient lists until reputation improves.

If both Hotmail and Gmail accounts are affected when sending from the same connection, the underlying issue is likely the sending IP or domain reputation rather than the Outlook or Gmail client itself.

References:

• External senders - Troubleshoot email sent to Microsoft 365
• Sender Support in Outlook.com