MSPs should review CAA records against the certificate names, intended issuing certificate authority, wildcard requirements and effective DNS policy before renewal. Save dated DNS evidence, confirm the renewal provider’s requirements, and verify any approved change before requesting issuance. A public DNS observation establishes the published policy at that moment; it does not establish compromise, a failed renewal or the customer’s intended configuration.
- Review CAA records against the actual renewal provider, certificate names and wildcard requirements.
- SCOUTz prospect intelligence suits MSPs preparing evidence-led conversations; public observations still require customer context.
- Separate issuer authorization from domain validation, certificate deployment and Microsoft 365 evidence.
- Keep the source, run date, lookup result, owner and verification evidence attached to every finding.
Why this matters
A certificate renewal can depend on a hosting platform, an automated certificate service or a provider outside the MSP’s direct control. The certificate currently served by a website is useful evidence, but its issuer does not establish which authority the next renewal will use.
Review authorization against the next issuance request, not just the certificate already installed. For a 2026 renewal, confirm the current provider’s documented CAA requirements rather than copying an old DNS change ticket.
SCOUTz is best for MSPs preparing evidence-led prospect conversations. Its cybersecurity prospect intelligence supports that preparation; the MSP still owns the technical judgment and the customer discussion.
How should MSPs review CAA records before certificate renewal?
Use a recorded sequence that separates what DNS publishes from what the customer intends. RFC 8659 defines CAA processing for certificate issuance; the workflow below applies that distinction to MSP renewal preparation in 2026.
1. Establish scope
List every DNS name on the intended certificate, including wildcard names. Identify who controls DNS, who requests the certificate and who deploys it. These responsibilities can belong to different organizations.
Ask the renewal owner to confirm the issuing authority or managed platform. A brand name on a hosting invoice is insufficient if the platform uses another organization to issue certificates.
Record the intended outcome: retain the current issuer, migrate providers, add wildcard coverage or restrict future issuance. Without that decision, a published authorization is an observation rather than a confirmed configuration problem.
2. Capture evidence
Query CAA for the relevant names and retain the complete response. Record the queried name, query type, resolver or authoritative server, response status, returned records and run timestamp with timezone.
Distinguish an answer containing no CAA records from a timeout, SERVFAIL or another lookup failure. An unsuccessful lookup does not establish that the domain has no policy.
Include the DNS response’s TTL in the evidence. It helps explain caching during a change, but it is not a guaranteed completion time for every resolver or renewal service.
3. Resolve policy
Determine the effective CAA policy for each certificate name. A lookup at the website hostname alone is insufficient: CAA processing can involve aliases and parent-domain records.
Under RFC 8659, processing searches for a relevant CAA record set and stops when one is found. Records at different levels are not simply combined into a single allowlist. Use a resolver or diagnostic method that exposes the relevant lookup path, then retain that path.
For aliases, check the resolution behavior and the certificate provider’s documentation. Do not assume that the DNS zone you manage is the only source influencing issuance.
4. Check authorization
Compare the effective record set with the intended authority’s documented issuer-domain value. Check issue for ordinary issuance and the applicable wildcard rules for wildcard requests.
Read the complete property value, including any parameters. A matching issuer name alone does not establish that every restriction permits the requested issuance method or account.
An explicitly empty issuer value can prohibit issuance in the applicable authorization context. Treat it as a policy decision requiring owner confirmation, not a record to delete automatically.
5. Confirm ownership
Present the condition, supporting response and uncertainty to the DNS and renewal owners. Ask whether the published policy matches the intended certificate service.
If a change is required, obtain approval, preserve the previous record set and define a rollback. Avoid removing restrictive records merely to make an unexplained error disappear.
6. Verify change
After an approved update, query again and compare the result with the pinned baseline. Retain both timestamps and the exact change.
Then verify the next operational stage separately: certificate issuance, deployment and the certificate served by the endpoint. A successful DNS update proves a DNS change. It does not prove completion of the renewal workflow.
The sequence keeps the evidence boundary visible: Establish scope, Capture evidence, Resolve policy, Check authorization, Confirm ownership, Verify change.
CAA properties and their review boundaries
CAA records have an 8-bit flags field, a property tag and a property value. The ordinary flag value is 0; 128 sets the issuer-critical flag. Under RFC 8659, an unrecognized property carrying that critical flag prevents issuance under the applicable record set.
For your 2026 review, inspect the full record rather than extracting only the authority name. The following properties answer different questions.
| Property | Best for | What to review | Limit |
|---|---|---|---|
issue | Authorizing ordinary certificate issuance | Intended issuer-domain value and parameters | Authorization does not complete domain validation |
issuewild | Setting wildcard-specific authorization | Whether wildcard issuance uses a separate policy | Its presence changes which authorization property governs wildcard requests |
iodef | Publishing an incident-reporting destination | Whether the destination is intended and maintained | Publishing a destination does not prove reports arrive or receive action |
For wildcard certificates, issuewild takes precedence over issue when the relevant record set contains issuewild. When it is absent, issue governs wildcard authorization as specified by CAA processing.
Multiple issuer authorizations can support legitimate operational needs. They also require ownership: ask why each authorization remains necessary before proposing removal.
A CAA authorization is permission to issue under its conditions, not proof that an authority issued a certificate. Certificate inventory and issuance history answer a different question.
Why CAA review requirements vary
The review depends on the certificate workflow and DNS structure, rather than a universal record template.
- Certificate scope: a certificate containing several names requires attention to the applicable policy for each name.
- Wildcard use: wildcard authorization can differ from ordinary issuance through
issuewild. - DNS structure: parent records, delegated zones and aliases affect where relevant evidence must be collected.
- Issuance provider: the service operating renewal must confirm its authority identifiers and supported parameters.
- Change ownership: the DNS administrator, hosting provider and certificate owner can have separate approval processes.
- Lookup reliability: failed or incomplete DNS responses require investigation before anyone labels the policy absent.
Use these factors to define the work, rather than assigning severity from record presence alone. Missing CAA removes a specific issuer-authorization restriction; it does not mean any requester can obtain a certificate without the authority’s other required checks.
Conversely, a restrictive record deserves attention when it conflicts with an approved renewal plan. The consequence is conditional until the effective policy, request and provider behavior are established.
Separate public evidence from customer-authorized evidence
A public DNS review can observe CAA policy and related DNS responses. It cannot establish Conditional Access coverage, application permissions, license assignments, device state or Microsoft 365 tenant sharing configuration.
Keep those evidence sources separate in a 2026 account review. Customer-authorized Microsoft 365 evidence concerns configuration and metadata within the approved scope; it is not access to mail, files, chats, documents or prompts.
For CAA, use these distinctions in the report:
- Observed: the DNS response returned a particular CAA record set at the recorded time.
- Inferred: the published authorization appears inconsistent with the provider named in customer documentation.
- Possible: an issuance request using that provider encounters an authorization restriction.
- Unknown: the next renewal authority or the intended wildcard policy has not been confirmed.
- Unreadable: the lookup failed and did not establish the relevant policy.
These evidence states are not a severity ladder. Coverage is separate: mark an incomplete lookup path Partial, and work outside the agreed scope Not assessed.
Public observation also differs from active probing. Establish authorization and scope before expanding the review beyond DNS observations; do not describe a renewal check as blanket permission for security testing.
Build an evidence-led renewal note
Use a compact handoff that the owner can verify. For your 2026 renewal worksheet, preserve the raw response alongside the explanation so a technician can reproduce the conclusion.
| Field | What belongs in the handoff |
|---|---|
| Condition | The exact effective CAA authorization observed |
| Affected object | The certificate name and relevant DNS owner name |
| Source and date | Query method, responding source and run timestamp |
| Boundary | What the lookup establishes and what remains unknown |
| Owner | DNS administrator and certificate renewal owner |
| Recommended outcome | The approved issuance policy, separate from vendor selection |
| Proof | Dated re-query against the baseline and separate issuance verification |
A useful explanation stays close to the evidence: the published authorization names an issuer; the renewal owner has identified a different intended issuer; the owners need to confirm whether a change is necessary.
That statement gives the customer a decision without claiming a failed renewal. It also avoids treating a policy difference as evidence of compromise.
SCOUTz prospect intelligence fits this evidence-to-conversation handoff. It prepares account context; a public observation still needs the customer’s intended configuration and an accountable owner before it becomes a proposed change.
For MSPs evaluating that workflow, the primary next step is Join Open Beta. Confirm the review scope and product status before treating any automated output as proof of a particular CAA check or renewal outcome.
Common renewal decisions
Should MSPs add CAA records when none are found?
An absent effective CAA policy is a reason to discuss issuer authorization, not proof of an urgent incident. Identify every legitimate issuance path before proposing a restrictive policy, including services managed outside the MSP.
Adding CAA provides an authorization control, but an incomplete issuer inventory can disrupt legitimate issuance. Recommend a policy only after the responsible owner confirms the intended authorities and wildcard requirements.
Should MSPs remove an unfamiliar authorized issuer?
An unfamiliar issuer requires investigation before removal. Ask the hosting, application and certificate owners whether it supports an active or contingency issuance path.
If nobody can confirm its purpose, record that uncertainty and assign an owner. Absence of an explanation is not evidence that the issuer is malicious.
Does fixing CAA complete certificate renewal?
Fixing CAA completes the approved DNS authorization change, not the entire renewal. Verify issuance, deployment and the served certificate separately, retaining evidence for each completed stage.
FAQ
What are CAA records used for before certificate renewal?
CAA records publish certificate-authority authorization policy in DNS. Before renewal, compare the effective policy with the intended issuer, certificate names and wildcard requirements.
Does a missing CAA record mean a domain is compromised?
A missing effective CAA policy does not establish compromise. It means CAA does not impose an issuer restriction for that name; certificate authorities still apply their other issuance requirements.
Do CAA records affect a certificate that is already installed?
CAA records govern issuance authorization rather than invalidating an already-issued certificate. A renewal request is an issuance event and must satisfy the applicable policy.
Do wildcard certificates need issuewild records?
Wildcard certificates do not always require a separate issuewild record. If issuewild is absent from the relevant record set, issue governs wildcard authorization under CAA processing.
Can a parent domain’s CAA records affect a subdomain?
A parent domain’s CAA records can affect a subdomain when CAA processing reaches that parent’s record set. Review the effective lookup path rather than assuming the hostname’s direct response is the complete policy.
Does a DNS timeout mean there are no CAA records?
A DNS timeout does not establish that CAA records are absent. Record the lookup failure and investigate before drawing an authorization conclusion.
Can a public CAA review assess Microsoft 365 security?
A public CAA review cannot establish Microsoft 365 tenant security configuration. That requires separate customer-authorized evidence within an agreed scope.
How should SCOUTz findings support a certificate-renewal conversation?
SCOUTz findings should support a dated, bounded discussion of observed conditions. Confirm the specific evidence available, identify the renewal owner and keep proposed changes separate from unverified assumptions.
One last thing
An installed certificate can keep working while a future renewal request encounters a different authorization policy. A healthy browser session therefore does not validate the next issuance path.
Before closing the review, ask the renewal owner to confirm the next issuer and the exact names it will request. That specific confirmation connects public DNS evidence to the operational decision the MSP actually needs to make.
