Hello. My name is Michael. I will be helping you with your question today.
There are a number of things that can cause this - you should see more information to the message, like 560 5.7.1. That will have the specific information about why relaying was denied.
Doubtful that it has anything to do with the client directly. The error message comes from an SMTP connection trying to use the SMTP server (connector in exchange) to relay to either your internal domain, or somewhere else. All these pieces are needed to know where the error is coming from.
Are these people in your domain? Are they using Outlook with an Exchange account on the server, or are they using Outlook to connect to an SMTP account on the server, or are they not in your domain at all ?(for example, sending a message to someone in your company).
You are correct that this is generally the result of requiring users to be logged into your domain to send mail. This would imply that these are domain users - so most importantly is what type of emails (from and to) is presenting this problem... would it be if I sent your company an email from gmail? If I send a message out from your company to a gmail account, etc...
So you are trying to relay outbound? And the SMTP relay is safire.com... is that you?
I did some poking around. It looks like you are trying to relay outbound mail through Google Apps.... which is OK and solves the problem of your exchange server not having a public facing internet interface, but it is a little complicated to set up properly because it uses AuthSMTP. The settings required in the client are as follows:
But there is also setup on the google apps side for authenticating users to relay SMTP. You can see the details of that here:
As I said, it's not simple.
OK. In all of this, what you are not telling me, but what I need to know is:
1. The sending domain
2. The receiving domain
3. Which domain is yours.
I see the local domain. I see the CannonCPA.com domain.
I also see that the server www29.safire.com is the server that is denying the relay. This is a google apps domain. Someone is trying to use www29.safire.com as an SMTP relay. That is what is producing the error. You have to remember - I have no idea who you are or what your domain is until you have told me. I don't know whether you are the sender or the receiver until you have told me. I don't have access to your personal information, but I now see that your email domain is "mctcomputer.net". The only information I have about your environment is what has been stated in our discussion so far. Please review that and make sure I have all the information you think I have. I don't need personal information - in fact, for privacy, we remove personal information. So please just use domain names.... header details are fine - nothing we can do about that. For example, if you look through our conversation, you'll notice that the header says that the sender is a person named "Gaye Davis". You will also notice that there is no way for me to determine, based on the information prior to the header, what the email domain of this individual is, nor whether it is even yours (whatever that might be). Do you see what I am saying? I don't know who these people are - I don't know who you are - I don't know what your domain is - initially, I would have assumed that it was safire.com. My second guess would have been CannonCPA.com, the receiver. Based on your last message (I am still guessing), I would say it's probably mctcomputer.net. BUT, you could be a consultant, and it might be yet a different domain that hasn't been mentioned yet.
This part of the header:
www29.safire.com rejected your message to the following e-mail addresses:Holly Chambers (*****@******.***) (*****@******.***)www29.safire.com gave this error:... Relaying denied. Proper authentication required.
Indicates that someone (someone named Gaye Davis - I don't know where they are - I'm assuming in your email domain) is trying to use ww29.safire.com to relay via SMTP a message to someone at CannonCPS.com.
That is what the header indicates. Why this person is using ww29.safire.com as an SMTP relay, I have no idea - I simply don't know enough about your environment.
Sending domain cannot be .local. This would be the active directory domain. For these users to exchange internet email, they must have SMTP addresses within exchange.
It would have to be a public domain.
What is the public domain of Gaye Davis?
I think the reason we are on different pages is that you are assuming the problem is with the install, and it probably is not.
I already know everything you have already stated in the question. There is no need to re-state that. You can assume that if I am asking for information, it is something that you haven't already given me. I need to know the following, which you still aren't telling me:
Senders EMAIL domain
Recipient's EMAIL domain
have no idea who 'ww29.safire.com' is
You need to find out, because this is where the error is coming from. As I explained, email can bounce for countless reasons. In this case it is because whatever user is connecting to ww29.safire.com to send email to some other domain (which I'm guessing is "CannonCPA.com"). ww29.safire.com is refusing to relay the SMTP email.
Based on what you have given me so far, you have a customer who uses a gmail custom domain for their email. Like it or not, someone is relaying, or trying to relay SMTP through the server ww29.safire.com, which DNS tells us is handled by google's email servers. If that is not by design, then it is a simple fix to correct their settings and change it to match their public email domain (which I still do not know).
If it doesn't bounce all the time, then there has to be something in common with those that do. That has to be figured out. Is it to certain domains? Is it from certain users? It definitely won't be random or without reason - email doesn't work like that. There has to be a common denominator. From the sum total of information here, the common denominator so far is that safire.com server. We need to find out why that is in the loop and you will have your answer.
And you might be tempted to respond back to tell me that it isn't in the loop. But I can tell you for certain that it is if the header you sent to me is genuine.
Do you have any additional questions?
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.