Security scan
The scan checks the records of a zone against established practice and reports what stands out:
GET /api/v1/zones/{id}/security-scanIn the UI, the report lives in the zone view.
What is checked
Section titled “What is checked”| Finding | Level | Meaning |
|---|---|---|
spf-missing | Info / warning | No SPF record at the zone origin. Warning if the zone accepts mail (MX present) |
spf-multiple | Error | Multiple SPF records — invalid per the standard, validation fails |
spf-lax | Warning | SPF ends too permissively (?all/+all), effectively useless |
dmarc-missing | Info / warning | No _dmarc; warning if the zone accepts mail |
dmarc-lax | Warning | DMARC policy is set to p=none — it only reports, it does not protect |
caa-missing | Info | No CAA record: any CA may issue for the domain |
wildcard | Warning | Wildcard record; also catches names nobody intended |
ns-single | Warning | Only one nameserver — no failover protection |
Every finding carries a level (error, warning, info), the affected name
and type, and a justification. The report summarizes the count per level.
What it is not
Section titled “What it is not”This is the scan at the configuration level — it reads the managed state of the zone. Monitoring the provider’s nameservers from the outside (records appearing out of nowhere, reachability, integrity) is a separate feature planned for later.
A finding is also a recommendation, not a verdict: a wildcard record can be exactly right. The scan says what stands out — the judgment stays with the operator.