How JustAnswer Works:
  • Ask an Expert
    Experts are full of valuable knowledge and are ready to help with any question. Credentials confirmed by a Fortune 500 verification firm.
  • Get a Professional Answer
    Via email, text message, or notification as you wait on our site.
    Ask follow up questions if you need to.
  • 100% Satisfaction Guarantee
    Rate the answer you receive.
Ask Michael Hannigan Your Own Question
Michael Hannigan
Michael Hannigan, Email Expert
Category: Email
Satisfied Customers: 11698
Experience:  25+ Years Experience in Field. MCSE, ICCP, Expert in Large Email Platforms
Type Your Email Question Here...
Michael Hannigan is online now
A new question is answered every 9 seconds

Have exchange 2010 running on windows 2012 r2 with Office

Customer Question

have exchange 2010 running on windows 2012 r2 with Office 2016, client is getting "Relaying denied. Proper authentication required" to some customers that were not an issue before we migrated them from exchange 2007 running on windows 2008 with office 2010. have seem blogs that refer to changing security in client; however that option is not in outlook 2016. please advise. mike
Submitted: 1 year ago.
Category: Email
Expert:  Michael Hannigan replied 1 year ago.

Hello. My name is Michael. I will be helping you with your question today.

Customer: replied 1 year ago.
what questions do you have?
Expert:  Michael Hannigan replied 1 year ago.

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...

Customer: replied 1 year ago.
new PDC running Server 2012 and member server running exchange 2010, users are logging into domain and using Office 2016 on desktops. client uses outlook 2016 to send mail. exchange server does not face internet. received mail is POP'ed using a third party app ( one we have used for several years ) and mail is sent from exchange smtp send connector, we replaced 100% of all equipment ( servers & workstations ). we did the previous PDC & exchange server which worked fine. most mail works without any issues; however are getting a bounce back from random email addresses.The following is a copy of the bounced email, ( it does NOT bounce every time ). This is our first install of office 2016 in domain. issues between exc 2010 & outlook 2016 ?? Outlook 2013 works fine at our other exc 2010 installs. Exc 2016 is not an rejected your message to the following e-mail addresses:
Holly Chambers (*****@******.***) (*****@******.***) gave this error:
... Relaying denied. Proper authentication required.
Your message wasn't delivered due to a permission or security issue. It may have been rejected by a moderator, the address may only accept e-mail from certain senders, or another restriction may be preventing delivery.Diagnostic information for administrators:
Generating server: MEMEXC.MEMPORT.LOCAL***@******.*** #550 5.7.1 ... Relaying denied. Proper authentication required. ##
Original message headers:
Received: from MEMEXC.MEMPORT.LOCAL ([::1]) by MEMEXC.MEMPORT.LOCAL ([::1])
with mapi id 14.03.0266.001; Thu, 7 Jan 2016 12:44:24 -0600
From: Gaye Davis
To: "Holly Chambers (*****@******.***)"
Subject: FW: Heineke
Thread-Topic: Heineke
Thread-Index: AdFJe037LY66DJp/Seet2bXDybIQzwAABskA
Date: Thu, 7 Jan 2016 18:44:23 +0000
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/mixed;
MIME-Version: 1.0
Expert:  Michael Hannigan replied 1 year ago.

So you are trying to relay outbound? And the SMTP relay is is that you?

Expert:  Michael Hannigan replied 1 year ago.

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:

  • Enter the SMTP server included in your AuthSMTP confirmation email (typically '')
  • Leave the 'Port' as 587
  • Enter your AuthSMTP username and password
  • Tick 'Secured connection using TLS'
  • Click 'Add Account'

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.

Customer: replied 1 year ago.
We are not relaying through any one. We do not use Google Apps for anything. Our exchange POPs just fine from our ISP. The exchange server sends mail directly to the internet. Not 'facing' internet means that mail coming to server goes to our ISP and not to a public facing IP address. Our server is set 'use domain name system (DNS) MX records to route mail automatically'. Our smtp address space is set to "*" . is not our server NOR our ISP.***@******.***
Expert:  Michael Hannigan replied 1 year ago.

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 domain.

I also see that the server is the server that is denying the relay. This is a google apps domain. Someone is trying to use 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 "". 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 My second guess would have been, the receiver. Based on your last message (I am still guessing), I would say it's probably 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: rejected your message to the following e-mail addresses:
Holly Chambers (*****@******.***) (*****@******.***) 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 to relay via SMTP a message to someone at

That is what the header indicates. Why this person is using as an SMTP relay, I have no idea - I simply don't know enough about your environment.

Customer: replied 1 year ago.
sending domain: memport.local ( see email )
receiving domain ????? this is email, everyone
Gaye Davis: customer of ours that is sending email to one of their customers ( happens to be their CPA firm ) ( see email )
we are IT people, that was my email address, has nothing to do with client or issues
I have no idea who '' is
customer is sending email & it is bouncing ( original description of issue )copied from line above:
"The following is a copy of the bounced email, ( it does NOT bounce every time ). This is our first install of office 2016
in domain. issues between exc 2010 & outlook 2016 ?? Outlook 2013 works fine at our other exc 2010 installs. Exc 2016
is not an option."We have several similar installs in place we administer. This is the only one ( and one we just installed ) that has this combination of software ( win 2012, exc 2010, outlook 2016 ). We have no other installs with outlook 2016.
Expert:  Michael Hannigan replied 1 year ago.

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 '' 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 to send email to some other domain (which I'm guessing is ""). 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, 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 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.

Expert:  Michael Hannigan replied 1 year ago.

Do you have any additional questions?

Customer: replied 1 year ago.
Do I have any additional questions????? Have you yet offered a solution and I missed it ???? You do realize the client settings you offered earlier do NOT apply to Outlook 2016??? I feel certain you do not know a great deal about exchange servers. Do you admin any exchange servers? Google may be your friend, but you may need to look elsewhere. The email client uses [email protected] ( in this case '*****@******.*** ), they send from an exchange server on the domain 'memexc.memport.local' ( memexc is the name of the exchange server ). The mail is going to***@******.***. Some times the email goes through and some times it does not. However, MOST replys bounce as in the e-mail header sent earlier. I'm looking at a SPF file issue with the ISP's DNS information.
Expert:  Michael Hannigan replied 1 year ago.

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 has denied the relay. This can only happen because the exchange server is trying to use 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 using

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 to relay to the 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 instead.

With all that being said, I also did a check of 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, 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.