Rewrite Sender FROM IP..

[tbc]

Issue is iron port intercepts the email then sends to office 365 
Office 365 MARKS all as spam since SPF = BAD fail.. all seem to come from IRON whilst the SPF of domain doesnt have that...

bob.com sends an email to us, goes to IPort.. iport sends to office365 and then to client.. so basically Office365 sees bob.com from IP of Ironport and SCL9 'it

now is there a way FROM THE IRONPORT to replace the FROM in the send from to the IP it was originaly from ? 

else i need to bypass spam filtering on office365 and i need both layers as they complete each other which works but is not the goal here..

[marc.luescherFRE · Accepted solution]

Hi there,
You will need two items first to overcome this:

1. An O365 connector to trust your Ironport IPs as accepted servers
2. An O365 rule to set the SCL to -1 for the same Ironport IPs
What this will do is to tell O365 that it should mainly disable the O365 SPAM control feature for emails received from the Ironports as all the checks are done there.

[marc.luescherFRE]

We have been integrating our network security, Ironport security, O365 and SIEM as a whole. While we have been able to combine some of the features, there are still some areas where O365 can not be changed in behavior.

So far we pilot the use of O365 junk folders and quarantines instead of Ironports features, we mirror our inbound filters to O365 as much as possible so we can also protect in a similar way internal O365 email traffic. (Blocking executables etc.)

All message authentication features and validations are being performed on the Ironports, most phishing controls and header rewrites as well. An example here is that if SPF fails or DKIM fails we drop the message already and will not deliver to O365 or the inseration of a warnign should an email come from an external -untrusted- source.

[tbc]

already doing that, problem is ironport does have leaks, some pass that o365 find... doing this sends them to the client directly.