Policy guidance
The following reference covers all 14 system-defined policies. For each policy, select the policy name on the Policies page to open the Policy Details panel. The panel provides the full description, compliance framework mappings, posture impact, and why it matters. The guidance below covers scope, pairing recommendations, and configuration context to help you evaluate and apply policies effectively across your account.
Opmerking
This policy tracks the ANS v2 Internet-Draft profile and will be updated as the standard evolves. It's a draft-profile check, not a conformance certification.
Most relevant for domains that expose or intend to expose AI agent endpoints under the ANS v2 draft specification.
Pair with TLS Certificate Validity, as agent endpoint identity depends on a valid, trusted TLS certificate at port 443.
Publish a well-formed _ans TXT record at _ans.<domain>; using the v=ans1 format. Ensure the version= field contains a v-prefixed semver value (for example, v1.0.0). If url= is included, it must be a valid HTTPS URL. Verify the TLS certificate covers the domain name, is issued by a publicly trusted CA, and hasn't expired.
Belangrijk
Enable this policy before removing any cloud resource a CNAME points to. Deprovisioning a cloud resource before removing its CNAME record creates a dangling reference that can be claimed by an attacker.
Most relevant for domains with CNAME records pointing to cloud or SaaS services such as AWS, Azure, Heroku, Fastly, and GitHub Pages.
Pair with TLS Certificate Validity, as a dangling CNAME will also fail TLS validation.
Highest priority during infrastructure deprovisioning. Treat this as a pre-decommission check for any cloud-hosted resource.
For domains with a DNS provider integration, the full zone scan will detect dangling records that aren't publicly observable.
Belangrijk
Before acting on a STALE_DELEGATION finding, verify it isn't an intentional CDN or load-balancer delegation pattern. Some providers use asymmetric NS sets by design.
Most relevant for all internet-facing domains, particularly those with secondary nameserver configurations.
Pair with NS Concentration Check for complete delegation health coverage.
LAME_NS findings combined with SOA Serial Consistency failures typically indicate a zone transfer problem rather than a provisioning error.
Waarschuwing
Monitor continuously for DNSSEC validation failures after enabling. Validation failures can cause DNS resolution to fail entirely for strict resolvers, resulting in the domain becoming unreachable.
Most relevant for externally exposed production domains, authentication services, mail domains, APIs, and other security-sensitive domains.
Pair with NS Concentration Check, as DNSSEC validation depends on consistent nameserver availability across providers.
Verify that DNSKEY and RRSIG records are being published correctly and that the DS record is visible at the parent. Obtain the DS record for the active signing key and publish it through the registrar or parent zone. The full DNSSEC chain must validate end-to-end.
Most relevant for high-traffic public domains where regional availability matters and for any domain where users or systems are geographically distributed.
Pair with Delegation Health Check, as reachability failures often share a root cause with lame delegation.
If your DNS provider supports anycast, reachability findings may indicate routing anomalies rather than configuration errors.
Opmerking
Selector discovery from provider telemetry isn't yet supported.
Most relevant for all domains that send mail, particularly those relying on DMARC enforcement.
Pair with Mail SPF and Mail DMARC. DKIM is one of the 2 authentication mechanisms DMARC uses to determine message alignment.
Configure DKIM signing on all mail-sending systems for this domain. Use RSA keys of at least 2048 bits per RFC 8301 and SHA-256 for signing, as SHA-1 is prohibited. Rotate keys periodically and revoke old keys by setting p= to empty in the selector record. Record known selector names in the MAIL_DKIM policy parameters so they can be continuously monitored.
Most relevant for all domains that send or are impersonated in mail, including domains that don't send mail directly.
Pair with Mail SPF and Mail DKIM. DMARC relies on both for alignment decisions.
Publish a DMARC TXT record at _dmarc.<domain>; with at minimum p=quarantine. Add an rua= tag to receive aggregate reports and gain visibility into authentication failures. Evaluate sp= and np= tags to explicitly govern subdomain mail posture. Work toward p=reject once all legitimate sending sources are confirmed SPF- or DKIM-aligned. Remove t=y (testing mode) once ready for full enforcement.
Use DMARC aggregate report data to safely advance your enforcement level before raising the policy to p=reject.
Belangrijk
Don't mix Null MX with real MX records. They're contradictory and will produce a finding.
Most relevant for all domains, including those that don't accept mail. Explicit MX configuration is required in both cases.
Pair with Mail SPF, as MX configuration correctness is a prerequisite for accurate SPF evaluation.
Publish explicit MX records for domains that accept mail rather than relying on implicit A/AAAA fallback. Ensure all MX hostnames resolve to valid IP addresses, as MX record targets must be hostnames, not IP addresses, per RFC 5321 - 5.1. For domains that don't accept mail, publish a Null MX record (MX 0 .) per RFC 7505 rather than leaving MX records absent.
Most relevant for all domains that send mail or are referenced as mail sources by other domains.
Pair with Mail DKIM and Mail DMARC. SPF alone is insufficient for DMARC alignment on forwarded mail.
Publish a single SPF TXT record at the domain apex beginning with v=spf1. Include all authorized sending sources using ip4:, ip6:, or include: mechanisms. End the record with -all (hard fail) to reject mail from unauthorized sources. Avoid +all and ?all, as these provide no protection against spoofing. Keep the DNS lookup count below 10 by flattening include: chains where possible. Replace deprecated ptr: mechanisms with ip4: or ip6: ranges.
Most relevant for all production domains, with highest priority where DNS availability is business-critical.
Pair with Delegation Health Check, as nameserver concentration and delegation correctness address overlapping failure conditions.
If this policy fires, evaluate whether your DNS provider supports multi-provider or secondary DNS configurations. The minNameserverCount parameter defaults to 2; increase to 4 for critical domains.
For domains intentionally using a single provider, such as internal or low-traffic domains, consider reducing concentrationSeverity to LOW to suppress findings that aren't operationally relevant.
Belangrijk
Treat newly-registered findings on domains you didn't create as a potential brand-protection or phishing signal and investigate immediately.
Most relevant for all externally registered domains. Highest priority where expiry or status changes carry operational risk, including production hostnames, login endpoints, and API gateways.
Pair with Delegation Health Check for complete registration and delegation health coverage.
Enable auto-renewal at your registrar and set the expiryDaysThreshold parameter to at least twice your registrar's renewal processing window (default 30 days). Raise expiryWarningDaysThreshold to 90 or more for domains renewed manually.
Most relevant for domains with multiple authoritative nameservers from different providers.
Pair with Delegation Health Check, as SOA serial inconsistency and lame delegation often indicate the same underlying zone transfer problem.
If your setup uses AXFR-based secondary zones, a single convergence round delay is normal. The serialInconsistencySeverity parameter can be lowered to MEDIUM for environments where brief lag is expected.
Less relevant for single-provider anycast deployments where all nodes share state internally.
Opmerking
Posture impact is set to 0. Findings are advisory only and don't affect posture scores while industry-wide PQC migration is in progress.
Let op
Don't raise the default severity until your CA offers ML-DSA or SLH-DSA issuance. Increasing it prematurely will generate findings that can't yet be remediated.
Most relevant for public domains that serve or are expected to carry sensitive traffic.
Pair with TLS Certificate Validity to maintain complete certificate health coverage across both current validity and quantum readiness.
Use findings as a migration inventory to identify which domains and CAs require action before PQC certificates become broadly available from your providers.
Most relevant for all domains serving HTTPS traffic. Not relevant for internal or non-public domains.
Pair with Dangling Record Check, as a dangling CNAME pointing to a deprovisioned host will also fail TLS validation.
Tune expiryWarningDays to match your renewal cadence. 60 days is recommended for manual renewal workflows; 30 days is sufficient for automated renewal.