DMARC Analyzer

TL;DR

• CAA (Certification Authority Authorization) is the DNS record that controls which CAs may issue TLS / SSL certificates for a domain. Defined in RFC 8659 (obsoletes RFC 6844).
• CAA records have three fields: flags (integer; 128 marks the record critical), tag (issue, issuewild, or iodef), and value (a quoted string — CA identifier for issue/issuewild; URI for iodef).
• CAA is mandatory under the CA/Browser Forum Baseline Requirements: a public CA that finds a CAA record naming a different issuer MUST refuse to sign the certificate. Enforcement is at issuance time.
• An empty-issue value (0 issue ";") explicitly forbids ALL CAs from issuing — the canonical pattern for parked or unused domains.
• CAs perform a tree-walking lookup: they check the requested name, then walk up one label at a time until they find CAA records or hit a Top Level Domain. A record at the apex governs all sub-domains unless a more-specific record overrides it.
• CAA is an issuance-time control, not a runtime check. Removing a CAA record after a certificate has been issued does NOT revoke that certificate. CAA only controls future issuances.

1. What is a CAA record?

CAA (Certification Authority Authorization) is a DNS-based mechanism that lets a domain owner declare which Certificate Authorities are authorised to issue TLS / SSL certificates for the domain. CAA is specified in RFC 8659 — DNS Certification Authority Authorization (CAA) Resource Record, which obsoletes the original RFC 6844.

Before CAA, any publicly-trusted CA could issue a certificate for any domain — the only thing stopping mis-issuance was the CA's domain-validation procedure. CAA inverts that posture: domain owners publish a DNS record naming the CAs they trust, and every publicly-trusted CA is required (by the CA/Browser Forum Baseline Requirements §3.2.2.8) to check that record before signing a certificate. A CA that finds a CAA record naming a different issuer MUST refuse the request — even if the requester passed domain-validation.

CAA is an issuance-time control, not a runtime control. The CAA check happens once when the CA is preparing to sign the certificate; after that, the certificate is valid for its declared lifetime regardless of any later CAA changes. To revoke a certificate, the domain owner must contact the issuing CA's revocation process — removing the CAA record is not enough.

Like other DNS-security records on this site (SPF, DKIM, MTA-STS), CAA is a publish-once-and-monitor control: write the record, then audit changes. It complements rather than replaces the existing PKI trust model.

2. How CAA works, step by step

