DNS problem: NXDOMAIN looking up TXT for _acme-challenge

Hi. So, my mail server autodiscover certificate has expired and users on our company domain can't access their mail. We have all-Windows domain with AD, 2 controllers run WS2019 and our on-premises mail server is Exchange 2013 on WS2012 (we are going to migrate to newer software soon). Specialists that configured everything are currently unavailable and we don't have an admin, so we are in a bit of a pickle.

I used this tutorial https://youtu.be/KkwWar5CiMg?si=r0_kGkwlJWfpvs2b. When it gave me the parameters to set up a TXT record I assumed I had to create it on our webhosting which I did.


But for some reason the script was looking for TXT records on our domain controllers. So I added a record on one DC and waited for it to appear on the second one.


But after that I got an error (I will add the whole thing below).

Now I'm at a loss. What was my mistake? Maybe I should've also done certs for mubis.ru and mail.mubis.ru? I only did autodiscover cause other certs are self-signed.

At some point I tried a different method but it gave me a different error:


The full thing:

 N: Create certificate (default settings)
 M: Create certificate (full options)
 R: Run renewals (1 currently due)
 A: Manage renewals (1 total, 1 in error)
 O: More options...
 Q: Quit

 Please choose from the menu: m

 Running in mode: Interactive, Advanced

 Please specify how the list of domain names that will be included in the
 certificate should be determined. If you choose for one of the "all bindings"
 options, the list will automatically be updated for future renewals to
 reflect the bindings at that time.

 1: Read bindings from IIS
 2: Manual input
 3: CSR created by another program
 C: Abort

 How shall we determine the domain(s) to include in the certificate?: 2

Description:         A host name to get a certificate for. This may be a
                     comma-separated list.

 Host: autodiscover.mubis.ru

 Source generated using plugin Manual: autodiscover.mubis.ru

 Friendly name '[Manual] autodiscover.mubis.ru'. <Enter> to accept or type desir
