We use SMTP2GO to relay scan-to-email messages from employees' home copiers into our Microsoft 365 tenant. The service has worked reliably for more than a year, but since Monday, messages have been stuck in SMTP2GO as "processed" for over 12 hours. I have already allowlisted their IP addresses, and SMTP2GO rotated our sending IP, which helped for one scan but did not resolve the issue. Their logs show that the messages were accepted, but they still have not arrived in Microsoft 365. Other inbound mail is arriving normally, and there have been no configuration changes on our side. This began around the time of the recent Microsoft 365 outages. A support ticket is open, but are there any other troubleshooting steps I should try?
3 Answers
First, test delivery to an external address outside Microsoft 365 if you can. That will help determine whether the delay is occurring within SMTP2GO or specifically between SMTP2GO and your tenant. Since normal inbound mail is working, an Exchange Online service issue or filtering problem seems more likely than a general SMTP2GO outage.
We use SMTP2GO with Microsoft 365 and have not seen delays, including deliveries to other tenants. That makes it worth checking whether all of the provider’s current IP ranges were added after the rotation, rather than assuming the old allowlist is still sufficient. Also compare the timestamps in the SMTP2GO logs with Microsoft 365 message trace results to see whether Microsoft ever accepted the messages.
The SMTP2GO logs only show the messages as processed, and Microsoft 365 does not show them arriving. I’ll verify the full current range list and check message trace as well.
Double-check that every SMTP2GO sending range is present in the Microsoft 365 Connection Filter Policy and that the recommended safe-list option is enabled. The path is Defender portal > Email & collaboration > Policies & rules > Threat policies > Anti-spam > Connection filter policy. The portal only accepts one range at a time; pasting the entire list may appear to save but leave the addresses out. Adding the ranges with PowerShell is usually quicker and more reliable. In similar cases, delivery began working immediately after the complete list was added correctly.
I have not tried an external recipient yet. The scanners are at users’ homes, so testing them remotely is difficult, but I’ll use that to narrow down where the delay is happening.