CAA records can limit certificate issuance, but an incomplete policy may prevent Tudor Internet or another authorised provider from renewing SSL.
Applies to: Email authentication and DNS security
SPF, DKIM, DMARC, DNSSEC and CAA solve different problems. Deploy them deliberately, validate syntax before tightening policy and keep an emergency rollback record for every production DNS change.
Before you start
- List every certificate authority used for current and planned certificates, including wildcard certificates.
Step-by-step
- Query existing CAA records at the hostname and parent domains because a parent policy can apply when no closer record exists.
- Add issue entries for each authorised certificate authority and issuewild entries where wildcard issuance is required.
- Keep accounturi or validationmethods parameters only when the certificate authority has explicitly supplied and supports them.
- Test a non-urgent certificate issuance or staging workflow before relying on the policy for an expiring production certificate.
- Document the approved authorities and update CAA before moving SSL providers.
- When emergency issuance fails, correct CAA and wait for its TTL rather than repeatedly submitting failed orders.
Confirm the result
- Only intended certificate authorities are authorised and normal AutoSSL or paid-certificate renewal succeeds.
Common problems
| Symptom | Likely cause | What to do |
|---|---|---|
| There is no CAA record at the host but issuance is blocked. | A parent-domain CAA record is inherited. | Query upward through the domain labels and update the authoritative parent policy. |
| Wildcard issuance fails while normal issuance works. | issuewild does not authorise the selected CA. | Add the required issuewild value or revise the wildcard design. |
When to contact Tudor Internet
Open a ticket through the Customer Portal when the checks above do not resolve the issue, when an action is unavailable for your service, or when continuing could risk data loss or service interruption. Include the following so the request can be investigated efficiently:
- The full domain name
- The current and intended registrar or nameservers
- Any registry or transfer error shown
- Whether website or email service is currently live
Do not send passwords, private keys, full payment-card details, one-time authentication codes or unredacted identity documents in an ordinary support reply.
Related articles
- Create SRV and CAA records
- Enable a free Let’s Encrypt SSL certificate
- Renew an SSL certificate
- Roll out DMARC safely from monitoring to enforcement
- Set up SPF, DKIM and DMARC records
Last reviewed: 2026-07-18.
