Skip to content
Ticket Portal
  • There are no suggestions because the search field is empty.

EasyDMARC DNS Insight Checks

DNS Intelligence: The Checks We Run on Your Domain

DNS Intelligence continuously checks your domain the way the rest of the internet sees it, and flags anything that could cause an outage, send your email to junk, or let someone impersonate your brand. This article explains each of the 49 checks running on your domains today.

How to Read Your Results

Each check returns one of five results:

  • Pass — Configured correctly. Nothing to do.
  • Info — Worth knowing, not a problem. Often a deliberate choice.
  • Warning — Works today, but weaker or riskier than it should be.
  • Critical — Broken or dangerous. Fix this first.
  • Inconclusive — We couldn't get a clear reading this time. We'll recheck automatically.

An Inconclusive result is never counted against your domain. It means our lookup didn't complete, not that something is wrong on your side. We also never report a Pass unless we could see everything the check needs.

DNSSEC

DNSSEC is a tamper-evident seal on your DNS answers. Without it, an attacker positioned between a resolver and your domain can hand out forged answers that nobody can tell apart from real ones.

DNSSEC is enabled

  • What we check: We look for signing keys (DNSKEY records) on your domain.
  • Why it matters: Unsigned DNS can be forged, quietly redirecting your website visitors or email to an attacker's server.

Signing keys are well-formed

  • What we check: We confirm each published key has valid flags, protocol and algorithm fields.
  • Why it matters: A malformed key can be worse than none: resolvers that validate DNSSEC may reject your domain entirely.

The chain of trust connects

  • What we check: We compare the key fingerprint held at your registrar (the DS record) with the key actually published in your zone.
  • Why it matters: After moving DNS providers, it's easy to forget to update the DS record. When they don't match, validating resolvers treat your domain as untrustworthy and it can stop resolving, email included.

Non-existence proofs are configured well

  • What we check: We check how your zone proves that a name doesn't exist (NSEC or NSEC3) and how NSEC3 is tuned.
  • Why it matters: Current guidance (NIST and RFC 9276) recommends NSEC3 without extra hashing iterations, which add load for resolvers without adding meaningful protection. Plain NSEC is noted for information only.

The signing algorithm is strong

  • What we check: We read which cryptographic algorithm your keys use.
  • Why it matters: Older algorithms (numbers 5 and 7) rely on SHA-1, which is no longer trusted. Algorithm 13 is recommended and 15 is the strongest.

Nameservers support larger DNS messages

  • What we check: We confirm each nameserver supports EDNS0, the extension that allows DNS responses larger than the original 512-byte limit.
  • Why it matters: DNSSEC signatures don't fit in small responses, so DNSSEC can't work without it.

Signatures aren't about to expire

  • What we check: We read the expiry date on your zone's signatures.
  • Why it matters: Expired signatures make your domain fail validation for a large share of the internet. Expired or under 1 day is Critical; under 7 days is a Warning.

RSA keys are long enough

  • What we check: For RSA keys, we measure the key size in bits.
  • Why it matters: Short keys can be broken. Under 1024 bits is Critical and under 2048 bits is a Warning, in line with NIST SP 800-81r3.

Mail Servers and Delivery

MX records are your domain's mailing address: they tell the world which servers accept your email. These checks make sure that address exists, is written correctly, has a real backup, and points to servers other mail systems will trust.

Mail servers are published

  • What we check: We look for MX records. A deliberate "null MX" (declaring that your domain accepts no email) counts as a pass.
  • Why it matters: Without MX records, email sent to your domain bounces.

MX records point to hostnames

  • What we check: We check each MX value is a hostname rather than a raw IP address.
  • Why it matters: The email standard (RFC 5321) requires hostnames, and some senders refuse to deliver otherwise.

Mail server identity checks out both ways

  • What we check: We resolve each mail server's name to its IP, look up that IP's reverse name, and confirm the reverse name resolves back to the same IP.
  • Why it matters: Receiving systems use this round-trip as a basic trust signal; a mismatch can hurt your spam scores.

There is more than one mail server

  • What we check: We count your MX records.
  • Why it matters: With a single mail server, one outage leaves incoming mail with nowhere to go.

Backup mail servers are really separate

  • What we check: We check whether all your mail servers sit in the same network or the same IP block.
  • Why it matters: Two servers in the same network share the same outages, so the backup offers little protection.

Mail servers aren't on a blocklist

  • What we check: We check your mail server IPs against Spamhaus.
  • Why it matters: A listed IP gets its mail rejected or sent to junk by many receivers.

Encrypted delivery is enforced (MTA-STS)

  • What we check: We check for an MTA-STS policy, which tells senders to deliver to you only over verified encryption. A missing policy is informational, testing mode is a Warning, and a broken policy is Critical.
  • Why it matters: Without it, an attacker can strip encryption from mail on its way to you.

