Overview
Assign a primary owner and backup for your registrar, DNS and certificate renewal. Enable supported account protections, automate certificate renewal and deployment, and monitor the certificate visitors actually receive. Publish CAA for your intended issuers after checking renewal requirements. These steps protect continuity for websites, email and connected services. Public observations can confirm delivered records and certificate dates; registrar account protection and recovery readiness need an authorized internal review.
Start with accountable owners rather than a list of technical settings. Record the registrar, DNS hosting provider, website platform and certificate renewal service in an internal inventory. Identify a primary owner and a backup contact. Keep recovery details and account identifiers out of public reports. An external review can describe an observed certificate or DNS record without exposing the private information required to administer it.
Map public DNS to the intended service inventory
DNS translates names into service configuration. A and AAAA records identify IPv4 and IPv6 destinations; aliases can delegate name resolution to provider-managed infrastructure. MX records identify inbound email routing. TXT records serve many purposes, including email authentication. A useful review asks whether each published record still has an intended service owner, rather than assuming every unfamiliar provider name is suspicious.
Apex and www can resolve differently or terminate at different edges. A website that works on one name may fail on another because of an old DNS destination, missing certificate or redirect configuration. Review names that customers actually use. Do not infer ownership of a whole provider address range from one DNS answer, or extend an external review to unrelated systems merely because they share hosting.
Before moving DNS, export the intended records and confirm the destination serves valid HTTPS for example.com and www.example.com. Lower TTLs ahead of the change and wait out the previous TTL, then update one service at a time. Verify both IPv4 and IPv6 where published, mail routing and HTTPS redirects before retiring the old destination. Keep the old service available through the cache transition and retain rollback records. Resolver caches make changes gradual; one successful request does not establish worldwide consistency.
Use CAA as a deliberate certificate issuance policy
Certification Authority Authorization, defined in RFC 8659, lets a domain publish which certificate authorities are authorized to issue under its policy. The issue property concerns ordinary issuance; issuewild can separately control wildcard issuance. Certification authorities evaluate applicable records under the specification’s lookup and inheritance rules. CAA does not revoke an existing certificate or replace control of the registrar and DNS accounts.
Publish CAA records authorizing your actual certificate issuers, plus an iodef contact for issuance-policy incident reports. The example authorizes Let’s Encrypt for example.com and names a role mailbox. Confirm your platform uses that issuer before deploying it. Include every required issuer, including managed-platform backup paths; add issuewild if wildcard policy needs separate treatment. iodef supplies a reporting destination and does not guarantee that anyone will send reports or prevent unauthorized issuance.
Stage CAA changes around a renewal test. First ask your certificate service which issuer identifiers and validation paths it needs. Add the matching authorization records, allow caches to expire, then verify an authorized test issuance or renewal through the provider. Only narrow the issuer list after confirming every service can renew. Keep the prior records ready for rollback. No CAA record is optional-policy context rather than proof of a defect; a restrictive but incorrect policy can block legitimate renewal.
CAA for example.com when Let’s Encrypt is the intended issuer:
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:[email protected]"
Use a monitored role mailbox. Replace or supplement the issuer to match your certificate service before publishing.Treat certificate names and expiry as operational evidence
The certificate served during a trusted HTTPS connection is evidence about that connection. Review its hostname coverage, accepted chain and expiry alongside the observation time. A wildcard for *.example.com does not cover example.com or nested labels such as shop.eu.example.com. Ensure certificates cover redirecting HTTPS hostnames because the browser must authenticate the source before receiving its redirect.
Automate certificate issuance, renewal and deployment using your hosting platform or an ACME client. Publicly trusted certificates are moving to shorter lifetimes under the CA/Browser Forum schedule, making manual renewal increasingly fragile. Monitor the certificate actually served, not only the automation job. Route expiry and renewal-failure alerts to a primary owner and backup. Test renewal through the provider before relying on it, verify the new certificate at the edge and document recovery. A short remaining lifetime alone does not prove automation is broken.
Certificate-transparency logs can help a separately agreed review discover public certificate names. Historical entries do not demonstrate that a hostname is currently active, owned by the same operator or reachable. Wildcard entries do not enumerate every possible subordinate name. Treat names from logs as inventory leads and validate current ownership and scope before contacting any additional host.
What to check
Maintain an internal register of domain renewal dates, registrar access owners, DNS change procedures and certificate automation owners. Use the registrar’s supported account protections and recovery process, and verify those settings through authorized account review. A public website check cannot inspect them. Keep the public remediation pack focused on required actions and responsible roles, with private administrative details stored appropriately.
For DNS, compare the intended service inventory with published records and investigate retired provider dependencies. Confirm that each name still belongs to the business and is needed. A suspected abandoned service needs provider-specific evidence before a stronger conclusion is justified. Do not attempt to claim a service, register a lookalike or test an account as part of a passive public review.
For certificates, verify the hostname set and delivered expiry, then ask for evidence that renewal is monitored. For CAA, confirm intended issuers and inheritance before narrowing policy. For email, coordinate with the mail administrator rather than treating all TXT records as website settings. Plan changes in an agreed window and verify each affected service after the public records have updated.
Common mistakes: interpreting optional policy as a vulnerability
The absence of CAA is not proof that unauthorized issuance occurred. The presence of CAA is not proof that issuance is perfectly controlled. Likewise, a certificate in a public log is not proof of an active website, and a hostname pointing to shared hosting does not make neighboring tenants part of the business. Separate observed configuration from ownership inference and incident claims.
Do not let a public checklist substitute for domain account governance. A website can have a valid certificate while its registrar recovery contact is obsolete. Those private operational risks require authorized internal evidence. Conversely, avoid publishing contact addresses, account names or recovery details in the external report. The goal is to make the work actionable without creating a directory of sensitive administration information.
How the free Meo audit checks this
Meo validates public DNS destinations as part of keeping ordinary requests within safe public scope. This destination check is contextual and does not contribute to the score. The instant review starts at the confirmed apex root on ports 80 and 443. Exact www is permitted through a redirect or HTTPS fallback when no apex HTTPS page was accepted and budget remains; both hosts are not necessarily sampled. It does not enumerate subdomains, inspect registrar settings or use certificate-transparency logs to expand the target list.
CAA is read at the registered domain, with record structure checked but complete issuance semantics and inheritance left unvalidated. An empty CAA answer is accepted optional-policy context, not attention solely for absence. Certificate expiry comes only from an accepted authenticated TLS connection; within 30 days prompts renewal-owner review. Failed authentication does not supply accepted certificate dates. These two observations contribute to domain-and-certificate grading with their stated limits.
Frequently asked questions
Is no CAA record a vulnerability?
Absence alone does not establish a vulnerability or unauthorized issuance. Review business requirements, applicable inheritance and the actual certificate service before deciding whether a CAA policy would improve issuance control.
Does CAA cancel existing certificates?
No. CAA expresses issuance authorization under its processing rules. It does not itself revoke certificates already issued. Suspected issuance problems require review through the responsible authority and the organization’s incident process.
Does a wildcard certificate cover the apex?
A wildcard such as *.example.com does not by itself cover example.com. Check the actual certificate name set and include the apex explicitly when it needs HTTPS, along with any relevant redirecting names.
Does a transparency-log name prove a live subdomain?
No. Logs contain certificate history and can include inactive, old or wildcard names. They support inventory discovery, but current ownership, service availability and review authorization need separate confirmation.
What should I do about a certificate expiring soon?
Ask the hosting owner to confirm automatic renewal, monitoring and the served certificate after renewal. A short lifetime can be normal. Preserve the observation date and avoid declaring renewal broken without operational evidence.
Sources and review dates
Content reviewed against the instant audit’s implemented checks and the references below. This is a content review date, not a new revision date for these standards. Confirm provider-specific settings with the responsible administrator before deployment.