How to Monitor Client SSL Certificates Without DNS Access
The most common objection agencies raise when evaluating SSL monitoring tools is a practical one: "We do not manage DNS for most of our clients."
It is a reasonable concern. Many marketing agencies build and manage sites for clients who retain control of their own domain registrar and DNS. The agency handles the hosting, the CMS, and the code — but if a DNS record needs to change, the client's IT team or the original registrar contact is the one who makes it.
When a monitoring tool requires you to add a DNS TXT record to verify a domain, that workflow breaks immediately. You are asking your agency team to coordinate a change on infrastructure you do not control, for the purpose of setting up a monitoring tool, before you have even demonstrated that the tool is worth using. The trial dies in the setup process.
The good news: DNS ownership is not the only way to establish that you are authorized to monitor a domain. The HTTP file verification method lets you prove authorization using the hosting access you already have.
Two Ways to Verify a Domain for Monitoring
When you add a client domain to Merlonix, you choose a verification method. Both prove the same thing — that you have a legitimate relationship with that domain — using different infrastructure paths.
Method 1: DNS TXT record
Add a TXT record to the domain's DNS zone:
_merlonix-verify.clientdomain.com TXT merlonix-token-abc123
Merlonix resolves the record and confirms the token. Verification completes in under a minute once the record propagates.
When to use this: You manage DNS for the client, or the client can make DNS changes quickly and without friction. The DNS method has no dependency on the hosting environment or web server configuration.
Method 2: HTTP file (no DNS access needed)
Upload a small text file to the client's web root:
/.well-known/merlonix-abc123.txt
The file contains nothing but the verification token. Merlonix fetches the URL over HTTPS, reads the token, and confirms it matches. Verification completes immediately.
When to use this: You have FTP, SFTP, or CMS-level file access to the client's hosting environment but not DNS access. This covers most agency situations where the client controls their own registrar.
The HTTP File Method: Step by Step
The HTTP file method works on any web hosting environment where you can place files in the document root. This includes shared hosting, managed WordPress hosting (via FTP, SFTP, or the cPanel file manager), VPS environments, and most CMS platforms via a file upload or plugin.
Step 1: Add the domain in Merlonix and select HTTP file verification.
When you create the asset in your Merlonix dashboard, choose "HTTP file" as the verification method. The dashboard generates a unique token for this domain.
Step 2: Create the .well-known directory if it does not exist.
The .well-known directory is a standard location for domain ownership
files, defined in RFC 5785.
Most modern hosting setups already have it. If yours does not:
On shared hosting via cPanel: use the File Manager to create a folder named
.well-known in the public_html directory. Note the leading dot — it is
significant.
On a VPS or dedicated server: mkdir -p /var/www/clientdomain.com/public/.well-known
On a WordPress site via SFTP: create the directory at the web root level,
outside of the wp-content folder.
Step 3: Upload the verification file.
Create a plain text file named merlonix-[token].txt containing only your
token string. Upload it to .well-known/. No HTML, no extra whitespace, just
the token.
Step 4: Confirm the URL resolves before triggering verification.
Before clicking Verify in the dashboard, open a browser and navigate to
https://clientdomain.com/.well-known/merlonix-[token].txt. You should see
the token string displayed as plain text. If the URL returns 404, check that
the file was placed in the correct directory.
Step 5: Trigger verification in Merlonix.
Click Verify in the dashboard. Merlonix fetches the URL, reads the token, and confirms it matches. If it does, the domain is verified and monitoring begins immediately.
Common Issues with HTTP File Verification
The URL returns 404.
Check that the .well-known directory is inside the web root (the directory
that serves the public website), not alongside it. On shared hosting, this is
usually public_html or htdocs. On a VPS, it depends on your server
configuration — check your virtual host DocumentRoot directive.
The URL returns 403 (forbidden).
Some server configurations block access to dotfiles and dot-directories by
default. On Apache, check for Options -Indexes or <Directory .well-known>
directives that might be restricting access. On Nginx, look for a location
block denying .well-known. The fix is to explicitly allow the directory:
location /.well-known/ {
allow all;
}
On WordPress with a security plugin (Wordfence, Sucuri, iThemes Security),
check whether the plugin has a rule blocking .well-known access. Most
security plugins have an explicit exception for /.well-known/acme-challenge/
for Let's Encrypt; you may need to add a similar exception for the Merlonix
verification path.
The client's CDN serves a cached 404.
If the domain sits behind Cloudflare or another CDN, the CDN may be caching
the 404 response from before you uploaded the file. Purge the cache for the
specific URL in the CDN dashboard, then retry. With Cloudflare, this is under
Caching → Configuration → Purge cache → Custom URLs.
The URL resolves over HTTP but not HTTPS.
Merlonix verifies over HTTPS, because that is the same context in which
SSL certificates are validated. If the client's site does not redirect HTTP to
HTTPS (or if the certificate is already expired), the HTTPS fetch will fail.
In this case, fix the underlying SSL issue first, then complete verification.
After Verification: What Gets Monitored
Once a domain is verified — by either method — Merlonix begins monitoring three things:
SSL certificate: Merlonix opens a TLS connection to the domain and reads the leaf certificate directly. It records the expiry date, the issuer, the chain, the key algorithm, and the Subject Alternative Names. It alerts at 30 days, 14 days, and 7 days before expiry, and immediately if the certificate lapses or the chain breaks unexpectedly.
DNS records: Merlonix stores a snapshot of your expected DNS configuration when you add the domain, then diffs that snapshot against live resolution from three independent resolvers on every check. A change to any record — A, AAAA, CNAME, MX, TXT, NS — triggers an alert.
Upstream vendor status: Independently of the per-domain checks, Merlonix polls 11 upstream vendor status pages (Stripe, Cloudflare, Shopify, Fastly, Vercel, SendGrid, and more) on a shared schedule. Any vendor degradation appears in your dashboard, tagged to the domains that depend on that vendor.
The verification step happens once. After that, monitoring runs automatically on every check cycle.
Which Method Is Right for Your Agency?
The short answer: use whichever one you can complete faster.
If you manage DNS for a client — either directly or with quick access to someone who does — the DNS TXT method is slightly more portable. It does not depend on the hosting environment, works regardless of web server configuration, and does not require access to the web root.
If you handle hosting but not DNS, use the HTTP file method. It works for almost every hosting setup where you can place files, and it takes under five minutes once you know where the web root is.
If you are mid-trial and trying to get to first monitoring signal quickly, use whatever you can complete right now. Both methods provide the same monitoring coverage once verification is done.