> For the complete documentation index, see [llms.txt](https://docs.certinext.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.certinext.io/documentation/certificate-lifecycle-management/domains-and-domain-control-validation.md). # Domains and Domain Control Validation ### Overview In CERTInext, a domain must be validated through Domain Control Validation (DCV) before certificates can be issued against it. DCV proves that the party requesting a certificate genuinely controls the domain name being certified. The CA/Browser Forum Baseline Requirements define the methods a publicly trusted Certificate Authority may use for this, and CERTInext implements a subset of them. DCV Inheritance allows a subdomain to be validated automatically by inheriting the validation already completed for a higher level (parent) domain in the same account, instead of requiring the subdomain owner to repeat the full DCV process. The evidence required for each inherited validation is generated and stored automatically by the platform, reducing administrative overhead and avoiding repetitive validation in supported scenarios. DCV inheritance applies by default within your account and organization. The account’s Primary Admin (Owner) controls whether it extends to a subdomain that is delegated to a different nameserver, and can also exclude an individual subdomain so that it is validated independently. It is important to distinguish DCV from the other checks a Certificate Authority must perform. Completing DCV proves domain control. It does not by itself authorize issuance. A domain showing as successfully validated does not remove the requirement to complete the applicable CAA, corroboration, risk and product checks. An order can therefore hold a fully validated domain and still remain pending if one of those checks has not completed successfully. ### Key Concepts • Parent domain: a higher level domain that has completed DCV, for example example.com. • Subdomain: a domain beneath a parent in the DNS hierarchy, for example vpn.example.com. • Independent validation: the domain completed its own DCV by publishing the required record or file for that exact name. • DCV inheritance: a subdomain is auto verified using the validation of its parent domain, without a separate DNS record. • Authorization Domain Name: the name whose proof of control authorizes a requested name. CERTInext works this out by walking up the DNS hierarchy from the requested name to its registrable domain. • Delegation: a subdomain that publishes its own nameservers, which makes it a separate DNS zone from its parent. • Verification Type: a column indicating how a domain was verified, either independently or auto verified (inherited). • Validation token: the value you publish to prove control for one validation cycle. • Perspective: one of the geographically separate vantage points from which CERTInext performs a validation lookup, as required by the CA/Browser Forum. ### How Domain Control Validation Works A domain travels through the following stages, from being added to being used for issuance. Each stage must complete before the next begins, and the reason a domain has stopped at any stage is shown against it in the portal. 1\. The domain is added. The name is checked for format, and a CAA evaluation is performed before the domain is saved. 2\. Inheritance is evaluated. If the domain is an eligible subdomain of a validated parent, it is auto verified on save and no record needs to be published for it. 3\. The validation token is published. Where the domain must be validated on its own, you publish the DNS record or the file shown on the domain. 4\. Verification is performed. CERTInext confirms the CAA position, then checks for your record or file from multiple regions at the same time. 5\. Consensus is reached. The required regions must independently obtain results that agree before the domain moves to Validated. 6\. The domain is used for issuance. At order time, CERTInext re checks CAA for every name on the request, together with risk screening, product and entitlement checks, before the certificate is issued. ### Prerequisites • You are logged in to CERTInext with an Administrator (Primary Admin or Owner) role for the account level settings described in this document. • At least one validated Organization is available in your account, as a domain must be associated with an organization. • A parent domain has been validated in the account if you intend to rely on inheritance for its subdomains. • You have access to your DNS settings, in case a domain must be validated independently. • The domain is publicly resolvable. Publicly trusted issuance requires CERTInext to complete public DNS and CAA lookups for the name. ### Supported Validation Methods CERTInext supports the following methods of Domain Control Validation. | Method | Where you publish the proof | Covers | Wildcards | | ------------------------- | -------------------------------------------------------------- | ---------------------------------------------------------------------------- | ------------------------- | | DNS TXT Record | A TXT record at your domain, or at \_emsigndcv.\ | The name and its subdomains | Yes | | HTTP / HTTPS File | A token file under /.well-known/pki-validation/ | The exact hostname only | No | | Persistent DNS TXT Record | A long lived TXT record at \_validation-persist.\ | The name at which it is published, and wildcards where the record permits it | Yes, with policy=wildcard | ACME clients validate through the standard ACME challenge types, dns-01 and http-01, which are covered later in this document. #### DNS TXT Record This is the recommended method. It is the only method you can select that authorizes both wildcard names and subdomains. Open the domain and follow the Step 1 instructions, “Create a DNS TXT Record in your DNS Server”. Log in to your DNS provider and create a TXT record using the Host and Value shown, then use Step 2, “Verify the DNS TXT record”, and click Verify Now. Choose Verify later to complete the step afterwards; the DCV Status stays Pending until verification succeeds. The token may be published in either of two places: • at the domain name itself, which for a base domain is the zone apex and for a subdomain is that subdomain’s own name; or • at \_emsigndcv.\. The value must be published exactly as shown in the portal, with the same upper case and no extra spaces. Always use the Copy buttons, because a single incorrect character will fail validation. Where your domain apex already carries a large number of TXT records, different regions can receive different answers and corroboration can fail even though your record is correct. Publishing the required token as the only TXT record at \_emsigndcv.\ avoids this and gives a clearer and more consistent response for validation.
Figure 1: DNS TXT Record. Step 1 shows the Host and the Value to publish, each with a Copy button. Step 2 verifies the record. The note states that the value proves domain control only and is not the certificate expiry date. #### HTTP / HTTPS File Create a .txt file with the file name and file content shown on the domain, and upload it to the /.well-known/pki-validation/ directory on the web root of the exact host being validated. A ready made file can be downloaded from the instructions panel. Do not modify the name or the contents of the file. Confirm the file opens in a browser, then click Verify Now. Two points to keep in mind: • This method covers the exact hostname only, as the Baseline Requirements prescribe. It proves control of a fully qualified domain name exactly as named. If you need both [www.example.com](http://www.example.com) and example.com, either validate each name separately or use a DNS based method. • It cannot validate a wildcard name. The Baseline Requirements state that this method is not suitable for wildcard domain names, so a wildcard must be validated by a DNS based method. If your site issues redirects, make sure the /.well-known/ path still serves the file unchanged, and that no firewall or web application firewall rule blocks requests to it.
Figure 2: HTTP / HTTPS File. Step 1 gives the file name, the file content and the exact directory the file must be served from, with a ready made file available to download. The banner states that this method proves control of the fully qualified domain name exactly as named. #### Persistent DNS TXT Record This method publishes a long lived record that keeps re authorizing issuance until you remove it, rather than a token you publish once. • Host: \_validation-persist.\ • Value: emsign.com; accounturi=\ You may add two optional parameters to the value: • ; policy=wildcard extends the record to cover wildcard names. A wildcard request against a persistent record without this parameter is refused. • ; persistUntil=\ makes the authorization expire automatically at a time you choose. The record stays in your DNS and re authorizes issuance automatically, subject to a maximum reuse period after which it is checked again. Removing the TXT record withdraws the standing authorization. The persistent record validates the domain at which it is published and covers wildcard names where it carries policy=wildcard. It does not extend to subdomains on its own. Where a domain already uses this method, renewing does not generate a new value to publish. CERTInext re checks the record already in your DNS and the renewal completes as soon as that check passes.
Figure 3: Persistent DNS TXT Record. The record is published at the \_validation-persist prefix and carries the account URI. It stays in your DNS and re authorizes issuance automatically until it is removed. The confirmation on the right shows a successful validation. #### Token Validity Validation tokens for the DNS TXT and HTTP file methods are valid for 48 hours. If validation is not completed within that time, a new token is generated automatically. Publishing an older token after it has rotated will not complete validation. Refresh the domain page, copy the current value, publish it again, and verify. The persistent method does not use a rotating token. Its record is stable and is read again on each cycle. #### Choosing a Method • Validating a wildcard name, or wanting subdomains to be covered automatically, use DNS TXT Record. • No access to DNS, and validating one specific hostname, use HTTP / HTTPS File. • Wanting a standing authorization that removes repeated publishing, use Persistent DNS TXT Record. ### Adding a Domain Open Certificates, then the Domains tab. Click Create Domain in the toolbar to open the Add Domain page directly, so a domain can be added from the Domains tab without going through any other screen.
Figure 4: Certificates > Domains > Create Domain. The Add Domain form collects the domain name, the owning organization and the DCV method. All three validation methods are offered here. Complete the form and click Save & Proceed. • Domain Name (mandatory): the fully qualified domain name, for example vpn.example.com or \*.example.com. • Organization (mandatory): the validated organization that owns the domain. • DCV Method (mandatory): the validation method you intend to use. When you save, CERTInext checks the name, performs a CAA evaluation for it, and evaluates inheritance. If DCV inheritance applies and the new domain is a subdomain of an already validated parent, the subdomain is auto verified on save and no DNS record needs to be published for it. Otherwise the domain opens on its validation instructions with DCV Status set to Pending. A domain added here is a reusable object. Certificate requests reference it when determining validation status and inheritance, which is why the Domains page exists separately from Orders. ### Verifying a Domain When you click Verify Now, CERTInext performs the following in order. The reason a verification did not succeed is almost always the first of these that did not pass. 1\. The CAA position is confirmed. Where CAA does not authorize emSign, verification is refused and the domain stays Pending until the records are corrected. 2\. The method is checked against the name. A wildcard name submitted for HTTP file validation is refused before any lookup is made. 3\. Your record or file is retrieved from every region at the same time. 4\. The results are corroborated. The required regions must agree before the domain moves to Validated. On success the domain moves to Validated and its validity period is recorded. On failure the attempt is stored with the evidence from each region, which you can review in the Domain Validation Diagnostics panel. ### CAA Checks Before issuing a publicly trusted TLS certificate, CERTInext performs the Certification Authority Authorization checks required by the CA/Browser Forum Baseline Requirements. CAA records determine which Certificate Authorities are authorized to issue certificates for a domain. At the time of issuance, CERTInext evaluates the applicable CAA records for every name on the request, from the exact requested hostname up through the DNS hierarchy to the registrable domain. Issuance can proceed only where no CAA records exist anywhere in that chain, or where the governing CAA record authorizes emsign.com. example.com. CAA 0 issue "emsign.com" CAA is inherited from the nearest parent that has a CAA record. CERTInext reports your current DNS configuration only and never modifies DNS records on your behalf, so any required change is made at your DNS provider. #### Wildcard Certificates and CAA For wildcard certificates, issuewild records govern wildcard issuance when present. Where no applicable issuewild record exists, the applicable issue record is considered. For a name that is not a wildcard, issuewild is not considered at all. In practice this means a domain publishing only issue "emsign.com" is correctly authorized for wildcard issuance, and no issuewild record is required. Where you do publish issuewild records, they should authorize emsign.com as well, because their presence makes them the governing property for wildcard requests. #### When a DNS Lookup Cannot Be Completed CAA validation depends on DNS being successfully resolvable. A DNS timeout, server failure, DNSSEC validation failure, or other lookup issue can prevent certificate issuance even where DCV has already been successfully completed, and even where the domain publishes no CAA records at all. An unanswerable lookup is not treated as an absence of records. The CA/Browser Forum Baseline Requirements permit only limited circumstances where a CAA lookup failure can be treated as permission to issue, broadly where the domain’s zone is provably not DNSSEC signed and the failure is confirmed to be outside our own infrastructure. As a result, a CAA lookup that cannot be successfully completed may prevent the certificate from being issued until the required checks succeed. Domains used for publicly trusted certificate issuance should therefore remain publicly resolvable, and DNS and DNSSEC responses should resolve consistently without timeout or server errors. #### Internal and Private DNS For organizations using internal or private DNS, publicly trusted certificate issuance still requires CERTInext to successfully perform the applicable public DNS and CAA checks. Where a hostname is served only from internal DNS, this generally means either removing the public delegation for that subdomain, or maintaining a minimal public zone that can answer CAA queries for it. The address a name resolves to is not the issue. What matters is whether the CAA query for that name can be answered publicly. ### Multi-Perspective Issuance Corroboration CAA and the applicable domain validation checks are subject to Multi-Perspective Issuance Corroboration (MPIC). MPIC is a CA/Browser Forum requirement designed to protect certificate issuance against localized DNS or network manipulation. Rather than relying on a result observed from only one network location, the result is corroborated using multiple geographically and network diverse perspectives before issuance can proceed. Under the current CA/Browser Forum requirements, a Certificate Authority must use a primary perspective together with at least four remote network perspectives, and the corroborating perspectives must span at least two Regional Internet Registry service regions. This means it is not sufficient for a DNS record to resolve successfully from your local network, or from a single public DNS testing service. The required perspectives must each be able to obtain results that satisfy the corroboration requirements, and those results must agree. Where they do not, CERTInext cannot proceed until the required checks succeed. This matters most where DNS responses vary depending on location, resolver, delegation, DNSSEC configuration or other DNS infrastructure behaviour. Split horizon and geographically routed DNS are common causes of a result where some regions find your record and others do not. Two further points: • DNS propagation is your DNS provider’s responsibility. When you add or change a record it takes time to reach resolvers worldwide, typically 5 to 30 minutes and sometimes longer. CERTInext cannot push or accelerate this. • DNSSEC must be intact. If your domain uses DNSSEC, every response must carry a valid chain of trust. A broken chain, for example missing or incorrect DS or DNSKEY records at your registrar, causes responses to be refused and fails from every region. Where a subdomain is auto verified by inheritance, it reuses the parent’s successful validation and does not repeat this multi region check for the DCV step. CAA is still evaluated for every name at issuance. ### Risk Screening Certificate requests are also subject to domain and risk screening, against Google Web Risk as well as our internal domain and country risk lists. Where a request is flagged for additional review, issuance may be held while our Validation team completes the necessary checks. A risk review does not necessarily mean that the request has been rejected. In many cases it simply means additional review is required before issuance can proceed. ### DCV Inheritance #### How DCV Inheritance Works When a parent domain is validated in an account, qualifying subdomains added under that parent are auto verified by inheriting the parent’s validation, so a separate DNS record does not need to be published for each subdomain. For each inherited validation, CERTInext generates and stores the required evidence automatically. No manual action is needed from the account administrator. Whether a subdomain qualifies depends on the method used to validate the parent: • A parent validated by DNS TXT covers its subdomains automatically. • A parent validated by HTTP file validation does not propagate, because that method covers the exact hostname only, as the Baseline Requirements prescribe. • A persistent record does not extend to subdomains on its own, although it covers wildcard names where it carries policy=wildcard. Inheritance flows only from parent to subdomain. Validating a subdomain does not validate its parent. It applies across multiple levels, so a validated example.edu can cover dept.example.edu and app.dept.example.com. example.com\ └── dept.example.com\ └── app.dept.example.com Inheritance is applied when a domain is added, and again when a parent completes its own validation, at which point eligible subdomains already waiting in the account are auto verified. An inherited subdomain carries the same validity period as the parent it inherited from. It never extends beyond the parent’s own validation period. Inheritance applies within your account, and within the organization that owns the domain. A validated domain in one organization does not act as validation authority for a domain in a different organization. #### Pre-issuance Checks on Subdomains Even when inheritance is enabled, CERTInext still checks the subdomain’s own records before issuance, including its CAA records and DNSSEC assertions, to ensure there is no contradiction affecting the ability to issue. If a contradiction is found, it must be rectified before issuance can proceed. Inheritance shortens the domain control step. It does not shorten the issuance checks. #### Account-Level Setting: Subdomains on a Different Nameserver Whether coverage extends across a separate DNS delegation is an account level setting. By default, a subdomain that is delegated to a different nameserver is asked to complete its own validation. The Account Configuration page carries the setting “Auto-verify subdomains (including subdomains delegated to a different nameserver)”. When it is enabled, eligible subdomains validate automatically even with a delegation in between. The setting note reads: *“When enabled, subdomains of a parent domain validated via DNS are automatically verified even when the subdomain is delegated to a different nameserver. Parents validated via HTTP file never propagate. CAA checks are not affected.”* This setting is visible and editable only by the account’s Primary Admin (Owner). Other roles can view the resulting Verification Type for each domain but cannot change the setting. *\[Screenshot to be added: Account Configuration, the Auto-verify subdomains setting.]* ### Understanding the Verification Type Column A Verification Type column on the Domains list shows how each domain was validated. It sits alongside the existing DCV Status column, so you can see not only whether a domain is validated, but also how. • Verified Independently: the domain completed its own DCV by publishing the required record or file for that exact name. • Auto-verified (Inherited): the domain, a subdomain, was validated automatically by inheriting its parent’s validation. The parent domain is shown when you hover over the value. • Inheritance disabled: inheritance has been turned off for this domain, so it must be validated independently. The column shows the note “(inheritance disabled)”, and the domain shows Pending until its own DCV is completed. A domain that was inherited and later completes its own validation moves to Verified Independently.
Figure 5: The Domains list. DCV Status shows whether a domain is validated, and Verification Type shows how, either Verified Independently or Auto-verified (Inherited). ### Excluding a Subdomain from Inheritance (Per-Domain Opt-Out) Even when account level inheritance applies, a Primary Admin can exclude a specific subdomain so that it is validated on its own. On the View Domain page, use Disable Auto-Inheritance to opt the subdomain out. CERTInext asks for confirmation before applying the change. The confirmation explains that the subdomain will no longer be auto verified from a validated parent domain and must complete its own domain control validation. After opting out, the subdomain’s Verification Type reflects that inheritance is disabled, and its DCV Status returns to Pending until the subdomain is independently validated. The same control can be used to allow inheritance for that domain again. ### Validating a Domain Independently When a domain must be validated on its own, because inheritance is disabled for it, because there is no validated parent, or because the parent was validated by a method that does not propagate, open the domain and follow the instructions for the method you selected. For DNS TXT, create the TXT record shown under Step 1 at your DNS provider, using the Copy buttons for the Host and Value, then click Verify Now. Choose Verify later to complete the step afterwards; the DCV Status stays Pending until verification succeeds. To change the method on a domain that has not yet been validated, use Change DCV Method on the View Domain page. Changing the method issues a fresh value for you to publish. Before verifying, confirm that your record is visible from more than one vantage point. A single successful lookup from your own network does not demonstrate that the required regions will agree. ### Domain Validation Diagnostics The View Domain page includes a Domain Validation Diagnostics panel showing exactly what each region saw during the most recent attempt, together with a history of earlier attempts. Use it to troubleshoot a failing validation. The panel shows: • the validation method and the time of the attempt; • the expected value, that is, the record name and value, or the file name, content and URL; • the consensus reached across the regions queried; • the status, latency and DNSSEC state for each region, with the raw response; • a specific recommended action for the result observed, rather than a generic message; • the history of previous attempts, with attempts made against a token that has since rotated marked as such.
Figure 6: Domain Validation Diagnostics. The panel shows the expected value, the consensus reached across regions, and the status, DNSSEC state and latency observed from each region. ### Understanding Validation Status Two separate status columns appear on the Domains list. DCV Status describes domain control validation: • Pending: added but not yet validated, or awaiting independent validation after an inheritance opt out. • Validated: domain control validation is complete. • Rejected: validation did not complete. Review the method and try again. Domain Status is a separate, optional column describing the state of the domain record itself, for example whether it is active or expired. A domain can show as Validated and still be unusable for issuance if its Domain Status is not active. The Diagnostics panel uses its own per attempt wording, Verified, Failed, Partial and Pending, which describes a single validation attempt rather than the domain overall. ### Validation Expiry and Renewal A completed validation is valid for a limited period, and the domain’s expiry date is shown in the Domains list. The CA/Browser Forum is progressively reducing the period for which a completed validation may be reused, so this period shortens over time. Issued certificates are not affected when a validation expires. New orders, renewals and reissues for that name go pending until the domain is validated again. Use the expiring domains filter on the Domains list to find domains approaching expiry, and revalidate before the validation lapses so that orders and renewals are not blocked. Renewing a domain starts a fresh validation cycle and issues a new value for you to publish, except for the persistent method, where the record already in your DNS is simply checked again. Because a renewal issues a fresh value, any automation that caches a validation token or file name must read the current value from the portal or the API rather than republishing a stored one. ### Checks Performed Before Issuance When an order reaches issuance, CERTInext checks every name on the request. All of the following must be satisfied: • the name is eligible for public issuance; • the domain was validated by a method that may authorize the requested name, which is why a wildcard cannot rely on HTTP file validation; • the domain record is active and its validation has not expired; • domain control validation is complete; • CAA authorizes emsign.com for every name, evaluated live at issuance; • risk screening has completed without a flag requiring review; • the selected certificate product supports the requested names. A failed check holds the order rather than being treated as a pass. This is why an order can hold a domain that shows as Validated and still remain pending. ### ACME Orders and Product Profiles CERTInext supports certificate issuance through ACME for validated domains, using External Account Binding. #### Challenge Types • dns-01: your client publishes a TXT record at \_acme-challenge.\. It works where there is no public web server and it supports wildcard names. A successful dns-01 validation covers subdomains in the same way as a DNS TXT validation made in the portal. • http-01: your client places a token file under /.well-known/acme-challenge/ on the exact host. It requires the host to be reachable from the internet, and it cannot validate a wildcard name. ACME challenges are subject to the same CAA checks and the same multi region corroboration as validations performed in the portal. #### Product Profiles ACME issuance is enforced against the certificate product associated with the ACME and EAB credential. A single domain product accepts one domain per order, a wildcard product accepts wildcard names including a wildcard with its base domain, and any order with multiple different names requires a multi domain or UCC product. An ACME credential associated with a standard single domain product cannot be used for an order requiring a multi domain or UCC product. Similarly, wildcard requests must use a product profile that supports wildcard issuance. Orders outside the mapped product are refused, with messages such as *“This ACME key is mapped to a certificate product that does not support additional SAN identifiers”*. Where an order requires a different product, use an ACME credential that is bound to the product the order needs. #### Other Requirements An ACME request succeeds only when the credential belongs to a group that contains the requested domain, the user has permission to use that group, the product supports the requested names, and, for OV certificates, Organization Validation is complete. Some ACME clients cache account registrations locally. If new credentials are generated, or group assignments change, delete the cached account registration and create a new account with the updated credentials before retrying. ### Wildcard and Multi-Domain Certificates • A wildcard name must be validated by a DNS based method. HTTP file validation cannot validate a wildcard. • A multi domain or SAN certificate requires every listed name to be validated, either independently or by inheritance. • The selected certificate product must support the requested names. A product mismatch causes the request to be rejected even where validation has completed successfully for every name. ### Troubleshooting a Pending Order If you have a pending order, please confirm the following. 1\. The requested domains are publicly resolvable. 2\. Any applicable CAA records permit issuance by emsign.com. 3\. DNS and DNSSEC responses are resolving consistently without timeout or server errors. 4\. The required DCV is complete and the applicable validation records remain correctly published. For the persistent method, the record must still be present in your DNS. 5\. For ACME requests, the requested certificate type and names are supported by the product associated with the ACME credential. 6\. The domain’s validation has not expired and the domain record is active. Common results and what they mean: | What you see | What it means | What to do | | ----------------------------------------------- | ----------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | No record found at the expected name | The record has not been published, or has not propagated | Confirm the host, publish the record, and retry after propagation | | Record value mismatch | A record exists but does not match the current value | Republish the value exactly as shown, with the same upper case and no extra spaces | | DNS inconsistent across regions | Some regions found the record and others did not | Usually propagation, split horizon or geographically routed DNS. Wait and retry. Publishing at \_emsigndcv gives a more consistent result | | Resolver could not resolve | A region received a DNS failure | Usually transient. If only one region is affected while others succeed, retry shortly | | DNSSEC broken | The chain of trust does not validate | Correct the DS or DNSKEY records with your registrar | | File not found or content mismatch | The token file is not reachable at the required path, or does not match | Confirm the path and file name exactly, that no authentication is required, and that no firewall rule blocks it | | CAA forbids issuance | A CAA record does not authorize emSign | Remove the record or add an issue "emsign.com" entry | | Domain shows Validated but the order is pending | An issuance check other than DCV has not completed | Review the checks listed above | Please keep in mind that successful DCV alone does not guarantee that an order is ready for issuance. CAA, corroboration across regions, risk screening, product profile requirements and other applicable issuance checks must also complete successfully. If you have reviewed the above and still believe your order should be eligible for issuance, please contact CERTInext Support with the order number, the affected domains, and any troubleshooting you have already completed. The Domain Validation Diagnostics panel carries the per region evidence that allows a case to be resolved quickly. ### Summary • A domain must complete Domain Control Validation before certificates can be issued against it. CERTInext supports DNS TXT, HTTP / HTTPS file and persistent DNS TXT validation, together with the ACME dns-01 and http-01 challenge types. • Validation tokens for the DNS TXT and HTTP file methods are valid for 48 hours, and the value must be published exactly as shown in the portal. • Add domains from Certificates, then the Domains tab, then Create Domain. Subdomains of a validated parent are auto verified on save. • DCV inheritance lets subdomains inherit a validated parent’s DCV, with the evidence stored automatically. Parents validated by DNS TXT cover their subdomains; parents validated by HTTP file do not; a persistent record does not extend to subdomains on its own. • Whether coverage extends across a separate DNS delegation is an account level setting, controlled by the Primary Admin. • The Verification Type column shows whether each domain was Verified Independently or Auto-verified (Inherited), and a Primary Admin can exclude a single subdomain with Disable Auto-Inheritance. • CAA is evaluated for every name at issuance, and is corroborated across multiple regions. A lookup that cannot be completed is not treated as an absence of records. • Successful DCV does not by itself authorize issuance. CAA, corroboration, risk screening, product profile and validation expiry all apply before a certificate is issued.