: I'm having some trouble moving MX records to the registrars DNS I run Google Apps email and have traditionally hosted my own DNS records through my Plesk setup. It has been recommended to
I run Google Apps email and have traditionally hosted my own DNS records through my Plesk setup. It has been recommended to us that we'd more reliably serve emails during downtime if we kept the MX and CNAME listings required by Google Apps hosted at Enom instead of handling it internally.
I have essentially copied the settings from Plesk over to Enom. The domain itself forwards with no problem, but the MX records, while they seem to be input into Enom without error, never seem to reroute my mail. If I try to send to the email address I'm trying to route, I get the following error bounced back:
Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 553 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1) (state 14).
This sort of error gets referenced a lot with regard to propogation, but It's been two days and Enom updates everything else almost instantly.
Ideas?
More posts by @Sent6035632
2 Comments
Sorted by latest first Latest Oldest Best
You might be waiting on the TTL (regardless of how quickly eNom updates their DNS records, the TTL will likely be observed by intermediary systems which have cached the MX record), however, the more likely culprit after 48 hours would be your Plesk settings.
Update:
My apologies - I got the impression from your question that you were duplicating your Plesk settings at eNom for redundancy, though the header you provided would indicate otherwise.
From a review of the headers you provided, it looks like eNom is not returning any MX records - see mx:nativeapps.org at MXToolBox (you may want to keep checking what eNom's nameservers return for your domain as you investigate with their support staff).
One comment, one idea:
The comment is that this question is probably better served at serverfault.com or superuser.com (I honestly don't know which one is most appropriate).
The idea is that you should include the full bounced mail headers in your question, and state which exact domain is having this problem. DNS is a public system, so once we know what domain it is, we can look at the information you're publicizing in DNS and tell you where the problem is.
Terms of Use Create Support ticket Your support tickets Stock Market News! © vmapp.org2024 All Rights reserved.