OK. Yes... I do... I designed one of the worlds larges email distribution centers. There is nowhere above that I suggested anything related to Outlook 2016 settings or any other Outlook settings. I believe it is you that is misunderstanding.
If you want the answer, I advise you to stop with the petty insults. Have I disrespected you in any way? If so, please let me know, because I would never do it intentionally. I've been doing this for over 25 years. If I'm wasting my time, I'll opt out for you. If you look above, you will see that I've spent a great deal of my time trying to explain things in detail. The information I'm giving you here is accurate based on an intimate understanding of Exchange, and email systems in general. I've configured and administered Echange server environments number in the thousands of servers, and hundreds of thousands of users. Yes, I do know Exchange servers.
they send from an exchange server on the domain 'memexc.memport.local'
I'm aware of that, but memport.local is obviously NOT the sending domain on the internet. It is the Active Directory domain. Until your latest reply, I had no idea what that sending domain was. Therefore, I have not had a way to check any DNS/SPF records. That was my point.
memexc is the name of the exchange server
I am aware of this.
Please tell me how I would have known this before this point. It is nowhere in the header - only the local user name is ***** ***** is the information I have been trying to get you to tell me. And no - the email client doesn't use the on an exchange server. It is a property of the user, but the client is interacting with the server using Active Directory, not SMTP. If they are set up to connect through SMTP to the local Exchange Server, that's a huge problem. It's the wrong way to configure them. If you are absolutely certain they they are setup this way, then that is your problem. When an exchange user sends email externally, they aren't sending it from their client. They are updating the Exchange Message stores and the Exchange server sends it out through the SMTP connector. There is NO interaction between the client and the internet in this case.
According to the header, the Exchange Server is telling you that the server www29.safire.com has denied the relay. This can only happen because the exchange server is trying to use www29.safire.com to relay an outbound SMTP message. In this case now I know that the message relates to the sender (you) trying to relay to a user at CannonCPA.com using www29.safire.com.
Regardless of how strange that sounds to you based on what you know of the configuration involved - that is the fact of what is happening.
I am not making any of that up - I'm not assuming any of that. I am only telling you what the headers are telling us. It is absolutely certain based on this header that the reason THIS message did not get out is that the sender (you) are trying to use the server www29.safire.com to relay to the CannonCPA.com domain. I have no way of knowing WHY it is doing that, but I can tell you for certain that it IS doing that.
In order to be sending to and receiving from internet email addresses, some server in the process must have an external facing interface.
The sometimes/sometimes not indicates that there is a difference we are not recognizing. Something like this rarely happens intermittently without a specific cause.
Now that I know what the public domain is, I can tell you that it does not have SPF/DKIM/DMARC records. So that is something that you may want to address. However, it is NOT causing the bounce that you have shared with me. I promise you - what you have shown me is an entirely different thing. The problem is somewhere in the outbound email leaving the exchange server and being relayed to the final recipient. As I said before, SOMETHING is trying to use that google server to relay email.
How this CAN happen with Exchange server is if the front-end transport is not looking up the MX records correctly for the receiving domain. For example, in this case, the Exchange server should be contacting CannonCPA, but it is sending through safire.com instead.
With all that being said, I also did a check of CannonCPA.com and they DO have some glaring problems with their SMTP setup. Their server fails an open relay test, their DNS allows open zone transfers, and they have duplicate conflicting records. So if this problem has only been observed with email to CannonCPA.com, it's their fault, not yours. I would strongly suggest trying to find a bounce with a different recipient so we can check that one as well and make sure this is not an isolated problem.