1

I have a user with an old email address in an ISP provided domain. This mailbox has been set to forward all email to their new email address in Microsoft 365. For a long time this worked without issue. Now the email is being blocked. If I send a message to user@ispdomain.com it is forwarding to user@companydomain.com but not hitting the mailbox. I can see in the message trace that it is being forwarded but M365 is dropping it. The results of the message trace are:

Reason: [{LED=550 4.3.2 QUEUE.TransportAgent; message deleted by transport agent: [Name=DC Post Content Filter Agent][AGT=PC2][MxId=11BB855DFD91CFA5]};{MSG=};{FQDN=};{IP=};{LRT=}]

Spam confidence level: 9

I have checked the transport rules to see if there is something that would block it an there is nothing there. Whitelisting likely won’t work as it appears to be coming from me, not the ISP domain. Even whitelisting the IP address is concerning as it is showing part of a /16 subnet owned by Oracle so the probability of the IP address changing is high and I don’t want to whitelist an entire /16 for a public cloud.

Is there anything I can do to allow this mail through without creating some unintended vulnerabilities?

4 Spice ups
2

On your transport rule, disable checking for spam - the message is being dropped as SCL 9 (spam confidence level).

Set SCL to -1 or no in your transport rule.

2 Spice ups
3

this says that MS 365 is 100% certain the email is spam. So its doing whatever you have setup in your spam filtering (Drop, Delete, Quarantine) and not delivering it to the user.

what do you mean by this? If the ISP is doing a true forward the email will appear to come from whomever the original sender is, not the ISP.

So if you sent an email from a@abc.com to x@isp.com and it forwards from x@isp.com to b@abc.com it may show as coming from a@abc.com, but the IP Trail in the headers would still show the forward. this could be why Exchange is marking it SCL:9

It may be time to simply drop this old x@isp.com address, if for some reason you have to keep it you may need a transport rule on outbound mail to redirect it internal rather than bouncing it through the old ISP account

Try sending from an external mail address for your testing like a regular gmail to x@isp.com and see what happens.

3 Spice ups
4

The forwarding email usually drops because the forwarding email server isn’t authorized by SPF to send email for the original domain and no DKIM signature especially if DMARC policy is set to drop for the original domain.

2 Spice ups
5

Thanks for the advice. I used this approach and adjusted some spam settings to confirm the cause of the drop. I have created a transport rule to mark messages from that IP with a SCL of -1 to bypass the filter. User has been advised to actively get contacts to start using new email address so that we can drop it in the near future.

3 Spice ups