Abstract: Domain Control Validation (DCV) is a required step before SSL can issue SSL/TLS, Mark, and, under certain circumstances, S/MIME certificates. However, configuration mistakes, network restrictions, and propagation delays can halt the process.
This guide walks through the most common reasons validation fails across all supported methods, including email, HTTP file upload, CNAME, and DNS TXT, and provides direct steps to resolve each one. Less common blockers, such as restrictive CAA records and expired tokens are also covered.
Before SSL can issue your certificate, you must prove control over the domain it will protect. This process is called Domain Control Validation, or DCV. When it does not go as expected, certificate issuance stalls, and your order stays in a pending state.
This guide explains why DCV fails for each supported validation method, what to look for, and exactly how to resolve it.
Common Reasons Email Validation Fails
The selected mailbox does not exist. This is the most frequent cause. Generic addresses like admin@ or webmaster@ are not created automatically at every hosting provider. If you selected one of these addresses during checkout and have never set it up, the message has nowhere to land.
The email was filtered as spam. Security gateways and spam filters sometimes quarantine automated messages from certificate authorities. Check your spam, junk, and quarantine folders before assuming the email was not sent.
The confirmation link expired. Validation links have a limited lifespan. If you did not complete the confirmation within the allowed timeframe, the link is no longer valid.
The wrong address was selected. If your organization uses a custom contact email registered via a DNS CAA or TXT record, confirm that the record is in place and that the address is reachable.
How to Fix It
http://yourdomain.com/.well-known/pki-validation/[MD5_hash].txt
A common mistake is uploading the file to the site’s root or a different subdirectory. The .well-known/pki-validation/ path is required and must be exact.
The file contents are incorrect. The text file must contain the SHA-256 hash of the CSR on the first line, followed by ssl.com on the second line, and the unique token on the third. Editing the file, adding extra spaces, or saving it in the wrong encoding will cause the check to fail.
A redirect is blocking access. Many sites redirect all HTTP traffic to HTTPS, or redirect the root domain to a www subdomain. SSL’s check follows standard HTTP redirects, but some redirect chains (especially those involving non-standard ports or authentication walls) can break the lookup. If your site forces a redirect, verify the file is still accessible at the final destination URL.
A CDN or WAF is intercepting the request. Content delivery networks and web application firewalls can block or cache requests to unfamiliar paths. If you use Cloudflare, Fastly, or a similar service, confirm there are no rules preventing access to the /.well-known/pki-validation/ path, or temporarily put the CDN in passthrough mode for that path.
The server is configured to block .txt files or the .well-known directory. Some server configurations disallow direct access to hidden directories (those starting with a dot). Review your .htaccess file or server configuration to ensure the path is publicly accessible without authentication.
The domain is not publicly reachable. If your server is on a private network or behind a firewall that blocks external connections, SSL’s automated check cannot reach it. In this case, DNS or email validation is the appropriate method.
How It Works
CNAME DNS validation requires you to add a specific CNAME record to your domain’s DNS zone. The record uses the MD5 and SHA-256 hashes of your CSR as its name and a random value, pointing back to ssl.com.
Common Reasons CNAME Validation Fails
Typographical errors in the record. Hash values are long strings and easy to mistype. Even a single incorrect character means the record will not match what SSL is looking for.
DNS propagation is incomplete. DNS changes do not take effect instantly. Depending on the TTL set on your DNS zone, it generally takes anywhere from a few minutes to 48 hours for a new record to be visible to all resolvers worldwide. SSL’s check must be able to see the record from multiple network vantage points.
The record was added at the wrong level. The CNAME must be created as a subdomain of the domain being validated. Placing it at the wrong zone or using an incorrect hostname format will cause the lookup to fail.
An existing CNAME conflict. If a CNAME record already exists for the same hostname, some DNS providers will reject the new entry or silently overwrite it. Confirm the record was saved correctly after adding it.
The order token has expired. Validation tokens are time-limited. If your order has been pending for an extended period without a completed check, the token may need to be regenerated. Log in to your account and reissue the validation request to get fresh values.
Validating a domain you do not control. If you are validating a domain on behalf of a client or third party, confirm that they have granted access to the required email addresses, DNS records, or server directories. DCV cannot be completed without some form of access to the domain’s infrastructure.
For a full reference of SSL’s DCV requirements and accepted record formats, see SSL/TLS Certificate Domain Validation Requirements.
This guide walks through the most common reasons validation fails across all supported methods, including email, HTTP file upload, CNAME, and DNS TXT, and provides direct steps to resolve each one. Less common blockers, such as restrictive CAA records and expired tokens are also covered.
Before SSL can issue your certificate, you must prove control over the domain it will protect. This process is called Domain Control Validation, or DCV. When it does not go as expected, certificate issuance stalls, and your order stays in a pending state.
This guide explains why DCV fails for each supported validation method, what to look for, and exactly how to resolve it.
Why DCV Fails: A Quick Overview
DCV failures fall into a few broad categories, regardless of the method you use:- The validation token, file, or record is incorrect, missing, or unreachable
- A network configuration (firewall, CDN, redirect) is blocking SSL’s automated check
- DNS changes have not yet propagated
- The validation window has expired before the check could succeed
Email Validation Failures
How It Works
When you select email validation, SSL sends a message containing a one-time code and a confirmation link to one of the pre-approved addresses for your domain (for example, admin@, administrator@, webmaster@, hostmaster@, or postmaster@).Common Reasons Email Validation Fails
The selected mailbox does not exist. This is the most frequent cause. Generic addresses like admin@ or webmaster@ are not created automatically at every hosting provider. If you selected one of these addresses during checkout and have never set it up, the message has nowhere to land.The email was filtered as spam. Security gateways and spam filters sometimes quarantine automated messages from certificate authorities. Check your spam, junk, and quarantine folders before assuming the email was not sent.
The confirmation link expired. Validation links have a limited lifespan. If you did not complete the confirmation within the allowed timeframe, the link is no longer valid.
The wrong address was selected. If your organization uses a custom contact email registered via a DNS CAA or TXT record, confirm that the record is in place and that the address is reachable.
How to Fix It
- Log in to your SSL account, navigate to your order, and click Perform Validation.
- Confirm the address shown is one you can access. If it is not, use the option to resend to a different approved address or switch to a DNS or HTTP-based method.
- After resending, check both your inbox and spam folder.
- Once you receive the email, follow the link and enter the validation code promptly. Do not close the confirmation page before submitting.
HTTP File Validation Failures
How It Works
With HTTP file validation, you download a small text file from your SSL portal and upload it to a specific path on your web server. SSL’s automated systems then attempt to retrieve it over HTTP on port 80 or HTTPS on port 443.Common Reasons HTTP File Validation Fails
The file is placed in the wrong directory. The file must be accessible at:http://yourdomain.com/.well-known/pki-validation/[MD5_hash].txt
A common mistake is uploading the file to the site’s root or a different subdirectory. The .well-known/pki-validation/ path is required and must be exact.
The file contents are incorrect. The text file must contain the SHA-256 hash of the CSR on the first line, followed by ssl.com on the second line, and the unique token on the third. Editing the file, adding extra spaces, or saving it in the wrong encoding will cause the check to fail.
A redirect is blocking access. Many sites redirect all HTTP traffic to HTTPS, or redirect the root domain to a www subdomain. SSL’s check follows standard HTTP redirects, but some redirect chains (especially those involving non-standard ports or authentication walls) can break the lookup. If your site forces a redirect, verify the file is still accessible at the final destination URL.
A CDN or WAF is intercepting the request. Content delivery networks and web application firewalls can block or cache requests to unfamiliar paths. If you use Cloudflare, Fastly, or a similar service, confirm there are no rules preventing access to the /.well-known/pki-validation/ path, or temporarily put the CDN in passthrough mode for that path.
The server is configured to block .txt files or the .well-known directory. Some server configurations disallow direct access to hidden directories (those starting with a dot). Review your .htaccess file or server configuration to ensure the path is publicly accessible without authentication.
The domain is not publicly reachable. If your server is on a private network or behind a firewall that blocks external connections, SSL’s automated check cannot reach it. In this case, DNS or email validation is the appropriate method.
How to Fix It
- Download the DCV file from your order’s Perform Validation page.
- Upload it exactly as downloaded to /.well-known/pki-validation/ on your web server.
- Before requesting a recheck, paste the full file URL into a browser or use curl to confirm the file returns a 200 OK response and correct contents.
- If you see a redirect, follow it to the final URL and make sure the file content is intact there.
- Once the file is confirmed reachable, return to your SSL portal and trigger the validation check.
CNAME DNS Validation Failures
How It Works
CNAME DNS validation requires you to add a specific CNAME record to your domain’s DNS zone. The record uses the MD5 and SHA-256 hashes of your CSR as its name and a random value, pointing back to ssl.com.Common Reasons CNAME Validation Fails
Typographical errors in the record. Hash values are long strings and easy to mistype. Even a single incorrect character means the record will not match what SSL is looking for.DNS propagation is incomplete. DNS changes do not take effect instantly. Depending on the TTL set on your DNS zone, it generally takes anywhere from a few minutes to 48 hours for a new record to be visible to all resolvers worldwide. SSL’s check must be able to see the record from multiple network vantage points.
The record was added at the wrong level. The CNAME must be created as a subdomain of the domain being validated. Placing it at the wrong zone or using an incorrect hostname format will cause the lookup to fail.
An existing CNAME conflict. If a CNAME record already exists for the same hostname, some DNS providers will reject the new entry or silently overwrite it. Confirm the record was saved correctly after adding it.
How to Fix It
- Copy the CNAME name and value directly from your SSL portal rather than retyping them.
- After saving the record, use a DNS lookup tool (such as dig or an online DNS checker) to verify the record is resolving correctly before requesting validation.
- If propagation is still in progress, wait and check again. Most records propagate within a few hours, though the full window can extend to 48 hours.
- Once the record is confirmed live, return to your order and trigger the validation check.
DNS TXT Validation Failures
DNS TXT validation follows the same principles as CNAME validation. The most common failure points are identical: typos in the record value, propagation delays, and placing the record in the wrong DNS zone. The same diagnostic steps apply. Confirm the record exists and resolves correctly before requesting a recheck.Less Common Causes Across All Methods
CAA records blocking issuance. If your domain has CAA (Certification Authority Authorization) records, they must explicitly permit ssl.com to issue certificates. A CAA record that lists only other CAs will cause issuance to fail even after DCV is complete. Check your DNS zone for any existing CAA records and add or update them as needed.The order token has expired. Validation tokens are time-limited. If your order has been pending for an extended period without a completed check, the token may need to be regenerated. Log in to your account and reissue the validation request to get fresh values.
Validating a domain you do not control. If you are validating a domain on behalf of a client or third party, confirm that they have granted access to the required email addresses, DNS records, or server directories. DCV cannot be completed without some form of access to the domain’s infrastructure.
Still Having Trouble?
If you have worked through the steps above and validation is still not completing, the SSL support team is available to help. You can reach us via live chat or by email at Support@SSL.com. When you reach out, having your order number and the specific validation method you are using on hand will help us resolve the issue as quickly as possible.For a full reference of SSL’s DCV requirements and accepted record formats, see SSL/TLS Certificate Domain Validation Requirements.
