Domain Health: DNS, Security & Email Checks

The important bit: a healthy domain is not simply one that resolves. DNS provides the foundation for services, CAA helps control certificate issuance, DNSSEC protects DNS integrity, and SPF/DMARC reduce email-domain abuse. The checks are a practical starting point rather than a complete security audit.

Run the Domain Health Check

Enter a domain and Ingenix will query public DNS, RDAP and Certificate Transparency data and turn the results into actionable findings.

Open Domain Health Check →

How the health check works

The Domain Health Check performs public lookups for the domain you enter. It is deliberately a first-pass tool: it looks at information available from DNS, domain registration data and Certificate Transparency rather than attempting authenticated access, vulnerability scanning or intrusive testing.

The current checks cover A, AAAA, NS, SOA, CAA, DS, MX, SPF and DMARC records, plus RDAP registration information and Certificate Transparency entries. Results are grouped into DNS health, email authentication, and domain/certificate information.

Domain
  │
  ├── DNS ── A / AAAA / NS / SOA / CAA / DS
  ├── Email ── MX / SPF / DMARC
  ├── Registration ── RDAP / expiry
  └── Certificates ── Certificate Transparency

A missing record is not automatically a fault. A domain that never receives email does not need an MX record, and a domain that is not used as a web endpoint may legitimately have no A or AAAA record. Read recommendations in context.

Core DNS records

A

An A record maps a hostname to an IPv4 address. Multiple A records are normal and can provide distribution or resilience.

AAAA

An AAAA record maps a hostname to an IPv6 address. It is the normal way to make a service reachable over IPv6.

NS

NS records identify the authoritative name servers for the zone. Multiple authoritative servers are normally desirable for resilience.

SOA

The Start of Authority record contains core administrative and timing information for the zone and is fundamental to authoritative DNS operation.

The tool treats two or more authoritative NS records as a positive resilience signal. One NS record is not necessarily broken, but it deserves review. Two names also do not guarantee independent infrastructure if they depend on the same provider or failure domain.

CAA — control certificate issuance

CAA (Certification Authority Authorization) lets a domain owner publish a DNS policy stating which public Certificate Authorities (CAs) are authorised to issue certificates for the domain. It is a preventive control against some forms of unintended certificate issuance; it does not replace certificate validation, account security or other CA controls.

example.com.  CAA  0 issue "pki.goog"

The issue property authorises a CA to issue ordinary certificates. Other CAA properties can control wildcard issuance or provide reporting. The CA identifier must match the CA you actually use.

For example, if a certificate is issued by Google Trust Services, a CAA policy authorising pki.goog is appropriate. Do not copy a CA value from another domain without checking which CA currently issues your certificates.

CAA is most useful when you know which CAs your organisation relies on. If you authorise several providers, publish the corresponding CAA records. If you change certificate provider, update the policy before the new CA needs to issue a certificate.

What a CAA warning means: it does not mean your certificate is broken. It means you have not published an additional DNS-level restriction on which CAs may issue certificates for the domain.

DNSSEC — protect DNS integrity

DNSSEC (DNS Security Extensions) adds origin authentication and integrity protection to DNS data. It allows a validating resolver to determine whether a DNS response is authentic and whether a name or record type genuinely does not exist. DNSSEC does not encrypt DNS queries.

Parent zone
    │
    └── DS record
          │
          ▼
      DNSKEY in child zone
          │
          ▼
       RRSIG records
          │
          ▼
      DNS answer

The DS record is published at the parent delegation and links the parent zone to a DNSKEY in the signed child zone. That chain of trust allows a validating resolver to establish that signed data belongs to the intended zone.

The Domain Health Check looks specifically for a DS record. If none is detected, it reports that DNSSEC DS records were not detected. This is deliberately cautious: it does not prove that every DNSSEC signature validates correctly from every resolver.

DNSSEC is also relevant to controls such as CAA because authenticated DNS responses make it harder to suppress or alter the DNS information that a CA relies upon.

Think of DNSSEC as authenticity, not secrecy. It helps answer “did this DNS data really come from the zone owner?” It does not answer “can anyone see this DNS query?”

MX — mail routing

MX (Mail Exchange) records tell sending mail systems which hosts accept mail for a domain. They contain a priority value and a mail server hostname.

example.com.  MX  10 mail.example.com.

If the domain receives email, MX configuration is important. If it is only used for a website or another service and deliberately does not receive mail, having no MX record can be perfectly valid.

SPF — authorised senders

SPF (Sender Policy Framework) lets a domain publish which systems are authorised to send email using the domain's SPF identity. SPF is published as a TXT record:

example.com.  TXT  "v=spf1 ip4:192.0.2.10 -all"

A policy ending in -all says senders not otherwise authorised by the policy should fail SPF. A domain that does not send email may deliberately use v=spf1 -all.

