Please check this thread Gmail MX settings - #10
I don’t think so. I think that Cloudflare’s back-end doesn’t work correctly.
With Google it’s all OK I think. It’s Cloudflare’s error. I used Yandex DNS and post worked perfectly.
I think that this problem because Cloudflare deletes dot in the end if MX records and sent this thread)
Thanks. But it didn’t solve my problem too)
Is it the same issue as in the linked thread?
Ok. I’ll tell about this problem. My English isn’t perfect but I’ll try.
All in all. When I add MX records to hwonline.ru domain dot in the end disepears. And Yandex says that I need dot in the end in all situations. Now it’s the third day and Yandex doesn’t links post to domain:(
1 Like
They said that I need contact Cloudflare XD
https://vk.com/wall450829055_112
And I have this errors
Thank you)
Retracted my responses.
I just ran your domain via dig and the trailing dot does show up. Why exactly should you contact Cloudflare? The trailing dot is there.
1 Like
I have the same problem with MX records now.
mx.yandex.net. is needed to me but Cloudflare deletes dot in the end and I can’t use emails. A few months ago I could use it correctly.
The final . is not needed. Please do not post in multiple threads. Create your own explaining your issue.
1 Like
All in all. Thanks. Yandex support helped me with connecting my domain to their services. If anyone has the same problem U can write to their support with e-mail or in VK Write message @yandex | VK
1 Like
Did they say what the issue was? As mentioned above the trailing dot is actually in place.
I couldn’t find the dot in the end of MX record but I think that they added this domain manually
The trailing dot is implied. It is not necessary that it be displayed int he UI. When you open a web browser and type www.google.com it is really visiting www.google.com. (that last dot is implied int he UI even though technically the application and underlying OS are using it.
The trailing dot represents the root of the internet (the root hinter servers), That it isn’t showing up in our UI isn’t an issue and isn’t the source of any validation problems. Our backend works just fine.
dig hwonline.ru mx +short
10 mx.yandex.net.
The record is correct when queried. The record works. I don’t see any description of an actual issue here other than a disagreement of how our UI should represent a DNS record. You are of course welcome to your opinion, but to call it a problem is inaccurate.
3 Likes
That was precisely what I eventually discovered. I believe it happened now for - at least - the third time that Yandex couldnt verify the MX record. Any idea what might potentially fail here or why they raise a warning?
Most companies that write these checkers put a low to mid-level developer on it. They write shitty code and the process doesn’t work well.
I had the exact same experience this weekend with the G Suite checker which was doing rechecks over the course of a 30 minute period but was either using a cached value for the NS which had subsequently changed (because I moved the zone to Cloudflare) or was querying an internal DNS server which had the NS value changed. After 20 mins I went in and purged the Google cache NS and SOA records for the zone manually and it eventually completed, but they are usually trying to ‘save’ DNS lookups by caching the NS to check or something equally stupid.
Microsoft has similarly bad logic but on different values for their Office 365 product… so it isn’t a stretch to assume Yandex (which I have never used) is also doing something sub-optimal in their caching and checking.
2 Likes