This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(112.00000000000001, 51%, 20%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ECD%3C/text%3E%3C/svg%3E)
I set up Azure communication service, added email service, added custom domain, began verification, entered the ms-domain-verification TXT record into my DNS as specified except TTL. Have verified the ms-domain-verification TXT record is found and resolves to its correct value (a GUID string) via ns1.azure.com, but my TTL is 14400 because 14400 is the minimum TTL allowed for me to set. Azure says I must set the TTL to 3600, but I can't. Due to impossiblity of TTL 3600 on this DNS provider (bluehost.com), I am not able to verify DNS in Azure and move along to setting up SPF and DKIM records. I tried opening an Azure support ticket about the impossible (for me) 3600 TTL demanded by Azure email service DNS provisioner, but Azure Support UI demanded money before it would help me with something that Azure demands but cannot be done via bluehost.com DNS setup UI. Seems nuts for Azure to demand a 3600 TTL for the TXT record it wants to check and can check and has the correct record value in ns1.azure.com but azure claims validation fails because it checks the TTL which doesn't even matter. Anybody know of anything that can be done to continue my project using Azure when it will require sending an e-mail and the e-mail needs to look legit (ie use the senders actual domain)?
bluehost.com support has helped me resolve issue from that side. i now have 3600 TTL as demanded by azure. very silly. maybe they could fix that for other people
Unfortunately now I have TTL 3600 but the secret bluehost DNS UI for professionals auto-changes the "host" value from my domain typed out to the @ symbol which is DNS shorthand for the domain that Azure apparently REQUIRES to be typed out. Now my txt record comes back as a ~top level TXT record that is accessible only via "dig -t txt (mydomainname).com ns1.azure.com" rather than how Azure requires which is "dig -t txt mydomainname.com.mydomainname.com ns1.azure.com" which puts me back at square zero unable to verify DNS despite my txt record coming back with the proper value via ns1.azure.com, now with TTL 3600, but not precisely the fashion Azure demands of me. Anything can be done such that azure will work with the absolutely correct @ sign as the host for the TXT record since that's the only way I can set the 3600 TTL?
But now the TXT record comes back as a (if you will) top level TXT record where apparently azure validation cannot find it. The "at" sign (which apparently causes comment here to be discared silently) is auto-replaced where i enter my domainname.com as host per azure. Due to the host being the "at" sign, the TXT record moves up to domain level and is not found by Azure now that it has the required TTL 3600. I have tried futzing with both DNS UIs in bluehost trying to con the host not to be auto-replaced with "at" symbol while maintaining TTL 3600 but it is impossible. Any ideas anyone?
Oh, the comment with the "at" symbol came back. This Q&A thing is as flakey as the Azure UI. JFC... "Azure. Change something. Check back later whe nUI does not lie anymore."
My DNS magically shows as verified now in Azure UI. Thank you to whoever did that.
Hi @Chris Davis , we are glad to hear issue was resolved. If you come across any other issues, please let us know.
-Grace