The health check looks for a TXT record beginning with v=spf1. It does not prove that every sender in the policy is correct, nor does it perform a complete SPF evaluation.

SPF has a lookup limit. Mechanisms such as include, a, mx, ptr and exists can trigger DNS lookups. SPF evaluation is limited to 10 DNS-lookup-causing mechanisms/modifiers, so adding providers can eventually make an SPF policy fail with a permanent error.

SPF does not encrypt email and does not by itself authenticate the visible From: address. That is where DMARC and, commonly, DKIM become important.

DMARC — policy and alignment

DMARC (Domain-based Message Authentication, Reporting and Conformance) builds on SPF and DKIM. It lets a domain owner tell participating receivers what to do when a message claiming to be from the domain fails authentication and alignment, and it can provide reporting.

DMARC is published at _dmarc.example.com. A simple enforced policy is:

v=DMARC1; p=reject

Policy	Meaning	Typical use
`none`	Do not request a specific delivery action for failing mail.	Monitoring and initial deployment.
`quarantine`	Ask receivers to treat failing mail as suspicious.	Intermediate enforcement.
`reject`	Ask receivers to reject failing mail.	Strong enforcement once legitimate senders are understood.

DMARC uses identifier alignment. A message can pass SPF or DKIM and still fail DMARC if the authenticated domain does not align with the domain in the visible From: address. Alignment can be relaxed or strict; aspf and adkim control those modes.

The health check rewards the presence of a DMARC record and calls out p=none because that records participation but does not request enforcement. It does not validate DKIM selectors, inspect actual mail flows, or analyse DMARC reports.

Practical deployment: establish SPF and DKIM for legitimate sending services, publish DMARC, monitor reports, fix legitimate authentication failures, and then move towards stronger enforcement such as p=reject where appropriate.

RDAP — registration and expiry

RDAP (Registration Data Access Protocol) provides structured information about domain registrations. Depending on the registry and privacy rules, it can expose the registrar, registration events and an expiration date.

The health check uses RDAP to identify the registrar when available and to flag domains approaching expiry. An expiry warning is operational rather than a DNS or security finding: a perfectly configured domain can still become unavailable if its registration expires.

RDAP data is not guaranteed to contain every field for every domain, so “not reported” should not be interpreted as “broken”.

Certificate Transparency

Certificate Transparency (CT) provides publicly auditable logs of certificates issued by participating Certificate Authorities. The health check queries CT data to see how many certificate entries are associated with the domain.

Seeing certificates in CT is normally expected for an internet-facing domain. Multiple entries can represent different certificates, renewals, SAN combinations or historical certificates. A CT entry is not itself evidence of compromise.

CT is useful for discovery: if you find an unexpected certificate for a domain you control, investigate it. The health check does not determine whether every certificate is currently valid, whether a certificate is deployed, or whether an unexpected entry represents malicious activity.

How to interpret recommendations

Finding	Usually means	What to do
CAA missing	No DNS-level CA issuance restriction was detected.	Consider publishing CAA records for the CA(s) you trust.
DNSSEC DS missing	No secure delegation was detected at the parent.	Enable DNSSEC with your DNS provider/registrar if supported and appropriate.
MX missing	No inbound mail route is published.	Only treat this as a problem if the domain should receive email.
SPF missing	No SPF policy was detected.	Publish SPF if the domain sends email; use the actual sending services.
DMARC missing	No DMARC policy was detected.	Publish DMARC for domains used in email, after understanding legitimate senders.
DMARC `p=none`	DMARC is monitoring rather than requesting enforcement.	Review reports and authentication coverage before moving to stronger enforcement.
One NS	Only one authoritative server was returned.	Review DNS provider resilience and delegation.
Expiry approaching	RDAP reports a registration expiry date within the warning window.	Confirm renewal and ownership arrangements.

Recommendations are contextual. A marketing platform may require an SPF include, a website may need A/AAAA records, and a parked or sending-only domain may have a very different correct configuration.

What the check does not prove

It is not a vulnerability scanner. It does not test applications, TLS configuration, open ports, firewall rules or software versions.
It does not fully validate DNSSEC. A DS record is evidence of a secure delegation, not proof that every DNSSEC signature validates correctly.
It does not validate email delivery. An SPF or DMARC record can exist and still be incorrectly configured.
It does not inspect DKIM. DKIM is important to complete email authentication, but this tool currently checks SPF and DMARC records only.
It does not prove certificate safety. CAA reduces the risk of unintended issuance; CT provides visibility. Neither replaces certificate lifecycle management.
Public data can vary. DNS caches, provider behaviour, RDAP availability and CT data can change over time.

Use the result as a starting point. A good score means the public records checked by Ingenix look broadly sensible; it does not mean the domain is secure. A warning means “review this”, not necessarily “the domain is broken”.