A while back in 2013 (Cumulative Update 2) there was a change which causes a header called X-Frame-Options to be inserted into rendered OWA pages. This header tells browsers to not render content in an iFrame. This is a security feature which is meant to help prevent click-jacking.
There is a WebPartsFrameOptionsType setting on VDIR/MailboxPolicy, which controls the value of the response’s X-Frame-Options header. With the default SAMEORIGIN, browser doesn’t display the content of IFRAME if hosting page has different than IFRAME page origin.
Setting WebPartFramesOptions to None disables sending the header (and disabling click-jacking protection). Note, that the value should be set depending on from where effective user settings are taken – via plan/policy or virtual directory:
Set-owavirtualdirectory –WebPartsFrameOptionsType None
Set-OwaMailboxPolicy -identity OwaMailboxPolicy-Default -WebPartsFrameOptionsType None
Note that in the example line above that OwaMailboxPolicy-Default is the default policy. You can get a list of policies using this command:
get-OwaMailboxPolicy | fl *identity
The App pool needs to be reset or after 3 hours max (for VDIR cache) the value should be refreshed. Note that you may need to set other headers as described in the articles below if the page hosting your portal is not on the Exchange server.
Please note that OWA web parts from a shared Exchange Online server cannot be used in an IFRAME because all the needed settings to override click-jacking cannot be set. One of the needed settings would cover all users on the server and it would affect more than one company. If you want ant to use OA Web Parts in an IFRAME then you need to use a dedicated Exchange Online server or an on premise server.
Here are some related articles:
Mitigating framesniffing with the X-Frame-Options header
Combating ClickJacking With X-Frame-Options
OWA Web Part in an iFrame sample
IFraming SharePoint-hosted pages in apps