Delivery problems get reported (TLS-RPT)

  • What we check: We check for a TLS-RPT record and that its report addresses are valid.
  • Why it matters: TLS-RPT sends you reports when encrypted delivery to your domain fails. Enforcing MTA-STS without it means failures happen silently.

Email Authentication: SPF, DKIM and DMARC

SPF lists the servers allowed to send as your domain, DKIM adds a signature to each message, and DMARC tells receivers what to do when those checks fail. Mistakes here lead to spoofing, junk-folder delivery, or both.

SPF stays within 10 lookups

  • What we check: We follow every include and redirect in your SPF record, including nested ones, and count the DNS lookups they require.
  • Why it matters: SPF allows at most 10 lookups. Exceeding the limit makes SPF fail for every message, including legitimate ones.

There is exactly one SPF record

  • What we check: We look for more than one SPF record on the same name.
  • Why it matters: Two SPF records invalidate SPF. This usually happens when a new vendor's record is added instead of being merged into the existing one.

SPF ends with a strict policy

  • What we check: We read the "all" rule at the end of your SPF record. -all passes, ~all or ?all is a Warning, and +all is Critical.
  • Why it matters: +all means anyone on the internet may send email as your domain.

DMARC is present and enforcing

  • What we check: We check for a DMARC record and flag: no record, more than one record, p=none on a domain that sends mail, no report address (rua=), and a policy applied to less than 100% of mail.
  • Why it matters: p=none monitors but doesn't protect. Multiple DMARC records mean receivers apply no policy at all. Without rua=, nobody receives the reports.

DKIM keys are strong

  • What we check: We decode each DKIM public key and check its strength. A key that can't be read is Critical.
  • Why it matters: Weak keys can be cracked, allowing someone to sign mail as your domain. An unreadable key means every signature fails.

One key per DKIM selector

  • What we check: We check that each DKIM selector publishes a single key.
  • Why it matters: With two keys under one selector, receivers may pick the wrong one and fail your signatures unpredictably.

Microsoft 365 baseline

  • What we check: If your mail goes to Microsoft 365, we check the autodiscover record and both DKIM selector records (selector1 and selector2). Both present passes, one is a Warning, and neither is Critical.
  • Why it matters: Missing selector records usually mean DKIM was never enabled in your Microsoft 365 tenant.

DNS Record Hygiene

Zones collect clutter over the years: records for retired services, shortcuts that break other records, and details nobody meant to publish.

Verification tokens

  • What we check: We detect domain-verification records from Google, Microsoft, Atlassian, Facebook, Adobe and DocuSign.
  • Why it matters: Tokens for services you no longer use are clutter, and they reveal which vendors you work with, which helps attackers tailor phishing. Review them and remove the ones you don't need.

No CNAME on the root domain

  • What we check: We check whether your bare domain (example.com itself) is a CNAME.
  • Why it matters: DNS rules forbid this, and it breaks MX and TXT records on the root, including SPF and DMARC.

No wildcard MX or TXT records

  • What we check: We look for wildcard (*) MX or TXT records.
  • Why it matters: A wildcard makes every made-up subdomain accept mail or carry a TXT record, which is rarely intended and can confuse email authentication.

No internal details exposed

  • What we check: We look for HINFO (hardware and OS), RP (responsible person) and LOC (location) records.
  • Why it matters: These give attackers free reconnaissance and are rarely needed today.

Caching Times (TTL)

Every record tells resolvers how long they may cache it. Too short makes DNS fragile and noisy; too long means changes and emergency fixes take a long time to reach everyone.

TTLs are in sensible ranges

  • What we check: We read TTLs from your own nameservers and compare them with recommended ranges for each record type. A TTL of 0 is flagged separately.
  • Why it matters: Out-of-range TTLs either slow down fixes or put unnecessary load on DNS. NIST advises never using a TTL of 0.

No TTL stands out

  • What we check: We compare each TTL with the typical value in your zone and flag any more than 10 times different.
  • Why it matters: A large outlier is usually a typo or a temporary change that was never reverted.

SOA timers are healthy

  • What we check: We check the timers in your SOA record, which control how secondary nameservers stay in sync, and whether the zone's serial number has changed in the last year.
  • Why it matters: Poor timer values can leave secondary nameservers serving stale data. An unchanged serial can indicate a zone nobody is maintaining.

Certificate Authority Control (CAA)

CAA records list which certificate authorities may issue HTTPS certificates for your domain.

A CAA record exists

  • What we check: We look for CAA records. If one is missing, we can suggest a record pre-filled with the certificate authority you already use.
  • Why it matters: Without CAA, any certificate authority may issue a certificate for your domain.

