What is Domain Validation?

Domain validation is a trust decision, not a formality

Every HTTPS padlock in your browser represents a decision. Before a Certificate Authority (CA) issued the certificate behind that padlock, it had to decide whether to trust the request and what the certificate would be allowed to claim. That decision is called validation, and it is the quiet mechanism that keeps online trust from being a free-for-all.

Validation matters because the cryptographic guarantees between the client and the server alone are not enough. As one way to think about it, SSL/TLS certificates do two jobs: the cryptography ensures that the communication is communication was established with the certificate owner and the traffic cannot be read or tampered with by eavesdroppers; on the other hand validation ensures the two communicating parties are actually who they say they are in the certificate. The public key infrastructure (PKI) that governs certificates works like a digital Department of Motor Vehicles: it vets and assigns certificates to identities that request it; and a certificate itself is a bit like a driver’s license, carrying information about its owner and an expiration date.

Domain Validation (DV) is the most common and fastest of these trust decisions. This guide explains what DV actually proves, how it compares to stricter validation levels, who writes the rules, how CAs perform validation and automate it, and why getting validation right is a foundational security decision rather than a one-time setup step. If you want the broader picture of certificate structure first, it helps to understand what is an SSL/TLS certificate.

What domain validation actually proves

Here is the answer-first definition: domain validation confirms that the applicant controls the domain named in the certificate, and nothing more. A CA issuing a DV certificate verifies that the party requesting it owns or controls the domain, typically through a lightweight check. No organization details are verified or displayed.

Put another way, DV certificates verify the identity of the server, while higher-assurance certificates go further and verify the legal organizational identity behind the site. It is important to be precise about the scope. A DV certificate proves that your connection reaches the domain you requested. It says nothing about the legal identity of the company operating the site, and nothing about whether that company is trustworthy.

The cryptography itself is the same. DV certificates allow for the same cryptographic algorithms and protocols to be followed exactly like any other certificate. The only thing that changes across validation levels is the assurance, meaning the depth of identity checking the CA performs and the information it records in the certificate.

What domain validation does not prove (and why that matters)

Because DV vets only domain control and never the business behind it, a valid DV certificate is not a seal of legitimacy. This gap has real consequences. Criminals can buy rather cheap DV certificates, sometimes on the dark market, to make phishing and impersonation sites look legitimate and lure unsuspecting visitors into handing over financial or personal information. Poor certificate management makes the problem worse, because a compromised or stolen DV certificate can be hard to distinguish from a legitimate one.

The takeaway is not that DV is bad. It is that the padlock and a DV certificate confirm a private, encrypted connection to a specific domain, not that the domain owner deserves your trust. That distinction sets up both the comparison that follows and the section on why validation matters.

How domain validation compares to higher validation levels

Seen from the DV point of view, the three validation levels differ in how strictly the CA checks identity, what appears in the certificate, and how long issuance takes. The cryptography is invariant across all three.

Validation level	What the CA verifies	Typical time to issue	Best-fit use case
Domain Validated (DV)	Control of the domain only; no organization details	Minutes	Personal sites, blogs, internal or non-commercial services
Organization Validated (OV)	Domain control plus the organization’s legal existence, shown in the certificate	Longer, involves CA contact	Commercial sites and applications that collect user data
Extended Validation (EV)	An in-depth review of the organization’s legal, physical, and operational identity, initiated by the organization itself	Longest, most rigorous vetting	High-profile sites often targeted for phishing, such as banks and major retailers

Domain validation is the most basic and fastest validation type, usually issued within minutes, which is a large part of why it is the most common certificate on the web. Organization validation adds a check of the organization’s legal existence and records those details in the certificate. Extended validation, governed by the CA/Browser Forum’s EV Guidelines that Keyfactor notes were established in 2007, adds the most demanding review and can trigger enhanced identity indicators in some browsers. Organization validation and extended validation are treated here only as reference points, since they are covered in depth elsewhere.

To check which validation tier corresponds to the certificate, you can open a terminal and run

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -text

Find the X509v3 Certificate Policies extension in the output. Domain Validation is signaled by the reserved identifier 2.23.140.1.2.1. A different value in that field means the certificate was issued under a different tier, and you can read more about what separates them on our dedicated page on certificate validation.

When domain validation is enough (and when it is not)

The practical decision comes down to what your site does. Because DV verifies no organization details, it is better suited for personal or internal sites, blogs, and non-commercial services where speed and simplicity matter more than displayed identity.

Commercial and public-facing sites are a different story. Sites that process logins, take payments, or handle regulated data should consider OV or EV, which are recommended for commercial websites and applications that collect user data. The higher levels give visitors a verified organizational identity to trust, which matters most exactly where attackers concentrate their phishing efforts. If your site is a hobby project or an internal tool, DV is usually the right call. If it collects sensitive data, treat DV as a floor, not a ceiling.

Who governs validation and what serves as the source of truth

Validation is not something each CA invents on its own. The rules come from the CA/Browser Forum, a voluntary body of Certificate Authorities and suppliers of browsers and other software that consumes certificates. The Forum publishes the TLS Baseline Requirements, which define the permitted methods a CA must use to validate domain control, and CAs are expected to follow them.

