Plesk SSL! and Let’s Encrypt operations verify the domain control using ACME validation. Incorrect A/A AAAA record, missing _acme-challenge TXT, external DNS, CAA restriction, port 80 block, or pending wildcard operation can prevent the certificate from being issued and automatically renewed.
Domain validation failed
Incorrect TXT record found at _acme-challenge.example.com
DNS problem: NXDOMAIN looking up TXT
DNS problem: SERVFAIL looking up TXT
Invalid response from http://example.com/.well-known/acme-challenge/
The certificate authority checks that you are managing the domain with HTTP-01 or DNS-01 validation. While HTTP paths are available in normal certificates, wildcard certificates usually require the _acme-challenge TXT record.
In HTTP-01 verification, the domain's A/AAAA record should be correctly pointed to the Plesk server, and the challenge file should be accessible over the internet via port 80.
In DNS-01 validation, the new TXT value displayed by Plesk must be published on the authorized nameserver. If the old TXT value remains, an Incorrect TXT record error may occur.
If DNS is managed by another provider, Plesk adding a record to the local DNS zone alone is not sufficient. The record must be entered in the actual authorized DNS panel.
Even if a certificate is obtained, if it has not been assigned to web, mail, webmail, or panel service, the user can still view the old certificate.
Wildcard TXT value may change with each renewal. If the external DNS provider is not automatically integrated with Plesk, automatic renewal may require manual TXT update.
Search for the phrase you see in the email, browser, or SSH log. Each card includes meaning, probable cause, and safe initial action.
Meaning: ACME server saw different value instead of expected TXT.
Possible cause: Old TXT record, wrong DNS panel, or incomplete deployment.
Meaning: _acme-challenge name could not be found on DNS.
Possible cause: The TXT record has not been added or entered into the wrong host field.
Meaning: Authorized DNS server failed to produce a valid response.
Possible cause: DNSSEC corruption, nameserver issue or DNS service error
Meaning: The HTTP challenge URL has not returned the expected token.
Possible cause: Incorrect A/AAAA, port 80 block, redirect, proxy, or application rule.
Meaning: The CAA record is not allowing Let's Encrypt to issue certificates.
Possible cause: Incorrect or restrictive issue/issuewild record.
Meaning: Let’s Encrypt has detected a large number of failed attempts in a short period of time.
Possible cause: Certificate requests were sent repeatedly before the issue was resolved.
Meaning: The automatic renewal task for the current certificate has not been completed.
Possible cause: DNS change, external DNS, task failure or domain scope change.
Meaning: The new certificate has not been assigned to the correct service or the proxy cache is serving an old certificate.
Possible cause: Domain hosting setting, mail/panel certificate, or CDN edge certificate.
No records matching this expression were found.
Commands are for root access. Collect only status and logs first; Do not change the permanent setting without seeing the reason.
dig +short A example.com
dig +short AAAA example.com
dig +trace example.com | tail -n 30
Shows which server the domain name and IPv6 record point to.
dig +short NS example.com
dig SOA example.com +noall +answer
Determines which DNS provider the change should be made to.
dig TXT _acme-challenge.example.com +noall +answer
Lists TXT values visible in the external world.
curl -vI http://example.com/.well-known/acme-challenge/eka-test
Port 80 shows external access to the redirect and challenge path.
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
Shows the certificate names and dates actually provided by the server.
grep -Ei 'letsencrypt|acme|certificate|sslIt' /var/log/plesk/panel.log | tail -n 120
Plesk panel certificate operations show error details.
plesk repair web example.com
Domain web configuration and SSL assignments check on the Plesk side
Specify the certificate type, verify the authorized DNS, test the challenge path, and only request again after the issue has been resolved.
Wildcard certificates require DNS-01 TXT verification. If a normal certificate can be obtained via HTTP-01, the process is different.
NS records should be set up in the DNS panel outside of Plesk if the Plesk server is not being displayed.
dig +short NS example.comIncorrect IPv6 record, may break old TXT or restrictive CAA certificate process.
Port 80 and the .well-known path should not be blocked by a proxy, redirect, or security rule.
curl -v http://example.com/.well-known/acme-challenge/eka-testDo not send Continue/Reload or new request without being visible in all authorized resolvers.
Certificate assignments for the website, webmail, mail, and panel can be separate. Check the public endpoint using openssl.
Redirects and WAF rules are checked during the HTTP challenge. The Origin A/AAAA record must be correct; a real DNS TXT record is required for wildcard.
DNS Plesk outside and API integration may require manual updating of the new TXT value.
Mail server and webmail certificate assignments are also checked in the Tools & Settings section.
Let’s Encrypt can reach the wrong origin over IPv6. Unused AAAA records must be removed or pointed to the correct IP.
The registrar DS record is checked for key matching with the DNS provider; a certificate is not requested before resolving the broken chain.
The DNS or challenge conditions may have changed after the initial setup. A common reason is that the wildcard TXT value in the external DNS cannot be updated automatically.
Let’s Encrypt is seeing a different or old TXT value instead of the expected new token.
Since it is not possible to individually verify all subdomains under the Wildcard scope via HTTP, domain verification is proven using the DNS-01 method.
No. Cloudflare edge certificate is between Cloudflare and visitor; origin Plesk server's certificate should also be managed.
Yes. If the domain is going to a wrong server with IPv6, the verification may fail from that endpoint.
The new certificate may not be assigned to the relevant domain or service, or the CDN/proxy may be displaying its own certificate.
Not required; but if present, only allowed certificate authorities can issue certificates. Incorrect CAA prevents issuance.
By analyzing cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim and security layers together, we fix the root cause of the failure instead of just removing the service.