Wildcard certificates are covered

  • What we check: We check for a dedicated rule for wildcard certificates (issuewild).
  • Why it matters: Wildcard certificates cover every subdomain, so it's worth deciding explicitly who may issue them.

Refused requests get reported

  • What we check: We check for an iodef contact address in your CAA records.
  • Why it matters: Without it, you won't hear about attempts to obtain a certificate for your domain.

Your certificate matches your CAA policy

  • What we check: We compare the issuer of your live website certificate with the authorities allowed in CAA.
  • Why it matters: If they don't match, your next certificate renewal will be refused.

Nameservers

Nameservers answer every question about your domain. If they fail, your website, email and everything else fail with them.

At least two nameservers

  • What we check: We count your NS records.
  • Why it matters: The DNS standard requires at least two. A single nameserver is a single point of failure.

Nameservers are on separate networks

  • What we check: We check whether all your nameservers share one network or one IP block.
  • Why it matters: If they do, a single network outage takes all of them down at once.

All nameservers serve the same version

  • What we check: We ask each nameserver for your zone's serial number and compare them.
  • Why it matters: A mismatch means synchronisation has failed, and some visitors get outdated records.

Every nameserver actually serves your zone

  • What we check: We query each listed nameserver directly and confirm it answers with authority for your domain.
  • Why it matters: A nameserver that's listed but doesn't know your domain causes intermittent, hard-to-diagnose failures, often after a migration.

Nameservers respond quickly

  • What we check: We send several queries to each nameserver and flag an average response time over 500 ms, or a server that drops most queries.
  • Why it matters: Slow DNS slows everything that depends on it: your website, email delivery, and every SPF and DKIM check receivers run.

Your zone can't be downloaded by strangers

  • What we check: We attempt a full zone transfer (AXFR) from each nameserver, as an anonymous party would.
  • Why it matters: If it succeeds, anyone can obtain a complete map of your domain's infrastructure. This is Critical.

Parked Domains

Domains that don't send email are popular targets for spoofing because they're rarely watched.

Parked domains are locked down

  • What we check: For domains marked as parked, we verify: no MX, a single SPF record of v=spf1 -all, DMARC at p=reject, no DKIM, DNSSEC enabled, and no wildcard CNAME.
  • Why it matters: This stops attackers from sending phishing that appears to come from your unused domains.

Security Contacts

These checks confirm that others can reach you when something goes wrong.

abuse@ accepts mail

  • What we check: We ask your mail server whether it would accept a message to abuse@ your domain, without sending one.
  • Why it matters: Other providers and recipients use this address to report spam or compromised accounts.

A security.txt file is published

  • What we check: We fetch /.well-known/security.txt and check it contains Contact and Expires fields (RFC 9116).
  • Why it matters: It tells security researchers how to report vulnerabilities to you.

Website Certificate (TLS)

The padlock in the browser depends on a valid certificate and modern encryption.

Your certificate isn't about to expire

  • What we check: We read your website certificate's validity dates. Expired or under 14 days is Critical, under 30 days is a Warning, and a certificate that isn't valid yet is Critical.
  • Why it matters: An expired certificate shows a full-screen warning to every visitor.

Outdated encryption isn't accepted

  • What we check: We specifically try TLS 1.0, TLS 1.1 and SSLv3 against your server. Accepting any of them is a Warning.
  • Why it matters: These versions are formally retired. Many servers still accept them even though modern browsers negotiate TLS 1.3 by default.

Website Security Settings (HTTP)

Your website sends instructions that tell browsers how to protect visitors.

Security headers are set

  • What we check: We check for six standard headers: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy and Permissions-Policy.
  • Why it matters: Each one blocks a class of attack, such as clickjacking or downgrading visitors to unencrypted HTTP.

http:// redirects to https://

  • What we check: We request your site over plain HTTP and expect a redirect to HTTPS. A closed port 80 alongside a working HTTPS site also passes.
  • Why it matters: A site that serves pages over plain HTTP lets passwords and form data travel unencrypted.

Cookies are protected

  • What we check: We flag cookies missing the Secure flag, and session cookies missing HttpOnly.
  • Why it matters: Without these flags, login cookies can leak over unencrypted connections or be read by malicious scripts.

Cross-site access is restricted (CORS)

  • What we check: We send a request that appears to come from an unknown website and check what your server allows. Trusting any origin with credentials is Critical; allowing all origins (*) is a Warning.
  • Why it matters: The Critical case means any website a signed-in user visits could read their data from your site.

Checks are based on current internet standards (RFCs) and NIST's DNS security guidance, SP 800-81r3. Current as of September 2026.