ed name:

 By default your source identifiers are covered by a single certificate. But
 if you want to avoid the 100 domain limit, want to prevent information
 disclosure via the SAN list, and/or reduce the operational impact of a single
 validation failure, you may choose to convert one source into multiple
 certificates, using different strategies.

 1: Separate certificate for each domain (e.g. *.example.com)
 2: Separate certificate for each host (e.g. sub.example.com)
 3: Separate certificate for each IIS site
 4: Single certificate
 C: Abort

 Would you like to split this source into multiple certificates?: 4

 The ACME server will need to verify that you are the owner of the domain
 names that you are requesting the certificate for. This happens both during
 initial setup *and* for every future renewal. There are two main methods of
 doing so: answering specific http requests (http-01) or create specific dns
 records (dns-01). For wildcard identifiers the latter is the only option.
 Various additional plugins are available from

 1: [http] Save verification files on (network) path
 2: [http] Serve verification files from memory
 3: [http] Upload verification files via FTP(S)
 4: [http] Upload verification files via SSH-FTP
 5: [http] Upload verification files via WebDav
 6: [dns] Create verification records manually (auto-renew not possible)
 7: [dns] Create verification records with acme-dns (https://github.com/joohoi/a
 8: [dns] Create verification records with your own script
 9: [tls-alpn] Answer TLS verification request from win-acme
 C: Abort

 How would you like prove ownership for the domain(s)?: 6

 After ownership of the domain(s) has been proven, we will create a
 Certificate Signing Request (CSR) to obtain the actual certificate. The CSR
 determines properties of the certificate like which (type of) key to use. If
 you are not sure what to pick here, RSA is the safe default.

 1: Elliptic Curve key
 2: RSA key
 C: Abort

 What kind of private key should be used for the certificate?: 2

 When we have the certificate, you can store in one or more ways to make it
 accessible to your applications. The Windows Certificate Store is the default
 location for IIS (unless you are managing a cluster of them).

 1: IIS Central Certificate Store (.pfx per host)
 2: PEM encoded files (Apache, nginx, etc.)
 3: PFX archive
 4: Windows Certificate Store (Local Computer)
 5: No (additional) store steps

 How would you like to store the certificate?: 4

 1: [My] - General computer store (for Exchange/RDS)
 2: [Default] - Use global default, currently WebHosting

 Choose store to use, or type the name of another unlisted store: 2

 1: IIS Central Certificate Store (.pfx per host)
 2: PEM encoded files (Apache, nginx, etc.)
 3: PFX archive
 4: Windows Certificate Store (Local Computer)
 5: No (additional) store steps

 Would you like to store it in another way too?: 5

 With the certificate saved to the store(s) of your choice, you may choose one
 or more steps to update your applications, e.g. to configure the new
 thumbprint, or to update bindings.

 1: Create or update bindings in IIS
 2: Start external script or program
 3: No (additional) installation steps

 Which installation step should run first?: 1

 This plugin will update *all* binding using the previous certificate in both
 Web and FTP sites, regardless of whether those bindings were created manually
 or by the program itself. Therefor you'll never need to run this installation
 step twice.

 During initial setup, it will try to make as few changes as possible to IIS
 to cover the source identifiers. If new bindings are needed, by default it
 will create those at the same site where the HTTP binding for that host was

 1: Default Web Site
 2: Exchange Back End

 Choose site to create new bindings: 1

 1: Create or update bindings in IIS
 2: Start external script or program
 3: No (additional) installation steps

 Add another installation step?: 2

Description:         Path to script file to run after retrieving the
                     certificate. This may be any executable file or a
                     Powershell (.ps1) script.

 File: ./Scripts/ImportExchange.ps1

{CertCommonName}:    Common name (primary domain name)
{CachePassword}:     .pfx password
{CacheFile}:         .pfx full path
{CertFriendlyName}:  Certificate friendly name
{CertThumbprint}:    Certificate thumbprint
{StoreType}:         Type of store (e.g. CentralSsl, CertificateStore,
                     PemFiles, ...)
{StorePath}:         Path to the store
{RenewalId}:         Renewal identifier
{OldCertCommonName}: Common name (primary domain name) of the previously
                     issued certificate
{OldCertFriendlyName}: Friendly name of the previously issued certificate
{OldCertThumbprint}: Thumbprint of the previously issued certificate
{vault://json/mysecret}: Secret from the vault

Description:         Parameters for the script to run after retrieving the
                     certificate. Refer to
                     for further instructions.

 Parameters: '{CertThumbprint}' 'IIS,SMTP,IMAP' 1 '{CacheFile}' '{CachePassword}
' '{CertFriendlyName}'

 1: Create or update bindings in IIS
 2: Start external script or program
 3: No (additional) installation steps

 Add another installation step?: 3

Existing renewal:    [Manual] autodiscover.mubis.ru - 5 renewals, due now, 38

 Overwrite settings? (y*/n) - no

 Plugin Manual generated source autodiscover.mubis.ru with 1 identifiers
 Plugin Single created 1 order
 First chance error calling into ACME server, retrying with new nonce...
 Cached order has status invalid, discarding
 [autodiscover.mubis.ru] Authorizing...
 [autodiscover.mubis.ru] Authorizing using dns-01 validation (Manual)

Domain:              autodiscover.mubis.ru
Record:              _acme-challenge.autodiscover.mubis.ru
Type:                TXT
Content:             "EnmVNrV-Jj7ihFf3xxjP5y1iIeyV_VXkKKorpy5OImc"
Note:                Some DNS managers add quotes automatically. A single set
                     is needed.

 Please press <Enter> after you've created and verified the record

 [autodiscover.mubis.ru] [] Incorrect TXT record(s) found
 [autodiscover.mubis.ru] [] Incorrect TXT record(s) found
 [autodiscover.mubis.ru] Preliminary validation failed on all nameservers

 The correct record has not yet been found by the local resolver. That means
 it's likely the validation attempt will fail, or your DNS provider needs a
 little more time to publish and synchronize the changes.

 1: Retry check
 2: Ignore and continue
 3: Abort

 How would you like to proceed?: 1

 [autodiscover.mubis.ru] Preliminary validation succeeded
 [autodiscover.mubis.ru] Preliminary validation succeeded
 [autodiscover.mubis.ru] Authorization result: invalid
 [autodiscover.mubis.ru] {"type":"urn:ietf:params:acme:error:dns","detail":"DNS
problem: NXDOMAIN looking up TXT for _acme-challenge.autodiscover.mubis.ru - che
ck that a DNS record exists for this domain","status":400,"instance":null}

Domain:              autodiscover.mubis.ru
Record:              _acme-challenge.autodiscover.mubis.ru
Type:                TXT
Content:             "EnmVNrV-Jj7ihFf3xxjP5y1iIeyV_VXkKKorpy5OImc"

 Please press <Enter> after you've deleted the record

Hi @zaparil, and welcome to the LE community forum :slight_smile:

The DNS verification would go to the authoritative Internet DNS servers:

mubis.ru        nameserver = ns8-l2.nic.ru
mubis.ru        nameserver = ns8-cloud.nic.ru
mubis.ru        nameserver = ns3-l2.nic.ru
mubis.ru        nameserver = ns4-cloud.nic.ru
mubis.ru        nameserver = ns4-l2.nic.ru

[not your AD DNS servers]


That said, why aren't you using AD for any certs required by the internal email system?

update: I see this is also public facing!
[exchange on the Internet - not my cup of tea]

How did you get the current/expired cert?


You appear to be using win-acme and it tries to pre-validate your TXT records are in place by making DNS queries against the DNS servers the underlying OS is configured to use. Because those DNS servers are your domain controllers and are hosting an internal copy of your domain, they obviously don't find the record you created on your hosting provider.

This was an unnecessary step. I don't know much about win-acme, but I would hope there's a way to disable the pre-validation it tries to do. If so, do that. But if not, you may want to look for a different client that doesn't have that limitation.



Default: true

If set to true, it will wait until it can verify that the validation record has been created and is available before beginning DNS validation.


Default: [ "[System]" ]

A list of servers to query during DNS prevalidation checks to verify whether or not the validation record has been properly created and is visible for the world. These servers will be used to located the actual authoritative name servers for the domain. You can use the string [System] to have the program query your servers default, but note that this can lead to prevalidation failures when your Active Directory is hosting a private version of the DNS zone for internal use.


Thanks everyone. I'm ashamed to say I found the solution as soon as I posted this by rereading similar topics. For some reason I didn't understand solutions provided in those topics before posting but upon rereading it clicked. And the solution is exactly the same as in all those topics. Apparently when you add a TXT record you only need to specify the subdomain you need a certificate for and skip the domain name because it's implied. So the record must look like this ↓
Screenshot 2023-08-30 at 12-25-49 DNS-master RU-CENTER
not like this ↑

1 Like

Depending on the DNS zone editor, it's sometimes possible to also use the full hostname, as long as it ends with the "root zone", i.e., a dot (.).


  • _acme-challenge.foo.example.com.

instead of:

  • _acme-challenge.foo.example.com

The dot at the end signals that it's a FQDN. Without a dot, the zone root would be appended:

  • _acme-challenge.foo.example.com -> _acme-challenge.foo.example.com.example.com.

Note that the dot at the end is actually a "real" part of a FQDN, but 99.999999999 % of the time it's omitted as it's usually implied. Except in DNS zone editors :wink:


Yeah, DNS provider GUIs are annoyingly inconsistent in their UX. This is a very common mistake, @zaparil. Don't even worry about it.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.