1. The domain owner publishes one or more CAA DNS records naming the CAs they trust. A typical apex record looks like example.com. IN CAA 0 issue "letsencrypt.org".
2. When a CA receives a certificate-signing request for foo.bar.example.com, it performs the CAA tree-walking algorithm (RFC 8659 §3): query foo.bar.example.com for CAA records; if none, query bar.example.com; if none, query example.com; continue until CAA records are found or the parent is a TLD (com). The closest set of CAA records wins.
3. The CA inspects the matched CAA records. If any issue (or issuewild for a wildcard request) record names the CA's identifier string, issuance is authorised. If ANY CAA record exists but none authorise the CA, issuance is REFUSED — even if the requester passed domain-validation.
4. If the matched records include an iodef tag, the CA SHOULD report every blocked-issuance attempt to the URI declared (typically a mailto: or https: endpoint). This is the operational feedback loop that lets domain owners detect attempted unauthorised issuance.
5. The CA records the CAA lookup details in its audit log (required by the CA/Browser Forum Baseline Requirements) and proceeds with issuance or refusal.
6. The published certificate is then valid for its full lifetime (typically 90 days for Let's Encrypt, 1 year for paid CAs) regardless of any later CAA changes.

3. CAA DNS syntax

A CAA record has three fields in the RDATA portion: flags, tag, and value.

example.com.  IN  CAA  0 issue "letsencrypt.org"
              ^   ^   ^ ^     ^
              |   |   | |     +-- value      (quoted string)
              |   |   | +-------- tag        (issue | issuewild | iodef)
              |   |   +---------- flags      (integer, 0 or 128)
              |   +-------------- record type (CAA)
              +------------------ class       (IN)

Field-by-field anatomy:

flags

Integer 0-255. Bit 7 (decimal 128) is the critical flag — when set, a CA that does not understand the tag MUST refuse to issue. All other bits are reserved. For the three currently-defined tags (issue, issuewild, iodef), every conforming CA understands them, so critical is rarely needed; the default 0 is correct in almost all cases.

tag

Lowercase property tag. RFC 8659 defines three: issue (authorise a CA to issue non-wildcard certificates), issuewild (authorise a CA to issue wildcard certificates), and iodef (declare a contact URI for violation reports). Additional tags are registered with IANA; current registrations include contactemail and contactphone from RFC 8657.

value

Quoted string. For issue and issuewild, the value is a CA identifier — typically the CA's primary domain name (letsencrypt.org, digicert.com, sectigo.com). For iodef, the value is a URI (mailto: or https:). An empty value (";") on an issue/issuewild tag means "no CA authorised" — the canonical explicit-forbid pattern.

Multiple CAA records at the same name are additive: the union of their authorisations applies. To allow Let's Encrypt AND DigiCert, publish two issue records — one for each.

Optional CA-specific value parameters can appear after the identifier, separated by semicolons. For example, 0 issue "letsencrypt.org; validationmethods=http-01" restricts Let's Encrypt to a specific challenge type. Parameter support varies by CA; check the CA's documentation for the full list.

4. CAA property tags

Interaction rule for issuewild: when a CA evaluates a wildcard issuance, it FIRST looks for issuewild records and uses those. If no issuewild records exist, it falls back to issue. So 0 issue "letsencrypt.org" alone authorises both regular AND wildcard certificates from Let's Encrypt; adding 0 issuewild ";" alongside it forbids wildcards specifically while keeping non-wildcard issuance authorised.

5. CA identifier values

The CA identifier string in a CAA issue record is defined by each CA individually — there is no IANA registry of canonical identifiers. CAs publish their accepted identifier in their documentation. Common values for major publicly-trusted CAs:

Always check the issuing CA's current documentation for the exact identifier before publishing — a typo or stale value silently blocks issuance until corrected. For private/internal CAs, the operator chooses the identifier and configures their CA to recognise it.

6. CAA examples

6.1 Single-CA authorisation (Let's Encrypt only)

example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 iodef "mailto:security@example.com"

The most common production shape: one issue record naming the active CA, plus an iodef record so the security team gets notified of any blocked-issuance attempts. Wildcard certificates from Let's Encrypt are also authorised because no issuewild override exists.

6.2 Multi-CA allow-list

example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 issue "digicert.com"
example.com.  IN  CAA  0 iodef "mailto:security@example.com"

Authorises Let's Encrypt (typical Web servers) AND DigiCert (for VMC / EV / paid certificate workflows). Multiple issue records at the same name are unioned together.

6.3 Block wildcard issuance

example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 issuewild ";"

Authorises Let's Encrypt for normal hostnames but explicitly forbids wildcard certificates from any CA. Useful for domains where each sub-domain should have its own certificate (smaller blast radius if any single private key is compromised).

6.4 Explicit "no certificates" — parked domain

example.com.  IN  CAA  0 issue ";"
example.com.  IN  CAA  0 issuewild ";"
example.com.  IN  CAA  0 iodef "mailto:security@example.com"

A parked or sale-only domain that should never have a certificate. Every CA is explicitly forbidden; the iodef record alerts the operator if someone attempts to issue one (often a sign of attempted impersonation or domain takeover).

6.5 ACME-only restriction

example.com.  IN  CAA  0 issue "letsencrypt.org; validationmethods=dns-01"

Authorises Let's Encrypt only for the DNS-01 challenge — HTTP-01 and TLS-ALPN-01 are forbidden by this restriction. Useful when the operator centralises certificate issuance through their DNS provider and wants to prevent compromise of individual Web servers from being usable to obtain a certificate.

6.6 Sub-domain override

example.com.        IN  CAA  0 issue "letsencrypt.org"
mta-sts.example.com. IN  CAA  0 issue "digicert.com"

The apex authorises Let's Encrypt for most sub-domains, but mta-sts.example.com uses DigiCert (perhaps because that host serves an MTA-STS policy requiring a longer-lifetime certificate, or because organisational policy mandates an EV cert there). The more-specific record wins per the RFC 8659 tree-walking rule.

6.7 IODEF reporting via HTTPS endpoint

example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 iodef "https://reports.example.com/iodef"

The HTTPS variant of iodef: blocked- issuance reports get POSTed to the URL as JSON. The endpoint should accept Content-Type: application/json and parse RFC 7970 IODEF documents.

7. CAA best practices

• Publish a CAA record on every active domain you own. A domain with no CAA record permits any publicly-trusted CA to issue — the default-open posture is the weakest one. Even a single 0 issue "letsencrypt.org" record meaningfully tightens the issuance attack surface.
• Always include an iodef URI. Without it, attempted unauthorised issuances are silent — you only learn about them after the fact (if ever). A mailto:security@example.com contact takes 30 seconds to add and gives you live attack telemetry.
• Use a small allow-list, not a single CA. The strictness of 0 issue "letsencrypt.org" alone bites the day Let's Encrypt has an outage or you migrate. Authorising 2-3 backup CAs (DigiCert, Sectigo, or Google) keeps operations flexible.
• Audit CAA before deploying MTA-STS and BIMI. Both standards require public-PKI certificates on dedicated hosts (mta-sts.<domain>, bimi.<domain>); a CAA record that doesn't authorise the issuing CA silently blocks deployment. See help_mta_sts_explained.php and help_bimi_explained.php.
• Pair CAA with DNSSEC. Without DNSSEC, a network attacker can spoof empty CAA responses to the CA and trick it into issuing. With DNSSEC, the response is cryptographically signed end-to-end. DNSSEC is not yet required by the CA/Browser Forum but is best-practice.
• Block wildcard issuance for high-value domains. 0 issuewild ";" reduces blast radius — a compromised wildcard cert covers every sub-domain at once; per-host certificates limit damage.
• Use ACME validation-method restrictions for centralised cert management. validationmethods=dns-01 guarantees issuance can only happen through the operator's DNS automation, blocking per-host issuance attempts from compromised Web servers.
• Set TTL low during CAA changes. A 300-second TTL during a CA migration lets you roll back quickly if issuance breaks. Bump TTL back to 3600+ once the migration stabilises.
• Test CAA before relying on it. Use dig CAA <domain> or SSLMate's CAA testing tool before attempting actual certificate issuance. DMARC Analyzer's Domain Security Checker also reports the current CAA records and flags missing-CAA as a security finding.
• Document CAA changes in your runbook. A CAA record change blocks future issuance — renewal cron jobs that started succeeding will suddenly fail. Record every change with a date + rationale so your future self can diagnose certificate-renewal incidents.

8. Common CAA mistakes

• Typo in the CA identifier. "lets-encrypt.org", "letsencrypt.com", or "letsencrypt" all silently block Let's Encrypt issuance. The canonical value is "letsencrypt.org" with no hyphen and the .org TLD. Always copy from the CA's documentation.
• Missing the issuewild record. Operators sometimes publish 0 issue "letsencrypt.org" and assume that blocks wildcard issuance from other CAs. It doesn't — wildcards from Let's Encrypt are still authorised by the issue tag in the absence of an explicit issuewild override. To block wildcards, publish 0 issuewild ";".
• Forgetting to update CAA before a CA migration. Switching from DigiCert to Let's Encrypt and updating only the renewal automation produces a green ACME validation result followed by a CAA refusal — the cert never gets issued. Update CAA FIRST, wait for DNS propagation, then migrate.
• Stripping CAA records when an old CA is deprecated. Removing 0 issue "digicert.com" works, but the change does NOT revoke existing DigiCert certificates — those remain valid until their notAfter date. Revocation is a separate process via the CA.
• Mixing flags 0 and 128 without reason. The critical flag (128) forces refusal on unknown tags. The three defined tags (issue, issuewild, iodef) are universally understood, so the critical flag almost never adds value — use 0 and reserve 128 for genuinely-new extensions.
• Using http:// for the iodef URI. Plain HTTP endpoints accept reports but are unauthenticated and can be tampered with. Use https:// or mailto:.
• Publishing CNAME for the mta-sts host that points to a CDN with a different CAA-authorised CA. Cross-CA / cross-CDN setups need the apex CAA record to authorise whatever CA the CDN provider actually uses. Audit the chain explicitly.
• Treating CAA as runtime enforcement. CAA only gates new issuances. A previously-issued certificate remains valid until it expires regardless of any later CAA change. The "removed-CAA- record-revokes-cert" assumption is wrong.
• Publishing CAA records at every sub-domain redundantly. CAA tree-walks, so a single apex record covers every sub-domain unless overridden. Don't copy-paste the same record across 50 sub-domains; publish it once at the apex.

9. CAA troubleshooting

Certificate issuance is failing with "CAA refusal" or similar

Look at the CA's error message for the exact identifier it queried. Check that one of your published issue records exactly matches that string (dig CAA <domain>). Common cause: a typo or a stale record left over from a prior CA. Fix the record and wait at least the published TTL before retrying.

dig CAA <domain> returns nothing but my DNS provider's UI shows the record

Some DNS providers attach CAA records to sub-domains that don't actually answer authoritatively, or split the response across cache views. Test against multiple resolvers (+trace, 1.1.1.1, 8.8.8.8) and confirm the authoritative server returns the record directly.

Wildcard issuance is failing but non-wildcard works

Check for an issuewild record that doesn't authorise the CA — if present, it takes precedence over issue for wildcards. Either add an issuewild for the desired CA or remove the conflicting one.

I'm getting iodef reports for attempted issuance I didn't initiate

This is exactly what iodef is for — investigate immediately. Common causes: a forgotten automated renewal job on a decommissioned host, a CA migration test from a colleague, OR an actual attempted impersonation (escalate to the security team).

My CAA record looks correct but the CA still refuses

CAs cache CAA responses for the published DNS TTL. If you updated the record recently, the CA may still see the previous value. Confirm the live record with dig CAA <domain>, wait for the previous TTL to expire, and retry. Cloudflare's 1.1.1.1 is a good no-cache test resolver.

How do I see CAA records for an arbitrary domain?

Use dig CAA example.com +short from any modern dig install (BIND 9.9.6+, RFC-compliant resolvers). DMARC Analyzer's Domain Security Checker also displays CAA records inline alongside SPF / DKIM / DMARC findings.

Does removing a CAA record revoke existing certificates?

No. CAA is only checked at issuance time; existing certificates remain valid for their full lifetime. To revoke a certificate, contact the issuing CA's revocation API or portal directly.

10. Frequently Asked Questions

What is a CAA record?

A CAA (Certification Authority Authorization) record is a DNS record that lets a domain owner declare which Certificate Authorities are authorised to issue TLS / SSL certificates for the domain. Defined in RFC 8659 (which obsoletes RFC 6844), CAA records are mandatory to check before issuance under the CA/Browser Forum Baseline Requirements: a CA that finds a CAA record naming a different issuer MUST refuse to sign the certificate. CAA is a defense against accidental or malicious mis-issuance.

What does a CAA DNS record look like?

A CAA record is a DNS record with three fields: flags (an integer, typically 0; 128 marks the record critical), tag (one of issue, issuewild, or iodef), and value (a quoted string — the CA identifier for issue/issuewild, a contact URI for iodef). A typical record is: example.com. IN CAA 0 issue "letsencrypt.org" — authorising Let's Encrypt to issue certificates for example.com.

What is the difference between issue, issuewild, and iodef?

issue authorises a CA to issue certificates for the exact domain (and, by default, wildcard certificates unless an issuewild record overrides it). issuewild authorises a CA to issue wildcard certificates (*.example.com); when present, it takes precedence over issue for wildcard requests. iodef declares a contact URI (typically mailto: or https:) where CAs should report attempted policy violations. iodef is informational; issue and issuewild are enforcement records.

What is the empty-issue value ";"?

An issue value of ";" (just a semicolon) is the explicit "no CAs authorised" marker. Publishing 0 issue ";" tells every CA that NO issuer may certify the domain — useful for unused or parked domains that should never have certificates. Combined with a small allow-list, the pattern "0 issue "letsencrypt.org"; 0 issue ";"" means only Let's Encrypt is authorised; every other CA is explicitly forbidden.

Where in DNS do CAA records live?

CAA records are published at the domain apex and at any sub-domain. RFC 8659 §3 defines a tree-walking algorithm: when a CA evaluates issuance for a hostname, it queries CAA for that name; if no CAA records are returned, it walks up the DNS tree one label at a time (mx.example.com → example.com → com) until it finds CAA records or reaches a Top Level Domain. The closest set of CAA records wins. So a record at example.com governs issuance for every sub-domain unless overridden by a more-specific CAA record.

Does CAA work with DNSSEC?

CAA does not require DNSSEC, but DNSSEC strengthens it considerably. Without DNSSEC, a network attacker positioned between the CA and the authoritative resolver can spoof empty CAA responses and trick the CA into issuing a certificate it would otherwise refuse. With DNSSEC, the CAA response is cryptographically signed end-to-end and cannot be spoofed. The CA/Browser Forum requires CAA checking but does not yet require DNSSEC validation — DNSSEC remains best-practice.

Does DMARC Analyzer check CAA records?

Yes. DMARC Analyzer's Domain Security Checker (domain_checker.php) performs live CAA lookups via the DnsChecker.php helper, surfacing the published issuers, any iodef contact, and warning when a domain has no CAA record published (which means every CA is implicitly authorised). The DNS Record Generator (dns_generator.php) includes a CAA wizard that builds well-formed records with flags, tag, and value fields validated against RFC 8659.

11. Related guides

• Email security glossary — the CAA-CERTIFICATE-AUTHORITY- AUTHORIZATION-ISSUER-ISSUEWILD-IODEF- CRITICAL-FLAG-VOCABULARY-CONSUMER companion to this CAA reference. Where THIS page documents the CAA protocol at the byte level (the RFC 8659 <flag> <tag> <value> CAA-RR record-body grammar, the three canonical CAA property tags issue / issuewild / iodef, the critical-flag bit's RFC 8659 §4.1 receiver-side contract, the CA-side CAA-record-fetch and tag-evaluation algorithm before ACME-challenge-validated certificate issuance, the MX-host CAA inheritance contract for transport-security certificate authorisation, the per-CA ;-separated parameter list extension for ACME- account binding via accounturi / validationmethods parameters per RFC 8657), the email-security- glossary spoke is the VOCABULARY- DEFINITION-REFERENCE companion documenting the canonical definitions for every term-of-art this CAA reference uses in the body text without inline glossing — readers arriving from a Google search for "what is CAA record" or "what is issuer property tag" or "what is iodef" or "what is ACME challenge" need the glossary spoke to establish the certificate-issuance- and-validation vocabulary baseline before they can productively read THIS page's CAA-RR byte-level deep dive. The CAA-vs-glossary relationship is pillar-and- vocabulary-reference: THIS page is the canonical RFC 8659 / RFC 8657 CAA-record protocol pillar; the glossary spoke is the cross-cluster vocabulary hub the CAA reference shares with every other transport- security / certificate-issuance / threat-catalogue / receiver-side pillar in the help cluster, and a reader moving between this CAA reference and an adjacent certificate-related pillar (MTA-STS, DANE, BIMI VMC) or threat-catalogue pillar needs the glossary spoke to bridge the cross-pillar vocabulary translation. Read the glossary spoke when the reader has not yet established the baseline vocabulary for CAA-cluster terms — CAA (Certificate Authority Authorization), CA (Certificate Authority), public-PKI certificate, issuer / issuewild / iodef property tag, critical flag bit, ACME challenge validation methods (HTTP-01 / DNS-01 / TLS-ALPN-01), ICANN ROA (Registry Operator Agreement), CT (Certificate Transparency) log, MX-host CAA inheritance — each defined in the glossary with the canonical RFC 8659 / RFC 8657 anchor, the cross-pillar links to the MTA-STS / DANE / BIMI-VMC certificate-issuance pillars, and the operator-side context for when each CAA term-of-art appears in the operator's pre-BIMI-VMC-launch CA-eligibility readiness audit, in the MTA-STS / DANE rollout readiness audit's CAA-compatibility check, or in the post-launch certificate-renewal incident- response triage when an unexpected CA-issuance refusal surfaces in the CT-log monitoring pipeline.
• MTA-STS explained — SMTP MTA Strict Transport Security (RFC 8461). Requires a public-PKI certificate on the mta-sts.<domain> host; an incompatible CAA record silently blocks rollout.
• MTA-STS for Microsoft 365 — the CAA-RECORD-AT-CUSTOMER-VANITY-DOMAIN- MUST-AUTHORIZE-THE-CA-THAT-WILL-ISSUE-THE- mta-sts-VANITY-HOST-CERTIFICATE-USED-BY- EXCHANGE-ONLINE-OUTBOUND-CONNECTOR-AND- INBOUND-MX-STARTTLS-CHAIN companion to this RFC 8659 CAA pillar. Where THIS page documents the CAA record (the 0 issue "letsencrypt.org" / 0 issuewild "letsencrypt.org" / 0 iodef "mailto:..." tag semantics, the per-CA issuance authorization, the iodef incident-reporting channel) — i.e. the CA-ISSUANCE-AUTHORIZATION side of the public-PKI ecosystem — the MTA- STS-for-Microsoft-365 spoke is the M365- TENANT-SPECIFIC TRANSPORT-CERT-CONSUMER companion documenting the structurally- distinct certificate-consumption surface a Microsoft-365-hosted vanity domain induces: (i) the M365 MTA-STS deployment publishes the policy file at https://mta-sts.<customer-vanity- domain>/.well-known/mta-sts.txt at the customer-controlled DNS zone — the mta-sts.<customer- domain> HTTPS endpoint requires a public-PKI certificate, and the customer- domain CAA record this page documents directly governs whether the customer's chosen CA (Let's Encrypt, DigiCert, Sectigo, ZeroSSL, GoDaddy) can issue that certificate; an incompatible 0 issue "wrong-ca.com" CAA at the customer apex zone silently blocks the MTA-STS-for-M365 rollout because the cert- issuance pre-issuance CAA check rejects the request before the cert can be deployed at the mta-sts subdomain; (ii) the M365 outbound connector's Exchange-Online-side STARTTLS negotiation to external receivers reads OTHER domains' MTA-STS policies (and thus relies on those domains' CAA-authorized public-PKI cert chains), but the M365-tenant-OWNED mta-sts.<customer-domain> endpoint's cert chain is what EXTERNAL senders' MTA-STS-enforce-mode checks validate when delivering INBOUND mail to the M365 tenant's MX ( <tenant>-mail.protection. outlook.com) — the customer- domain CAA on THIS page is the operator- controlled cert-authorization lever for the customer-domain side of the inbound MTA-STS certificate chain; (iii) the Microsoft-managed Exchange-Online inbound MX hostnames (<tenant>-mail. protection.outlook.com) have their own Microsoft-controlled CAA at the protection.outlook.com / outlook.com apex zones, NOT under customer control — this is the structural division of CA-authorization responsibility that operators must understand: the customer controls CAA for their vanity domain's mta-sts.<customer-domain> endpoint cert, Microsoft controls CAA for the Exchange-Online MX hostname's STARTTLS-served cert chain; (iv) the CAA iodef channel surfaces M365 MTA-STS cert-issuance failures at the customer-side mta-sts endpoint — when the customer- domain CAA blocks a cert renewal for the mta-sts.<customer-domain> endpoint, the iodef-pointed mailbox receives the CA's incident report, providing the operator with primary forensic evidence for the silently-failing M365 MTA-STS deployment posture this page's CAA mechanics directly govern. Read the MTA-STS-for-Microsoft-365 spoke alongside this CAA pillar when designing the customer-vanity-domain transport-security cert-authorization posture for an M365- hosted mail domain — the M365-tenant- specific mta-sts.<customer-domain> policy-file host's public-PKI cert chain the spoke documents is the load-bearing cert-issuance-CAA-authorization consumer whose rollout silently breaks unless the customer-domain CAA record this page documents authorizes the customer's chosen public-PKI CA.
• MTA-STS for Google Workspace — the CAA-RECORD-AT-CUSTOMER-VANITY- DOMAIN-MUST-AUTHORIZE-THE-CA-THAT- WILL-ISSUE-THE-mta-sts-VANITY-HOST- CERTIFICATE-USED-BY-WORKSPACE-INBOUND- MX-STARTTLS-VALIDATION companion to this RFC 8659 CAA pillar. Where THIS page documents the CAA record (the 0 issue "letsencrypt.org" / 0 issuewild "letsencrypt.org" / 0 iodef "mailto:..." tag semantics, the per-CA issuance authorization, the iodef incident- reporting channel) — i.e. the CA- ISSUANCE-AUTHORIZATION side of the public-PKI ecosystem — the MTA-STS- for-Google-Workspace spoke is the WORKSPACE-TENANT-SPECIFIC TRANSPORT- CERT-CONSUMER companion documenting the structurally-distinct certificate- consumption surface a Google-Workspace- hosted vanity domain induces, which differs from the M365 case along STRUCTURAL DIVISION-OF-CA-AUTHORIZATION boundaries that the customer-vanity CAA pillar this page documents directly governs. Concretely, the spoke documents FOUR Workspace-CAA- vs-MTA-STS-cert-authorization- coordination dimensions: (i) the Workspace MTA-STS deployment publishes the policy file at https://mta-sts.<customer- vanity-domain>/.well-known/mta- sts.txt at the customer- controlled DNS zone — the mta-sts.<customer-domain> HTTPS endpoint requires a public-PKI certificate, and the customer-domain CAA record this page documents directly governs whether the customer's chosen CA (Let's Encrypt, DigiCert, Sectigo, ZeroSSL, GoDaddy) can issue that certificate; an incompatible 0 issue "wrong-ca.com" CAA at the customer apex zone silently blocks the MTA-STS-for- Workspace rollout because the cert- issuance pre-issuance CAA check rejects the request before the cert can be deployed at the mta-sts subdomain; (ii) the Workspace-tenant operator's customer-OWNED mta- sts.<customer-domain> endpoint's cert chain is what EXTERNAL senders' MTA-STS-enforce- mode checks validate when delivering INBOUND mail to the Workspace tenant's 5-host tier'd MX inventory (aspmx.l.google.com, alt1.aspmx.l.google.com, alt2.aspmx.l.google.com, alt3.aspmx.l.google.com, alt4.aspmx.l.google.com) — the customer-domain CAA on THIS page is the operator-controlled cert- authorization lever for the customer- domain side of the inbound MTA-STS certificate chain; sending MTAs that cache the Workspace tenant's MTA-STS policy file validate the mta-sts.<customer-domain> endpoint's public-PKI cert chain at policy-fetch time, and a CAA-blocked cert renewal silently leaves the policy file unreachable from sending MTAs whose policy-cache rollover window has elapsed; (iii) the Google-managed Workspace inbound MX hostnames (the 5-host tier'd aspmx.l.google.com + 4-alt inventory) have their own Google-controlled CAA at the aspmx.l.google.com / l.google.com / google.com apex zones, NOT under customer control — this is the structural division-of- CA-authorization responsibility that Workspace operators must understand: the customer controls CAA for their vanity domain's mta-sts.<customer-domain> endpoint cert, Google controls CAA for the Workspace inbound MX hostname's STARTTLS-served cert chain (Google publishes 0 issue "pki.goog" at the relevant apex zones authorizing the Google Trust Services CA family to issue certs for the Workspace MX hostnames' STARTTLS-served cert chain); and (iv) the CAA iodef channel surfaces Workspace MTA-STS cert-issuance failures at the customer-side mta-sts endpoint — when the customer-domain CAA blocks a cert renewal for the mta-sts.<customer-domain> endpoint of a Workspace-hosted domain, the iodef-pointed mailbox receives the CA's incident report, providing the Workspace operator with primary forensic evidence for the silently-failing Workspace MTA-STS deployment posture this page's CAA mechanics directly govern. Read the MTA-STS-for-Google- Workspace spoke alongside this CAA pillar when designing the customer- vanity-domain transport-security cert-authorization posture for a Workspace-hosted mail domain — the Workspace-tenant-specific mta-sts.<customer-domain> policy-file host's public-PKI cert chain the spoke documents is the load-bearing cert-issuance-CAA- authorization consumer whose rollout silently breaks unless the customer- domain CAA record this page documents authorizes the customer's chosen public-PKI CA.
• MTA-STS vs DANE — the transport-security head-to-head decision reference (the DNS-CERT-PINNING-DECISION-INPUT companion to this CAA reference) — the DNS-CERT-PINNING-DECISION-INPUT companion documenting the transport-security choice between MTA-STS and DANE whose cert- validation models BOTH have upstream dependencies on the CA-authorization rules THIS page documents. Where THIS page documents the CAA record (RFC 8659 — the 0 issue "letsencrypt.org" / 0 issuewild "letsencrypt.org" / 0 iodef "mailto:..." tag semantics, the per-CA issuance authorization, the iodef incident-reporting channel), the mta_sts_vs_dane spoke is the HEAD-TO-HEAD DECISION REFERENCE documenting how the CA-authorization rules feed into BOTH transport-security technologies in structurally-distinct ways the cross-reference makes explicit: (i) MTA-STS REQUIRES CAA AUTHORIZING THE PUBLIC-PKI CA — the MTA-STS HTTPS-served policy file at mta-sts.<domain> requires a public-PKI certificate; the CAA record MUST authorize the issuing CA OR MTA-STS rollout silently fails (cert-issuance blocked); (ii) DANE BYPASSES CAA BY DESIGN — DANE TLSA records contain a cert hash that receivers validate directly without requiring public-PKI trust; this means DANE-protected domains can use self-signed or private-CA certs whose issuer is NOT authorized by CAA; receivers trust the DANE-published hash, not a CA's signature; (iii) operator who cannot get CAA aligned with public CAs SHOULD prefer DANE — when an operator's CAA is locked to a private/internal CA AND the operator wants transport-security, DANE is the natural choice because it sidesteps the public-PKI-CAA dependency; conversely an operator with CAA authorizing Let's Encrypt / DigiCert / Sectigo can use MTA-STS without the DNSSEC-chain infrastructure requirement DANE imposes; (iv) CAA iodef channel reports MTA-STS cert-issuance failures, not DANE failures — the CAA iodef tag's incident reporting endpoint receives notification of CA-side rejections that would block MTA-STS cert issuance, but does NOT report DANE TLSA-record-mismatch failures (which surface in TLS-RPT instead). Read the MTA-STS-vs-DANE head-to-head when choosing the transport- security technology AND the CA-authorization landscape documented on THIS page is one of the decision-shaping inputs.
• DANE for SMTP (RFC 7672) explained — the CAA-CONSTRAINS-WHICH-CAs-CAN-ISSUE- LEAF-CERTS-DANE-PINS companion documenting the RFC 7672 DNSSEC-anchored TLSA-based certificate authentication mechanism whose DANE-EE (3 1 1) leaf-certificate pinning model layers DEFENSE-IN-DEPTH with the CA-issuance-authorization rules THIS CAA pillar documents. Where THIS page documents the CAA record (RFC 8659 — the 0 issue "letsencrypt.org" / 0 issuewild "letsencrypt.org" / 0 iodef "mailto:..." tag semantics, the per-CA issuance authorization gating, the issuance-time CA query of the domain's CAA tree, the iodef incident- reporting channel), the DANE for SMTP spoke is the DNSSEC-ANCHORED TRANSPORT-CERT-PINNING companion documenting how the _25._tcp.mx.<domain> IN TLSA record pins WHICH SPECIFIC leaf certificate (3 1 1 DANE-EE SHA-256 cert-hash) or trust anchor (2 0 1 DANE-TA SHA-256 cert-hash) sending MTAs must validate against — the four-axis CAA-VS-DANE complement comparison exposes the structurally-distinct DEFENSE-IN-DEPTH ROLES the CA-authorization landscape plays vs the DNS-anchored cert- pinning landscape: (i) CAA constrains WHICH CAs CAN issue, DANE pins WHICH SPECIFIC cert must be presented — CAA is the ISSUANCE-AUTHORIZATION-CONSTRAINT layer (CA SHALL NOT issue unless authorized); DANE is the VALIDATION-TIME-CERTIFICATE-PINNING layer (receiver SHALL NOT trust unless TLSA hash matches); the two are ORTHOGONAL — DANE pins a cert that DOES NOT need CAA-authorization provenance because DANE bypasses public-PKI; (ii) operator with CAA aligned for public-PKI CA + MTA-STS deployed can ALSO deploy DANE on the same MX records — the DNS infrastructure layers cooperate; CAA gates the MTA-STS HTTPS cert at mta-sts.<domain>, DANE gates the SMTP STARTTLS cert at the MX hosts; the two technology layers each have their own DNS-zone-published-trust-anchor; (iii) CAA failure mode is CA-side rejection + iodef report, DANE failure mode is receiver-side TLSA mismatch + TLS-RPT report — both pathways are observable, but in different reporting channels (iodef vs TLS-RPT); operators running both must monitor both channels; (iv) DANE rotation requires publish-new-TLSA + wait-TTL-then-cutover- cert + retire-old-TLSA cadence — analogous to the DKIM-selector dual-publish rotation pattern but at the transport-cert level; the CAA 0 issue tag remains stable during DANE cert rotation because CAA constrains the CA not the specific cert. Read the DANE-for-SMTP page when scoping the transport-security DNS-zone landscape: this page documents the ISSUANCE-AUTHORIZATION constraint, the DANE page documents the VALIDATION-TIME- CERTIFICATE-PINNING constraint, and the two together name the full DNS-zone-anchored transport-security posture.
• BIMI explained — Brand Indicators for Message Identification. Requires a Verified Mark Certificate (VMC) from DigiCert or Entrust; CAA must authorise the issuing CA before VMC issuance can succeed.
• MTA-STS policy file byte-syntax — the CAA-AUTHORIZES-MTA-STS-HTTPS- ENDPOINT-CERTIFICATE-ISSUANCE companion to this CAA reference. Where THIS page documents the CAA protocol's certificate- authority-authorization primitive (the 0 issue "ca.example", 0 issuewild, iodef property tags, the critical flag bit, the CA-side CAA-record-fetch and tag-evaluation algorithm before ACME-challenge-validated certificate issuance), the MTA-STS-policy- syntax spoke documents the byte-syntax of the policy file served from https://mta-sts.<domain>/.well-known/mta-sts.txt — an HTTPS endpoint whose TLS certificate the customer's CAA record on THIS page MUST authorize before the policy file can be served at all. The four-axis CAA- AUTHORIZATION-VS-MTA-STS-POLICY-HOSTING comparison exposes the structurally- distinct PREREQUISITE-CHAIN roles: (i) the MTA-STS policy file is published via HTTPS at mta-sts.<domain>, NOT via DNS — and the HTTPS endpoint's TLS certificate MUST be issued by a CA the customer's CAA record authorizes via the 0 issue "ca.example" tag THIS page documents; without proper CAA authorization, no public-PKI CA will issue a TLS certificate for mta-sts.<domain> and the MTA-STS policy file is structurally unserveable; (ii) the CAA 0 issuewild tag THIS page documents controls wildcard-certificate issuance and is irrelevant to MTA-STS policy hosting (the mta-sts.<domain> endpoint requires a NON-wildcard certificate matching the literal hostname); the MTA-STS-policy- syntax spoke documents the exact host the certificate must match; (iii) the CAA iodef tag THIS page documents requests CA-side notification of mis-issuance attempts — critical for MTA-STS policy hosting because an attacker who can fraudulently obtain a TLS certificate for mta-sts.<domain> can serve a malicious policy file downgrading the MTA-STS contract; operators publishing an MTA-STS policy SHOULD also publish an iodef CAA tag per THIS page's discipline; (iv) the MTA-STS policy file's mx: tag patterns name the recipient domain's authoritative MX hostnames whose TLS certificates ALSO require CAA authorization at the recipient MX hostname's zone — a complete CAA + MTA-STS posture requires CAA records at BOTH the policy-hosting mta-sts.<domain> and the policy-listed MX hostnames; the spoke documents the byte-syntax of the mx: patterns whose CAA- authorization the operator must coordinate across multiple DNS zones. Read the MTA-STS-policy-syntax spoke when authoring the customer's CAA record on THIS page: the mta-sts.<domain> HTTPS endpoint's TLS certificate must be issuable under the CAA authorization THIS page documents, AND the MTA-STS policy file's mx:-listed MX hostnames must have parallel CAA records at their respective zones — the two records form the certificate-issuance-authorization chain that gates the entire transport- security posture.
• TLS-RPT explained — SMTP TLS Reporting (RFC 8460). Reports surface sts-webpki-invalid when a CAA- blocked certificate fails public-PKI validation on the mta-sts.<domain> vhost.
• TLS-RPT record syntax (RFC 8460 §3) — the CAA-RR-BYTE-GRAMMAR-PARALLEL- WITH-TLS-RPT-TXT-RR-BYTE-GRAMMAR companion to this CAA reference. Where THIS page documents the RFC 8659 CAA-RR <flag> <tag> <value> record-body grammar (the three canonical CAA property tags issue / issuewild / iodef, the critical-flag bit's RFC 8659 §4.1 receiver-side contract, and the RFC 8657 extensions accounturi / validationmethods / contactemail / contactphone ACME-binding parameters), the TLS-RPT record-syntax spoke is the RFC 8460 §3 TLS-RPT TXT-RR byte-grammar companion whose strict-publisher-side-byte-grammar publication discipline mirrors the CAA-RR byte-grammar discipline THIS page documents. The CAA-RR-BYTE-GRAMMAR- PARALLEL-WITH-TLS-RPT-TXT-RR-BYTE-GRAMMAR cross-reference establishes FOUR structurally-distinct DNS-RR byte-level publisher-side-syntax-discipline dimensions: (i) sentinel-token byte-grammar parallel — CAA-RR omits a leading version-sentinel (the <flag> 0/128 octet is the sole framing) per RFC 8659 §4.1; TLS-RPT-TXT-RR requires the literal leading v=TLSRPTv1 sentinel per RFC 8460 §3.1 as the receiver-side identification primitive that distinguishes TLS-RPT TXT records from same-host TXT siblings (SPF v=spf1, DKIM v=DKIM1, DMARC v=DMARC1); both protocols' sentinel-token discipline gates receiver-side parser dispatch and publisher-side syntax errors at the sentinel boundary collapse the entire publication; (ii) tag-list byte-grammar parallel — CAA-RR encodes the issuance policy via three property-tag tokens (issue / issuewild / iodef) each with quoted value strings per RFC 8659 §4.2; TLS-RPT-TXT-RR encodes the reporting policy via the rua=mailto:... / rua=https://... URI-scheme tag list per RFC 8460 §3.2 with semicolon-separated tag delimiters; both protocols' tag-list byte grammars are publisher-side-strict and produce publication-collapse on minor syntax errors (unmatched quotation marks, missing semicolons, invalid iodef URI scheme, invalid rua= URI scheme); (iii) publisher-side-syntax- error-collapses-entire-publication parallel — CAA-RR with a typo in the CA identifier (0 issue "ets-encrpt.org" instead of "letsencrypt.org") collapses the publisher's INTENDED CA-authorisation contract entirely; TLS-RPT-TXT-RR with a typo in the rua URI scheme (rua=mailtoo:... instead of rua=mailto:...) collapses the publisher's INTENDED receiver-side- reporting contract entirely; both protocols' publisher-side-syntax errors are silent receiver-side (CA simply refuses to issue / receiving MTA simply doesn't send reports) and require operator-side proactive validation; (iv) DNS-RR-publication-as- operator-runbook-discipline parallel — CAA-RR publication-discipline requires DNSSEC pairing (per RFC 8659 §6 normative recommendation), low-TTL during CAA changes (per RFC 8659 §6 operational guidance), and pre-deployment validation against the operator's existing CA pool; TLS-RPT- TXT-RR publication-discipline requires the same operator-runbook patterns (DNSSEC pairing for receiver-side confidence the report-target URI hasn't been hijacked, low-TTL during report-aggregator migration, and pre-deployment validation against the operator's report-aggregator vendor's accepted URI schemes). Pair this page (the CAA-RR byte-grammar protocol pillar) with the TLS-RPT record-syntax spoke (the RFC 8460 §3 TLS-RPT TXT-RR byte-grammar reference) when an operator authors the publisher-side DNS-RR-byte-level publication discipline for transport-security incident reporting and needs to apply the sentinel-token / tag-list / syntax- error-collapse / DNSSEC-pairing operator-runbook patterns the CAA protocol introduces to the parallel TLS-RPT TXT-RR publication context.
• TLS-RPT JSON report format — the CAA-AUTHORIZATION-FAILURES-SURFACE-AS- TLS-RPT-RESULT-TYPES companion to this CAA pillar. Where THIS page documents the CAA protocol's certificate-authority- authorization primitive (the 0 issue "ca.example", 0 issuewild, iodef, and contactemail / contactphone / validationmethods / accounturi RFC 8657 extensions, the CA/Browser-Forum-Baseline-Requirements- mandated pre-issuance CAA-check protocol), the TLS-RPT report-format spoke documents the RFC 8460 §4 JSON schema whose result-type enum encodes the downstream consequences when CAA blocks public-PKI cert issuance for the mta-sts.<domain> vhost. The CAA-AUTHORIZATION-FAILURES-SURFACE-AS- TLS-RPT-RESULT-TYPES cross-reference establishes four specific CAA-to-TLS-RPT- result-type mappings: (i) CAA blocks issuance → cert never deployed → sts-webpki-invalid result-type — when the 0 issue property tag on THIS page omits the CA the operator's ACME client requested, the MTA-STS vhost has no valid cert, and every receiving-MTA-side TLS handshake to that vhost surfaces a sts-webpki-invalid entry in the failure-details[] array of the receiver-generated TLS-RPT report; (ii) CAA rotated mid-flight → cert deployed but new cert blocked at renewal → certificate-expired result-type — when CAA is TIGHTENED to remove the operator's existing CA between renewal cycles (a common CA-migration mistake), the existing cert runs out and the renewal fails the pre-issuance CAA check; receiving MTAs surface certificate-expired in TLS-RPT once the cert lifetime expires; (iii) iodef CAA-violation reports complement TLS-RPT receiver-side reports — the iodef property tag on THIS page subscribes the operator to incident reports from issuing CAs when CAA-violation attempts occur (the CA-side perspective); TLS-RPT reports document the receiver-side perspective on the SAME cert-issuance failure (cert never reaches the receiving MTA); the two reporter channels together establish the full bidirectional incident audit trail; (iv) the report-id + date-range redelivery deduplication semantics on the receiver side are what CAA operators consume when correlating CAA-incident- report timestamps with TLS-RPT receiver- side failure-session-count totals across a CAA-rotation event window — the <reporter>!<policy-domain>!<unix-start>!<unix-end>.json[.gz] filename convention on the TLS-RPT report- format spoke is the deduplication key. Read THIS page when authoring the CAA record that authorises the operator's CAs; read the TLS-RPT report-format spoke when reading the JSON report whose result-type enum encodes the downstream failures the CA-authorization landscape produces.
• DMARC explained — the email message-authentication standard DMARC Analyzer is built around. Indirectly depends on CAA via the transport-security stack.
• SPF explained — Sender Policy Framework (RFC 7208). Companion email-authentication standard.
• include: vs ip4:/ip6: vs a: vs mx: SPF mechanism choice — the CAA-PROPERTY-TAG-CHOICE-MATRIX- PARALLELS-SPF-MECHANISM-TYPE-CHOICE-MATRIX cross-protocol companion to this CAA- records reference. Where THIS page documents the CAA RR's per-property-tag publication discipline (the publisher's choice of issue vs issuewild vs iodef vs contactemail vs contactphone property tags each carries structurally-distinct X.509-pre-issuance-authorization semantics the issuing CA enforces at certificate- issuance time), the include-vs-ip4-vs-a- vs-mx spoke is the STRUCTURAL-PARALLEL per-SPF-mechanism-type-choice decision matrix at the SMTP-sender-authorization layer. The CAA-PROPERTY-TAG-VS-SPF- MECHANISM-TYPE-CHOICE cross-reference establishes FOUR structurally-distinct dimensions where the spoke's per- mechanism reference parallels THIS page's per-property-tag reference at the cross- protocol DNS-published-authorization boundary: (i) per-property-tag-vs-per- mechanism-type publication-token-choice parallel — the spoke documents the publisher's four-mechanism-type choice (include: / ip4: + ip6: / a: / mx:) parallel to THIS page's five-property- tag choice — in both cases the publisher's per-DNS-RR-published-token choice directly determines which downstream-enforcer (the CA at issuance time for CAA, the recipient MTA at SMTP-receipt time for SPF) will accept the authorization-grant; the spoke is the canonical per-mechanism-type reference at the SMTP-sender- authorization layer paralleling THIS page's per-property-tag reference at the X.509-issuance-authorization layer; (ii) wildcard-policy differentiation parallel — issuewild vs issue parallels mx: + a: vs ip4: literal — the spoke documents the per-mechanism- type semantics where mx: and a: resolve DNS-record- sets dynamically (potentially expanding as the publisher rotates MX or A records) while ip4: / ip6: literals are static — paralleling THIS page's issuewild-tag-broader- authorization-scope semantics vs issue-tag-FQDN-narrower- authorization-scope semantics: in both DNS-published-authorization families the publisher's choice between DYNAMIC-EXPANSION-CONVENIENCE (issuewild / mx: / a:) and EXPLICIT- ENUMERATION-DEFENSIVENESS (issue / ip4: literal) follows the same structural trade-off across protocols; (iii) multi-CA permission stacking parallels include:-cascade stacking — the spoke documents how publishers stack multiple include: tokens to authorize multiple external- sender platforms (Mailchimp + SendGrid + Salesforce concurrent), each include: token representing a per-platform delegated authorization scope — paralleling THIS page's multi-CA permission stacking pattern where publishers stack multiple issue property-tag records (letsencrypt.org + digicert.com + sectigo.com concurrent), each issue tag representing per-CA delegated issuance authority: in both DNS-published-authorization families the publisher composes multi-token sets to grant concurrent authorization to multiple downstream authorities; (iv) per-FQDN-tree-cascade inheritance parallels SPF redirect= + include: cascade traversal — the spoke documents the SPF include:- cascade recursion and redirect= delegation semantics where the receiver traverses delegated SPF trees consuming the §4.6.4 ten- lookup budget — paralleling THIS page's CAA-tree-traversal-up-the- FQDN-hierarchy semantics where the issuing CA walks the FQDN tree UPWARD looking for the nearest- ancestor CAA record (RFC 8659 §3 tree-climb algorithm): in both DNS-published-authorization families the enforcer (receiver for SPF, issuing-CA for CAA) executes a per-DNS-tree-traversal algorithm whose budget-bounded / ancestor-bounded termination contract the publisher MUST author DNS records to satisfy. Read the include-vs-ip4-vs-a-vs-mx spoke alongside this CAA-records- explained reference when authoring cross-protocol per-domain DNS- published-authorization-policy records — the spoke is the canonical per-mechanism-choice reference at the SMTP-sender- authorization layer whose four mechanism-type dimensions structurally parallel THIS page's per-property-tag reference at the X.509-issuance-authorization layer, enabling the operator to author both DNS-published authorization-policy families with consistent per-token-choice discipline.
• SPF permerror vs temperror — the CAA-DNS-PUBLICATION-DISCIPLINE- PARALLEL-TO-SPF-RECORD-PUBLICATION- DISCIPLINE companion documenting the structural-parallel DNS-published- authorization-policy publication-time- error-class taxonomy across the two DNS-RR-published authorization-policy families this site references: (a) the CAA-RR-published X.509-issuance- authorization policy THIS page documents (RFC 8659 issue / issuewild / iodef property-tag set + the pre-issuance CA-side CAA-tree-walk check the issuing CA performs from certificate-target FQDN upward to the apex), AND (b) the SPF- TXT-RR-published SMTP-sender-authorization policy the SPF-permerror spoke documents (RFC 7208 v=spf1 mechanism-token- list qualifier grammar + the receiver-side per-message envelope-MAIL- FROM evaluation against the authorized- sender set). Where THIS page documents the CAA-record publication-time syntax- error class operators face (malformed property-tag value, wrong issue/issuewild tag-grammar, base64-decode-failure on iodef URI, accidentally- excluded fallback issuer), the SPF- permerror-vs-temperror spoke is the SPF-side-PARALLEL ERROR-CLASS REFERENCE documenting the structurally-analogous publication-time error-class operators face on the SPF-record-publication boundary. The four-axis CAA-PUBLICATION- DISCIPLINE-VS-SPF-PUBLICATION-DISCIPLINE comparison exposes the structurally- distinct DNS-PUBLISHED-AUTHORIZATION- POLICY error-class-pair parallels: (i) CAA-record syntax-error classes → SPF-record permerror verdict from publication-time syntax violation — the canonical CAA- publication-time syntax errors THIS page documents (malformed property-tag value in 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123" with mis-escaped semicolon, missing property-tag value, wrong critical flag-bit byte position) STRUCTURALLY PARALLEL the canonical SPF-publication-time syntax errors the spoke documents (malformed mechanism token, invalid CIDR notation on ip4:/ip6: mechanism, missing ~all qualifier terminator, accidentally-truncated record at the 255-byte string-segment boundary) — both yield receiver-side or CA-side permerror-class verdict from the byte-grammar-conformance check; (ii) CAA-record DNS- resolution failure-class → SPF- record temperror verdict from transient DNS-resolution failure — the canonical CAA-resolution- failure cases the issuing CA encounters (transient SERVFAIL during the pre- issuance CAA-tree-walk, authoritative- nameserver outage during peak certificate- issuance traffic, recursive-resolver- cache eviction window between TTL rotation and propagation) STRUCTURALLY PARALLEL the canonical SPF-resolution- failure cases the spoke documents (transient SERVFAIL during the receiver- side per-message SPF evaluation, recursive-resolver-cache eviction between the publisher's SPF-record TTL rotation and recursive propagation, network-partition-induced query timeout during peak send-traffic) — both yield the temperror-class verdict + retry-deferred receiver-side behavior; (iii) CAA-record- publication-discipline operator-side publication-quality-as-KPI → SPF- record-publication-quality-as-KPI — the publication-discipline operator responsibility THIS page documents (per- domain-tree per-property-tag publication- quality discipline) STRUCTURALLY PARALLEL the SPF-record-publication-quality-KPI the spoke documents (per-domain SPF- record-syntax-pass rate observed by the receiver's daily aggregate-report-row spf=permerror rate, per- domain SPF-record-DNS-resolution- availability KPI observed by the spf=temperror rate); publication-quality is a publication- time operator-controlled DISCIPLINE, DNS-resolution-availability is a runtime upstream-DNS-authority OPERATIONAL property — the two error classes both surfaces require independent monitoring on both authorization-policy layers; (iv) CAA-vs-SPF cross-protocol publication-error-class-correlation operational insight → per-domain DNS-publication-pipeline-health holistic-KPI — when the same domain's CAA records AND SPF records both regress to permerror- class verdicts within the same publication window, the operational insight is a common-root-cause DNS- publication-pipeline regression (typical causes: DNS-provider UI bug, mass- publication automation script that corrupted multiple RR types, recursive- resolver-cache poisoning event); the spoke documents the SPF-side observation surface for this cross-protocol regression pattern that THIS page's CAA-monitoring discipline observes from the X.509-issuance-authorization side. Read the SPF-permerror-vs-temperror spoke when the operator's CAA-record- monitoring discipline has just observed a regression in the per-day CAA-record- syntax-pass rate (or a transient spike in CA-side iodef incident- reports) and the operator needs the parallel SPF-side error-class taxonomy to determine whether the regression spans both DNS-published-authorization- policy families (suggesting a common- root-cause DNS-publication-pipeline regression) OR is isolated to the CAA- side authoring discipline alone.
• DKIM explained — DomainKeys Identified Mail (RFC 6376). Companion email-authentication standard.
• DMARC multi-domain strategy — the PER-DOMAIN-TREE-CAA-RR-CASCADE- PARALLELS-PER-DOMAIN-TREE-DMARC-POLICY- CASCADE companion to this RFC 8659 CAA protocol reference. Where THIS page documents the SINGLE-DOMAIN-TREE CAA authoring discipline (the apex-domain issue / issuewild property-tag set; the per-subdomain CAA-tree-walk resolution rule RFC 8659 §3 mandates the issuing CA perform from the certificate-target FQDN upward to the apex; the iodef incident-reporting URI; the critical flag bit semantics), the multi-domain-strategy spoke documents the OPERATIONAL DISCIPLINE the multi-domain operator MUST follow to maintain INDEPENDENT CAA property-tag sets across the FIVE structurally-distinct multi-domain operator cohorts: (i) MULTI-BRAND ESTATES where each brand- domain runs its own certificate-procurement operation potentially using a different CA (brand-A using DigiCert for VMC issuance, brand-B using Entrust for legacy EV certificate compatibility, brand-C using Let's Encrypt for development-tier deployment) — each brand-domain's CAA issue property-tag set MUST enumerate the CA(s) authorised to issue certificates for THAT specific brand- domain, INDEPENDENTLY of sibling brand- domains' CAA preferences; (ii) ACQUISITION DOMAINS recently acquired through M&A whose pre-acquisition CAA posture is UNKNOWN — the multi-domain operator MUST inventory the acquired domain's existing CAA records BEFORE any CA-issuance procurement against the acquired domain (a frequent acquisition-tier discovery is the acquired domain has NO CAA records, meaning any public CA may issue — the operator MUST author CAA records EQUAL TO the parent-organization CAA discipline before proceeding); (iii) PARKED DOMAINS the operator owns but does not procure certificates for where the correct multi- domain-strategy choice is to publish CAA issue ";" EXPLICIT-DENY (no CA may issue any certificate for the parked domain) — a STRUCTURALLY-DIFFERENT choice from the primary-domain CAA property-tag set; (iv) SEND-ONLY DOMAINS (mailer.example.com bounce.example.com) used for outbound transactional mail with their own certificate-procurement operations whose CAA discipline may ratchet faster than the receive-also primary domain (the send-only domain's certificate-using-population is bounded to a small known ESP set); (v) RECEIVE-ONLY DOMAINS used only for inbound mail with certificate-procurement bounded to the inbound MX-host's transport-security chain (the multi-domain operator's CAA discipline for receive-only domains typically authorizes only the MX-host's certificate-procurement CA). Read the multi-domain-strategy spoke when an organizational-restructure event (merger, divestiture, brand consolidation) forces a re-evaluation of the entire CAA property-tag set ACROSS the multi-domain portfolio — the same per-organizational- domain DNS-RR-cascade discipline that applies to DMARC p= tag publication, SPF include-chain authoring, DKIM selector deployment, MTA-STS policy- file publication, TLS-RPT rua= mailbox publication, AND BIMI VMC issuance applies to CAA property-tag authoring as a CROSS-PROTOCOL DNS-RR-PER- ORGANIZATIONAL-DOMAIN PATTERN.
• DNS propagation explained — the DNS-INFRASTRUCTURE-CACHE-AGING companion to this CAA pillar. Where THIS page documents the CAA protocol's certificate-authority-authorization primitive (RFC 8659: the 0 issue "ca.example" and 0 issuewild property tags, the iodef incident-report URI, the contactemail / contactphone / validationmethods / accounturi RFC 8657 extensions, and the CA/Browser-Forum-Baseline-Requirements- mandated pre-issuance CAA-check protocol every public CA performs before signing a new certificate), the DNS-propagation spoke documents the DNS-INFRASTRUCTURE-LAYER behaviour that determines WHEN a fresh CAA- record rotation BECOMES OBSERVABLE at the issuing CA's pre-issuance CAA check: per- record TTL semantics (RFC 1035 §3.2.1 + RFC 2181 §8), the resolver-cache minimum + maximum cap quirks that determine when each issuing CA's recursive resolver will FIRST see the rotated CAA-property record, and the diagnostic workflow operators run when a CAA-record rotation (e.g. switching from letsencrypt.org to digicert.com for a fresh Verified Mark Certificate issuance) appears to not take effect at the issuing CA's pre-issuance CAA check despite the operator confirming the new CAA record is present in the authoritative zone: dig / kdig directly against the authoritative nameservers ("dig example.com CAA @ns1.your-dns-provider.com") to confirm publication, then dig with +norecurse against multiple recursive resolvers to confirm what each cache believes, then the web-based propagation checker for the global cache snapshot. Read the propagation spoke when a fresh CAA-record rotation produces "CAA record does not authorize this CA" errors at the issuing CA's certificate- issuance step despite the operator's confidence that the new CAA property is published — DNS propagation of the new CAA record across the issuing CA's recursive-resolver path is almost always the explanation in the first 24-72 hours following a CAA-rotation event, especially because the CA/Browser-Forum baseline mandates the issuing CA perform the CAA check at the moment of issuance — not at the time the certificate-signing request was submitted.
• BIMI VMC certificates deep dive — the CAA-CONSTRAINS-VMC- ISSUANCE-UPSTREAM-PKI- GATEKEEPER companion reference. Where THIS page documents the CAA RR-type-257 byte-syntax, the issue / issuewild / iodef properties, the flags=128 critical-bit semantics, and the canonical publisher-side CA-issuance- policy assertion contract receivers (the issuing CA at certificate-issuance-time per CA/Browser-Forum Baseline Requirements) MUST RESPECT before issuing any X.509 certificate for the publisher's domain, the BIMI-VMC- certificates spoke is the authoritative reference for ONE OF THE MOST OPERATIONALLY- IMPORTANT downstream certificate-issuance scenarios the CAA records on the publisher's apex domain DIRECTLY GATEKEEPER: the VMC (Verified Mark Certificate) procurement workflow that BOOTSTRAPS BIMI inbox-display eligibility. The VMC is an EXTENDED-VALIDATION X.509 certificate issued by ONE OF ONLY TWO CURRENTLY-OPERATING VMC-issuing CAs (DigiCert and Entrust at time of writing) — the certificate binds the publisher's TRADEMARK- REGISTERED MARK (per USPTO, EUIPO, UKIPO, JPO trademark registries depending on the publisher's jurisdiction) to the publisher's DOMAIN per the publisher's BIMI-RECORD- DECLARED l= SVG-URI authoring step. A publisher with CAA records at the apex domain enumerating issue "letsencrypt.org" and issue "sectigo.com" but NOT issue "digicert.com" or issue "entrust.net" ENCOUNTERS CA-SIDE REFUSAL- TO-ISSUE at the VMC application step — DigiCert / Entrust per CA/Browser-Forum BR §3.2.2.8 perform the CAA check at the moment of VMC issuance and find their domain (digicert.com / entrust.net) ABSENT from the publisher's issue property and HARD-REFUSE the VMC issuance regardless of whether the trademark validation, SVG conformance, and underlying public-key validation steps succeeded. The canonical pre-VMC- procurement deployment sequence: (i) confirm the trademark registration is FINAL and the registry certificate is on hand; (ii) AUDIT THE PUBLISHER'S APEX DOMAIN CAA RECORDS for the VMC CA's domain (issue "digicert.com" and/or issue "entrust.net") and ADD if absent; (iii) wait for CAA propagation through the global DNS resolver tier (per CAA record TTL); (iv) submit the VMC application; (v) receive the issued VMC certificate; (vi) finalise the SVG-Tiny-PS file per BIMI rendering rules; (vii) publish the default._bimi.<domain> TXT record with v=BIMI1; l=https://...svg; a=https://...pem declaring both the SVG and the VMC PEM file paths; (viii) verify receiver-side BIMI display at Gmail, Yahoo, Apple Mail, Fastmail (the current rolling-out receivers as of writing). Read the BIMI-VMC- certificates spoke alongside this CAA page when authoring any publisher BIMI- deployment runbook — the VMC application step is UPSTREAM-GATED by the publisher's CAA records at the apex, and operators skipping the CAA-pre- audit step waste application time and incur CA-side refusal-to-issue rounds the CAA-pre-audit would have caught before application submission.
• BIMI SVG Tiny PS logo requirements — the CAA-PRE-AUDIT-AS-UPSTREAM- PKI-GATEKEEPER-WHEN-SVG-ASSET-IS- SELF-HOSTED-BEHIND-PUBLISHER- CONTROLLED-HTTPS-ENDPOINT companion reference. Where THIS page documents the CAA record's issue / issuewild / iodef property contract publishers author at the apex to constrain X.509 cert issuance across all sub-domains, the BIMI-SVG-Tiny-PS spoke documents the byte-level SVG Tiny PS profile compliance contract for the brand logo asset that the BIMI l= tag points at — and the LINKED CONSIDERATION is that publishers who self-host the SVG asset behind a publisher- controlled HTTPS endpoint (rather than a SaaS-platform-hosted CDN endpoint) require CAA-authorised X.509 cert issuance at the SVG-hosting sub-domain to enable receiver-side MUA fetchability, across four CAA-vs-SVG-publication- prerequisite coordination dimensions: (i) when the SVG asset is self-hosted at https://bimi.<domain>/logo.svg or https://<domain>/.well-known/brand/logo.svg, the publisher's CAA issue tag set MUST encompass the CA issuing the SVG-hosting endpoint cert (typically Let's Encrypt for the publisher-controlled HTTPS endpoint distinct from the VMC- issuing CA), composing the per- sub-domain PKI-trust-chain validation surface at the MUA-side SVG-asset fetcher, (ii) CAA iodef URI provides publisher-side observability for attempted unauthorised cert issuance against the SVG-hosting sub-domain, surfacing attacker- reconnaissance of SVG-asset delivery surfaces ahead of attempted cross-domain logo- substitution at the publisher's SVG fetch boundary, (iii) the SVG-asset's byte-level Tiny-PS profile compliance the BIMI-SVG- Tiny-PS spoke documents and the cert-chain validity the CAA- controlled cert-issuance pipeline gates compose into the MUA-side TWO-PHASE BIMI display eligibility check (CAA-authorised HTTPS cert chain validates → SVG-Tiny-PS byte-profile validates → VMC SVG-hash-binding validates → BIMI logo renders), and (iv) publishers using a SaaS-platform- hosted SVG asset (rather than self-hosting) shift the CAA- cert-issuance discipline OUT of the publisher's CAA-pre-audit scope and INTO the SaaS-platform- provider's PKI discipline, composing trust-delegation across the SaaS-platform boundary. Read the BIMI-SVG-Tiny-PS spoke alongside this CAA page when scoping a self-hosted SVG-asset deployment — the CAA-pre-audit discipline for the VMC issuance documented in the sibling-entry above extends symmetrically to the SVG-asset-hosting endpoint's cert-issuance pipeline when the publisher self-hosts the asset rather than delegating to a SaaS-platform-hosted CDN.
• DMARC for shared hosting — the SHARED-HOSTING-TENANT-PUBLISHES-CAA- AT-THE-SAME-PROVIDER-MANAGED-DNS-ZONE-THE- DMARC-PUBLICATION-DISCIPLINE-TARGETS-AT- FOUR-PROVIDER-MANAGED-ZONE-CO-PUBLICATION- COORDINATION-DIMENSIONS companion to this CAA reference. Where THIS page documents the CAA-RR byte-level grammar at the apex- domain DNS publisher boundary (the RFC 8659 <flag> <tag> <value> CAA-RR record body, the canonical property-tag triplet issue / issuewild / iodef, the receiver-side critical-flag bit contract, and the CA- side pre-issuance CAA-fetch + tag- evaluation algorithm), the shared-hosting spoke is the per-shared-hosting-tenant per-domain DMARC publication-discipline reference whose hosting-provider-managed DNS-zone publisher-side surface is the SAME zone the CAA records THIS page documents must be co-published at — at four provider-managed zone co-publication coordination dimensions: (i) cPanel Zone Editor / Plesk DNS Template provider- side publisher-surface coordination — the shared-hosting tenant's per-domain DMARC _dmarc.<domain> TXT-RR + CAA-RR at the apex domain are BOTH edited through the SAME hosting-provider- gated DNS-zone editor (cPanel Zone Editor on cPanel hosts, Plesk DNS Template on Plesk hosts, hPanel / DirectAdmin / ISPConfig on other panels) which means the shared-hosting tenant's per-domain CAA- record-authoring discipline THIS page documents is gated by the SAME hosting- provider-side DNS-publication-permission surface the per-tenant DMARC publication ladder bottoms out on; (ii) hosting- provider AutoSSL / Let's-Encrypt-via- AcmePHP CA-authorization coordination constraint — shared-hosting platforms typically issue per-vhost X.509 certificates through an AutoSSL pipeline (cPanel AutoSSL via Sectigo / Let's Encrypt) whose CAA-record-authorization THIS page documents must EXPLICITLY enumerate the per-platform issuance-CA (e.g. 0 issue "letsencrypt.org" + 0 issue "sectigo.com") at the SAME apex-domain DNS zone where the tenant's per-domain DMARC TXT-RR is published — a tenant whose CAA record excludes the hosting-provider's AutoSSL CA encounters AutoSSL-issuance failure for the per-vhost cert serving the same domain whose DMARC publication the shared-hosting spoke documents; (iii) shared-mta-sts-host-certificate- issuance-via-AutoSSL coordination constraint — when a shared- hosting tenant additionally publishes an MTA-STS policy at https://mta-sts.<tenant- domain>/.well-known/mta-sts.txt, the per-tenant MTA-STS-policy-host certificate is issued through the SAME hosting-provider AutoSSL pipeline whose CAA-authorization THIS page documents, making the per-tenant CAA-record publication an UPSTREAM prerequisite for the per-tenant transport-layer hardening the DMARC-for-shared-hosting spoke documents at the cross-protocol per- tenant boundary; (iv) per-tenant DNS-zone-edit-throttle vs CAA + DMARC co-publication race-condition surface — shared-hosting providers commonly throttle per-tenant DNS-zone-edit frequency (cPanel typically caches zone edits for 5-15 minutes before propagating to the recursive resolver tier), meaning the per-tenant CAA-rotation + DMARC-rotation publication-ladder must be coordinated through a single zone-edit transaction to avoid per-edit-throttle-induced split-zone-state during the rotation cutover window. Read the shared-hosting spoke ALONGSIDE this CAA reference whenever a shared-hosting tenant's per- domain DNS-publication ladder requires coordinating CAA + DMARC + (optionally) MTA-STS + TLS-RPT co-publication across the SAME provider-managed zone editor surface — THIS page gives the CAA-RR byte-level publication contract, the shared-hosting spoke gives the per- tenant cross-protocol DMARC publication- discipline reference the per-tenant provider-managed zone-editor publication ladder bottoms out on.
• DNS Record Generator — interactive wizard for building SPF, DKIM, DMARC, BIMI, MTA-STS, CAA, and TLS-RPT records with syntax validation.
• Domain Security Checker — live DNS lookups for SPF, DKIM, DMARC, MTA-STS, TLS-RPT, CAA, BIMI, and DNSSEC against any domain.
• DMARC attacker-bypass techniques (defender's red-team catalogue) — the CAA-RECORD-ABSENCE-OR-PERMISSIVE- ISSUANCE-AUTHORIZATION-AS-LOAD-BEARING- DMARC-BYPASS-VECTOR companion to this CAA records reference. Where THIS page documents the RFC 8659 CAA issue / issuewild / iodef property-tag publication discipline + the CA/Browser-Forum CAA-checking-at-issuance mandate + the per-publisher per-domain CA- authorisation-control surface, the DMARC- attacker-bypass spoke is the OPERATOR-SIDE 22-technique attacker-bypass classification framework whose TRANSPORT-LAYER-MITM-VIA- ATTACKER-CONTROLLED-CERTIFICATE-ISSUANCE technique class consumes the CAA-record- absence or permissive-issuance-authorization misconfigurations at FOUR CAA-misconfiguration- to-attacker-bypass-exploitation dimensions: (i) CAA-record-absence attacker exploitation via arbitrary-CA-issuance — the attacker compromises ANY publicly-trusted CA (via the documented historical CA-compromise incidents involving DigiNotar, Comodo, and the documented bait-attack research surface against CAs without strong account-control attestation) to issue an attacker-controlled certificate for the publisher's MTA-STS hostname (mta-sts.<domain>) OR BIMI-VMC hostname, bypassing the per- publisher per-domain transport-layer MTA-STS policy enforcement AND the per-publisher per-domain BIMI-VMC display-gating, collapsing the per-receiver transport-layer DMARC-aligned- pass-rate observability floor and enabling per-message body-modification MITM that bypasses DKIM-aligned-pass — the attacker-bypass spoke documents this as the canonical CAA-record-absence attacker-bypass class the CAA-issue-tag-bounded- CA-set publication discipline THIS page documents protects against; (ii) permissive-CAA-issue-tag-set attacker exploitation via included-but- compromised CA — the attacker compromises a less-rigorously-attested CA that IS listed in the publisher's permissive CAA issue tag-set, exploiting the publisher's failure to scope the issue tag to the SMALLEST possible CA set actually used by the publisher's certificate issuance workflow, producing attacker-controlled cert issuance within the publisher's own permissive CAA policy — the attacker-bypass spoke documents this as the canonical permissive- CAA-issue-tag attacker-bypass class the minimal-CA-set discipline THIS page documents protects against; (iii) CAA-issuewild-tag- permissive-wildcard attacker exploitation — the attacker exploits the publisher's broad issuewild tag-set OR the absence of a restrictive issuewild tag (treated as equivalent to the issue tag- set per RFC 8659 §4.3) to obtain a wildcard certificate from any included CA, enabling attacker-controlled cert coverage of arbitrary subdomains including mta-sts.<domain> and BIMI-VMC subdomain — the attacker- bypass spoke documents this as the canonical wildcard-certificate attacker-bypass class the per-subdomain-scoped issuewild discipline THIS page documents protects against; (iv) CAA-iodef- tag-absent attacker exploitation via silent cert-issuance suppression — the publisher's failure to publish the iodef= property tag suppresses per-publisher per- domain notification of attempted-but-failed cert issuance events at non-authorised CAs, eliminating the canonical detection-layer evidence-row pattern operators consume to detect ongoing attacker-controlled-cert- issuance reconnaissance — the attacker-bypass spoke documents this as the canonical detection-layer CAA- iodef-absent attacker-bypass- detection-suppression class the iodef=mailto: / iodef=https: publication discipline THIS page documents protects against. Read the DMARC-attacker-bypass spoke ALONGSIDE this CAA records reference when designing the per-publisher per-domain CAA-attacker-bypass-defense posture and when investigating per-publisher per-domain attacker-controlled-cert-issuance reconnaissance evidence — the spoke is the canonical 22-technique attacker-bypass classification framework whose transport- layer-MITM-via-attacker-controlled- certificate-issuance technique class consumes the CAA-misconfiguration primitives this page documents.
• DMARC for cPanel-hosted domains — the PER-CPANEL-MANAGED- HOSTING-TENANT-ZONE-EDITOR companion to this CAA-record- publication reference. Where THIS page documents the CAA record byte-grammar per RFC 8659 (the issue, issuewild, iodef property tags, the per-property CA-domain-list authorization semantics, the critical-flag RFC 8657 extensions for validationmethods= + contactemail=), the dmarc_for_cpanel spoke documents the per-cPanel-tenant Zone Editor + AutoSSL infrastructure whose CAA-publication-interface IS the canonical load-bearing per-tenant CAA-record-publication infrastructure the per-publisher CAA-publication-discipline THIS page documents resolves to at the per-shared-hosting-tenant deployment boundary. FOUR structurally-distinct PER-CPANEL- INTERFACE-VS-CAA-PUBLICATION- STAGE-COUPLING-DIMENSIONS the dmarc_for_cpanel spoke operationally documents: (i) per-cPanel-tenant Zone Editor "Add Record" → TYPE=CAA → FLAGS=0 → TAG= issue → VALUE= letsencrypt.org AS LOAD-BEARING-PER-TENANT-AUTOSSL- ISSUANCE-AUTHORIZATION-PRIMITIVE — cPanel's AutoSSL feature defaults to Let's Encrypt (or cPanel-bundled Sectigo) issuance; without a per-tenant issue-CAA record authorizing the AutoSSL provider, AutoSSL issuance fails with the CA-side CAA-check rejection THIS page catalogues as a publication- defect class; the dmarc_for_ cpanel spoke documents the canonical per-tenant 0 issue "letsencrypt.org" + 0 issue "sectigo.com" Zone Editor publication that authorises the AutoSSL stack every per-tenant HTTPS certificate depends on; (ii) per- cPanel-tenant Zone Editor issuewild property- tag publication coordinated with per-tenant wildcard-Subject-Alt- Name issuance AS LOAD-BEARING- PER-TENANT-WILDCARD-CERT- ISSUANCE-AUTHORIZATION-PRIMITIVE — per-tenant subdomain sprawl (the cpanel.<domain>, webmail.<domain>, autodiscover.<domain>, autoconfig.<domain> AutoSSL service hostnames) often consumes a wildcard cert; the per-tenant 0 issuewild "letsencrypt.org" Zone Editor publication authorises the wildcard-Subject- Alt-Name issuance the per-tenant AutoSSL stack THIS page's CAA- record-property-tag-publication discipline depends on; (iii) per-cPanel-tenant Zone Editor iodef property-tag publication coordinated with the per-tenant contact-email-address rotation AS LOAD-BEARING-PER-TENANT- ISSUANCE-VIOLATION-NOTIFICATION- INFRASTRUCTURE-PRIMITIVE — the iodef:mailto: property-tag publishes the per- tenant security-incident contact for CA-side CAA-violation notifications; the dmarc_for_ cpanel spoke documents the per- tenant Zone Editor + cPanel contact-email-address-rotation discipline that coordinates the per-tenant iodef-TAG-published notification-address with the per-tenant cPanel-account-owner contact-email-field every per- tenant CAA-violation-notification- consumption operation THIS page's iodef-notification-infrastructure discipline depends on; (iv) per-cPanel-tenant Zone Editor TTL-discipline coordinated with the per-tenant AutoSSL- renewal-cadence + per-tenant CA- side CAA-check-cache-window AS LOAD-BEARING-PER-TENANT- OPERATIONAL-DISCIPLINE-PRIMITIVE — CA-side CAA-check validity windows (RFC 8657 + CA/Browser Forum baseline- requirement: 8-hour validity ceiling, frequent re-check) require per-tenant TTL coordination with the per-tenant AutoSSL- renewal cadence; the dmarc_for_ cpanel spoke documents the per- tenant Zone Editor TTL + AutoSSL renewal-cron coordination every per-tenant CA-side CAA- check-cache-coherence outcome THIS page's per-publisher CAA- TTL-coordination-discipline depends on. Read the dmarc_for_ cpanel spoke ALONGSIDE this CAA- record-publication reference whenever a per-cPanel-managed- hosting-tenant publisher scopes a per-tenant CAA-record deployment plan — the per-cPanel-tenant Zone Editor + AutoSSL stack THIS deployment spoke documents IS the canonical load-bearing per- shared-hosting-tenant CAA- publication infrastructure every per-tenant CA-side issuance- authorization outcome THIS page's CAA-publication-discipline catalogue depends on at the per- tenant deployment boundary.
• SPF for Google Workspace — the per-Workspace-tenant per-domain apex-zone v=spf1 include:_spf.google.com ~all TXT-RR publication discipline is the per-publisher per-domain envelope- layer authentication-record- publication primitive that coexists with the per-publisher per-domain apex-zone CAA RR publication primitive at the same authoritative DNS zone publication boundary. Joint SPF + CAA apex-zone RR publication discipline forms the per-publisher per-domain dual-RR-class authoritative DNS zone-editor commit cadence covering both the per- message envelope-MAIL-FROM authorization surface (SPF) and the per-tenant TLS-certificate issuance authorization surface (CAA) for the Workspace-tenant deployment topology.
• DKIM cryptography basics (RSA-2048 / Ed25519 / SHA-256) — the PER-PUBLISHER-CRYPTOGRAPHIC-DNS- PUBLICATION-DISCIPLINE-PARALLEL companion to this CAA reference. Where THIS page documents the CAA protocol at the byte level (the RFC 8659 <flag> <tag> <value> CAA-RR record-body grammar, the three canonical CAA property tags issue / issuewild / iodef, the critical-flag bit's RFC 8659 §4.1 receiver-side contract, the CA-side CAA-record-fetch and tag-evaluation algorithm before ACME-challenge-validated certificate issuance, the MX-host CAA inheritance contract for transport-security certificate authorisation), the DKIM- cryptography-basics spoke documents the PARALLEL message-authentication-layer per-publisher per-selector cryptographic- key-pair DNS publication discipline (RFC 6376 §3.3 rsa-sha256 / ed25519- sha256 algorithm catalogue, the per- selector 2048-bit RSA modulus floor, the per-publisher key-rotation cadence, the per-selector public-key TXT record v=DKIM1; k=rsa; p=<BASE64-key> byte-shape) whose per-publisher per- selector cryptographic-primitive publication is the structural-parallel DNS-rooted cryptographic-trust-anchor publication discipline at the message- authentication layer to the CAA-RR PKI-issuance-authorization publication discipline THIS page documents at the X.509-certificate-issuance-authorization layer. The CAA-VS-DKIM-CRYPTOGRAPHY cross-reference establishes FOUR structurally-distinct cross-layer cryptographic-DNS-publication coupling dimensions: (i) BOTH protocols are per-publisher per-domain DNS-RR cryptographic-control publication disciplines — CAA publishes per-domain CA-issuance-authorization at the apex; DKIM publishes per-selector public-key cryptographic-anchor under <s>._domainkey.<d> — the per-publisher per-domain DNS-RR publication primitive is the shared cryptographic-control publication substrate; (ii) CAA gates per- publisher per-domain X.509-certificate issuance (PKIX trust-anchor publication); DKIM publishes per-publisher per- selector message-signature trust-anchor (rsa-sha256 / ed25519-sha256 trust- anchor publication) — the two protocols occupy complementary cryptographic-publication layers (PKI- issuance-authorization layer vs message- authentication layer) of the per- publisher per-domain cryptographic- publication-discipline stack; (iii) per-publisher per-selector DKIM public-key TXT-record publication and per-publisher per-domain CAA RR publication share an identical operational discipline — both require per-publisher zone-editor commit cadence with DNS-propagation-aware overlap windows during rotation events (per-selector DKIM key rotation per RFC 6376 §3.6.1; per-CA migration via dual- CA issue publication windows per RFC 8659 §3) — the operator-side zone-editor cadence and DNS-propagation-aware overlap-window discipline transfers directly between the two protocols; (iv) per- publisher DKIM p=-tag base64 public-key publication and per-publisher CAA iodef=mailto: incident- report-channel publication are both per-publisher cryptographic-discipline- publication primitives the operator-side zone-editor maintains as load-bearing per-publisher per-domain cryptographic-policy publications — both rely on the per-publisher zone-editor commit discipline as the load-bearing authoritative-DNS-zone publication substrate. Read this CAA reference when DEPLOYING the per-publisher per-domain CA-issuance-authorization publication posture at the X.509-certificate- issuance-authorization layer; read the DKIM-cryptography-basics spoke when DEPLOYING the per-publisher per-selector cryptographic-key-pair publication posture at the message-authentication layer — both are load-bearing per- publisher per-domain DNS-RR cryptographic- publication disciplines the operator- side authoritative-DNS-zone-editor maintains in parallel.
• DMARC monitoring — the CAA-RR-PUBLICATION-DISCIPLINE-AS- CROSS-PROTOCOL-PEER-OF-DMARC-RECORD- PUBLICATION-DISCIPLINE companion to this CAA-RR byte-syntax reference. Where THIS page documents the per-publisher per-domain RFC 8659 CAA-RR publication discipline (per-CA authorization at <domain> CAA 0 issue "<ca>", per-CA wildcard authorization at 0 issuewild "<ca>", per-domain CA- violation reporting at 0 iodef "mailto:<reporter>", empty- CA explicit-zero authorization at 0 issue ";") at the authoritative-DNS zone-apex boundary, the DMARC-monitoring spoke documents the per-publisher per-domain DMARC-record publication discipline whose downstream per-day per-receiver per-source-IP aggregate-XML KPI dashboard surfaces the per-publisher per-domain DMARC-disposition and DKIM-aligned-pass and SPF-aligned-pass cohort distribution at the per-source-IP granularity. The CAA-RR-PUBLICATION-VS- DMARC-MONITORING-KPI-DASHBOARD cross- reference establishes FOUR cross-protocol publication-discipline-as-monitoring- substrate coupling dimensions: (i) parallel zone-apex publication substrate — the per-publisher per-domain <domain> CAA RR publication discipline this page documents structurally parallels the per-publisher per-domain _dmarc.<domain> TXT-RR publication discipline whose downstream KPI dashboard the monitoring spoke documents; both publications target the publisher's authoritative zone, both are operator-side zone-editor commits, both gate the existence of the corresponding downstream observability- signal (CAA gates per-publisher per-CA cert-issuance authorization; DMARC gates per-publisher per-domain aggregate-report emission to the rua= mailbox the monitoring KPI dashboard feeds on); (ii) per-publisher per-domain CAA-RR- iodef-mailto reporting channel as cross- protocol structural-parallel to per- publisher per-domain DMARC-rua mailto reporting channel feeding the monitoring KPI dashboard — the per-publisher per-domain CAA 0 iodef "mailto: <reporter>" reporting-channel publication this page documents structurally parallels the per-publisher per-domain DMARC rua=mailto: <collector> reporting-channel publication the monitoring spoke's KPI dashboard ingests aggregate-XML reports from; both reporting channels are per- publisher per-domain operator-side opt-in mailto-URI-based aggregate-event streams that the publisher's downstream operations team consumes for per-publisher per-domain observability of per-protocol-layer events (CAA reports unauthorized-CA-issuance- attempt events; DMARC reports per-message authentication-disposition events at the per-source-IP granularity the monitoring spoke's KPI dashboard surfaces); (iii) cross-protocol publication- discipline drift as upstream regression signal feeding the monitoring KPI dashboard's per-day per-receiver per- source-IP authentication-result-drift alert — the per-publisher per- domain CAA-RR publication-discipline this page documents (per-CA authorization precision, per-CA wildcard authorization accuracy, per-CA-removal cert-procurement coordination) and the per-publisher per- domain DMARC-record publication-discipline the monitoring spoke's KPI dashboard depends on are BOTH operator-side zone- editor disciplines whose drift (e.g. an ad-hoc CAA-RR edit removing a previously- authorized CA, an ad-hoc _dmarc TXT edit changing p=reject to p=none) manifests as downstream observability- signal drift in the per-publisher per- domain monitoring KPI dashboard; the monitoring spoke documents the per-day- bucket per-receiver per-source-IP disposition-rate-drift alert as the canonical downstream signal of upstream publication-discipline drift this page's CAA-RR authoring discipline parallels; (iv) per-publisher per-domain coherent zone-apex-publication discipline across CAA-RR + DMARC-RR + SPF-RR + TLS- RPT-RR as upstream prerequisite for comprehensive per-publisher per-domain monitoring KPI dashboard coverage — the per-publisher per-domain zone- editor commit discipline whose CAA-RR publication this page documents is the SAME per-publisher per-domain zone-editor commit discipline whose DMARC-RR publication the monitoring spoke's KPI dashboard depends on; together with the per- publisher per-domain SPF and DKIM and TLS-RPT and MTA-STS publication discipline peers, these per-RR-type publication disciplines collectively form the per-publisher per-domain coherent- publisher publication-discipline boundary the monitoring spoke's KPI dashboard depends on for comprehensive per-day per- receiver per-source-IP authentication-and- transport-and-cert-issuance observability. Read the DMARC-monitoring spoke alongside this CAA-RR byte-syntax reference when operating per-publisher per-domain cross- protocol publication-discipline observability spanning the CAA-RR cert- issuance authorization channel this page documents and the DMARC aggregate-report authentication-disposition channel the monitoring spoke's KPI dashboard aggregates.
• Why SPF alone is insufficient — the structural-limitations-of-SPF reference cataloguing the four reasons every per-publisher per-domain email- authentication posture requires additional protocols beyond SPF: (i) RFC 7208 §11.4 forwarding-MAIL-FROM-rewrite breaks SPF; (ii) no per-message message-content cryptographic integrity at the envelope- MAIL-FROM authorization layer; (iii) no per-publisher per-domain CERTIFICATE- ISSUANCE-AUTHORIZATION publication perimeter at the X.509-certificate-issuance layer — SPF authorises envelope-MAIL-FROM but offers NO control over which Certificate Authorities are authorised to issue per-publisher per-domain TLS / S/MIME / BIMI VMC certificates that downstream cryptographic-validation pipelines consume; (iv) no per-publisher per-domain CA- violation-reporting channel for unauthorised-issuance evidence collection. THIS page documents the RFC 8659 CAA Resource Record per-publisher per-domain apex-zone CERTIFICATE-AUTHORITY-AUTHORIZATION publication grammar (0 issue "<ca>" per-CA-authorisation, 0 issuewild "<ca>" per-CA- wildcard-authorisation, 0 iodef "mailto:<reporter>" per-domain CA-violation-reporting channel, 0 issue ";" empty-CA explicit-zero- authorization) as the canonical X.509- ISSUANCE-AUTHORIZATION-PERIMETER per- publisher per-domain CAA RR publishes to close exactly the CERTIFICATE-ISSUANCE- AUTHORIZATION gap the structural-SPF- insufficiency catalogue enumerates as the orthogonal-cryptographic-authorization- layer limit — CAA publishes the per- publisher per-domain AUTHORISED-CA catalogue + per-domain CA-VIOLATION- REPORTING channel at the per-domain apex- zone authoring boundary, which envelope- MAIL-FROM SPF authorisation STRUCTURALLY CANNOT publish at any envelope-layer authoring boundary. Read the why-SPF- alone-is-insufficient spoke alongside this CAA-records reference when scoping the per-publisher per-domain X.509-issuance- authorization publication discipline that structurally closes the certificate- issuance gap SPF leaves open, when authoring the per-publisher per-domain SPF + DKIM + DMARC + BIMI + MTA-STS + CAA defense-in-depth deployment playbook, or when sequencing the per-publisher per- domain BIMI VMC + MTA-STS PKIX-chain certificate-issuance plan against the per-publisher per-domain CAA-authorised- CA roster.
• RFC 8659 — DNS Certification Authority Authorization Resource Record — the current CAA specification.
• RFC 8657 — CAA Record Extensions for Account URI and ACME Method Binding — the validationmethods= and contactemail= extensions.
• CA/Browser Forum Baseline Requirements — the industry policy that mandates CAA checking at issuance time.
• DMARC forensic reports (RUF / AFRF) — the PER-PUBLISHER-CAA-iodef-CHANNEL-AS- STRUCTURAL-PARALLEL-TO-PER-PUBLISHER-DMARC- ruf-CHANNEL companion to this CAA-record publication-discipline reference. Where THIS page documents the RFC 8659 §4.4 CAA iodef property-tag publication discipline (the per-publisher-published iodef=mailto:<security-incident- mailbox> endpoint, the CA-side unauthorized-issuance-attempt incident-report emission contract, the per-CA-Baseline- Requirement issuance-time CAA-check coordination), the DMARC-forensic-reports spoke is the message-authentication-layer per-publisher incident-report-channel structural-twin reference documenting the RFC 7489 §6.5 ruf= per-publisher- published incident-report endpoint contract at the per-message DKIM-signature-or-SPF- envelope-from authentication-failure-emission layer. The PER-PUBLISHER-CAA-iodef-VS- PER-PUBLISHER-DMARC-ruf cross-reference establishes FOUR structurally-distinct cross- protocol per-publisher incident-report-channel dimensions: (i) per-publisher incident-report-mailbox-publication-discipline invariant — both protocols publish the per-publisher security-incident-mailbox via a mailto: URI in a DNS-RR- published policy record (CAA RR iodef tag vs DMARC TXT RR ruf= tag) — the per-publisher operator-discipline of publishing a per-organization-monitored security-incident-mailbox and rotating the mailbox owner when SOC personnel change is shared across both protocols; the DMARC- forensic-reports spoke documents the per-RFC 7489 §6.5 ruf=mailto: publication-discipline that mirrors the per-RFC 8659 §4.4 iodef=mailto: publication-discipline THIS page documents — the per-publisher cross-protocol mailbox- owner-coordination invariant prevents stale per-publisher security-incident-mailbox configurations from one protocol drifting ahead of the other; (ii) per-receiver- organization (CA OR DMARC verifier) emission- contract invariant — both protocols specify that the receiver-organization SHOULD emit per-incident reports to the per-publisher- published endpoint when the per-message-or- per-issuance-attempt incident triggers — for CAA the CA-Baseline-Requirement mandates the CA emit per-unauthorized-issuance-attempt IODEF reports per RFC 7970 to the per- publisher CAA iodef endpoint; for DMARC the per-receiver verifier emits per-message AFRF / IODEF reports per RFC 6591 / RFC 5965 to the per-publisher DMARC ruf endpoint; the DMARC- forensic-reports spoke documents the per- receiver per-message AFRF-emission contract whose structural-twin is the per-CA per- issuance-attempt IODEF-emission contract THIS page documents; (iii) per- publisher security-incident-mailbox-overload operational-discipline parallel — both protocols expose the per-publisher security- incident-mailbox to high-volume per-incident- report emission requiring per-organization dedicated SIRT triage-queue configuration — a per-publisher CAA iodef endpoint receiving thousands of per-day unauthorized-issuance-attempt reports during a domain-wide phishing campaign produces an operational mailbox-overload signature structurally-identical to the per-publisher DMARC ruf endpoint receiving thousands of per-day authentication-failure reports during a per-domain spoofing campaign; the DMARC-forensic-reports spoke documents the per-publisher per-day RUF volume operational-discipline whose mailbox- provisioning per-organization-monitored- capacity contract mirrors the per-publisher per-day IODEF volume contract THIS page documents; (iv) per-publisher cross- protocol incident-correlation per-domain- wide-campaign reconstruction invariant — a per-publisher domain-wide attacker campaign typically generates SIMULTANEOUS evidence streams in BOTH the per-publisher CAA iodef channel AND the per- publisher DMARC ruf channel — an attacker requesting unauthorized X.509 certificate issuance for the per-publisher domain (CAA iodef evidence) AND simultaneously spoofing per-publisher- domain envelope-from / signed-header identities (DMARC ruf evidence) produces a per-publisher cross-protocol incident-evidence-correlation surface the SIRT reconstructs by joining the per-day IODEF-evidence-stream with the per-day AFRF-evidence-stream on the per-publisher- domain key; the DMARC-forensic-reports spoke documents the per-AFRF / IODEF evidence-stream byte-anatomy whose per- domain-keyed cross-protocol correlation surface IS the per-publisher-incident- reconstruction primitive the per-organization SIRT relies on. Read the DMARC-forensic- reports spoke alongside THIS CAA-record- publication-discipline reference whenever the operator authors the per-publisher security-incident-mailbox publication-and- rotation playbook — the per-publisher cross-protocol per-organization-monitored- security-incident-mailbox-discipline pattern is shared at the per-publisher policy-RR- publication layer across BOTH the per-CA X.509-certificate-issuance-authorization layer AND the per-receiver per-message DKIM-or-SPF-authentication-verification layer.
• SPF qualifiers explained — the CROSS-LAYER-PARALLEL-PER-PUBLISHER- DNS-PUBLISHED-POLICY-RR-TOKEN-BYTE-SHAPE- AUTHORING-DISCIPLINE companion reference. Where THIS page documents the per-publisher CAA-RR byte-shape at the TLS-cert-issuance- authorization layer (the issue / issuewild / iodef property-tag bytes per RFC 8659 §4 published at the <domain> CAA-RR owner-name, each property-tag-value gating per-CA X.509-certificate-issuance authority for SMTP-STARTTLS-cert and mta-sts.<domain> HTTPS-endpoint-cert procurement), the SPF-qualifiers-explained spoke documents the STRUCTURALLY-PARALLEL per-publisher DNS-published policy-RR byte-shape at the application layer (the four canonical mechanism-prefix qualifier bytes + Pass / - Fail / ~ SoftFail / ? Neutral per RFC 7208 §4.6.2 that prefix every SPF mechanism token in the v=spf1 TXT-record at the apex <org-domain> owner-name) across four cross-layer DNS-published- policy-RR token-byte-authoring dimensions: (i) both publication primitives are per-publisher DNS-published per-RR-owner-name policy-tokens with byte-precision-strict token-vocabulary — the CAA-RR issue / issuewild / iodef property-tag is a registered-vocabulary per RFC 8659 §4.1, just as the SPF qualifier-prefix byte is a closed four-state vocabulary (+ / - / ~ / ?) per RFC 7208 §4.6.2; per-publisher operator authoring discipline depends on byte- precision-strict adherence to BOTH registered-vocabulary token-sets at the DNS-publication-discipline layer; (ii) both publication primitives encode per-publisher per-receiver-side-evaluation outcome-determination semantics — each per-CA CAA-RR issue property-tag-value deterministically gates a per-CA per-publisher TLS-cert-issuance outcome (issue-allowed / issue-denied) at per-CA CAA-evaluation time per RFC 8659 §3, just as each per-mechanism SPF qualifier- prefix byte deterministically maps to a per-receiver SPF-evaluation verdict (Pass / Fail / SoftFail / Neutral) at receiver-side check_host() evaluation time per RFC 7208 §4; (iii) both publication primitives are paired with DMARC-and-MTA- STS-aligned-pass outcomes — a per-publisher CAA-RR issue "<cert-authority-domain>" publication without a per-publisher SPF -all qualifier-prefix on the publisher's v=spf1 record leaves the cross-layer per-publisher sender- authentication plan incomplete: the TLS-cert- layer per-CA-issuance attacker-bypass class is gated by the CAA property-tag THIS page documents while the application-layer per-publisher spoofing attacker-bypass class is gated by the SPF qualifier-prefix the SPF-qualifiers spoke documents; (iv) both publication primitives share the same per-publisher per-domain DNS publication-cadence coordination discipline — the per-publisher CAA- RR publishes at the <domain> CAA-RR owner-name, while the SPF qualifier-prefix bytes publish at the apex <org-domain> owner-name's TXT-RR; per-publisher per-domain authoring tooling must keep BOTH RR-owner-name publication cadences synchronised across per-publisher per-domain CAA-RR-edit operations and SPF qualifier-prefix-edit operations. Read the SPF-qualifiers spoke alongside this CAA-RR publication-discipline reference whenever the per-publisher per- domain cross-layer DNS-published-policy plan extends to a complete TLS-cert-layer-and- application-layer DNS-published-policy byte- shape coordination plan — the SPF qualifier- prefix byte IS the application-layer per- publisher DNS-published-policy primitive that runs ALONGSIDE the CAA-RR property-tag byte discipline THIS page documents at every per-publisher cross-layer sender-and-cert- authorization-commitment event.
• DKIM key rotation — the APPLICATION-LAYER CRYPTOGRAPHIC-KEY-LIFECYCLE DISCIPLINE-PARALLEL companion to this CAA-RR per-domain CA-issuance-authorisation publication reference. Where THIS page documents the per-publisher per-domain CAA-RR property-tag publication discipline (issue, issuewild, iodef) constraining which Certificate Authorities may issue TLS certificates for the domain, the DKIM-key-rotation spoke documents the structurally parallel application-layer per-publisher per-selector key-rotation cadence (quarterly-or-faster rotation, old-selector grace-period retention, per-selector revocation discipline) whose cryptographic- key-lifecycle posture runs ALONGSIDE the CAA-RR per-CA- issuance-authorisation discipline at every per-publisher cross-layer cryptographic-policy- commitment event. Read THIS page when AUTHORING the per-domain CAA-RR publication discipline; read the DKIM-key-rotation spoke when AUTHORING the parallel application-layer per-selector key-rotation cadence the per-message DKIM-Signature cryptographic foundation depends on.
• DMARC for transactional email — the PER-ESP-PER-CUSTOMER-DOMAIN- CAA-RR-CO-PUBLICATION companion to this CAA-records-explained operator reference. Where THIS page documents the canonical CAA-RR per-CA issuance-authorisation discipline (RFC 8659 issue / issuewild property-tag authoring, the iodef violation-reporting property-tag publication, the per-domain CAA- inheritance traversal at the per-CA pre-issuance verification, the per- publisher per-CA whitelist operational discipline), the transactional-email spoke is the per- ESP per-customer-domain deployment- execution companion documenting FOUR transactional-CAA-coordination dimensions whose per-customer satisfaction gates per-ESP per- customer-domain TLS-certificate- anchored infrastructure provisioning: (i) per-ESP per-customer- domain CA authorisation through CAA- RR publication is the per-customer- domain authorisation contract per- ESP TLS certificate procurement depends on — when SendGrid / Mailgun / Amazon SES / Postmark / SparkPost procures a TLS certificate for a per-customer-domain MTA-STS policy host (mta-sts.<customer-domain>), per-customer-domain link-tracking host (links.<customer-domain>), or per-customer-domain custom-bounce host (bounce.<customer-domain>), the per-CA pre-issuance CAA-RR traversal THIS page documents must find an issue property- tag authorising the per-ESP-chosen CA at the customer's CAA-RR publication boundary; the transactional-email spoke documents the per-ESP per-customer-domain CA selection and the per-customer- domain CAA-RR authorisation discipline; (ii) per-customer- domain CAA inheritance through the ESP-managed CNAME chain at the per- ESP per-selector signer / link- tracker / bounce host topology defines which per-customer-domain zone hosts the load-bearing CAA-RR — the per-customer-domain CNAME chain delegating links.<customer-domain> to sendgrid.net or mailgun.org traverses the per-customer-domain CAA-RR at the customer's organisational zone boundary (the per-CA pre-issuance traversal walks UP from the per- host record toward the apex through the customer's zone, not the ESP's zone), making the per-customer- domain CAA-RR publication discipline THIS page documents the load- bearing per-customer-domain authorisation contract per-ESP TLS certificate procurement depends on; the transactional-email spoke documents the per-customer-domain CAA-RR-vs-CNAME-chain interaction discipline; (iii) per-customer- domain CAA-RR publication discipline at the customer's organisational zone is the per- customer-domain authorisation contract authoring discipline that determines whether per-ESP TLS certificate procurement succeeds — when a per-customer-domain operator publishes <customer-domain> IN CAA 0 issue "letsencrypt.org" at the customer's organisational zone, the per-customer-domain CA- authorisation set determines which per-ESP-chosen CA can issue certificates for per-ESP-managed per-customer-domain subdomains; the transactional-email spoke documents the per-ESP per-customer-domain CA- selection compatibility matrix (which CAs each ESP uses, which CAs the per-customer-domain CAA-RR must authorise); (iv) per-customer- domain escalation path from CAA- default (no CAA-RR) to per-ESP- anchored CAA-RR publication is the structurally-required remediation when per-ESP TLS certificate procurement fails at per-CA pre- issuance — when a per- customer-domain operator's per-ESP TLS certificate procurement fails because the per-customer-domain CAA-default state authorises only the customer's primary CA but the per-ESP uses a different CA, the transactional-email spoke documents the per-customer-domain CAA-RR authorisation update discipline (the per-customer-domain CAA-RR republication, the per-RR-TTL propagation wait, the per-CA pre-issuance re-attempt) and the per-customer-domain operator- escalation path from CAA-default to per-ESP-anchored CAA-RR publication. Read the transactional- email spoke ALONGSIDE this CAA- records-explained reference whenever the operator scopes a per-customer- domain transactional-email deployment on SendGrid / Mailgun / Amazon SES / Postmark / SparkPost — the CAA-RR per-CA issuance-authorisation discipline THIS page documents IS the per-customer-domain authorisation contract the transactional-email deployment guide encodes the per-ESP per-customer-domain TLS-certificate- anchored infrastructure execution discipline for.
• Phishing protection — the DEFENDER-SIDE-PHISHING-ATTACK- CLASS-ENUMERATION-AT-PER-PROTOCOL-LAYER- MITIGATION-PILLAR companion to this CAA records reference. Where THIS page documents the RFC 8659 per-publisher per- domain Certification Authority Authorization (CAA) DNS-RR publication discipline (per-CA issue / issuewild / iodef tag semantics, per- publisher per-CA authorisation cone, per- publisher CA-restriction enforcement at certificate-issuance time), the phishing- protection cluster-level enumeration spoke is the cluster-level DEFENDER-SIDE- PHISHING-ATTACK-CLASS-CATALOGUE REFERENCE documenting the six canonical per-protocol-layer phishing attack classes plus the per-protocol-layer mitigation pillar that closes each class. The CAA-RECORDS-VS-PHISHING-PROTECTION cross-reference establishes that the per-publisher per-domain CAA-RR publication IS the per-certificate- issuance-layer mitigation pillar for the UNAUTHORISED-CA-CERTIFICATE phishing- impersonation attack class — an attacker who registers a lookalike domain or compromises an unrelated CA account cannot obtain a valid TLS certificate for the publisher's domain BECAUSE every RFC-compliant CA must check CAA records at issuance time and refuse to issue when the CAA issue tag excludes them; the per-publisher per- domain CAA-RR publication discipline THIS page documents is the per-CA enforcement contract that closes the unauthorised- CA-certificate phishing-impersonation attack at the per-domain certificate- issuance boundary. Read THIS page when AUTHORING per-publisher per-domain CAA-RR publication; read the phishing- protection cluster-level enumeration spoke when MAPPING per-publisher per- domain CAA coverage to the per-receiver per-attack-class defender-side enumeration, or when CO-AUDITING the per-publisher per-protocol-layer mitigation-pillar completeness across SPF / DKIM / DMARC / BIMI / MTA-STS / TLS-RPT / CAA / ARC at per-attack-class closure boundaries.
• DMARC for SaaS senders — the per-publisher per-domain AUTHENTICATION-RECORD-PUBLICATION- DISCIPLINE peer to this per-publisher per-domain CERTIFICATE-ISSUANCE- AUTHORIZATION-RECORD-PUBLICATION- DISCIPLINE reference. Where THIS page documents the per-publisher per- domain CAA-record byte-grammar (the issue, issuewild, issuemail, and iodef property-tags authorising specific CAs to issue TLS/S-MIME certificates for the publisher's domain), the SaaS-sender DMARC spoke documents the per-SaaS- sender per-customer-domain DMARC TXT- record publication, the per-customer- domain SPF-include cascade (include:<saas>.com), and the per-customer-domain DKIM- CNAME delegation (<selector>._domainkey.<customer> → <selector>.<saas>.com) publication discipline. Read the SaaS-sender DMARC spoke when CO- DESIGNING the per-customer-domain CROSS-RECORD-CLASS publication discipline across BOTH the AUTHENTICATION-record class (SaaS- sender-mediated SPF + DKIM + DMARC per customer domain) AND the CERTIFICATE-ISSUANCE-AUTHORIZATION record class (per-customer-domain CAA constraining which CA may issue the customer-domain TLS certificate) — both record-classes together close the per-customer-domain CROSS- RECORD-CLASS publication-discipline surface a multi-tenant SaaS sender must coordinate with its customer portfolio's DNS-publishing operators.
• DMARC troubleshooting — the PER-PUBLISHER-PER-DOMAIN-DMARC- VERDICT-OPERATIONAL-DIAGNOSIS companion to this per-publisher per- domain CAA record byte-grammar reference. Where THIS page documents the per-publisher per-domain CAA record byte-grammar (the per-domain 0 issue "<ca-domain>" property issuance-authorization, the per-domain 0 issuewild "<ca-domain>" wildcard-issuance-authorization, the per-domain 0 iodef "mailto:<contact>" violation-report endpoint, the per- receiver per-domain critical-flag-vs-non-critical-flag evaluation semantics), the DMARC troubleshooting spoke is the STRUCTURALLY-PEER per-publisher per- domain DNS-publication-discipline diagnostic-substrate companion: both record-classes are per-publisher per- domain DNS-published authorization records whose per-receiver evaluation outcome depends on the per-publisher per-domain DNS-publication discipline the operator coordinates. CAA failures and DMARC failures share the same per-publisher per-domain DNS-publication diagnostic surface: (i) per-domain CAA-record byte- grammar mistypes (wrong CA domain, missing trailing dot, malformed flag-property-tag tuple, conflicting per-subdomain CAA override) collapse the per-CA per-domain certificate- issuance contract — analogous to per-domain DMARC TXT-RR byte-grammar mistypes (wrong v=DMARC1 version, wrong p= policy value, wrong rua= endpoint URI, wrong tag-separator) collapsing the per-receiver per-domain DMARC- verdict contract; (ii) per-domain DNSSEC-validation regressions cascade identically through BOTH the CAA evaluation surface AND the DMARC evaluation surface — a per-publisher per-domain DNSSEC mis-signing produces per-CA per-domain CAA evaluation failures AND per-receiver per-domain DMARC TXT-RR retrieval failures from the same per-publisher per-domain DNS-publication root- cause; (iii) per-publisher per- domain DNS-publication-cadence drift across DNS-provider migrations, per-domain-delegation transitions, and per-zone-resigning windows affects BOTH record-classes through the same per-publisher per-domain DNS-publishing-operator coordination boundary the troubleshooting spoke catalogues. Read THIS page when AUTHORING the per-publisher per- domain CAA record-publication byte- grammar discipline; read the DMARC- troubleshooting spoke when DIAGNOSING per-publisher per-domain DMARC-verdict regressions whose root cause is the same per-publisher per- domain DNS-publication discipline the per-publisher per-domain CAA record-publication audit THIS page documents independently surfaces at the per-publisher per-domain DNS- publication operational-discipline cross-record-class diagnostic- substrate boundary.
• Email deliverability — the per-publisher per-domain DELIVERABILITY-ENGINEERING-OPERATIONAL companion to this per-publisher per- domain CAA record byte-grammar reference. Where THIS page documents the per-publisher per-domain CAA record byte-grammar (the per-domain 0 issue "<ca-domain>" property, the 0 issuewild "<ca-domain>" wildcard-issuance property, the 0 iodef "mailto:<contact>" violation-report endpoint, and the per-receiver critical-flag evaluation semantics per RFC 8659), the email- deliverability spoke documents the per-publisher per-domain deliverability- engineering operational discipline whose TLS-certificate-issuance prerequisite the CAA record-publication discipline gates. The composition operates through the per-publisher per-domain TLS- certificate dependency chain: the per- publisher per-domain MTA-STS publication (mta-sts.<domain>/.well-known/mta-sts.txt HTTPS-fetched policy file) requires a valid TLS certificate on the mta-sts.<domain> host; the per-publisher per-domain DANE publication (TLSA RR at _25._tcp.<mx-host>) binds the receiving MX certificate to a TLSA hash; the per-publisher per- domain BIMI publication requires a VMC certificate from a CA Browser Forum Mark-Certificate-CA-eligible authority. ALL THREE certificate-issuance flows are GATED by the per-publisher per- domain CAA record-publication discipline THIS page documents — a per-publisher per-domain CAA record that fails to authorise the chosen CA BLOCKS the per-CA issuance request, which BLOCKS the per-publisher per- domain TLS-certificate publication, which BLOCKS the per-publisher per- domain MTA-STS / DANE / BIMI publication, which DEGRADES the per- publisher per-domain deliverability- engineering operational baseline the email-deliverability spoke catalogues. Read THIS page when AUTHORING the per- publisher per-domain CAA record- publication byte-grammar discipline; read the email-deliverability spoke when UNDERSTANDING the per-publisher per-domain deliverability-engineering operational baseline whose TLS- certificate-issuance prerequisite the per-publisher per-domain CAA record- publication discipline THIS page documents materially gates at the per- publisher per-domain certificate- authority-issuance-authorization tier.
• MX records — the per-publisher per-domain MX-RECORD- MAIL-DELIVERY-ROUTING-DISCIPLINE peer-DNS- RR-publication companion to this per- publisher per-domain CAA-record- publication byte-grammar reference. Where THIS page documents the per-publisher per- domain CAA record's authoritative certificate-authority-issuance- authorization byte-grammar (the flags octet, the tag field's issue / issuewild / iodef / contactemail / contactphone values per RFC 8659 + RFC 8657, the value field's CA-identifier + per-CA parameter byte-grammar, the per- publisher per-domain CA-issuance- authorization discipline against the per- CA's CAA pre-issuance check), the MX- records spoke documents the structurally- paired per-publisher per-domain mail- delivery-routing DNS-RR publication discipline (RFC 1035 §3.3.9 MX-record byte-grammar, RFC 5321 §5.1 sender → MX-lookup → A/AAAA → SMTP delivery sequence, RFC 7505 null-MX semantics, the per-publisher per-domain backup-MX anti-pattern catalogue, MX-vs-A implicit- MX fallback rule per RFC 5321 §5.1). The composition operates as a per-publisher per-domain DNS-RR PUBLICATION-DISCIPLINE- PEER relationship: per-publisher per- domain CAA records publish the per- publisher per-domain certificate- authority-issuance-authorization at the per-CA's CAA pre-issuance-check tier; per- publisher per-domain MX records publish the per-publisher per-domain mail- exchanger-host-routing topology at the per-sender SMTP-client's mail-delivery routing tier — both are LOAD-BEARING per- publisher per-domain DNS-RR publication disciplines whose per-publisher per-domain publication-completeness gates a per- publisher per-domain operational outcome (per-CA certificate-issuance vs per-sender mail-delivery). Read THIS page when AUTHORING the per-publisher per-domain CAA record-publication byte-grammar discipline; read the MX-records spoke when AUTHORING the per-publisher per- domain mail-delivery-routing DNS-RR publication discipline as the per- publisher per-domain DNS-publication- completeness peer discipline whose publication-completeness gates the per- publisher per-domain mail-delivery surface upon which the per-publisher per- domain CAA-authorized TLS-certificate's per-publisher per-domain MTA STARTTLS- enforcement contractually depends.
• SPF DNS record syntax — the PEER-DNS-RR-PUBLICATION-DISCIPLINE AT-THE-PER-PUBLISHER-PER-DOMAIN-APEX-OF- PER-PUBLISHER-PER-DOMAIN-SPF-AUTHORIZATION- RR-VS-CAA-AUTHORIZATION-RR-PUBLICATION- PARITY companion to THIS page's per-publisher per-domain CAA record-publication byte- grammar discipline. Where THIS page documents the per-publisher per-domain CAA record- publication byte-grammar (the RFC 8659 issue, issuewild, iodef, and contactemail property tag-value pairs, the per-publisher per-domain CA-authorization scope semantics, and the per-publisher per-domain certificate- issuance-time CA-validation contract), the SPF-DNS-syntax spoke is the PEER-DNS-RR- PUBLICATION-DISCIPLINE reference documenting the per-publisher per-domain SPF-record TXT- RR syntactic publication discipline. Both spokes occupy the per-publisher per-domain APEX-RR-AUTHORIZATION-PUBLICATION-DISCIPLINE tier of the per-publisher per-domain DNS publication catalogue: CAA publishes the per-publisher per-domain CERTIFICATE-AUTHORITY-AUTHORIZATION scope at the per-publisher per-domain apex; SPF publishes the per-publisher per- domain SENDER-IP-AUTHORIZATION scope at the per-publisher per-domain apex. The two publication disciplines are PEER per- publisher per-domain AUTHORIZATION-RR publications whose syntactic-correctness floors sustain the per-publisher per-domain certificate-issuance-AND-mail-sending publication-completeness floor. Read THIS page when AUTHORING the per-publisher per- domain CAA record-publication byte-grammar discipline; read the SPF-DNS-syntax spoke when AUTHORING the per-publisher per-domain SPF-record byte-grammar publication discipline as the per-publisher per-domain PEER-DNS-RR-PUBLICATION-DISCIPLINE complementing the per-publisher per-domain CAA publication at the per-publisher per- domain apex-RR-authorization-publication tier.
• DKIM best practices — the per-publisher per-domain canonical DKIM publication-and-rotation deployment discipline (RSA-2048-minimum key-size baseline per Feb 2024 bulk-sender requirements, dual-selector rotation- overlap-window discipline, per-publisher per-selector private-key custody-vs-ESP- delegation policy, per-publisher per- selector v=DKIM1; k=rsa; p=<base64> TXT-RR byte-syntax publication at <selector>._domainkey.<domain>) whose per-publisher per-domain DKIM- public-key DNS-RR publication discipline is the LOAD-BEARING per-publisher per- domain CRYPTOGRAPHIC-MATERIAL- AUTHORIZATION DNS-RR-publication peer of the per-publisher per-domain CAA CERTIFICATE-AUTHORITY-AUTHORIZATION DNS- RR-publication discipline THIS page documents. The composition operates through FOUR per-publisher per-domain cryptographic-authorization-RR-publication- discipline coupling dimensions every per- publisher per-domain operator must reason about jointly with the CAA-publication discipline: (i) per-publisher per-domain CAA-record publication authorizes WHICH CAs may issue X.509 TLS certificates for per-publisher per-domain MTA-STS-policy- host and per-publisher per-domain BIMI- VMC, AND per-publisher per-domain DKIM- selector TXT-RR publication authorizes WHICH per-message DKIM signatures can emit per-publisher per-domain-aligned d= for per-receiver per- message DKIM-aligned-pass — both per- publisher per-domain CRYPTOGRAPHIC- TRUST-ANCHOR-PUBLICATION DNS-RR classes published at the per-publisher per- domain apex-zone-editor publication boundary; (ii) per-publisher per-domain CAA-record-tags (issue + issuewild + iodef) byte-syntax publication discipline parallels per- publisher per-domain per-selector DKIM- TXT-RR tags (v= + k= + p= + s=) byte- syntax publication discipline — both per- publisher per-domain CRYPTOGRAPHIC-AUTHORIZATION-RR byte- grammar classes share the RFC 1035 §3.3.14 TXT-character-string format publication floor AND the per-publisher per-domain DNS-zone-editor commit cadence; (iii) per-publisher per-domain CAA-record publication-and-rotation cadence coordinates with per-publisher per-domain DKIM-selector publication-and-rotation cadence at the per-publisher per-domain cryptographic-material-lifecycle- management discipline — both per-publisher per-domain DNS-RR classes expose publication-boundary cryptographic- material-rotation risk that the per- publisher per-domain operations playbook MUST coordinate across the per-publisher per-domain CAA-CA-cert-renewal cadence AND the per-publisher per-domain per- selector DKIM-key-rotation cadence; (iv) per-publisher per-domain joint CAA- record-violation-CA-issuance-attempt per-CA-iodef-alert-stream AND per- publisher per-domain per-selector DKIM- aligned-pass-rate-regression-per- receiver-per-day RUA-stream-observability as DUAL-OBSERVABILITY-STREAM per- publisher per-domain CRYPTOGRAPHIC-AUTHORIZATION-RR- regression-detection pipeline — both per-publisher per-domain CRYPTOGRAPHIC-AUTHORIZATION-RR observability streams must be ingested jointly to detect per-publisher per- domain CRYPTOGRAPHIC-AUTHORIZATION-RR publication regressions across BOTH the per-publisher per-domain per- certificate per-CA-issuance-attempt boundary AND the per-publisher per- domain per-message per-selector DKIM- signature-emission boundary. Read THIS page when AUTHORING the per-publisher per-domain CAA record-publication byte-grammar discipline; read the DKIM-best-practices spoke when AUTHORING the per-publisher per-domain per-selector DKIM-public-key DNS-RR publication-and-rotation discipline as the per-publisher per-domain CRYPTOGRAPHIC-MATERIAL-AUTHORIZATION DNS-RR-publication peer of the per- publisher per-domain CAA CERTIFICATE-AUTHORITY-AUTHORIZATION DNS-RR-publication discipline THIS page documents at the per-publisher per-domain CRYPTOGRAPHIC-AUTHORIZATION- RR-publication-discipline catalogue boundary.
• DMARC for Microsoft 365 — the M365-TENANT-PER-CUSTOM-DOMAIN-CAA- RECORD-AUTHORIZED-CA-ROSTER companion to this CAA-record publication-discipline reference. Where THIS page documents the per-publisher per-domain CAA TXT-record publication discipline (the issue / issuewild / iodef property-tag triple per RFC 8659, the validationmethods= / contactemail= extensions per RFC 8657, the CA/Browser Forum Baseline Requirements issuance-time CAA-check contract, and the per-publisher per-domain CAA-record-authorised-CA-roster publication coordinating with per-publisher per-domain BIMI VMC + MTA-STS PKIX-chain certificate- issuance), the M365-tenant spoke documents the per-M365-tenant per-custom-domain DMARC deployment topology where the per- tenant per-custom-domain dual-selector DKIM CNAME-delegated selectors (selector1._domainkey + selector2._domainkey CNAME- delegated to selector1-<tenant-domain-mangled>._domainkey.<tenant>.onmicrosoft.com) + per-tenant SPF include:spf.protection.outlook.com cascade + per-tenant per-custom-domain DMARC + MTA-STS publication need TLS certificates that the per-tenant per- custom-domain CAA record THIS page documents authorises issuance of. The per-M365-tenant per-custom-domain CAA- record publication IS the per-tenant per- custom-domain canonical certificate- issuance-authorisation consumer of the CAA-record publication-discipline THIS page architectures at four M365-tenant- deployment-vs-CAA-record-publication- discipline coupling dimensions: (i) per- M365-tenant per-custom-domain CAA issue "digicert.com" + similar authorised-CA-roster publication as canonical Workspace + Outlook BIMI VMC issuance-authorisation precondition — BIMI VMCs are issued by DigiCert and Entrust; without per-M365-tenant per- custom-domain CAA publication of the BIMI VMC issuing CA, the per-M365-tenant per-custom-domain VMC procurement infrastructure is structurally blocked by the CA/Browser Forum Baseline-Requirement CAA-check the M365 tenant's BIMI-VMC issuance enrolment depends on; (ii) per- M365-tenant per-custom-domain CAA issue "letsencrypt.org" / issue "<tenant-CA>" publication as per-tenant per-custom- domain MTA-STS HTTPS-served policy-file TLS-certificate authorization precondition — the per-M365-tenant per-custom-domain MTA-STS policy at https://mta-sts.<tenant-domain>/.well-known/mta-sts.txt requires per-tenant per-custom-domain TLS-certificate issuance that the per- tenant per-custom-domain CAA record THIS page documents structurally authorises; (iii) per-M365-tenant per-custom-domain CAA iodef=mailto: publication as per-tenant per-custom-domain CA-side- unauthorised-issuance incident-report channel — the per-M365-tenant per-custom- domain CAA iodef-property-tag publication creates the per-tenant per- custom-domain CA-side incident-report channel mirroring the per-tenant per- custom-domain DMARC ruf forensic-report channel at the cross- protocol per-tenant per-custom-domain incident-report-channel publication boundary; and (iv) per-M365-tenant per- custom-domain CAA record-update cadence as per-tenant per-custom-domain operator- side certificate-issuance-pipeline coordination — the per-M365-tenant per- custom-domain CAA record-publication cadence MUST coordinate with the per-M365- tenant per-custom-domain certificate- renewal lifecycle (BIMI VMC 13-month renewal, MTA-STS HTTPS-certificate renewal, per-tenant per-custom-domain Defender for Office 365 certificate renewal) the per-M365-tenant per-custom- domain operator-side certificate-issuance- pipeline executes against. Read THIS page when AUTHORING the per-publisher per- domain CAA TXT-record publication discipline at the canonical record-syntax reference layer; read the M365-tenant DMARC deployment spoke when AUDITING the per-M365-tenant per-custom-domain CAA- record-authorised-CA-roster against the per-M365-tenant per-custom-domain BIMI VMC + MTA-STS + Defender-for-Office-365 certificate-issuance-pipeline at the per- M365-tenant per-custom-domain certificate- issuance-authorisation publication boundary.
• Business Email Compromise (BEC) defence stack — the per-publisher per-domain CAA-RR- authorized-CA-binding-as-load-bearing-anti- BEC-PKI-layer-defence companion to this CAA DNS-record-publication pillar. Where THIS page documents the per-publisher per-domain CAA RFC 8659 §4 tag-vocabulary publication discipline (the issue "<ca-domain>" / issuewild "<ca-domain>" per-CA-authority-binding, the iodef "mailto:<incident-channel>" per-publisher per-domain incident-report channel, the accounturi + validationmethods per RFC 8657 per-CA-account-binding-strengthening publication discipline), the BEC defence- stack spoke documents the per-publisher per- domain anti-BEC PKI-layer defence boundary the CAA-RR publication-discipline underpins. Four coupling axes connect them: (i) per- publisher per-domain CAA-RR issue + issuewild per-CA-authority-binding IS the load-bearing anti-lookalike-domain-PKI-impersonation defence — attackers registering BEC-pretext phishing landing-pages on lookalike domains (flnance-<org>.com / <org>-payroll.net) need TLS certificates from a CA; per-publisher per-domain CAA-RR restricting CA-issuance scope to the legitimate-publisher's contracted CAs limits per-attacker per- lookalike-domain unauthorized-cert-issuance exposure across the CA/B Forum mandatory CAA-checking ecosystem per RFC 8659 §3; (ii) per-publisher per-domain CAA-RR iodef "mailto:<incident-channel>" IS the load-bearing anti-BEC incident- observability per-attempt-detection primitive — CA-issuance-attempt incident emission per RFC 6546 surfaces per-publisher per- domain unauthorized-cert-issuance-attempts the per-publisher per-domain BEC defence- team can investigate as a pre-attack early- warning signal; (iii) per-publisher per- domain CAA-RR accounturi + validationmethods per RFC 8657 per-CA-account-binding publication-discipline IS the load-bearing anti-CA-account-takeover defence-strength primitive — per-CA- account binding restricts unauthorized cert- issuance to a specific CA-side account- identity even if the per-publisher per-domain DNS or CA-account credentials are partially compromised at the per-CA per-account boundary; (iv) per-publisher per-domain CAA- RR publication discipline IS the structurally- parallel PKI-layer-publication discipline companion to the per-publisher per-domain SPF + DKIM + DMARC + BIMI application-layer- authentication publication-discipline portfolio the anti-BEC defence-stack composes — per-publisher per-domain BEC defence depends on the COMPOSITE PKI-layer + envelope-MAIL-FROM-layer + application-layer + brand-indicator-layer publication-discipline portfolio closing the anti-BEC defence- boundary at the per-publisher per-domain composite cross-layer publication-discipline coordination boundary. Read the BEC defence- stack spoke alongside this CAA records- explained pillar when AUTHORING per-publisher per-domain CAA-RR publication discipline scoped to the anti-BEC PKI-layer-defence boundary, when AUDITING per-publisher per- domain CAA-RR iodef incident-channel observability against per-attempt unauthorized- cert-issuance forensics, or when PLANNING per-publisher per-domain composite cross- layer anti-BEC publication-discipline sequencing against the PKI-layer + envelope-MAIL-FROM-layer + application-layer composite-defence-floor progression discipline.
• Email authentication glossary
• DKIM for Google Workspace
• DMARC for Google Workspace
• DKIM troubleshooting
• DMARC for Office 365 hybrid — the per-publisher per-domain hybrid M365 deployment THIS hybrid- deployment spoke documents materially depends on the per-tenant per-custom- domain CAA-RR issue / issuewild CA-authority- binding publication-discipline THIS CAA records explained page documents the per-publisher per-domain byte-grammar of — hybrid M365 tenants must coordinate per-tenant CAA-RR publication against Microsoft's DigiCert + Sectigo + IdenTrust certificate-issuance pipeline driving the per-tenant on-prem-Exchange TLS-certificate + Exchange-Online MTA-STS HTTPS-served- policy + Defender-for-Office-365 cert- issuance chains, all structurally parallel to the per-publisher per-domain DKIM / SPF / DMARC DNS-TXT-RR publication discipline the hybrid-M365 deployment spoke documents at the per-publisher per- domain composite hybrid-M365-PKI-and-DNS- publication coordination boundary.
• Email spoofing seven-technique attack catalogue
• DKIM canonicalization — the PER-PUBLISHER-PER-SELECTOR-DKIM-APPLICATION-LAYER-CANONICALIZATION-ALGORITHM-CHOICE-PUBLICATION-DECISION-AS-STRUCTURALLY-PARALLEL-APPLICATION-LAYER-CANONICAL-BYTE-STREAM-PRODUCTION-DISCIPLINE-COMPANION-TO-PER-PUBLISHER-PER-DOMAIN-CAA-RR-PER-CA-ALLOWLIST-PUBLICATION-DISCIPLINE companion at four per-publisher per-domain CAA-RR-vs-DKIM-canonicalization coupling dimensions: (i) per-publisher per-domain CAA-RR issue + issuewild per-CA-allowlist publication-discipline per RFC 8659 §4 IS structurally parallel application-layer publication-discipline primitive to per-publisher per-selector DKIM c=relaxed/relaxed vs c=simple/simple canonicalization-algorithm publication-decision per RFC 6376 §3.4 — both per-publisher per-domain application-layer publication-discipline primitives underpin per-publisher per-domain composite cross-protocol cryptographic-trust-anchor-and-signature-integrity floor at the per-publisher per-domain composite per-CA-issuance-discipline-and-per-message-cryptographic-verification coordination boundary; (ii) per-publisher per-domain CAA-RR wire-format byte-grammar publication-discipline per RFC 8659 §4.1 (flags-octet + tag-length + tag-key + value-byte-string) IS structurally parallel canonical-byte-encoding publication-discipline to per-publisher per-selector DKIM canonicalization-mode byte-stream production-discipline per RFC 6376 §3.4 (relaxed-body unfolds WSP / collapses repeated WSP / strips trailing-WSP / removes trailing CRLF-CRLF sequences) — both per-publisher per-domain canonical-byte-stream production-discipline references are per-publisher per-domain operator-side cryptographic-byte-stream-integrity primitives the per-receiver-side cryptographic-verification consumes; (iii) per-publisher per-domain CAA-RR publication-discipline drift (premature wildcard issuewild ";" reject-all publication-decision before per-CA-onboarding-ramp completion, or stalled issue ";" publication-discipline drift surfacing as cert-issuance-pipeline outage) IS structurally parallel publication-discipline-drift class to per-publisher per-selector DKIM canonicalization-mode publication-discipline drift (premature c=simple/simple publication-decision exposing per-message DKIM-leg fragility to forwarder whitespace-mangling) — both per-publisher per-domain publication-discipline-drift classes surface as per-publisher per-domain operator-actionable per-day per-receiver evidence-driven publication-discipline drift-closure visibility at the per-publisher per-domain composite cross-protocol publication-discipline-integrity coordination boundary; (iv) per-publisher per-domain CAA-RR PKI-layer per-CA-allowlist publication-discipline closes per-attacker per-target-domain TLS-cert-mis-issuance attack-class subset structurally parallel to per-publisher per-selector DKIM canonicalization-mode publication-decision closing per-attacker per-message DKIM-Signature replay-attack-class subset against per-publisher per-domain composite cryptographic-publication-discipline-integrity floor — both per-publisher per-domain cross-layer publication-discipline references jointly underpin per-publisher per-domain composite anti-spoofing-and-anti-replay defense-stack the per-publisher per-domain CAA-RR primer THIS page documents the per-CA-allowlist-and-issuance-discipline floor of.
• DMARC aggregate (RUA) reports
• Reverse DNS / PTR records for mail servers
• DKIM selectors — the companion DNS-RR publication-discipline reference at the other end of the per-publisher per-domain cryptographic-publication portfolio this page anchors. Where the CAA record authorises which CAs may issue X.509 certificates for the domain, the DKIM selector names the <selector>._domainkey.<domain> TXT-RR that carries the per-key public half receivers fetch to verify a DKIM-Signature. Both are operator-controlled DNS-RR primitives published from the same apex-zone editor, and both gate cryptographic trust: a missing or malformed CAA lets an unauthorised CA mis-issue, while a missing or stale selector TXT-RR silently fails every DKIM-aligned pass. Read the DKIM selectors spoke to see how the selector namespace lets a domain run and rotate multiple signing keys without the single-record constraint a CAA set faces.
• DKIM alignment with DMARC — the next step once the DKIM selector keys this page references are published: a valid DKIM signature only helps DMARC if its d= domain aligns (relaxed or strict) with the From-header domain. CAA governs which CA may certify the domain; DKIM alignment governs whether the signed mail actually passes DMARC. Read the alignment spoke to connect the DNS-RR publication discipline here to a DMARC-aligned pass.
• DKIM DNS record syntax — both the CAA records this page covers and the DKIM key record are operator-published DNS resource records that live in the same zone: CAA constrains which CA may issue certificates, while the DKIM DNS syntax reference documents the <selector>._domainkey TXT-RR carrying v=DKIM1; k=rsa; p=<base64-pubkey> that receivers fetch to verify a signature. Read it to round out the per-domain DNS-RR publication discipline this CAA guide anchors.
• SPF 10-DNS-lookup limit — the SAME-ZONE-DNS-PUBLICATION-DISCIPLINE companion to this CAA reference: the CAA records this page covers and the SPF record both live as operator-published resource records in the same DNS zone, and both impose a publication discipline an operator must keep correct — CAA constrains which CA may issue a certificate, while SPF must keep its include:-cascade within the §4.6.4 10-DNS-lookup budget or collapse to spf=permerror. Where CAA mis-publication silently lets the wrong CA issue, an SPF lookup-budget overrun silently fails the envelope-authorization leg of DMARC. Read the SPF-10-DNS-lookup-limit spoke to round out the per-domain DNS-record publication discipline this CAA guide anchors with its envelope-layer budget analogue.
• Email authentication explained — CAA constrains which CA may issue certificates for your domain; email authentication (SPF + DKIM + DMARC) constrains who may send mail as your domain. Both are operator-published DNS-zone controls that harden a different surface of the same domain, and the email-authentication primer is the umbrella overview of the message-layer half. Read it to pair the certificate-issuance control this CAA guide covers with the sender-authorization stack that protects the same domain's mail.
• Microsoft SNDS + JMRP monitoring — Microsoft grades the sending IP itself, not just the domain: SNDS per-IP GREEN/YELLOW/RED verdicts and JMRP complaints are the reputation companion to getting the DNS foundation right.

12. Audit your CAA records now

DMARC Analyzer's Domain Security Checker performs live CAA lookups via includes/DnsChecker.php, surfacing the published issue / issuewild / iodef records inline with SPF, DKIM, DMARC, MTA-STS, BIMI, and DNSSEC results. A missing CAA record surfaces as a security finding so you can spot default-open issuance posture before a CA is tricked into mis-issuing. The DNS Record Generator's CAA wizard builds well-formed records with RFC 8659 syntax validation and a curated list of canonical CA identifiers — copy the output directly into your DNS provider.

Check my CAA records Sign up — Free plan