To confirm control, a CA consults external sources of truth rather than taking an applicant’s word for it. WHOIS, and its successor protocol RDAP, identify the registered contact for a domain. DNS provides authoritative records that only someone with control of the domain’s zone can change. And underneath it all sits the root CA, which serves as the trusted source of integrity for the entire chain: your browser trusts the certificate because it chains up to a root it already trusts. This layered arrangement is why control of a domain, proven against records the applicant cannot easily forge, is enough to anchor a DV certificate.

The framework is actively enforced and actively tightening. The longest certificate lifetime allowed today is 200 days, but the CA/Browser Forum has passed a ballot to shorten maximum lifetimes dramatically, going down to 100 days by 2027, and just 47 days by 2029. Shorter lifespans mean validation and renewal happen far more often, which is the single biggest reason the industry is moving from manual checks to automation.

How domain validation is performed: the validation methods

When a CA needs to confirm that an applicant controls a domain, it relies on a small set of standardized methods defined in the Baseline Requirements. Each one asks the applicant to demonstrate control in a way that would be difficult to fake, usually by proving they can receive a message at, or place a specific value on, infrastructure only the domain owner controls. The three methods below are the ones most site operators encounter.

Email to a domain contact

In this method, the CA sends a message containing a unique random value to an address associated with the domain, and control is confirmed when the recipient returns that value. Historically the CA could look up the registered contact in the WHOIS record, but the widely used variant today sends email to a constructed address: a standard mailbox such as admin@, administrator@, webmaster@, hostmaster@, or postmaster@ at the domain being validated. The applicant retrieves the random value and responds to prove control. The random value is single-use for that request and, under the Baseline Requirements, remains valid for no more than 30 days. The logic is simple: only someone who controls the domain’s mail can receive and return the code.

DNS record change

Here the applicant proves authority over the domain’s DNS zone by publishing a value the CA supplies. The CA asks for a unique random value or request token to appear in a DNS record, typically a TXT record, and sometimes a CNAME or CAA record, at the authorization domain name, often under an underscore-prefixed label. Once the CA queries DNS and sees the expected value, control is confirmed. Because only the party who manages a domain’s DNS can add records to its zone, a successful DNS check is strong evidence of control, and this method is well suited to automation and to validating wildcard domains.

HTTP file (verification file) method

The file-based method has the applicant place a CA-supplied token where only the site’s operator could put it. The CA provides a request token or random value, and the applicant saves it in a file on the web server under the /.well-known/pki-validation/ directory. The CA then fetches that file over HTTP or HTTPS on an authorized port and must receive a successful (2xx) response containing the expected value. Modern automated variants of this approach, including the ACME HTTP challenge defined in RFC 8555, work the same way at their core: prove control by serving a specific value from the web server itself. As with the other methods, the token is time-limited to no more than 30 days.

Automating domain validation with ACME

Performing these checks by hand is manageable when a certificate lasts a year. It becomes impractical when certificates last weeks. That is where the Automated Certificate Management Environment (ACME) comes in. ACME is a protocol that lets a client and a CA carry out domain validation, issuance, renewal, and revocation programmatically, with no human clicking a verification link.

ACME facilitates the automatic issuance, renewal, and revocation of certificates by streamlining the interactions between a web server and the CA. It was originally developed for Let’s Encrypt and is now widely supported across CAs and PKI vendors. Its rise is directly tied to the shrinking lifespans described earlier: as maximum lifetimes head toward 47 days by 2029, manual validation and renewal simply cannot keep pace, and automation becomes the only reliable way to avoid lapses. ACME is one of several automated enrollment protocols like ACME, SCEP, and EST that make certificate management scalable.

Why certificate validation matters

Validation underpins the trust decision your browser makes on every secure connection. By confirming that a certificate genuinely belongs to the domain you are visiting, validation is what prevents man-in-the-middle attacks, in which an attacker intercepts traffic between you and a site to steal credentials or data. Without trustworthy validation, an attacker could stand up a fake site and quietly proxy your banking session.

Validation is also the line attackers try to exploit. Because DV certificates are cheap and fast, criminals use them to dress up phishing sites, which is precisely why identity assurance beyond domain control matters for sites handling sensitive transactions. And validation supports compliance: regulations and standards such as PCI DSS, HIPAA, and GDPR require organizations to protect financial, medical, and personal data, and properly validated, well-managed certificates are part of meeting those obligations.

Finally, validation is no longer a one-time event. As lifespans shrink, reliable validation and renewal become ongoing operational necessities. A missed renewal can take a site or application offline, erode user trust, and create a security gap, so dependable validation is now a continuous requirement rather than a box you check at launch.

How Keyfactor can help

At enterprise scale, the challenge is rarely validating a single domain. It is validating, issuing, and renewing thousands of certificates consistently as lifespans keep shrinking. Keyfactor lets you discover, manage, and automate every certificate across your enterprise, shifting teams from reactive firefighting to proactive visibility and control.

That means automated discovery so you know exactly how many certificates you have and when each expires, automated issuance and renewal through standard protocols including ACME, and consistent validation and policy enforcement across multiple CAs. Keyfactor AgileSec enables discovery and creates an inventory of cryptographic assets, including certificates, throughout the enterprise. Keyfactor Command focuses on certificate lifecycle automation and outage prevention, while EJBCA supports modern PKI issuance at scale. Together they help organizations stay ahead of the move toward 47-day certificates without the manual overhead, and follow certificate lifecycle management best practices as a matter of routine rather than heroics.