Use /.well-known/ when a service must fetch a file from the website, and use DNS records when ownership must be proven at the domain level. The /.well-known/ path is a standardized place for site-wide metadata, defined by the IETF in RFC 8615 [source: IETF]. DNS records fit better when the website is down, hosted elsewhere, or controlled by a different team than the domain.
TLDR: /.well-known/ is usually faster for web-based checks, while DNS records are stronger for domain-wide control. For example, a SaaS platform may ask a customer to upload /.well-known/app-verification.txt, while Google Workspace may ask for a TXT record at the root domain. In a 50-domain rollout, a team might finish file-based checks in 30 minutes if web hosting access is ready, but DNS checks can take 1 to 24 hours because of TTLs and provider delays. The best choice depends on who controls the web server, DNS zone, CDN, and deployment pipeline.
What /.well-known/ Does
The /.well-known/ directory is not a normal content folder. It is a predictable URL location where software can find security files, app links, ownership tokens, and service policies. A common example is:
https://example.com/.well-known/security.txthttps://example.com/.well-known/acme-challenge/tokenhttps://example.com/.well-known/assetlinks.jsonhttps://example.com/.well-known/apple-app-site-association
These files help external systems verify that the website operator controls that host. Certificate automation, Android app links, iOS universal links, and security contact discovery often depend on this location.
The biggest strength is direct proof. If a service can fetch a token from https://example.com/.well-known/..., it knows the web host responds for that exact name. That is useful for subdomains, staging sites, customer portals, and product-specific domains.
The catch is that web routing can turn a simple file into a 40-minute headache. CDNs cache old files. Frameworks block hidden paths. Reverse proxies strip unknown routes. Some static hosts need special config just to serve a filename without an extension. It drives many admins crazy that a five-line text file can fail because a redirect added three seconds to a validation request.
What DNS Records Do
DNS verification uses records such as TXT, CNAME, CAA, MX, SPF, DKIM, and DMARC. For ownership checks, the most common method is a TXT record with a token such as:
example.com TXT "service-verification=abc123"_service.example.com TXT "abc123"verify.example.com CNAME verify.vendor.com
DNS proves control of the domain zone, not only the web server. That makes it useful for email security, certificate rules, SaaS onboarding, search console tools, and domains that do not host a website.
DNS also works when the website is offline. A parked domain can still be verified. A domain that points to a third-party storefront can still publish a TXT record. That separation is useful in larger companies where the marketing team controls the CMS, but IT owns the DNS provider.
Security Differences
/.well-known/ verification is host-specific. It proves that the verifier can reach a file on a website. This is useful, but it can be fooled by mistakes in hosting. If an old subdomain points to an abandoned cloud bucket, an attacker may claim it and serve a valid token. That turns poor asset cleanup into a real security risk.
DNS verification is domain-specific. It proves access to the authoritative DNS zone. This is harder to fake, but risk shifts to registrar accounts, DNS dashboards, API keys, and weak admin permissions. A compromised DNS account can redirect traffic, approve certificates, and break email authentication.
For certificate security, DNS has a special advantage: CAA records can restrict which certificate authorities may issue certificates for a domain. For email security, DNS is also the main control plane because SPF, DKIM, and DMARC live there.
When /.well-known/ Is the Better Choice
A website team should prefer /.well-known/ when validation must match the live web host. It is also a clean choice when deployment is automated and the site has stable routing.
Good cases include:
- ACME HTTP validation for certificates on a specific host.
- Mobile app association with Android or iOS.
- Security contact publishing through
security.txt. - SaaS site verification where web admins do not have DNS access.
- Per-subdomain validation for customer-facing services.
This method is simple when one team owns hosting, CDN rules, and deployment. It is less pleasant when every release needs a developer ticket. Honestly, it feels like overkill when a non-technical admin must wait two days for someone to upload one token file.
When DNS Records Are the Better Choice
DNS records beat /.well-known/ when the proof must cover the domain as a whole. They also work better for services that do not depend on HTTP.
Good cases include:
- Email authentication with SPF, DKIM, and DMARC.
- Domain ownership for analytics, search, and SaaS platforms.
- Certificate authority control with CAA records.
- Wildcard certificate validation, where HTTP validation may not apply.
- Domains without websites, such as redirect-only or email-only domains.
DNS is also safer when a website is managed by an outside agency. The company can prove domain control without giving that agency registrar access. That split reduces damage if the CMS account is compromised.
Common Failure Points
Both methods fail in boring but painful ways.
- Redirects: A verifier may reject a token if HTTP redirects behave oddly.
- CDN caching: Old
/.well-known/files may stay visible after updates. - Wrong root: Files may land in the app folder instead of the public web root.
- DNS TTLs: TXT changes may not appear everywhere right away.
- Split DNS: Internal and public DNS can show different answers.
- Conflicting records: Multiple TXT records can confuse poorly built tools.
Best Practice: Use Both, but for Different Jobs
Mature teams rarely pick one method forever. They use each where it fits.
- Use
/.well-known/for web host checks, app links, ACME HTTP validation, and public security metadata. - Use DNS for domain ownership, email policy, wildcard certificates, and certificate authority restrictions.
- Automate both through CI pipelines, DNS APIs, and change logs.
- Limit access so web teams cannot alter registrar settings and DNS admins cannot blindly publish app files.
- Monitor drift because old verification tokens become clutter and may confuse audits.
A practical rule works well: if the service asks, “Can this website serve my file?” then /.well-known/ is right. If it asks, “Who controls this domain?” then DNS is right.
FAQ
Is /.well-known/ more secure than DNS?
No. It is secure for host-level checks, but DNS is stronger for domain-level proof. Each method protects a different layer.
Can a website use both methods at the same time?
Yes. Many organizations use /.well-known/ for certificates and app links, while DNS handles email security and domain verification.
Why does DNS verification take longer?
DNS changes may wait on TTL values, resolver caches, and provider update speed. Some changes appear in minutes. Others take hours.
Why does /.well-known/ verification fail even when the file exists?
Common causes include CDN cache, redirects, blocked hidden paths, wrong MIME types, firewall rules, and files placed in the wrong directory.
Which method should a SaaS product offer?
It should offer both. Smaller customers may prefer file upload. Larger customers often prefer DNS because IT controls domain records.
Should old verification files and TXT records be removed?
Yes, unless a service still needs them. Old tokens create clutter and may confuse security reviews. A quarterly cleanup is a sensible habit.