email failing to reach us from ONE sender.
we have a single exchange mail server which for the most part is working OK. However, we have one client who is trying to email us, and receiving bouncebacks that the account does not exist.
we have an mx record pointing to our mail server as follows :-
mail.domainname.co.uk
On the bounceback we are told :-
mx.google.com rejected your message to the following email addresses:
On checking further I notice that we have acquired several google mx public dns records
Our main or primary dns record is still correctly set at mail.domainname.co.uk
My question is where did all of the google mx records come from, and why this one particular client is having problems getting mail to us when the main mx record points to our mail server correctly? All other mail is reaching us correctly.
Any advice much appreciated.
Thanks
we have an mx record pointing to our mail server as follows :-
mail.domainname.co.uk
On the bounceback we are told :-
mx.google.com rejected your message to the following email addresses:
On checking further I notice that we have acquired several google mx public dns records
Our main or primary dns record is still correctly set at mail.domainname.co.uk
My question is where did all of the google mx records come from, and why this one particular client is having problems getting mail to us when the main mx record points to our mail server correctly? All other mail is reaching us correctly.
Any advice much appreciated.
Thanks
ASKER
many thanks.
This is a strange one for us, as the mx record does look set correctly, but as I said there are several google related entries in the DNS that we are not familiar with. Unfortunately the MD is away and we cannot establish yet, whether the google entries have been put there for some authorised reason to which we are not privy to.
It is indeed frustrating that only ONE client seems to be affected.
The fact it is receiving NDR's from mx.google.com consistently is strange, but unfortunately their domain is totally outside my control, and I cant carry out any checks at that end.
If I can establish that the google dns records are not required, I will remove them, but if they are required, I am not sure what else I can do, as the preferences in the DNS entries are set correctly with our required MX entry set as 1.
If anyone else can throw any light on this matter I would welcome the help.
Many thanks
This is a strange one for us, as the mx record does look set correctly, but as I said there are several google related entries in the DNS that we are not familiar with. Unfortunately the MD is away and we cannot establish yet, whether the google entries have been put there for some authorised reason to which we are not privy to.
It is indeed frustrating that only ONE client seems to be affected.
The fact it is receiving NDR's from mx.google.com consistently is strange, but unfortunately their domain is totally outside my control, and I cant carry out any checks at that end.
If I can establish that the google dns records are not required, I will remove them, but if they are required, I am not sure what else I can do, as the preferences in the DNS entries are set correctly with our required MX entry set as 1.
If anyone else can throw any light on this matter I would welcome the help.
Many thanks
Depends on if you GSuite.
1) If use GSuite, then you must login your GSuite account + you will have a list of correct MX records to set.
Note: These seem to vary slightly between accounts + maybe over time. You must set the correct MX record list based on what Google tells you are the correct MX records for your account.
2) If you don't use GSuite, then remove all the Google MX records + point them to your correct incoming MX IP(s).
1) If use GSuite, then you must login your GSuite account + you will have a list of correct MX records to set.
Note: These seem to vary slightly between accounts + maybe over time. You must set the correct MX record list based on what Google tells you are the correct MX records for your account.
2) If you don't use GSuite, then remove all the Google MX records + point them to your correct incoming MX IP(s).
you mentioned it says account doesn't exist, did you check if the account really does exist?
it could be similar to something we have n EOP directly based edge blocking....
or it could be that the sender is sending emails to an incorrect email address altogether....
it could be similar to something we have n EOP directly based edge blocking....
or it could be that the sender is sending emails to an incorrect email address altogether....
ASKER
thanks for your reply.
yes the account does exist. its only for the one sender that has a problem. we receive mail regularly from everyone else.
it seems that they receive and ndr from a google mx which is not the primary mx record.
the email is addressed correctly as they even tried replying to an email that we sent to them, with the same results.
Regards.
yes the account does exist. its only for the one sender that has a problem. we receive mail regularly from everyone else.
it seems that they receive and ndr from a google mx which is not the primary mx record.
the email is addressed correctly as they even tried replying to an email that we sent to them, with the same results.
Regards.
where does your mx points to, does it points to google, if its not then think about the reason why it would go to google ??
ASKER
our mx is mail.domainname.co.uk and is set is the 1st preference.
There are around 8 other google related mx records present, but all are set to a higher preference?
As I said before, I do not know where these google mx records have appeared from, but as soon as I can gain access to the DNS records I will know more.
Here are a list of the mx records reported
There are around 8 other google related mx records present, but all are set to a higher preference?
As I said before, I do not know where these google mx records have appeared from, but as soon as I can gain access to the DNS records I will know more.
Here are a list of the mx records reported
so it is clear that the mx from the sender is failing so thats why the other mx is beeing picked for message delivery..
please have the sender do a mx look at there sending host that should get your correct mx if not they need to fix the dns look for your domain at there end.
the other option would for you is to go into your google system and probably set the routing to the correct destination, probably disable the user checking there and route to your first preference.
please have the sender do a mx look at there sending host that should get your correct mx if not they need to fix the dns look for your domain at there end.
the other option would for you is to go into your google system and probably set the routing to the correct destination, probably disable the user checking there and route to your first preference.
ASKER
we dont use google at all, so we dont have anything to change here. thats why i was going to remove all of the google mx records when i get access to their public dns records.
why would the mx record fail for just this single sender?
why would the mx record fail for just this single sender?
if you remove those stale mx that would be a good step.
there sending host may have issues reaching your preferred mx, it only they can tell why its failing you can't control that, please have them do a telnet test to your mail gateway from there Mail gateway.
there sending host may have issues reaching your preferred mx, it only they can tell why its failing you can't control that, please have them do a telnet test to your mail gateway from there Mail gateway.
if you do not use gmail, removing the gmail records is an obvious step.
That sender uses a failover mx. That can be by design, due to a network issue, or possibly to some kind of greylisting on your side. Anyxay The RFC quite clearly implies that you are not supposed to expect remote servers to ONLY use the main mx record. So any server stated as an mx SHOULD work
That sender uses a failover mx. That can be by design, due to a network issue, or possibly to some kind of greylisting on your side. Anyxay The RFC quite clearly implies that you are not supposed to expect remote servers to ONLY use the main mx record. So any server stated as an mx SHOULD work
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
we dont use google. no one seems to know how these mx records have appeared!
i will remove them one i get the credentials for the domain host portal.
many thanks
i will remove them one i get the credentials for the domain host portal.
many thanks
ASKER
many thanks to all. i will update this once the google mx records have been removed
You're welcome!
Once you remove the Google MX records, your single MX will be only surviving MX record, so likely all will work correctly.
Once you remove the Google MX records, your single MX will be only surviving MX record, so likely all will work correctly.
- Either ask your DNS provider (could be an administrative error, either automated, or by support staff)
- If you have log in info to a DNS panel, check who has that info, or try to change passwords
Second, why the sender uses the secondary (or tertiary etc) records, instead of the main? Sometimes mail servers do that (it shouldn't though). Also, you don't actually know where he got the info from (could be that he's using a DNS server where the Google entries ARE the primary entries)