DEV Community: Regő Botond Ronyecz

Top 10 DNS Security Tools for Proactive Threat Hunting (2026)

Regő Botond Ronyecz — Thu, 04 Jun 2026 13:25:25 +0000

Most DNS security advice is reactive. Something breaks, you investigate. But the teams that catch problems early aren't waiting for alerts from their SIEM — they're actively mapping their own attack surface before anyone else does.

These are the tools that make that possible. Some are for enumeration, some for continuous monitoring, some for hunting typosquatting and phishing infrastructure. All of them are worth having in your rotation.

1. Amass

What it does: Attack surface mapping and subdomain enumeration.

Amass is the most comprehensive open-source tool for external attack surface discovery. It combines passive DNS, certificate transparency logs, web archives, and active DNS queries to build the fullest possible picture of what's associated with a domain.

# Passive enumeration only (no direct queries to target)
amass enum -passive -d yourapp.com

# Active enumeration with brute forcing
amass enum -active -brute -d yourapp.com -o results.txt

It integrates with dozens of data sources: Shodan, VirusTotal, SecurityTrails, crt.sh, and more. The output can be fed into other tools or visualized with the built-in graph database.

Best for: getting a complete picture of your external footprint before a pentest or infrastructure audit.

Install: go install -v github.com/owasp-amass/amass/v4/...@master

2. dnsx

What it does: Fast, bulk DNS resolution and record querying.

dnsx is a swiss army knife for DNS queries at scale. You give it a list of subdomains and it resolves them fast, with support for filtering by record type, status code, or response content.

# Resolve a list and show only live hosts
cat subdomains.txt | dnsx -silent -a -resp

# Find all subdomains with CNAME records
cat subdomains.txt | dnsx -cname -silent

# Check for wildcard DNS
dnsx -d yourapp.com -wc -silent

Where MassDNS is about raw speed, dnsx is about usability. It fits naturally into pipelines with other tools.

Best for: quickly triaging a large list of subdomains, filtering by record type, feeding results into takeover scanners.

Install: go install -v github.com/projectdiscovery/dnsx/cmd/dnsx@latest

3. ZeroHook

What it does: Continuous DNS monitoring and dangling record detection.

Most of the tools on this list are point-in-time scanners. You run them, you get a snapshot, and then you move on. ZeroHook is different: it monitors your DNS records continuously and alerts you when something changes.

That matters because DNS threats aren't always present when you run your weekly scan. A dangling CNAME gets claimed at 2am on a Sunday. A nameserver record gets changed by someone who still has registrar access. An MX record gets removed and your email starts bouncing. You find out from a customer.

ZeroHook flags dangling CNAMEs, monitors NS and MX records for unexpected changes, and integrates with the rest of your alerting setup. It has a free tier that covers most small to medium setups.

Best for: teams that have done a one-time audit and now need ongoing visibility without running manual scans on a schedule.

zerohook.org

4. subjack

What it does: Automated subdomain takeover detection.

subjack takes a list of subdomains and checks each one against a fingerprint database of vulnerable hosting platforms: Heroku, GitHub Pages, Netlify, S3, Fastly, Shopify, and dozens more. It's looking for the pattern where your CNAME points at a platform, but the resource at that platform no longer exists.

# Basic scan
subjack -w subdomains.txt -t 100 -timeout 30 -o results.txt -ssl

# With verbose output
subjack -w subdomains.txt -t 100 -timeout 30 -v -ssl

The fingerprint database is community-maintained and updated as new platforms are identified as vulnerable. Worth cross-referencing with EdOverflow/can-i-take-over-xyz.

Best for: running after Amass or dnsx to identify which discovered subdomains are actually claimable.

Install: go install github.com/haccer/subjack@latest

5. DNStwist

What it does: Typosquatting and phishing domain detection.

DNStwist generates permutations of your domain — typos, homoglyphs, different TLDs, added words — and checks which ones are registered and what they're pointing at. It's how you find out that someone registered yourapp-login.com and is serving a credential harvesting page.

# Basic scan
dnstwist yourapp.com

# With MX records and GeoIP
dnstwist --mxcheck --geoip yourapp.com

# Export to CSV
dnstwist yourapp.com --format csv --output results.csv

The output tells you which permutations are registered, what their A/MX records are, and whether they look like they're set up to receive email (a strong phishing signal).

Best for: brand protection, finding phishing infrastructure before your users do, and incident response when you suspect an active campaign.

Install: pip install dnstwist

6. MassDNS

What it does: High-performance passive DNS resolution.

When you have a large wordlist and need to brute-force subdomain discovery fast, MassDNS is the tool. It's a stub resolver that can handle hundreds of thousands of queries per second by sending them asynchronously across multiple resolvers.

# Brute-force subdomains using a wordlist
massdns -r resolvers.txt -t A -o S wordlist.txt > results.txt

# Parse the output
cat results.txt | grep -v "NXDOMAIN" | awk '{print $1}' | sed 's/\.$//'

It's deliberately minimal — just resolution, no fingerprinting or analysis. Pipe the output to dnsx or subjack for the next step.

Best for: large-scale subdomain brute-forcing during a full attack surface audit. Less useful for targeted monitoring.

7. DNSRecon

What it does: DNS enumeration, zone transfer testing, and record auditing.

DNSRecon is one of the older tools on this list and still one of the most thorough for initial enumeration. It tests for zone transfer vulnerabilities (which still exist on misconfigured servers), enumerates standard and non-standard record types, and checks for common misconfigurations.

# Standard enumeration
dnsrecon -d yourapp.com

# Zone transfer attempt
dnsrecon -d yourapp.com -t axfr

# Reverse lookup on a CIDR range
dnsrecon -r 192.168.1.0/24

The zone transfer check is worth running on every domain you own. AXFR transfers should be restricted to authorized secondary nameservers only. When they're not, your entire zone file — every subdomain, every internal hostname — is readable by anyone.

Best for: initial enumeration, zone transfer testing, auditing record configurations.

Install: pip install dnsrecon

8. crt.sh

What it does: Certificate transparency log search.

Not a tool you install — a web interface and API for searching certificate transparency logs. Every TLS certificate ever issued for your domain is in there, including historical subdomains you may have forgotten.

# Pull all subdomains ever certificated for your domain
curl "https://crt.sh/?q=%.yourapp.com&output=json" \
  | jq -r '.[].name_value' \
  | sed 's/\*\.//g' \
  | sort -u

The output is a historical subdomain list you can feed directly into dnsx or subjack. It's usually the starting point for any DNS audit, because it doesn't require active scanning and returns data on infrastructure that may have been decommissioned years ago.

Best for: building a historical subdomain list, finding forgotten infrastructure, starting any DNS audit. Covered in more depth in our CT logs post.

9. Shodan

What it does: Internet-wide scanning, including DNS and nameserver infrastructure.

Shodan indexes the internet continuously and lets you query it. From a DNS security perspective, it's useful for finding exposed DNS servers (open resolvers, BIND version disclosure), locating infrastructure associated with your IP ranges, and understanding what's publicly visible on your network.

# Via CLI (requires API key)
shodan search "hostname:yourapp.com"

# Find open DNS resolvers on a CIDR
shodan search "net:192.168.1.0/24 port:53"

Shodan won't replace dedicated DNS enumeration tools, but it adds a layer that the others miss: what's actually running on the servers your DNS records point at.

Best for: understanding what's exposed beyond just the DNS records themselves, finding misconfigured nameservers, validating that decommissioned infrastructure is actually gone.

10. Passive DNS databases (DNSDB / SecurityTrails)

What it does: Historical DNS record lookup.

Passive DNS databases record DNS responses observed across large resolver networks over time. They answer questions that active scanning can't: what did this domain point at six months ago? When did this IP start hosting this domain? What other domains share this nameserver?

DNSDB (Farsight Security) and SecurityTrails are the main commercial options. SecurityTrails has a free tier with limited queries. Both are useful for threat hunting — if you're investigating suspicious infrastructure, passive DNS data lets you reconstruct its history and find connected domains.

Best for: incident response and threat hunting, tracing attacker infrastructure, understanding historical DNS changes you didn't monitor at the time.

Putting it together: a practical workflow

These tools work best in sequence, not in isolation.

For a one-time audit:

Pull historical subdomains from crt.sh
Enumerate additional subdomains with Amass
Resolve everything live with dnsx
Scan for takeover candidates with subjack
Check zone transfer exposure with DNSRecon
Run DNStwist to find phishing domains targeting your brand

For ongoing monitoring:

Set up ZeroHook or equivalent continuous monitoring on your DNS records. Run DNStwist monthly. Review your zone file quarterly. The one-time audit tells you where you are. The ongoing monitoring tells you when something changes.

Quick reference

Tool	Type	Primary use
Amass	Active/passive	Full attack surface enumeration
dnsx	Active	Bulk DNS resolution and filtering
ZeroHook	Monitoring	Continuous DNS change alerting
subjack	Active	Subdomain takeover detection
DNStwist	Active	Typosquatting and phishing detection
MassDNS	Active	High-speed brute-force resolution
DNSRecon	Active	Enumeration and zone transfer testing
crt.sh	Passive	Certificate transparency log search
Shodan	Passive	Exposed infrastructure discovery
DNSDB / SecurityTrails	Passive	Historical DNS records

TL;DR

Proactive DNS security is two things: knowing what you have, and knowing when it changes. The enumeration tools (Amass, dnsx, subjack, MassDNS, crt.sh) tell you what's out there. The monitoring tools (ZeroHook, passive DNS databases) tell you when things shift.

Run the audit workflow at least once against your full domain portfolio. You'll find something you forgot about. That's the point.

Part of an ongoing series on DNS security.

Developer's Guide to MTA-STS and TLS Reporting (2026)

Regő Botond Ronyecz — Thu, 04 Jun 2026 13:20:17 +0000

Most developers have heard of SPF, DKIM, and DMARC. Far fewer have heard of MTA-STS, and almost nobody has set up TLS Reporting. Which is a shame, because MTA-STS closes a real gap that the other three don't touch — and TLS Reporting is the only way to know when your email delivery is silently failing.

This guide covers both: what they do, how to set them up, and how to verify they're working.

The problem MTA-STS solves

When two mail servers exchange email, they're supposed to negotiate TLS so the message travels encrypted. But "supposed to" is doing a lot of work in that sentence.

SMTP's STARTTLS mechanism is opportunistic by default. That means:

Sending server connects to your MX host
Sending server says "do you support TLS?"
If yes, they upgrade to TLS
If no (or if an attacker strips the STARTTLS offer), they fall back to plaintext

Step 4 is the problem. An attacker who can intercept traffic between two mail servers — a network-level attacker, a rogue DNS resolver, anyone doing BGP hijacking — can silently strip the STARTTLS advertisement. The sending server sees "no TLS available" and delivers in plaintext. No error. No bounce. No indication anything went wrong.

This is called a STARTTLS downgrade attack, and it's been documented in the wild against real mail providers.

MTA-STS fixes this by publishing a policy that tells sending servers: "our MX hosts support TLS, you should require it, and here's a certificate you can validate against." A sending server that respects MTA-STS will refuse to deliver if TLS negotiation fails or if the certificate doesn't match, rather than falling back to plaintext.

The short version: SPF, DKIM, and DMARC protect against spoofing and phishing. MTA-STS protects the transport layer — the connection between mail servers — from being downgraded or intercepted.

How MTA-STS works

The mechanism involves two components: a policy file served over HTTPS, and a DNS TXT record that tells sending servers where to find it.

Sending server looks up _mta-sts.yourapp.com in DNS to check if a policy exists
If found, it fetches https://mta-sts.yourapp.com/.well-known/mta-sts.txt over HTTPS
The policy tells it which MX hosts to expect and what mode to operate in
It connects to your MX host and requires TLS with a valid, matching certificate
If TLS fails or the cert doesn't match, it refuses delivery instead of falling back to plaintext

The policy file is served over HTTPS from a subdomain you control. The HTTPS requirement is what makes this work: the policy itself can't be tampered with in transit.

The policy file is served over HTTPS from a subdomain you control. The HTTPS requirement matters: it means the policy itself can't be tampered with in transit.

Setting up MTA-STS

Step 1 — Create the policy file

The policy file is a plain text file served at exactly this path:

https://mta-sts.yourapp.com/.well-known/mta-sts.txt

It looks like this:

version: STSv1
mode: enforce
mx: mail.yourapp.com
mx: *.yourapp.com
max_age: 86400

Field	Description
`version`	Always `STSv1`
`mode`	`enforce`, `testing`, or `none` (see below)
`mx`	One entry per MX host you accept mail on. Wildcards allowed.
`max_age`	How long (seconds) sending servers should cache this policy

Mode choices explained:

Mode	What happens when TLS fails
`testing`	Delivery proceeds, failure reported via TLS-RPT
`enforce`	Delivery refused if TLS fails or cert doesn't match
`none`	Policy effectively disabled

Start with testing. Run it for a week or two while you monitor TLS-RPT reports (covered below). Once you're confident your MX hosts are properly configured, switch to enforce.

Don't start with enforce if you haven't verified your MX hosts present valid, trusted certificates with matching hostnames. You will break inbound email delivery.

Step 2 — Serve the policy file over HTTPS

You need a subdomain mta-sts.yourapp.com with a valid TLS certificate serving the policy file. The response must:

Return HTTP 200
Have Content-Type: text/plain
Be accessible over HTTPS (not HTTP)

If you're on Nginx:

server {
    listen 443 ssl;
    server_name mta-sts.yourapp.com;

    ssl_certificate     /etc/letsencrypt/live/mta-sts.yourapp.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mta-sts.yourapp.com/privkey.pem;

    location /.well-known/mta-sts.txt {
        alias /var/www/mta-sts/mta-sts.txt;
        default_type text/plain;
    }
}

If you're on a static hosting platform (Netlify, Vercel, Cloudflare Pages), put the file at /.well-known/mta-sts.txt and set the content type to text/plain. Make sure HTTPS redirect is enabled.

Step 3 — Add the DNS TXT record

Add a TXT record at _mta-sts.yourapp.com:

_mta-sts.yourapp.com.  IN  TXT  "v=STSv1; id=20260101000000Z"

The id field is how sending servers know when your policy has changed. It's a version string — you can use a timestamp or any string up to 32 characters. Every time you update your policy file, update the id in this DNS record. Sending servers that have cached your policy check the id to know whether to re-fetch.

Common mistake: Updating the policy file without updating the id means sending servers keep using the cached version. If you're changing from testing to enforce, the old cached policy stays in effect until the max_age expires.

Setting up TLS Reporting (TLS-RPT)

TLS Reporting is RFC 8460. It lets you receive reports when sending mail servers encounter TLS failures while trying to deliver to your domain.

You add one DNS TXT record at _smtp._tls.yourapp.com:

_smtp._tls.yourapp.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@yourapp.com"

That's it. Sending servers that support TLS-RPT will now send daily JSON reports to that address summarizing:

How many messages were delivered successfully with TLS
How many failed, and why
Which sending servers encountered the failures

The reports are machine-readable JSON. You'll want either a dedicated inbox you check periodically or a service that parses and aggregates them. Report URI and Postmark's DMARC/TLS aggregator both handle TLS-RPT reports.

Sample report structure:

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-01-01T00:00:00Z",
    "end-datetime": "2026-01-01T23:59:59Z"
  },
  "policies": [{
    "policy": {
      "policy-type": "sts",
      "policy-domain": "yourapp.com"
    },
    "summary": {
      "total-successful-session-count": 1240,
      "total-failure-session-count": 3
    },
    "failure-details": [{
      "result-type": "certificate-expired",
      "sending-mta-ip": "209.85.128.0",
      "receiving-mx-hostname": "mail.yourapp.com",
      "failed-session-count": 3
    }]
  }]
}

Three failures from certificate expiry. Without TLS-RPT, you'd never know.

Verifying your setup

Check the DNS record:

dig TXT _mta-sts.yourapp.com +short
dig TXT _smtp._tls.yourapp.com +short

Check the policy file is reachable:

curl -I https://mta-sts.yourapp.com/.well-known/mta-sts.txt
curl https://mta-sts.yourapp.com/.well-known/mta-sts.txt

Expected output from the first command: HTTP/2 200 with content-type: text/plain.

Full validation tools:

Tool	What it checks
mta-sts.io	Full MTA-STS policy validation
internet.nl	Comprehensive mail security check including MTA-STS
checktls.com	TLS configuration on your MX hosts
MXToolbox	MTA-STS policy lookup

Common failure modes

Policy file returns wrong content type
Some static hosts serve .txt files as application/octet-stream. Sending servers will reject the policy. Set Content-Type: text/plain explicitly in your hosting config.

Certificate on mta-sts subdomain doesn't cover the subdomain
If you're using a wildcard cert for *.yourapp.com, make sure it covers mta-sts.yourapp.com. A separate cert for just the subdomain also works.

MX host certificate doesn't match hostname
Your policy file lists mail.yourapp.com as an MX host. The certificate on that host needs to include mail.yourapp.com in the SAN. If it only has the bare domain or a different hostname, validation will fail under enforce mode.

id not updated after policy change
Covered above, but worth repeating: if you change the policy file without changing the id, sending servers use the stale cached version. The id is how they know to re-fetch.

HTTP redirect on the policy URL
The policy must be served directly over HTTPS. If your setup serves HTTP and redirects to HTTPS, some sending servers won't follow the redirect and will treat the policy as unavailable.

The rollout sequence

Here's the order that avoids breaking inbound email:

Week 1-2: deploy in testing mode

Deploy the policy file with mode: testing
Add both DNS records (_mta-sts and _smtp._tls)
Verify with the validation tools listed above

Week 2-4: collect reports and fix issues

Read the TLS-RPT reports coming into your inbox
Fix any certificate or TLS config issues on your MX hosts
Re-check with checktls.com

Week 4 onwards: switch to enforce

Update the policy file: change mode: testing to mode: enforce
Update the id value in your _mta-sts DNS TXT record
Keep watching TLS-RPT reports for anything new

Don't rush the middle step. The reports will show you things you didn't know were broken.

Monitoring

Once MTA-STS is in enforce mode, any DNS misconfiguration on your end can break inbound email delivery. If your policy file goes down, if the mta-sts subdomain certificate expires, or if someone changes the DNS records unexpectedly, sending servers that respect MTA-STS will stop delivering to you.

Two things to monitor:

The HTTPS endpoint. Uptime monitoring on https://mta-sts.yourapp.com/.well-known/mta-sts.txt should alert you if the file becomes unavailable or returns a non-200 status.

The DNS records. If your _mta-sts TXT record is modified or deleted, sending servers can't find your policy. ZeroHook monitors DNS records continuously and alerts you when something changes — useful not just for MTA-STS but for the full set of email security records (SPF, DKIM, DMARC, MX). One change to the wrong record can quietly break email in ways that take days to diagnose: zerohook.org.

Quick reference

DNS records you need:

Record	Type	Value
`_mta-sts.yourapp.com`	TXT	`v=STSv1; id=20260101000000Z`
`_smtp._tls.yourapp.com`	TXT	`v=TLSRPTv1; rua=mailto:tls-reports@yourapp.com`

Policy file location:

https://mta-sts.yourapp.com/.well-known/mta-sts.txt

Policy file content:

version: STSv1
mode: testing
mx: mail.yourapp.com
max_age: 86400

Rollout order: deploy in testing → collect reports → fix issues → switch to enforce → monitor.

TL;DR

SPF, DKIM, and DMARC don't protect the connection between mail servers. A network-level attacker can strip TLS from SMTP and your email travels in plaintext with no indication anything went wrong.

MTA-STS fixes that by publishing a policy that says "require TLS, validate the cert, refuse delivery if it fails." TLS Reporting gives you visibility into when and why TLS is failing so you can fix it before you switch to enforce mode.

Setup is two DNS records and a text file on a subdomain. The tricky part is the rollout order — start in testing, read the reports, fix your cert issues, then enforce.

Part of an ongoing series on DNS and email security.

Beginner-Friendly: The Small Business Owner's DNS Security Checklist

Regő Botond Ronyecz — Thu, 04 Jun 2026 12:20:35 +0000

You do not need to know what DNS stands for to use this checklist.

You need to know three things:

Your domain name (the part after the @ in your email address — like yourbusiness.com)
Who hosts your website or where you registered your domain (GoDaddy, Namecheap, Cloudflare, or whoever sends you the renewal invoice)
About 30 minutes

That is enough to work through this checklist, identify what is missing on your domain, and know who to call to fix it.

Why This Matters Before Anything Else

Every small business that owns a domain has the same three problems, usually without knowing it.

Problem 1: Anyone can send email pretending to be you. By default, email has no authentication. If you own yourbusiness.com, a scammer can send an email saying it came from invoices@yourbusiness.com and most email apps will show your business name as the sender. Your customers have no way to tell the difference. Three DNS records (SPF, DKIM, DMARC) fix this — and most small businesses have none of them correctly configured.

Problem 2: Your legitimate emails are landing in spam. Not because you did anything wrong. Because without those same three records, Gmail and Outlook treat your emails with suspicion. Password resets, invoices, and follow-ups are going to spam folders instead of inboxes — and you have no idea.

Problem 3: Your domain could be stolen or redirected. The account where you registered your domain (GoDaddy, Namecheap, etc.) is the single most valuable target for someone who wants to impersonate your business. If someone gets into that account, they own your domain, your website, and your email. A few settings changes prevent this entirely.

None of this requires technical expertise to fix. It requires knowing what to look for and asking the right person to action it.

How to Use This Checklist

Each item below has:

What it is — a plain-English explanation
How to check — the easiest way to see your current status
Who fixes it — you, your web developer, your IT person, or your hosting provider
Priority — how urgently this needs attention

Work through the items in order. The high-priority items first. If something is above your comfort level, screenshot it and send it to whoever manages your website or IT.

Section 1: Your Domain Registrar Account (Do This First)

Your domain registrar is where you registered your domain name — companies like GoDaddy, Namecheap, Cloudflare, Google Domains, or Hover. This account controls everything. Protecting it is the first step.

✅ Item 1.1 — Two-Factor Authentication on Your Registrar Account

What it is: Two-factor authentication (2FA) means that even if someone steals your password, they cannot log in without also having your phone. It is a second lock on the front door.

Why it matters: If someone gains access to your domain registrar account, they can point your domain at any website they choose — including a fake version of yours that steals your customers' passwords. This has happened to well-known businesses, not just careless ones.

How to check: Log in to your domain registrar. Go to account settings or security settings. Look for "Two-Factor Authentication," "2-Step Verification," or "Multi-Factor Authentication." If it is not enabled, there will be an option to turn it on.

Who fixes it: You. It takes five minutes. Use an authenticator app (Google Authenticator, Authy) rather than SMS if the option is available — SMS can be intercepted.

Priority: Critical. Do this today.

✅ Item 1.2 — Domain Lock / Transfer Lock Enabled

What it is: Most registrars offer a "domain lock" that prevents your domain from being transferred to another registrar without additional verification. Unlocked domains can be stolen through a process called an unauthorized transfer.

Why it matters: Domain theft — transferring your domain to a registrar the attacker controls — is one of the most damaging things that can happen to a business. It takes days to recover, and your website and email are offline the entire time.

How to check: Log in to your domain registrar. Find your domain and look for a setting called "Transfer Lock," "Registrar Lock," or "Domain Lock." It should be set to ON or LOCKED.

Who fixes it: You. Toggle the lock on in your registrar account.

Priority: High.

✅ Item 1.3 — Your Registrar Contact Email Is Current

What it is: Your registrar sends renewal notices, security alerts, and transfer confirmations to the email address on file. If that address is an old personal email, a former employee's account, or an inbox nobody checks, these notifications disappear.

Why it matters: Domain renewal notices going to an inbox nobody monitors is one of the most common reasons small businesses lose their domain — they miss the renewal, the domain expires, and someone else registers it.

How to check: Log in to your registrar. Check the contact email address under account settings. Send a test email to it and confirm you receive it.

Who fixes it: You. Update the email to one that you — or someone responsible — actively monitors.

Priority: High.

✅ Item 1.4 — Auto-Renew Is Enabled for Your Domain

What it is: Auto-renew automatically renews your domain registration before it expires, charging the card on file.

Why it matters: An expired domain goes offline immediately. Website down, email stopped, everything offline. After a 30-day grace period, the domain enters public availability. Competitors, domain squatters, or attackers can register it. Recovering it — if possible — is expensive and takes days.

How to check: Log in to your registrar. Find your domain. Check whether auto-renew is enabled and whether the payment card on file is current.

Who fixes it: You. Enable auto-renew and confirm the payment method is valid.

Priority: High.

Section 2: Email Authentication Records

These three records (SPF, DKIM, DMARC) tell the internet that your emails are legitimate. Without them, your emails look suspicious to every inbox provider in the world. With them, you are protected against email impersonation and your delivery rates improve.

You do not need to understand how they work. You need to know whether they are set up — and if not, have someone set them up.

✅ Item 2.1 — SPF Record Exists and Is Correct

What it is: SPF (Sender Policy Framework) is a list, published in your domain's DNS, of the email services that are allowed to send email on your behalf. Think of it as an authorized sender list that inbox providers check before accepting your email.

Why it matters: Without SPF, anyone can send email claiming to be from your domain and inbox providers have no way to verify it is fake. With a broken SPF record (two records, or over the 10-lookup limit), your emails may land in spam or be rejected.

How to check: Go to mxtoolbox.com/spf.aspx and enter your domain. It will tell you whether an SPF record exists, whether it is valid, and whether there are any errors.

What to look for:

✅ "SPF record found" with no errors — you are set
⚠️ "Multiple SPF records found" — there are two SPF records, which breaks email. One needs to be deleted.
❌ "No SPF record found" — no SPF is configured

Who fixes it: Your web developer, IT person, or email provider. Give them the MXToolbox result and ask them to fix it.

Priority: High.

✅ Item 2.2 — DKIM Is Configured for Your Email Service

What it is: DKIM (DomainKeys Identified Mail) adds an invisible digital signature to every email you send. Receiving servers verify this signature to confirm the email genuinely came from you and was not altered in transit. Think of it as a tamper-evident seal on every email.

Why it matters: Without DKIM, your emails lack a key trust signal that Gmail, Outlook, and Yahoo use to evaluate sender reputation. It is also required before you can set up DMARC (the next item).

How to check: Go to mxtoolbox.com/dkim.aspx. Enter your domain. For the selector field, try google if you use Google Workspace, or selector1 if you use Microsoft 365. If you are unsure, ask whoever set up your email.

What to look for:

✅ "DKIM record found, valid" — you are set
❌ "DKIM record not found" — DKIM is not configured for that selector

Who fixes it: Your email provider or IT person. Google Workspace, Microsoft 365, and most email providers have documentation on how to configure DKIM — it involves adding a TXT record to your DNS. Your provider can walk you through it or do it for you.

Priority: High.

✅ Item 2.3 — DMARC Is Configured (and Not Just at p=none)

What it is: DMARC ties SPF and DKIM together and tells inbox providers what to do when an email fails authentication — for example, when a scammer tries to send a fake invoice from your domain. It also sends you daily reports showing who is sending email as your domain.

There are three DMARC policy levels:

p=none — monitor only, do nothing (a starting point, not a finished configuration)
p=quarantine — send suspicious emails to spam
p=reject — block suspicious emails entirely

Why it matters: p=none does not protect anyone. It just collects data. The protection starts at p=quarantine. Most small businesses that have DMARC configured are stuck at p=none and don't know it.

How to check: Go to mxtoolbox.com/dmarc.aspx and enter your domain.

What to look for:

✅ "DMARC record found" with p=quarantine or p=reject — good
⚠️ "DMARC record found" with p=none — configured but not enforced. Ask your IT person to move it to p=quarantine after confirming SPF and DKIM are passing.
❌ "No DMARC record found" — DMARC is not configured at all

Who fixes it: Your IT person or web developer. Moving from p=none to p=quarantine is a single character change to a DNS record — but it should be done carefully, after confirming SPF and DKIM are working correctly first.

Priority: High.

✅ Item 2.4 — You Are Not on an Email Blacklist

What it is: Email blacklists are databases of IP addresses and domains known to send spam. Inbox providers check these lists when deciding whether to deliver your email. If your domain or sending IP is listed, your emails may be silently rejected or sent to spam.

Why it matters: Blacklistings happen to legitimate businesses — often from a compromised email account, a spam complaint, or a sudden spike in sending volume. Most businesses find out when customers stop receiving their emails.

How to check: Go to mxtoolbox.com/blacklists.aspx and enter your domain or sending IP address. It checks against over 100 blacklists simultaneously.

What to look for:

✅ All green — you are not listed anywhere
❌ One or more red items — you are listed on a blacklist. Follow the removal instructions for each list. Spamhaus, Barracuda, and SORBS each have their own removal forms.

Who fixes it: You can often submit removal requests yourself — each blacklist has a form on their website. If you are listed on Spamhaus specifically, contact your IT person first as it requires explaining what caused the listing.

Priority: High if listed, otherwise ongoing monitoring.

Section 3: Website and SSL Security

✅ Item 3.1 — Your SSL Certificate Is Valid and Not Expiring Soon

What it is: The padlock icon in your browser that indicates a secure connection. Your website needs a valid SSL certificate to show this padlock. An expired certificate causes browsers to display a warning page that blocks visitors.

Why it matters: A browser warning page stops customers from reaching your website. It looks like your site has been hacked even if it has not. It also harms your search engine rankings.

How to check: Visit your website. In your browser address bar, click the padlock icon. It should show "Connection is secure" and a certificate that is not expiring in the next 30 days. You can also check at sslshopper.com/ssl-checker.html.

What to look for:

✅ Padlock present, certificate valid for 30+ days — you are set
⚠️ Expiring within 30 days — contact your hosting provider to renew
❌ No padlock or certificate error — contact your hosting provider immediately

Who fixes it: Your hosting provider or web developer. Most hosting providers offer free SSL certificates through Let's Encrypt that auto-renew.

Priority: Critical if expired. Monitoring if valid.

✅ Item 3.2 — Your Website Redirects HTTP to HTTPS

What it is: Your website should automatically redirect visitors from http://yourbusiness.com to https://yourbusiness.com. Without this redirect, some visitors — especially those following old links — reach your site over an unencrypted connection.

How to check: In your browser address bar, type http://yourbusiness.com (with http, not https) and press enter. You should be automatically redirected to the https:// version. If you stay on http://, the redirect is missing.

Who fixes it: Your web developer or hosting provider. It is a standard configuration option on all major hosting platforms.

Priority: Medium.

Section 4: DNS Configuration

This section requires slightly more technical knowledge — but each check has a simple tool you can use to see your status, and a clear description of what to ask your IT person to fix.

✅ Item 4.1 — DNSSEC Is Enabled

What it is: DNSSEC is a security layer that adds a digital signature to your DNS records. Without it, it is theoretically possible for attackers to intercept the "where does this website live?" lookup that happens when someone visits your domain and redirect them to a fake website instead.

Why it matters: Most small businesses do not have DNSSEC enabled because it was not on by default when they set up their domain. On modern DNS providers it takes about five minutes to enable.

How to check: Go to dnssec-analyzer.verisignlabs.com and enter your domain. A green result means DNSSEC is active and working. Red or missing means it is not configured.

Who fixes it: Your IT person or DNS provider. On Cloudflare, it is a one-click toggle under DNS settings. On GoDaddy, it requires a manual DS record submission. Ask your IT person to enable it.

Priority: Medium — high if you are in an NIS2-regulated sector.

✅ Item 4.2 — MTA-STS Is Configured (Inbound Email Encryption)

What it is: MTA-STS forces other email servers to use encryption when delivering email to your inbox. Without it, there is a theoretical risk that email sent to you could be intercepted and read in transit.

Why it matters: Most email transport is encrypted by default today, but without MTA-STS there is no enforcement — an attacker in the right position can downgrade the connection. MTA-STS eliminates that possibility.

How to check: Go to internet.nl/mail/yourbusiness.com/ (replace with your domain) and look for the MTA-STS result. Or ask your IT person to check.

Who fixes it: Your IT person. MTA-STS requires two changes — a DNS record and a small text file hosted on a subdomain of your domain. It is a 15-minute task for someone with web hosting access.

Priority: Medium — required for NIS2 compliance.

✅ Item 4.3 — CAA Records Restrict Certificate Issuance

What it is: CAA records tell the internet which companies are allowed to issue SSL certificates for your domain. Without them, any certificate authority in the world could issue a certificate for your website — including in response to an impersonation attack.

How to check: Go to mxtoolbox.com/caa.aspx and enter your domain.

What to look for:

✅ "CAA record found" — you have records restricting certificate issuance
❌ "No CAA records found" — any CA can issue for your domain

Who fixes it: Your IT person or DNS provider. They add a CAA record specifying your current certificate provider.

Priority: Low-medium.

Section 5: Quick Reference — Who Does What

If you manage your website and email yourself, you can action most of these items using your registrar and hosting provider's control panel. If you have an IT person, web developer, or use a managed hosting service, forward them this checklist with the items you want actioned.

Item	You can do it	Needs your IT person
Enable 2FA on registrar	✅
Enable domain lock	✅
Update registrar contact email	✅
Enable auto-renew	✅
Check SPF record	✅ (check)	✅ (fix)
Configure DKIM		✅
Configure DMARC		✅
Blacklist check	✅
SSL certificate check	✅ (check)	✅ (fix if expired)
Enable DNSSEC		✅
Configure MTA-STS		✅
Add CAA records		✅

The One-Page Summary for Your IT Person

If you are forwarding this to someone technical, here is the condensed version of what needs checking:

Domain security audit — please check and fix the following:

Registrar:
- 2FA enabled on registrar account?
- Transfer lock enabled?
- Auto-renew active, card current?

Email authentication:
- SPF record valid? Single record, under 10 lookups?
- DKIM configured for all sending services (Google Workspace / M365 / other)?
- DMARC at p=quarantine or p=reject? (p=none is not sufficient)
- Domain/sending IP clean on MXToolbox blacklist check?

DNS:
- DNSSEC enabled? (verify at dnssec-analyzer.verisignlabs.com)
- MTA-STS configured in enforce mode?
- CAA records restricting certificate issuance?

Website:
- SSL certificate valid, not expiring within 30 days?
- HTTP → HTTPS redirect working?

What to Do After the Checklist

Running through this list once is a good start. The problem is that DNS security is not a one-time task — it changes.

Email services you add change which servers need to be in your SPF record. SSL certificates expire. Domains come off blacklists and go back on. DNSSEC signatures have expiry dates. Your registrar account password may be compromised without you knowing.

The options for ongoing monitoring:

Manual — check quarterly. Block 30 minutes in your calendar every three months to run through the checks in this list. Use the tools above. It is not automated, but it is better than checking once and forgetting about it.

Automated — use a monitoring tool. ZeroHook runs these checks automatically and alerts you when something changes or breaks — a blacklist listing, an SSL certificate approaching expiry, an SPF failure. The free tier covers one domain with SPF, DKIM, DMARC validation, blacklist monitoring, and an Email Health Score: zerohook.org

TL;DR

Secure your registrar account first — 2FA enabled, transfer lock on, auto-renew active, contact email current. This single step prevents domain theft.
SPF, DKIM, and DMARC are the three email records every domain needs — without them, your emails look suspicious to inbox providers and anyone can send email impersonating you
DMARC at p=none is not a finished configuration — it monitors without protecting; ask your IT person to move it to p=quarantine
Check your blacklist status at mxtoolbox.com/blacklists.aspx — listings happen silently and your dashboard will not tell you
DNSSEC and MTA-STS are the next tier — not urgent for day-to-day operations, but required for NIS2 compliance and best practice for any business handling customer data
Forward the one-page summary above to your IT person — they can action the full list in an afternoon

Part of an ongoing series on DNS security and email deliverability.

How to Test Your SPF Record for Common Mistakes (Step by Step)

Regő Botond Ronyecz — Sat, 30 May 2026 23:28:38 +0000

Your SPF record looks correct. You added the include values your email provider told you to add. You saved the record. Emails are still landing in spam.

The problem is almost certainly one of five things — and four of them are invisible in your DNS provider's interface. You cannot tell by looking at the record whether you have exceeded the 10-lookup limit. You cannot tell from a browser whether your propagation has completed. You cannot see from the dashboard that a second SPF record was created instead of the existing one being edited.

This guide covers how to test for each of the five most common SPF mistakes, what the symptoms of each one look like, and the exact fix.

The Basics: What SPF Is and What It Isn't

SPF (Sender Policy Framework) is a TXT record published at your root domain that lists which mail servers are authorized to send email on your behalf. When a receiving server gets an email claiming to be from your domain, it checks your SPF record and asks: did the sending server have permission?

The record structure:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

v=spf1 — required, always first, identifies the record as SPF
include: — delegates authorization to another domain's SPF record
~all — soft fail: unauthorized senders are flagged but still delivered
-all — hard fail: unauthorized senders are rejected entirely
+all — allows everyone: never use this

SPF does not encrypt email. It does not stop spam. It tells receiving servers who is allowed to send email from your domain — and when combined with DKIM and DMARC, it provides the full authentication chain that inbox providers use to decide where your email lands.

Step 1: Check That Your SPF Record Exists

Before testing for mistakes, confirm the record is actually there.

dig yourdomain.com TXT +short | grep spf

Expected output:

"v=spf1 include:_spf.google.com ~all"

If you get no output: Your domain has no SPF record. Create one — the absence of SPF means any server on the internet can send email claiming to be from your domain, and receiving servers have no way to verify it is fake.

If you get output but it does not start with v=spf1: You have a TXT record but it is not a valid SPF record. Check for typos — a common one is v=spfl (lowercase L instead of the digit 1).

Mistake 1: Two SPF Records on the Same Domain

This is the most common SPF mistake and the most damaging. It happens when someone creates a new SPF TXT record instead of editing the existing one — a natural thing to do if you are unfamiliar with DNS and want to add a new sending service.

The rule: Only one TXT record starting with v=spf1 is allowed per domain. Two records instantly invalidates both. Every email you send fails SPF. The symptom — emails landing in spam or being rejected — appears immediately after the second record propagates.

How to test:

dig yourdomain.com TXT +short

Count the lines in the output that start with v=spf1. If you see two, you have a duplicate.

"v=spf1 include:_spf.google.com ~all"
"v=spf1 include:sendgrid.net ~all"

That is two SPF records. Both are now invalid.

The fix: Go to your DNS provider. Delete one of the records. Edit the remaining one to include all the values from both:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Provider note: DigitalOcean's DNS panel does not have an inline edit button for existing records — you delete and recreate. Cloudflare and Namecheap have pencil icons to edit in place.

Mistake 2: Exceeding the 10 DNS Lookup Limit (SPF PermError)

SPF allows a maximum of 10 DNS lookups during validation. Each include: directive in your record counts as one lookup. Each of those included records may itself contain include: directives, which count as additional lookups — recursively.

When the 10-lookup limit is exceeded, SPF validation returns a PermError result. Many receiving servers treat PermError the same as a hard fail — your email is rejected or sent to spam, and the SPF result in the email headers shows permerror or fail.

The problem is invisible. Your record may look fine with only three include: values. But if one of those included records itself includes four more records, you may already be at seven lookups before counting the rest.

How to test:

The command-line approach requires manually counting recursive lookups, which is tedious. Use an online SPF checker instead — MXToolbox's SPF lookup at mxtoolbox.com/spf.aspx shows the total lookup count including recursive includes:

# Quick local check: count your direct includes
dig yourdomain.com TXT +short | grep -o 'include:[^ ]*' | wc -l

This counts only your direct includes, not recursive ones — use it as a first indicator. If you have 6+ direct includes, you are likely over the limit when recursive lookups are counted.

Common high-lookup culprits:

Service	Include value	Recursive lookups
Google Workspace	`include:_spf.google.com`	1
Microsoft 365	`include:spf.protection.outlook.com`	1
SendGrid	`include:sendgrid.net`	1
Salesforce	`include:_spf.salesforce.com`	3–4
Mailchimp / Mandrill	`include:servers.mcsv.net`	2–3
HubSpot	`include:_spf.hubspot.com`	2
Zendesk	`include:mail.zendesk.com`	2

A setup with Google Workspace, SendGrid, Salesforce, HubSpot, and Zendesk is likely already over the limit.

The fix: Remove include: entries for services you no longer use. If you legitimately use more services than the limit allows, use SPF flattening — a tool that resolves all the include chains into their constituent IP addresses and writes a single record with explicit ip4: and ip6: entries instead of include: directives. autospf.com and dmarcian's SPF Surveyor both do this. ZeroHook flags the PermError in its SPF audit check and shows the current lookup count alongside the fix, so you can see exactly how much headroom you have left. The tradeoff is that flattened records need to be updated whenever your email providers change their sending IPs, which happens periodically without announcement.

Mistake 3: Not Including All Your Sending Services

SPF only authorizes the services explicitly listed in your record. Every service that sends email as your domain — your inbox provider, your transactional email platform, your CRM, your marketing tool, your HR system — needs to be in your SPF record or its emails will fail authentication.

The symptom is partial: some emails pass SPF and some fail, which is harder to diagnose than a complete failure. DMARC reports (if you have DMARC configured with a rua= address) will show exactly which sources are failing — the unauthorized senders appear in the reports with spf=fail.

How to find your sending services:

Every service that has ever sent email from your domain appears in your DMARC aggregate reports. If you do not have DMARC configured yet, check your email provider's admin panel for a list of allowed senders, and audit each tool your company uses that sends any automated email: invoices, support tickets, password resets, marketing campaigns.

The standard include values for common providers:

Google Workspace:    include:_spf.google.com
Microsoft 365:       include:spf.protection.outlook.com
Zoho Mail (global):  include:zoho.com
Zoho Mail (EU):      include:zoho.eu
Zoho Mail (India):   include:zoho.in
Fastmail:            include:spf.messagingengine.com
Proton Mail:         include:_spf.protonmail.ch
Apple iCloud:        include:icloud.com
SendGrid:            include:sendgrid.net
Amazon SES:          include:amazonses.com
Mailchimp/Mandrill:  include:servers.mcsv.net
Postmark:            include:spf.mtasv.net

Verify your specific include value with your provider — some (Google Workspace, Microsoft 365, Zoho) show the exact expected SPF record in their admin panel.

How to test:

After adding a new include, send a test email from that service to a Gmail account you control. In Gmail, click the three-dot menu on the email → Show original. Look for the SPF result:

Received-SPF: pass (google.com: domain of noreply@yourdomain.com
              designates 167.89.123.45 as permitted sender)

pass means the sending service is in your SPF record. fail or softfail means it is not.

Mistake 4: Using Hard Fail (-all) Too Early

The ~all (soft fail) at the end of your SPF record flags unauthorized senders as suspicious but still delivers their email. The -all (hard fail) rejects unauthorized senders entirely — their emails are not delivered at all.

Hard fail is the correct long-term configuration. Moving to it before you have confirmed that every service sending email from your domain is listed in your SPF record causes those services' emails to be rejected. If you discover a missing service after switching to -all, every email from that service has already been bouncing.

How to test before switching:

dig yourdomain.com TXT +short | grep spf

Check whether your record ends with ~all or -all. If you are at -all and experiencing email delivery issues from specific services, the first step is switching back to ~all immediately:

Find the SPF TXT record in your DNS provider
Edit it — change -all to ~all
Save — propagation takes 5–15 minutes
Use DMARC reports to identify all failing senders
Add missing services to the record
Verify each service passes SPF by checking email headers
Switch back to -all only when all services show spf=pass

The recommendation: Start with ~all. Run in soft-fail mode for at least two to four weeks while reviewing DMARC reports. Switch to -all only after you are confident the record is complete.

Never use +all. It authorizes every server in the world to send email as your domain and completely defeats the purpose of SPF.

Mistake 5: Not Waiting for Propagation Before Testing

DNS changes do not take effect instantly. Your DNS provider saves the record immediately, but cached versions of your old record persist at resolvers around the world until the TTL expires. If your SPF record's TTL is set to 3600 (one hour), changes may take up to an hour to reach all resolvers.

The symptom: you make a change, test immediately, and see the old result. You assume the change did not save. You make the change again. You now have a duplicate record (Mistake 1).

How to test propagation:

# Check what your specific nameserver is serving right now:
dig yourdomain.com TXT +short @ns1.yourdomain.com

# Check what Google's resolver sees (may still be cached):
dig yourdomain.com TXT +short @8.8.8.8

# Check what Cloudflare's resolver sees:
dig yourdomain.com TXT +short @1.1.1.1

If your nameserver shows the new record but @8.8.8.8 shows the old one, propagation is still in progress. Wait and test again.

Typical propagation times by provider:

DNS Provider	Typical propagation
Cloudflare	5–15 minutes
GoDaddy	15–30 minutes
Namecheap	15–30 minutes
AWS Route53	5–15 minutes
DigitalOcean	15–30 minutes
Hostinger	15–60 minutes

These are typical times — propagation can take longer if a resolver has cached your record with a high TTL. Check your current TTL:

dig yourdomain.com TXT

Look for the TTL value in the answer section (the number between the domain name and the record type). If it shows 3600, resolvers will cache the old record for up to an hour.

The Full SPF Verification Sequence

Run through this sequence in order after making any SPF change:

Step 1: Confirm only one SPF record exists

dig yourdomain.com TXT +short | grep -c "v=spf1"

Output must be 1. If it is 2 or higher, delete the duplicate before continuing.

Step 2: Check lookup count

Run your record through mxtoolbox.com/spf.aspx and confirm total lookup count is 10 or under.

Step 3: Confirm propagation to major resolvers

dig yourdomain.com TXT +short @8.8.8.8 | grep spf
dig yourdomain.com TXT +short @1.1.1.1 | grep spf

Both should return the same record.

Step 4: Send a test email and check headers

Send an email from your mail client (or from a service you just added to SPF) to a Gmail address you control. In Gmail, click the three-dot menu → Show original. Look for:

Received-SPF: pass

Authentication-Results: ... spf=pass

spf=pass — authorized, SPF configured correctly for this sender.
spf=softfail — sender is not in your SPF record, but you are using ~all.
spf=fail — sender is not in your SPF record and you are using -all.
spf=none — no SPF record found (propagation not complete, or record missing).
spf=permerror — the record exceeds the 10-lookup limit or has a syntax error.

Step 5: Check DMARC reports

If you have DMARC configured with a rua= address, check the reports after 24 hours. Every sender that appears with spf=fail in the aggregate reports is a service you are missing from your SPF record.

Quick Reference: SPF Include Values by Provider

Email Provider	Include value to add to SPF
Google Workspace	`include:_spf.google.com`
Microsoft 365 / Outlook	`include:spf.protection.outlook.com`
Zoho Mail (global)	`include:zoho.com`
Zoho Mail (EU datacenter)	`include:zoho.eu`
Zoho Mail (India datacenter)	`include:zoho.in`
Fastmail	`include:spf.messagingengine.com`
Proton Mail	`include:_spf.protonmail.ch`
Apple iCloud	`include:icloud.com`
SendGrid	`include:sendgrid.net`
Amazon SES	`include:amazonses.com`
Postmark	`include:spf.mtasv.net`

Assemble your record by combining the relevant values:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

One record. All services listed. Under 10 total lookups. Ending in ~all to start, -all after verification.

Provider-Specific Notes

Cloudflare: Never set the proxy toggle (orange cloud) on TXT records. SPF records must always be DNS only (grey cloud). The orange cloud is only for A and AAAA records that you want proxied through Cloudflare's CDN.

AWS Route53: TXT record values must be wrapped in double quotes in the Value field. Enter "v=spf1 include:_spf.google.com ~all" with the quotes — Route53 requires them. Other providers do not.

GoDaddy: The Host field for root domain records should be @. GoDaddy adds your domain name automatically — do not type the full domain name in the Host field or the record will be created at yourdomain.com.yourdomain.com.

DigitalOcean: Does not have an inline edit button for DNS records. To update an SPF record, delete the existing one and create a new one with the updated value. Do not create a second record before deleting the first.

Namecheap: Uses a green checkmark button (not a Save button) to confirm record changes. Clicking away without clicking the checkmark discards the change without warning.

TL;DR

Only one SPF record is allowed per domain — creating a second one instead of editing the existing one instantly breaks all email delivery. Check with dig yourdomain.com TXT +short | grep -c "v=spf1" — the answer must be 1
The 10-lookup limit is recursive and invisible — use an online SPF checker to count total lookups including nested includes before assuming your record is under the limit
Start with ~all (soft fail), not -all (hard fail) — switch to hard fail only after DMARC reports confirm every sending service passes SPF
Wait for propagation before testing — changes take 5–60 minutes to reach external resolvers depending on your provider; check with dig @8.8.8.8 to see what Google's resolver sees
spf=pass in Gmail's Show Original is the ground truth — that is the only check that confirms SPF is working end to end for a specific sending service
DMARC reports show every sender failing SPF — if you have rua= configured, the aggregate reports identify every unauthorized sender and every legitimate sender that is missing from your record
Run the full audit on your domain — ZeroHook checks SPF syntax, lookup count, duplicate records, and missing senders in one pass, with provider-specific fix steps included: zerohook.org

*Part of an ongoing series on email deliverability and DNS security.

The Anatomy of a 30-Point Security Audit (And Why Every Domain Needs One)

Regő Botond Ronyecz — Sat, 30 May 2026 01:34:06 +0000

Most domains have between six and ten security misconfigurations that their owners do not know about.

Not because the owners are careless. Because DNS is a layered system built over four decades, where each layer adds its own records, requirements, and failure modes — and where a misconfiguration in one layer often has no visible symptom until an attacker finds it first.

An open DNS resolver. A dangling CNAME pointing to a deleted Heroku app. An SMTP server that answers user enumeration queries. A DNSSEC chain with an expired signature. None of these appear in uptime monitors. None of them trigger alerts. All of them are exploitable.

A structured security audit checks every layer systematically. This post walks through all 30 checks — what each one tests, what a failure means in practice, and why the check exists.

How the Audit Is Organized

The 30 checks fall into five categories, each targeting a different attack surface on the same domain.

Category	Checks	What it covers
Email Security	8	Authentication, deliverability, blacklist status
DNS Security	10	Record integrity, configuration, cryptography
Infrastructure Security	6	Server exposure, zone data, redundancy
Compliance Mapping	4	NIS2, GDPR, ISO 27001, PCI-DSS
Additional Checks	2	Certificate and domain expiry

Every check produces one of three outputs: pass, fail with severity rating, or warning. Every fail produces a fix guide. The aggregate result is an Email Health Score from 0 to 100.

Category 1: Email Security (8 Checks)

These eight checks cover everything that determines whether your outgoing email reaches the inbox — and whether your domain can be spoofed to send email you never sent.

Check 1: SPF Record Validation

What it tests: Whether a TXT record starting with v=spf1 exists at your root domain, whether it is syntactically valid, and whether it lists all your authorized sending services without exceeding the 10 DNS lookup limit.

What failure looks like: No SPF record means any server on the internet can send email claiming to be from your domain, and receiving servers have no mechanism to verify it is fake. A broken SPF record — syntactically invalid or over the 10-lookup limit — produces an SPF PermError, which many receiving servers treat the same as a hard fail.

The two-record failure is particularly common: a company adds a second SPF TXT record instead of editing the existing one. Having two v=spf1 records on the same domain immediately invalidates both. Every email you send fails SPF. The symptom — emails landing in spam — appears days later and is hard to trace back to the DNS change.

Why it matters: SPF is the first authentication layer that inbox providers check. Without it, your domain has no control over who can send email in your name.

Check 2: DKIM Signing Verification

What it tests: Whether DKIM TXT records exist for your active email selectors, whether the keys are present (not revoked with p=), and whether the key length is 2048 bits or higher.

What failure looks like: Missing DKIM means every email you send goes unsigned. Receiving servers cannot verify the email came from you — it is treated as unauthenticated. Weak 1024-bit keys can be computationally cracked, allowing an attacker to forge valid DKIM signatures for your domain. Revoked keys (p= with no value) indicate a service that has been removed from your stack but whose DNS records were never cleaned up.

Why it matters: DKIM is the cryptographic proof that an email bearing your domain name was actually sent by you and was not modified in transit. Gmail and Outlook increasingly deprioritize unsigned email from domains where DKIM is expected.

Check 3: DMARC Policy Enforcement

What it tests: Whether a DMARC record exists at _dmarc.yourdomain.com, whether the p= policy is set to quarantine or reject, and whether a rua= reporting address is configured.

What failure looks like: No DMARC record means SPF and DKIM results are never coordinated — a receiving server that sees SPF pass and DKIM fail has no policy to apply. p=none means the policy exists but takes no action: spoofed emails still reach recipients' inboxes. No rua= address means you receive no reports and have no visibility into authentication failures or unauthorized senders using your domain.

Why it matters: DMARC ties SPF and DKIM together and gives the receiving server an explicit instruction for what to do when authentication fails. It is the only control that actively blocks email domain spoofing. NIS2 and SOC2 CC6.6 both require enforcement (p=quarantine or p=reject) — p=none satisfies neither.

Check 4: BIMI Logo and VMC Validation

What it tests: Whether a BIMI TXT record exists at default._bimi.yourdomain.com, whether the logo URL in the record is reachable over HTTPS, and whether the SVG file passes BIMI format requirements (SVG Tiny 1.2). If a VMC certificate URL is present in the a= field, that is validated separately.

What failure looks like: A BIMI record pointing to an unreachable logo URL silently fails — no logo appears in the inbox and no error is reported. A standard SVG file that has not been converted to SVG Tiny 1.2 fails validation at the mail client level. A BIMI record without p=quarantine or p=reject DMARC has no effect regardless of the logo configuration.

Why it matters: BIMI is the only control that makes your brand visually identifiable in the inbox before the email is opened. Its prerequisites — enforced DMARC and a compliant SVG — are checked as part of this audit step.

Check 5: MTA-STS Configuration

What it tests: Whether an _mta-sts TXT record exists at your domain, whether the policy file is reachable at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt, and whether the policy specifies mode: enforce (not mode: testing).

What failure looks like: No MTA-STS means inbound email delivery to your domain has no transport security enforcement — a network attacker on the path between a remote mail server and yours can strip TLS and transmit the email in plaintext. mode: testing collects data but does not prevent this. A policy file served over HTTP (not HTTPS) is ignored by the spec.

Why it matters: MTA-STS is the email equivalent of HTTPS enforcement — it prevents downgrade attacks on your inbound email transport. ISO 27001:2022 Annex A.5.14 and NIS2 Article 21.2j both reference transport encryption for email communications.

Check 6: TLS-RPT Monitoring Setup

What it tests: Whether a _smtp._tls TXT record exists at your domain with a rua= reporting address.

What failure looks like: No TLS-RPT means you receive no reports when other mail servers fail to establish TLS connections when delivering to your domain. TLS negotiation failures are silent — email may be delayed or dropped and you have no visibility into why.

Why it matters: TLS-RPT is the monitoring companion to MTA-STS. MTA-STS enforces transport security; TLS-RPT tells you when enforcement is causing delivery failures or when TLS negotiation is being blocked. Without it, MTA-STS enforcement is a one-way door — you cannot see whether it is working correctly.

Check 7: DMARC Reporting (RUA) Validation

What it tests: Whether the DMARC record includes a rua=mailto: address that is reachable — specifically whether the receiving domain at the rua= address has published a DMARC external reporting authorization record if it differs from the sending domain.

What failure looks like: A rua= address that points to a domain you no longer control stops receiving reports silently. A third-party reporting address (e.g., a DMARC analysis service) that has not published the external reporting authorization record causes report delivery to fail — you configure reporting, assume it is working, and receive nothing.

Why it matters: DMARC reports are the primary mechanism for discovering unauthorized senders using your domain and for verifying that your authentication is working correctly. The reporting check confirms reports are actually being delivered, not just configured.

Check 8: Blacklist Monitoring (50+ Databases)

What it tests: Whether your sending IP address or domain is listed on any of 50+ DNS-based blacklists, including Spamhaus ZEN (SBL, XBL, PBL), Barracuda BRBL, SpamCop, SORBS, and Microsoft SNDS.

What failure looks like: A Spamhaus ZEN listing blocks delivery to approximately 3 billion mailboxes. Most blacklist listings produce no bounce notice to the sender — email is silently rejected or dropped. The sender's dashboard shows emails as delivered. Recipients never see them.

Why it matters: Blacklist placement is one of the fastest-moving and highest-impact email deliverability events. A single compromised account or a sending volume spike can trigger a listing within hours. The only way to know your status is to check continuously — a clean result from a manual check last month says nothing about your status today.

Category 2: DNS Security (10 Checks)

These ten checks audit the integrity, configuration, and cryptographic security of your DNS zone — the infrastructure that everything else depends on.

Check 9: DNSSEC Validation

What it tests: Whether DNSSEC signing is active on your zone (DNSKEY records present), whether a DS record exists in the parent zone establishing the chain of trust, and whether signatures are valid and not expired.

What failure looks like: No DNSSEC means DNS responses for your domain carry no cryptographic proof of authenticity — cache poisoning attacks can substitute forged responses and resolvers have no way to detect the substitution. An expired DNSSEC signature causes validating resolvers to return SERVFAIL for your domain, which is indistinguishable from a DNS outage for roughly 30% of users (those whose resolvers validate DNSSEC).

Why it matters: DNSSEC is the only DNS-layer defense against cache poisoning and DNS hijacking via forged responses. NIS2 Article 21.2g and ISO 27001:2022 Annex A.8.20 both reference cryptographic controls for DNS.

Check 10: CAA Records

What it tests: Whether Certificate Authority Authorization records exist at your domain specifying which CAs are permitted to issue TLS certificates.

What failure looks like: No CAA records mean any of the hundreds of publicly trusted certificate authorities in the world can issue a certificate for your domain — including in response to a social engineering attack or a rogue CA. The audit detects your current CA from your existing SSL certificate and flags if CAA records are missing or if the authorized CA does not match your actual certificate issuer.

Why it matters: CAA records are a pre-issuance control on certificate fraud. They do not prevent an attacker from attempting to obtain a fraudulent certificate, but they prevent a non-authorized CA from issuing one.

Check 11: Nameserver Configuration and Redundancy

What it tests: Whether your domain has at least two nameservers, whether they are reachable and responding correctly, and whether they return consistent answers (zone consistency between primary and secondary).

What failure looks like: A single nameserver is a single point of failure — one server going offline takes your domain completely offline. Inconsistent zones between nameservers (zone transfer lag or misconfiguration) can cause different users to receive different DNS answers for the same query.

Why it matters: DNS availability is the prerequisite for every other internet service. Email delivery, website availability, and API connectivity all depend on DNS resolving correctly.

Check 12: CNAME Chain Analysis

What it tests: Whether any CNAME records on your domain create excessively long chains (standard limit is 8 hops) or create circular references that would cause resolution to fail.

What failure looks like: CNAME chains longer than 8 hops are truncated by some resolvers, causing the final record to fail to resolve. Circular CNAMEs — where A points to B and B points to A — cause resolution to loop until timeout.

Why it matters: Long or broken CNAME chains produce intermittent resolution failures that are difficult to diagnose and appear as random downtime to users.

Check 13: SOA Parameters Validation

What it tests: Whether the Start of Authority record's timing parameters (REFRESH, RETRY, EXPIRE, MINIMUM TTL) are within RFC-recommended ranges.

What failure looks like: An EXPIRE value that is too short causes secondary nameservers to stop serving the zone if they cannot reach the primary — a primary nameserver outage triggers a full zone outage much sooner than necessary. A MINIMUM TTL that is too low causes excessive negative caching traffic. Values that deviate significantly from RFC recommendations often indicate a zone that has never been audited.

Why it matters: SOA parameters control zone reliability and propagation behavior. Incorrect values create fragility that only surfaces under failure conditions.

Check 14: TTL Optimization Analysis

What it tests: Whether TTL values on your DNS records are set appropriately — not so low that they cause excessive query load, not so high that DNS changes take days to propagate.

What failure looks like: TTL values under 60 seconds on stable records create unnecessary query volume without meaningful benefit. TTL values of 86400 (24 hours) on records that might need to change during an incident mean that DNS changes take a full day to reach all resolvers — a significant problem during a migration or a security incident.

Why it matters: TTL is a reliability lever. Appropriate TTL values give you fast propagation when you need it and low query load when you do not.

Check 15: PTR / Reverse DNS Check

What it tests: Whether your mail server's IP address has a PTR (Pointer) record that resolves to a hostname matching your domain, and whether that hostname forward-resolves back to the same IP.

What failure looks like: A missing PTR record is one of the most common reasons email is filtered as spam by Gmail, Outlook, and Yahoo. These providers perform a PTR lookup on the sending IP and compare the result to the HELO hostname. A mismatch or a missing record is a strong spam signal. A PTR record that resolves to a generic hostname like ip-192-0-2-1.ec2.internal instead of a mail hostname is nearly as bad.

Why it matters: PTR validation is one of the first checks major inbox providers perform on inbound email. It is configurable at your hosting provider (AWS EC2, DigitalOcean, Hetzner, etc.) and is frequently overlooked on new mail server setups.

Check 16: Open Resolver Detection

What it tests: Whether your nameserver answers recursive DNS queries from arbitrary external IP addresses.

What failure looks like: An open resolver will appear in public databases used by DDoS attack operators within days of being discovered. Attackers send small forged DNS queries to your server with a victim's IP as the source address. Your server sends large responses to the victim, multiplying the attacker's bandwidth by 30–70×. Your server's IP may be blacklisted by upstream providers as a result.

Why it matters: An open resolver turns your DNS infrastructure into an amplification tool for attacks on others — and an operational liability for you.

Check 17: DNS Performance Benchmarking

What it tests: Response time from your nameservers measured from multiple geographic locations, and whether any nameserver is returning DNS timeouts rather than responses.

What failure looks like: Response times above 200ms from major geographic regions indicate a DNS provider with poor coverage or a nameserver that is geographically distant from that region's users. Timeouts are more serious — a nameserver returning timeouts means some resolvers cannot reach it at all, causing resolution failures for a subset of users.

Why it matters: DNS response time is the first component of every web request, email delivery check, and API call. High DNS latency adds directly to page load time and service availability perception.

Check 18: DANE / TLSA Records

What it tests: Whether TLSA records exist for your mail server, pinning the TLS certificate or public key that connecting servers should expect.

What failure looks like: No TLSA records mean email transport TLS has no certificate pinning — a compromised CA can issue a fraudulent certificate for your mail server and a man-in-the-middle attacker could use it to intercept email in transit, with no mechanism for the sending server to detect the substitution.

Why it matters: DANE (DNS-Based Authentication of Named Entities) is the mail server equivalent of certificate pinning. It requires DNSSEC to be active — DNSSEC signs the TLSA records, making them tamper-evident. Without DNSSEC, DANE is not implementable.

Category 3: Infrastructure Security (6 Checks)

These six checks look at your server exposure and zone data — the attack surface that exists below the DNS record layer.

Check 19: Subdomain Takeover Detection

What it tests: Whether any CNAME records on your domain point to external resources (Heroku apps, S3 buckets, GitHub Pages, Azure web apps, Netlify sites, etc.) that no longer exist and are therefore claimable by anyone.

What failure looks like: A CNAME pointing to yourapp-staging.herokuapp.com where that Heroku app has been deleted means anyone can create a new Heroku app with that name and immediately receive all HTTP traffic sent to that subdomain — including session cookies scoped to your root domain. The attacker serves content from a URL that reads staging.yourdomain.com with a valid SSL certificate and no browser warnings. Azure, S3, GitHub Pages, Fastly, Shopify, and many other platforms have the same vulnerability pattern.

Why it matters: Subdomain takeover is one of the most exploitable vulnerabilities in the category because it requires no access to your systems — only access to the third-party platform, which is open to anyone. The fix is deletion of the dangling CNAME record.

Check 20: Zone Transfer Vulnerability Test

What it tests: Whether your nameservers respond to DNS zone transfer requests (AXFR queries) from arbitrary IP addresses.

What failure looks like: A successful zone transfer dumps your entire DNS zone — every record, every hostname, every subdomain, every internal service — to anyone who asks. This is reconnaissance of your entire infrastructure handed to an attacker in one query. Properly configured nameservers restrict zone transfers to authorized secondary nameservers only.

# Test if your nameserver allows unrestricted zone transfers
dig axfr yourdomain.com @ns1.yourdomain.com

A response with actual zone data is a critical failure. A response of Transfer failed or REFUSED is the correct behavior.

Why it matters: Zone transfer exposure is a configuration error that has no legitimate use case for external access. It provides complete infrastructure reconnaissance to anyone who checks.

Check 21: DNS Flood Protection Evaluation

What it tests: Whether your DNS infrastructure has Response Rate Limiting (RRL) configured, or whether it is protected by a managed provider's Anycast network that absorbs flood attacks at the network level.

What failure looks like: An unprotected nameserver with no RRL can be used as an amplification device in DDoS attacks — attackers send small queries and your server sends large responses to a victim's IP. Separately, NXDomain flood attacks (DNS Water Torture) send queries for random subdomains of your domain, exhausting your nameserver's resources.

Why it matters: Managed DNS providers (Cloudflare, Route53, Google Cloud DNS) handle this automatically through their Anycast infrastructure. Self-hosted nameservers require explicit RRL configuration in BIND, Unbound, or NSD.

Check 22: Geographic Redundancy Analysis

What it tests: Whether your nameservers are distributed across geographically and network-diverse locations, or whether they are concentrated in a single region or autonomous system.

What failure looks like: Two nameservers in the same data center, on the same AS, or with the same upstream provider are not meaningfully redundant — a regional outage or a BGP routing incident that affects that provider takes both offline simultaneously. Fewer than three distinct networks detected across all nameservers is a warning indicator.

Why it matters: Geographic redundancy determines whether your domain remains reachable during regional internet incidents. NIS2 Article 21.2c (business continuity) requires resilient infrastructure for this reason.

Check 23: MX Record Validation

What it tests: Whether your MX records are syntactically correct, whether the hostnames in MX records resolve to valid IP addresses, and whether multiple MX records exist with different priority values for failover.

What failure looks like: An MX record pointing to a hostname that does not resolve means email delivery to your domain fails for all senders whose MX resolution hits that record. A single MX record with no backup means your entire inbound email delivery depends on one server.

Why it matters: MX misconfiguration is one of the most direct paths to complete email delivery failure. It is also one of the easiest checks to overlook after a mail server migration.

Check 24: SMTP VRFY/EXPN Exposure Check

What it tests: Whether your mail server responds to SMTP VRFY commands from arbitrary external connections — queries that ask whether a specific email address exists at your domain.

What failure looks like: A mail server that responds to VRFY with 250 User exists or 252 Cannot VRFY user (confirming the query was processed) allows attackers to enumerate valid email addresses at your domain. A list of valid email addresses is a prerequisite for targeted phishing and spear phishing campaigns. The audit connects to your actual mail server (identified from your MX records) and probes VRFY directly — it reports the actual response received, not a theoretical vulnerability.

Why it matters: User enumeration through SMTP VRFY is a reconnaissance step that precedes targeted phishing attacks. Disabling VRFY has no impact on legitimate email delivery — the command is used only by diagnostic tools and attackers.

Category 4: Compliance Mapping (4 Frameworks)

The compliance checks do not add new technical tests — they map the results of the preceding 24 checks against the specific control requirements of four frameworks, identify which controls are missing or insufficient for each framework, and produce a compliance gap analysis with a score per framework.

NIS2 (EU Directive 2022/2555): Maps against Article 21.2c (business continuity → nameserver redundancy), 21.2d (supply chain → SPF, DKIM, DMARC enforcement), 21.2g (cryptography → DNSSEC, MTA-STS), and 21.2j (secure communications → TLS-RPT).

GDPR (EU 2016/679): Maps against data transmission security requirements — specifically MTA-STS enforcement, DMARC p=reject, and DNSSEC as controls over data-in-transit protection.

ISO/IEC 27001:2022: Maps against Annex A.5.14 (information transfer — DMARC, MTA-STS, SPF, DKIM), A.8.16 (monitoring activities — DMARC RUA, TLS-RPT), A.8.20 (network security — DNSSEC, CAA, nameserver redundancy), and A.8.12 (data leakage prevention — DMARC p=reject).

PCI-DSS v4.0: Maps against email security controls relevant to cardholder data environments — authentication requirements and transport encryption standards.

Category 5: Additional Checks (2 Checks)

Check 29: SSL Certificate Expiry Monitoring

What it tests: Whether your domain's SSL certificate is valid, which CA issued it, and how many days remain before expiry.

What failure looks like: An expired SSL certificate causes browsers to display a full-page trust error that blocks users from accessing your site. Automated certificate renewal (Let's Encrypt via Certbot, or managed renewal through your hosting provider) can fail silently for months before the certificate actually expires — the renewal process runs, encounters an error, and logs it somewhere that nobody checks. The audit catches expirations before they happen.

Check 30: Domain Expiry Tracking and Alerts

What it tests: Your domain's registration expiry date and registrar.

What failure looks like: An expired domain is immediately deactivated — website down, email stopped, all DNS records stop resolving. Most registrars send renewal notices to the WHOIS contact email, which is often an old address that nobody monitors. After expiry, a 30-day redemption period typically allows recovery at a significant fee. After redemption, the domain enters public availability and can be registered by anyone — including a competitor or attacker who then controls the entire namespace of your brand.

Why it matters: Domain expiry is a catastrophic, recoverable but humiliating failure mode. It is also completely preventable with auto-renew and monitoring.

What the Score Means

Every domain that runs the full audit receives an Email Health Score from 0 to 100. The score is weighted by severity:

Critical failures (open zone transfer, subdomain takeover, no DMARC, blacklist listing) carry the most weight
Configuration gaps (missing CAA, suboptimal TTLs, no TLS-RPT) carry moderate weight
Optimization opportunities (BIMI not configured, DANE not implemented) carry the least weight

A score above 85 indicates a domain with no critical failures and most recommended controls in place. A score below 60 almost always includes at least one critical failure that represents an active, exploitable vulnerability.

Most domains score between 40 and 65 on first audit. The common pattern: email authentication is partially configured (SPF present, DKIM present, DMARC at p=none), DNS security is minimal (no DNSSEC, no CAA), and infrastructure checks reveal at least one unexpected exposure.

The audit does not stop at the score. Every failed check produces a fix guide with the exact corrective action — provider-specific steps for DNS changes, server configuration changes for SMTP VRFY and open resolver checks, and compliance documentation guidance for the framework mapping checks.

You can run the audit on any domain — your own, a competitor's, a prospective acquisition target — at zerohook.org. The free tier includes SPF, DKIM, DMARC, blacklist monitoring, and an Email Health Score. The full 30-point audit is on paid plans starting at $49/month.

TL;DR

30 checks across 5 categories: email security (8), DNS security (10), infrastructure security (6), compliance mapping (4), and expiry monitoring (2)
The highest-severity findings are subdomain takeover (exploitable immediately with no access to your systems), open zone transfer (complete infrastructure reconnaissance), blacklist listing (silent email delivery failure), and DMARC p=none (no enforcement against domain spoofing)
SMTP VRFY exposure is underestimated — a mail server that confirms whether email addresses exist hands attackers a validated list of targets for phishing campaigns
Compliance mapping is a byproduct, not a separate effort — the technical checks feed directly into NIS2, ISO 27001, GDPR, and PCI-DSS gap analysis
Most domains score 40–65 on first audit — partially configured email authentication and minimal DNS security with at least one unexpected infrastructure exposure is the most common pattern
Every failed check produces a fix guide — the audit does not stop at finding problems; it produces the specific corrective action for each one

*Part of an ongoing series on DNS security and email deliverability.

What's a 1% Email Deliverability Improvement Worth to Your Business?

Regő Botond Ronyecz — Sat, 30 May 2026 01:28:21 +0000

The average inbox placement rate across all senders is 83.1%. That means roughly one in six emails never reaches the inbox — delivered by the mail server's definition, invisible by any practical one.

If you are sending 50,000 emails a month with an 83% inbox placement rate, about 8,500 of those emails are going directly to spam or being silently discarded. They were sent. They were not received. You have no idea which ones.

Most businesses treat deliverability as a binary: either emails are arriving or they are not. The more useful framing is economic. Inbox placement is a revenue lever that most teams are leaving in its default position. Moving it by 1% is worth a calculable, specific number of dollars — and for most businesses sending transactional or lifecycle email, that number is larger than the cost of every tool needed to fix it combined.

This post walks through the calculation in concrete terms, shows what inbox placement actually costs across different business models, and identifies the specific DNS and authentication configurations that drive the gap between 83% and 95%+.

The Baseline: What "Delivered" Actually Means

There is a critical distinction in email metrics that most dashboards blur: delivery rate and deliverability rate are not the same number.

Delivery rate measures whether the receiving mail server accepted the message. A 99% delivery rate means 99% of your emails were not bounced. It says nothing about where they went after acceptance.

Deliverability rate (or inbox placement rate) measures whether the accepted message reached the inbox — not the spam folder, not the promotions tab, the inbox.

Your ESP's dashboard shows delivery rate. What actually drives revenue is deliverability rate.

The gap between them is the spam folder. An email that lands in spam was "delivered" by every metric your dashboard tracks. It generated zero opens, zero clicks, and zero revenue. It is indistinguishable, in your reporting, from an email that reached the primary inbox and was simply not opened.

This is why inbox placement problems are so persistent: the data you see doesn't show them.

The Math: Calculating Your Deliverability Revenue Gap

The calculation has four inputs:

Monthly email volume — how many emails you send per month
Current inbox placement rate — what percentage actually reach the inbox (not your delivery rate — your inbox placement rate, which requires seed testing to measure)
Revenue per email sent — total email-attributed revenue divided by emails sent
Target inbox placement rate — realistically 95%+ with proper authentication in place

The formula:

Revenue gap = Monthly volume × (Target rate − Current rate) × Revenue per email

Let's run it for three different business models.

E-commerce: 100,000 emails/month

An online retailer sending 100,000 emails per month — marketing campaigns, abandoned cart sequences, order confirmations, post-purchase flows — at a revenue per email of $0.25 (a conservative figure; many optimized e-commerce programs run $0.40–$0.80).

Scenario	Inbox placement	Monthly revenue
Current (industry average)	83%	$20,750
Target (properly authenticated)	95%	$23,750
Difference	+12 percentage points	+$3,000/month

That is $36,000 per year from closing the inbox placement gap — on a conservative revenue-per-email figure, before any change to subject lines, send times, or creative.

If the retailer is closer to the industry average inbox placement of 83% and their revenue per email is higher — which is typical for businesses with mature lifecycle sequences — the annual gap is larger.

SaaS: Transactional email at 500,000 emails/month

A SaaS company sending 500,000 transactional emails per month — trial onboarding sequences, feature announcements, expiry warnings, payment failure notices. Revenue per email is harder to calculate directly, but the downstream cost of spam placement on transactional email is concrete: a payment failure notice that lands in spam means a churned customer. An onboarding email that goes unread means a user who does not activate.

Transactional emails have 8x higher opens and clicks compared to regular marketing emails. They are also the emails where deliverability failure has the most direct business consequence — a missed invoice or a password reset that never arrives is a support ticket and a frustrated customer.

At this volume, a 1% inbox placement improvement means 5,000 more transactional emails reaching their recipients every month. For a SaaS with a $500 annual contract value and even a 0.1% conversion rate on those recovered emails, that is 5 additional conversions per month — $2,500/month, $30,000/year.

Agency / MSP: Client email reputation management

An agency managing email infrastructure for 20 clients, each sending 10,000 emails per month at an average revenue per email of $0.15. Current average inbox placement across the client portfolio: 80%.

If the agency brings every client from 80% to 95% inbox placement:

20 clients × 10,000 emails × $0.15 × 0.15 improvement = $4,500/month in recovered revenue

That is $4,500 per month in additional revenue attribution across the portfolio — generated by DNS and authentication fixes, not by a single additional piece of content.

What Is Holding Inbox Placement Below 95%

Only approximately 33.4% of top 1M domains publish valid DMARC, and roughly 85.7% don't enforce it. That is the core of the inbox placement problem for most businesses: the authentication signals that inbox providers use to evaluate sender reputation are either missing or misconfigured on the majority of domains.

Gmail and Yahoo introduced mandatory authentication requirements for bulk senders in early 2024: SPF, DKIM, and DMARC are now required for anyone sending to these providers at scale. Senders who do not meet these requirements see increased spam folder placement, regardless of list quality or content.

The specific configurations that drive inbox placement below 95%:

Missing or broken SPF

SPF lists the mail servers authorized to send email from your domain. When a receiving server checks SPF and the sending IP is not on the list, the email fails authentication — and failed authentication is one of the strongest spam signals an inbox provider uses.

The most common SPF failure mode is not a missing record — it is an incomplete one. A company adds SendGrid to their SPF record when they sign up for transactional email, then adds Google Workspace, then Salesforce, and never updates the SPF record. The Salesforce emails fail SPF. They land in spam. The DMARC report shows it but nobody reads the DMARC report.

# Check your current SPF record
dig yourdomain.com TXT +short | grep spf

DKIM not configured for all sending services

DKIM adds a cryptographic signature to every outgoing email. Receiving servers verify the signature against a public key in your DNS. Unsigned email from your domain — email sent by a service you use that does not have DKIM configured — is treated with significantly more suspicion than signed email.

The problem mirrors the SPF issue: DKIM is configured for the primary email provider and missing for secondary senders. Marketing platforms, CRM tools, HR systems, invoicing software — any of these that send email as your domain without DKIM configured contribute to failed authentication across a portion of your sends.

DMARC at p=none — monitoring without enforcement

DMARC ties SPF and DKIM together and tells receiving servers what to do when authentication fails. The policy options are p=none (do nothing), p=quarantine (send to spam), and p=reject (block entirely).

p=none is the configuration most organizations land on and never leave. It generates reports about authentication failures. It takes no action on them. From an inbox provider's perspective, p=none signals a domain that is aware of its authentication status but has chosen not to enforce it.

Since early 2024, Gmail and Yahoo require SPF, DKIM, and DMARC for any sender delivering at bulk volume. But the requirement is for the records to exist — not for the policy to be enforced. p=none satisfies the existence requirement while doing nothing to improve inbox placement. Moving to p=quarantine and eventually p=reject is what drives the authentication signal that inbox providers reward.

Blacklist placement

A sending IP or domain on a major blacklist sees immediate, severe inbox placement degradation. Spamhaus ZEN covers approximately 3 billion mailboxes. A listing there means a large portion of your emails are being rejected at the server level — they never even reach the spam folder.

Blacklist placement happens for reasons unrelated to your content: a compromised account sending spam, a spike in sending volume that looks automated, or a shared IP on an ESP where a neighboring sender triggered a listing. The only way to know your current blacklist status is to check — and the only way to know when status changes is continuous monitoring.

# Check Spamhaus combined zone (SBL + XBL + PBL)
# Reverse your sending IP octets first (e.g. 192.0.2.1 → 1.2.0.192)
dig 1.2.0.192.zen.spamhaus.org A
# NXDOMAIN = clean. Any other response = listed.

The Fix: What Moves Inbox Placement From 83% to 95%+

The inbox placement gap between the industry average and a properly configured sender is almost entirely explained by four authentication controls. None of them require changes to email content, subject lines, sending frequency, or list composition.

1. Complete SPF record — all sending services listed, under 10 DNS lookups, one record per domain (two records breaks SPF for everyone).

2. DKIM for every sender — all services that send email as your domain have a DKIM key configured, minimum 2048-bit key strength. Keys older than 12 months should be rotated.

3. DMARC policy enforcement — move from p=none to p=quarantine. Read the DMARC RUA reports for two to four weeks. When the reports show clean authentication across your legitimate senders, advance to p=reject. This is the single highest-impact change for inbox placement, and it is a DNS record update.

4. Active blacklist monitoring — know your blacklist status before your recipients tell you about it. The window between listing and your team noticing it manually is typically days. Automated monitoring closes that gap to minutes.

These four changes are not creative work. They are configuration. They require DNS access and about two hours to implement correctly. The revenue recovery they enable is proportional to your email volume — for most businesses, that means the tool cost pays for itself inside the first month.

The Revenue Per Email Calculation for Your Business

If you have not calculated your revenue per email, here is the straightforward version:

Revenue per email = (Email-attributed revenue per month) ÷ (Emails sent per month)

Email-attributed revenue is the revenue from purchases that occurred within the attribution window after an email click or open — your ESP should report this directly.

If you do not have this number, use these industry benchmarks as a starting point:

Business type	Revenue per email sent (conservative)
E-commerce (promotional)	$0.10–$0.40
E-commerce (transactional / cart recovery)	$0.40–$1.50
SaaS (lifecycle / onboarding)	$0.05–$0.20
SaaS (payment failure / renewal)	$0.50–$2.00
Financial services	$0.20–$0.80
B2B (lead nurture)	$0.30–$1.50

Now apply the deliverability gap:

Annual revenue gap = Monthly volume × (0.95 − Current placement rate) × Revenue per email × 12

If your current inbox placement rate is 83% and your target is 95%, that is a 12-percentage-point gap. On 50,000 emails per month at $0.25 revenue per email:

50,000 × 0.12 × $0.25 × 12 = $18,000/year

That is the revenue sitting between your current inbox placement rate and where it should be — recoverable through authentication fixes, not through more content or bigger lists.

ZeroHook's Email ROI Calculator runs this calculation for your own numbers without requiring an account — enter your volume, current open rate, and average order value to see your specific gap estimate.

TL;DR

The average inbox placement rate is 83.1% — meaning roughly 1 in 6 emails never reaches the inbox. Your ESP's delivery rate does not show this
A 1% deliverability improvement is worth $3,000–$36,000+ per year depending on email volume and revenue per email — the range is wide but the floor is significant for any business sending at moderate volume
The gap between 83% and 95%+ inbox placement is almost entirely explained by four authentication controls: complete SPF, DKIM for all senders, DMARC at p=quarantine or p=reject, and active blacklist monitoring
None of these require content changes — they are DNS configuration fixes that take two hours to implement correctly
p=none is the configuration most organizations never leave — it satisfies the existence requirement but takes no action on authentication failures. Moving to p=quarantine is the single highest-impact change for inbox placement
Calculate your own number: monthly email volume × (0.95 − current placement rate) × revenue per email × 12 = annual revenue gap from the inbox placement shortfall

*Part of an ongoing series on email deliverability and DNS security.

ISO 27001 Annex A and Email Security: A Simple Gap Analysis Guide

Regő Botond Ronyecz — Sat, 30 May 2026 01:23:28 +0000

Your ISMS is certified. Your Statement of Applicability covers the controls. Your auditor arrives and runs a DNS lookup on your domain.

dig _dmarc.yourdomain.com TXT +short

The output shows p=none. The auditor makes a note.

This is not a hypothetical. DMARC policy enforcement has become a standard ISMS audit check since ISO 27001:2022 made Annex A.5.14 — Information Transfer an explicit Annex A control for the first time. If your organization was certified against ISO 27001:2013 and has not reviewed email security controls since the transition to the 2022 standard, there is a material gap in your Statement of Applicability — whether or not the auditor has found it yet.

This guide maps every email and DNS security control to the specific Annex A clauses they satisfy, explains what auditors check and what they accept as evidence, and identifies the three findings that appear most frequently in ISMS email security reviews.

Why 2022 Changed the Picture

ISO 27001:2013 did not include an explicit Annex A control for information transfer security in email. Organizations could and did satisfy information security requirements through general controls on network security and communications without formally addressing SPF, DKIM, DMARC, or MTA-STS in their SoA.

ISO 27001:2022 introduced Annex A.5.14 — Information Transfer as a new, named control. It explicitly requires "rules, procedures and agreements" for information transfer across all channels — including email. MTA-STS and DMARC serve as automated technical enforcement of these rules. The 2022 revision also reorganized and renumbered controls; several email-adjacent controls moved between clauses.

The transition deadline for existing certifications was October 31, 2025. Certifications that have not transitioned to ISO 27001:2022 are no longer valid. If your ISMS was certified under the 2013 standard, the audit against the 2022 standard requires you to explicitly add email security controls to your SoA — they cannot be treated as implicitly covered by older, broader controls.

The Annex A Controls That Cover Email and DNS Security

Four Annex A controls in ISO 27001:2022 map directly to email and DNS security. Each one has a specific scope, a specific technical implementation, and a specific evidence requirement.

Annex A.5.14 — Information Transfer

Scope: Rules, procedures, and agreements ensuring that information transferred via all channels — including email — is protected appropriately.

What it requires for email: Documented policies for email security, backed by technical enforcement controls that automatically apply those policies. The 2022 guidance explicitly notes that automated enforcement (rather than user-dependent procedures) is preferred.

Technical controls that satisfy A.5.14:

DMARC at p=quarantine or p=reject is the primary control. It enforces your email authentication policy automatically — emails that fail SPF and DKIM authentication are either quarantined or rejected, depending on your policy level. The key word is enforces. p=none collects data but enforces nothing. It does not satisfy A.5.14 as an active protection control.

MTA-STS in enforce mode is the complementary control for inbound email transport security. It instructs sending mail servers that they must use TLS when delivering email to your domain, and rejects delivery attempts that cannot establish a secure connection. Without it, downgrade attacks on TLS are possible and undetected.

How to document this in your SoA:

Control: Annex A.5.14 — Information Transfer
Applicable: Yes
Justification: Email is a primary information transfer channel for the organization.
Implementation:
  - DMARC: p=quarantine (or p=reject) enforced at _dmarc.yourdomain.com
  - MTA-STS: enforce mode policy at mta-sts.yourdomain.com
  - SPF: all authorized senders listed at yourdomain.com TXT
  - DKIM: 2048-bit keys configured for all sending services
Control owner: [IT Manager / CTO / named role]
Review schedule: Quarterly DNS audit + annual DKIM key rotation review
Evidence reference: [Link to monitoring dashboard or export]

Annex A.8.16 — Monitoring Activities

Scope: Networks, systems, and applications must be monitored to detect anomalous behavior and potential security events.

What it requires for email: Active monitoring of email authentication and transport encryption — not just having the controls configured, but actively receiving and reviewing the data those controls generate.

The distinction auditors enforce: Having a rua= address in your DMARC record is configuration. Reading the reports that arrive at that address is monitoring. Having TLS-RPT configured is configuration. Reviewing TLS negotiation failure reports is monitoring.

Annex A.8.16 requires monitoring to be active. An organization with DMARC RUA configured but six months of unread XML reports in an inbox has a configuration, not a monitoring program. Auditors distinguish between the two.

Technical controls that satisfy A.8.16:

DMARC RUA reporting — aggregate reports sent daily to your rua= address, showing which services sent email as your domain, which passed authentication, and which failed. These reports must be read and actioned. The most practical approach for most organizations is a DMARC report parser (Postmark DMARC Digests, dmarcian, DMARC Analyzer) that converts the raw XML into readable summaries.

TLS-RPT — daily reports from other mail servers about TLS connection failures when delivering to your domain. Configure via a TXT record at _smtp._tls.yourdomain.com with a rua= address.

Verification:

# DMARC reporting active
dig _dmarc.yourdomain.com TXT +short
# Look for rua=mailto: in the output

# TLS-RPT active
dig _smtp._tls.yourdomain.com TXT +short
# Look for rua=mailto: in the output

What to document: Monthly or quarterly summaries of DMARC report review, showing compliance rates and any anomalies investigated. A log of actions taken when unauthorized senders appeared in reports.

Annex A.8.20 — Networks Security

Scope: Networks and network devices must be managed and controlled to protect information in systems.

DNS security controls that satisfy A.8.20:

DNSSEC — cryptographic signing of DNS records that allows resolvers to verify responses have not been tampered with in transit. A compromised DNS response that redirects your domain's traffic is a network security failure. DNSSEC prevents it.

CAA records — restricting which certificate authorities may issue TLS certificates for your domain. An attacker who obtains a fraudulent certificate for your domain under a permissive CA has bypassed your network security boundary. CAA records constrain this attack surface.

Redundant nameservers — at least two geographically separated nameservers ensure that a regional network outage does not make your domain unreachable. Managed DNS providers (Cloudflare, Route53) satisfy this by default through Anycast.

Verification:

# DNSSEC
dig yourdomain.com DNSKEY +short

# CAA
dig yourdomain.com CAA +short

# Nameserver redundancy
dig yourdomain.com NS +short

Annex A.8.12 — Data Leakage Prevention

Scope: Measures to prevent unauthorized disclosure of sensitive information.

Email controls that contribute to A.8.12:

DMARC at p=reject prevents spoofed emails bearing your domain from reaching recipients. An attacker sending phishing email that appears to come from your domain — and successfully reaches recipients' inboxes — represents unauthorized disclosure of your brand identity and potential exposure of recipient trust. p=reject eliminates the delivery vector for this attack.

BIMI (Brand Indicators for Message Identification) is relevant here as a supporting control: by displaying your verified logo in the inbox, it helps recipients identify legitimate email from your domain and distinguish it from spoofed attempts. It is not a primary A.8.12 control but can be referenced as a user-facing anti-spoofing measure.

The Gap Analysis: Control-by-Control

Use this table to assess your current state against each Annex A control. Each row shows the specific technical check, the pass condition, and what constitutes acceptable ISMS evidence.

Annex A Control	Technical Check	Pass Condition	Evidence
A.5.14	DMARC policy	`p=quarantine` or `p=reject`	`dig _dmarc.yourdomain.com TXT +short` output
A.5.14	MTA-STS mode	`mode: enforce` in policy file	`curl https://mta-sts.yourdomain.com/.well-known/mta-sts.txt`
A.5.14	SPF completeness	All sending services listed, under 10 lookups	`dig yourdomain.com TXT +short`
A.5.14	DKIM per sender	2048-bit key, not older than 12 months	`dig [selector]._domainkey.yourdomain.com TXT +short`
A.8.16	DMARC RUA active	`rua=mailto:` present, reports reviewed	DMARC report dashboard export or summary log
A.8.16	TLS-RPT active	`_smtp._tls` TXT record with `rua=` present	`dig _smtp._tls.yourdomain.com TXT +short`
A.8.20	DNSSEC enabled	DNSKEY records + DS in parent zone	`dig yourdomain.com DNSKEY +short`
A.8.20	CAA records	At least one `issue` record for approved CA	`dig yourdomain.com CAA +short`
A.8.20	Nameserver redundancy	≥2 NS records, geographically separated	`dig yourdomain.com NS +short`
A.8.12	DMARC enforcement	`p=reject` (full enforcement, not quarantine)	Same as A.5.14 DMARC check

The Three Most Common ISO 27001 Email Security Findings

Across ISMS email security reviews, three findings appear with disproportionate frequency. Knowing them in advance lets you close them before the auditor finds them.

Finding 1: DMARC at p=none in the SoA as a "monitoring control"

Organizations document DMARC in their SoA as an implemented A.5.14 control — which is correct in principle. The problem is that the policy is p=none, and the SoA describes it as a "monitoring control for email authentication."

Auditors reject this framing for A.5.14. The clause requires information transfer to be protected, not observed. A p=none policy that delivers spoofed emails to recipients while logging the event is not protecting information transfer. It is watching it fail.

The fix is a policy change (p=quarantine → p=reject) and an SoA update that describes DMARC as an enforcement control, not a monitoring one.

Finding 2: DKIM key rotation not documented or overdue

DKIM key rotation is a standard ISO 27001 cryptographic hygiene finding. Keys that have not been rotated in over 12 months are flagged as a key management weakness under A.8 (Cryptographic Controls in the 2022 standard maps to the broader A.10 category from 2013).

The finding has two components:

No documented rotation procedure. Auditors ask for your DKIM key rotation policy — how often keys rotate, who is responsible, and how the transition is managed. If this is not documented as a procedure in your ISMS, the control is not formally in place regardless of whether you have rotated keys in practice.

No rotation log. Even if a procedure exists, auditors want a log showing when each DKIM selector was last rotated and what key length was applied. A mental note that "we rotated it about a year ago" is not sufficient.

The fix: document a DKIM rotation procedure (minimum annually, new selector deployed before old one removed, key length minimum 2048-bit), and maintain a rotation log with dates and selector names.

Finding 3: Monitoring configured but not active (A.8.16 gap)

This is the most subtle finding because it looks compliant from the outside. The DNS records are correct. DMARC has a rua= address. TLS-RPT has a rua= address. The controls appear to be in place.

The auditor asks: "Can you show me the last three months of DMARC aggregate reports and what actions you took based on them?"

If the answer is "we have them but haven't been reviewing them systematically," the A.8.16 monitoring requirement is not met. Configuration is not monitoring. Receiving reports is not monitoring. Reading them, acting on anomalies, and documenting that process is monitoring.

The fix: establish a monthly DMARC report review cadence, use a parser that makes reports readable (raw XML is not practical to review), and log the review with a brief summary each month. A one-paragraph entry in a security log — "DMARC review [date]: 98.2% pass rate, two unauthorized senders identified, both are legacy services now removed from production" — is sufficient documented evidence.

What to Include in Your ISMS Audit Evidence Package

When your auditor requests evidence for A.5.14, A.8.16, A.8.20, and A.8.12, provide these in a single organized folder:

/ISO27001-Email-DNS-Evidence/

  /A.5.14-Information-Transfer/
    dmarc-record-[date].txt          ← dig output showing p=quarantine or p=reject
    mta-sts-policy-[date].txt        ← curl output of policy file showing enforce mode
    spf-record-[date].txt            ← dig output
    dkim-records-[date].txt          ← dig outputs per selector
    soa-entry-A514.docx              ← SoA entry describing controls and ownership

  /A.8.16-Monitoring/
    dmarc-rua-review-log.xlsx        ← monthly review summary, compliance rates
    tls-rpt-config-[date].txt        ← dig output of _smtp._tls record
    dkim-rotation-log.xlsx           ← selector name, rotation date, key length

  /A.8.20-Network-Security/
    dnssec-dnskey-[date].txt         ← dig DNSKEY output
    dnssec-ds-[date].txt             ← dig DS output from parent zone
    caa-record-[date].txt            ← dig CAA output
    nameservers-[date].txt           ← dig NS output

  /A.8.12-Data-Leakage/
    dmarc-reject-evidence-[date].txt ← same as A.5.14 DMARC, p=reject confirmation

Date every file. Auditors cross-reference timestamps. An evidence file with no date, or dated the week of the audit, signals point-in-time collection rather than continuous monitoring.

Automating Evidence Collection for Annual Audits

The evidence folder above, assembled manually, takes two to four hours per audit cycle if your records are clean and you know where to look. It takes longer if anything is broken, if people have left the team, or if records were not maintained consistently.

The more durable approach is continuous monitoring that generates timestamped evidence automatically throughout the year. When the audit arrives, the evidence package is an export from the monitoring system, not a manual assembly exercise.

For ISMS audits specifically, auditors want to see that monitoring was active throughout the audit period — not just that controls were in place on audit day. A monitoring system with a 365-day audit log answers that question directly. Tools like ZeroHook cover exactly these controls — SPF, DKIM, DMARC, DNSSEC, MTA-STS, CAA, TLS-RPT, blacklist monitoring — and generate compliance-mapped reports for ISO 27001 Annex A alongside NIS2 and SOC2.

TL;DR

ISO 27001:2022 added Annex A.5.14 — information transfer security is now an explicit named control; organizations transitioning from the 2013 standard must add email security controls (DMARC, MTA-STS) to their SoA explicitly
Four Annex A controls cover email and DNS security: A.5.14 (information transfer — DMARC, MTA-STS, SPF, DKIM), A.8.16 (monitoring — DMARC RUA, TLS-RPT review), A.8.20 (network security — DNSSEC, CAA, redundant NS), A.8.12 (data leakage — DMARC p=reject)
p=none does not satisfy A.5.14 — enforcement is required; p=none is a monitoring posture, not a protection control
DKIM key rotation must be documented as a procedure and logged — auditors ask for the rotation schedule and the rotation history; a mental note is not evidence
Monitoring configured ≠ monitoring active — receiving DMARC RUA reports satisfies nothing; reading them, acting on anomalies, and logging that review satisfies A.8.16
Date every evidence file — timestamps on evidence are how auditors verify continuous monitoring vs. point-in-time collection assembled for the audit

*Part of an ongoing series on DNS security and compliance.

SOC2 CC6.6 Made Easy: Automating Logical Access Evidence

Regő Botond Ronyecz — Sat, 30 May 2026 01:18:39 +0000

Your SOC2 audit window opens in three months. Your DMARC policy is p=none. Your auditor is going to flag it.

Not because p=none is wrong as a starting point — it's the standard way to begin DMARC rollout. But p=none at the start of a SOC2 audit period means that for the entire months it was in place, you had zero enforcement on a logical access control that CC6.6 explicitly requires. You cannot retroactively fix those months. You can only fix what comes next.

This is the most common CC6.6 failure mode: organizations that have technically correct configurations but arrive at the audit with the wrong policy value, at the wrong time, with no continuous evidence to show it was ever in the right state.

This guide covers exactly what CC6.6 requires for DNS and email security, what evidence auditors look for, and how to build a configuration that generates audit evidence automatically — rather than manually assembling it the week before the audit.

What CC6.6 Actually Covers

SOC2 is organized around Trust Services Criteria (TSC). CC6.6 sits inside the CC6 — Logical and Physical Access Controls category and specifically addresses:

"The entity implements logical access security measures to protect against threats from sources outside its system boundaries."

In practice, CC6.6 covers controls that prevent unauthorized external access to your systems. For most SaaS companies, the auditor's DNS and email security review under CC6.6 focuses on three threat vectors:

Email domain spoofing — an attacker sending email that appears to come from your domain. If your domain can be spoofed, phishing attacks can impersonate your company to your own customers. This is an external threat to your system boundary that email authentication controls address directly.

DNS record tampering — an attacker modifying your DNS records to redirect traffic. An unprotected DNS zone is an attack surface on your system boundary. DNSSEC and registrar-level controls address this.

Certificate issuance abuse — an attacker obtaining a valid TLS certificate for your domain through a compromised or rogue certificate authority. CAA records restrict which CAs can issue certificates for your domain.

CC6.6 also connects to CC6.1 — Security Communications, which covers transmission security. MTA-STS in enforce mode — requiring TLS for all inbound email delivery — is the CC6.1 email control that auditors verify alongside CC6.6.

The Five Controls SOC2 Auditors Check

When your auditor reviews DNS and email security as part of CC6.6, these are the specific controls they test. Each has a pass condition, a failure mode, and an evidence requirement.

Control 1: DMARC at p=quarantine or p=reject

What auditors check: The value of p= in your DMARC record at _dmarc.yourdomain.com.

Pass condition: p=quarantine or p=reject

Why p=none fails: p=none is a monitoring-only policy. It generates reports about authentication failures but takes no action — emails that fail SPF and DKIM are still delivered normally. SOC2 auditors treat p=none the same as no DMARC record from a CC6.6 enforcement perspective. You have visibility into the problem, but no control preventing it.

The timing trap: SOC2 auditors test controls at the start of the audit period, not the end. If your 12-month audit window begins January 1 and you are at p=none until March 15, you fail CC6.6 for those 10.5 weeks — even if you are at p=reject by the time the auditor arrives. The audit looks back across the entire period.

Check your current policy:

dig _dmarc.yourdomain.com TXT +short

If you see p=none, change it to p=quarantine immediately. Do not wait. Monitor DMARC reports for two to four weeks to confirm no legitimate email is failing, then advance to p=reject.

Evidence requirement: A screenshot or exported record showing p=quarantine or p=reject, timestamped at the start of the audit period. DMARC RUA reports received and reviewed during the audit period — auditors want to see that you are actively consuming the reporting data, not just publishing the record.

Control 2: All sending services in SPF, all with DKIM keys

What auditors check: Your SPF record for completeness, and DKIM key configuration for every active email sender.

The third-party sender problem: DMARC reports reveal every service sending email that claims to be from your domain. If your CRM, your marketing platform, your HR system, and your transactional email provider are all sending as your domain — and any of them are not in your SPF record or don't have DKIM configured — they appear in your DMARC reports as unauthorized senders.

SOC2 auditors review DMARC reports during the audit. Unauthorized senders in your own reports are a red flag. They indicate a gap in your logical access controls: something is sending email from your domain that is outside your control boundary.

DKIM key strength: 1024-bit DKIM keys are considered cryptographically weak and should be rotated to 2048-bit. SOC2 auditors increasingly flag 1024-bit keys as a cryptographic control weakness under CC6.6.

Check:

# SPF
dig yourdomain.com TXT +short | grep spf

# DKIM (for each active sending service selector)
dig google._domainkey.yourdomain.com TXT +short
dig selector1._domainkey.yourdomain.com TXT +short

Evidence requirement: SPF record export showing all authorized senders. DKIM TXT records for each active sending service. DMARC RUA report excerpts showing alignment pass rates above 95% for the audit period.

Control 3: MTA-STS in enforce mode (CC6.1)

What auditors check: Whether your MTA-STS policy file exists, is served over HTTPS, and specifies mode: enforce.

MTA-STS prevents downgrade attacks on inbound email delivery. Without it, a network attacker on the path between a remote mail server and yours can strip the TLS negotiation and transmit email in plaintext — bypassing your encryption entirely. mode: testing collects data but does not prevent this. mode: enforce rejects delivery attempts that cannot establish a secure TLS connection.

Check:

# DNS record
dig _mta-sts.yourdomain.com TXT +short

# Policy file
curl https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

Pass condition: the DNS record exists, the policy file is reachable over HTTPS, and the file contains mode: enforce.

Evidence requirement: A curl output or screenshot of the policy file showing mode: enforce, with a timestamp. The DNS record screenshot showing the _mta-sts TXT record.

Control 4: DNSSEC enabled and validated

What auditors check: Whether your DNS zone has DNSSEC signing active and whether the chain of trust is complete from your zone to the TLD.

DNSSEC prevents cache poisoning attacks where a resolver is fed forged DNS responses. Without DNSSEC, an attacker who can inject forged DNS responses can redirect your domain's traffic to their server — capturing credentials, intercepting email, or serving malicious content under your brand.

Check:

# Confirm DNSKEY records exist
dig yourdomain.com DNSKEY +short

# Confirm DS record in parent zone
dig DS yourdomain.com @8.8.8.8 +short

For a visual chain-of-trust verification, dnsviz.net generates a diagram showing the full DNSSEC validation path. This is useful audit evidence — it shows the complete chain, not just the presence of individual records.

Evidence requirement: DNSKEY record output, DS record in the parent zone, or a DNSViz screenshot showing a green validation chain. Timestamped at audit start and periodically through the audit period.

Control 5: CAA records restricting certificate issuance

What auditors check: Whether CAA records exist at your domain that specify which certificate authorities are permitted to issue TLS certificates for your domain.

Without CAA records, any publicly trusted CA can issue a certificate for your domain. CAA records constrain this to your approved CA(s) — so even if an attacker successfully completes a DV validation challenge through a rogue CA, that CA cannot issue the certificate if it is not listed in your CAA record.

Check:

dig yourdomain.com CAA +short

Pass condition: at least one 0 issue "your-ca.com" record exists authorizing your current CA.

Evidence requirement: CAA record export showing authorized CAs. If you use Let's Encrypt, the record should authorize letsencrypt.org. If DigiCert, digicert.com.

The Evidence Assembly Problem

Most SaaS companies that fail CC6.6 reviews are not failing because their controls are wrong. They are failing because their evidence is wrong.

Evidence problems fall into three patterns:

Pattern 1: Point-in-time snapshots. You export your DNS records the week before the audit and submit them as evidence. The auditor asks: "How do we know these controls were in place on January 1 when the audit period started?" You have no answer.

Pattern 2: Manually assembled packages. Your team spends 20+ hours before each audit cycle hunting down screenshots, pulling DMARC report exports, collecting DNS record outputs, and organizing them into an evidence folder. This is expensive, error-prone, and produces inconsistent output across audit cycles.

Pattern 3: Missing RUA data. Your DMARC record has a rua= address, but no one has been reading the reports. The auditor asks to see DMARC aggregate reports for the audit period and you have six months of unread XML files in an inbox. The data exists but is not actionable — which is functionally the same as not having DMARC reporting at all from an audit perspective.

What Automated Evidence Collection Looks Like

The alternative to manual evidence assembly is a continuous monitoring system that generates timestamped audit evidence as a byproduct of its normal operation.

For SOC2 CC6.6, the evidence package an auditor wants covers five things:

DMARC record showing p=quarantine or p=reject — with history showing it was in this state throughout the audit period
MTA-STS policy file in enforce mode — with history
DNSSEC validation active — with history
CAA records authorizing approved CAs — with history
DMARC RUA reports showing compliance rates — actively received and reviewed

The word "history" is doing most of the work here. A single clean screenshot is not history. A timestamped log of automated scans run daily or weekly across the audit period is history. It shows continuity, not just current state.

ZeroHook runs continuous DNS and email security scans and maintains a tamper-proof, hash-verified audit log — the kind of timestamped, continuous evidence record that answers the auditor's "how do we know this was in place on day one?" question directly. The Compliance Pro tier includes automated evidence collection mapped specifically to SOC2 CC6.6, NIS2, and ISO 27001 Annex A.

The audit evidence package is generated from the monitoring history, not assembled manually before the audit. The difference in preparation time is the difference between two hours and two days.

The CC6.6 Audit Preparation Checklist

Run through this at least 90 days before your audit period starts — not 90 days before the auditor arrives.

Technical controls:

- [ ] DMARC at _dmarc.yourdomain.com with p=quarantine or p=reject
      dig _dmarc.yourdomain.com TXT +short

- [ ] SPF includes all active sending services (CRM, marketing, transactional)
      dig yourdomain.com TXT +short | grep spf

- [ ] DKIM configured for every sending service, all keys 2048-bit
      dig [selector]._domainkey.yourdomain.com TXT +short

- [ ] MTA-STS policy file exists at mta-sts.yourdomain.com with mode: enforce
      curl https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

- [ ] DNSSEC enabled — DNSKEY records present, DS in parent zone
      dig yourdomain.com DNSKEY +short

- [ ] CAA records specify authorized CAs
      dig yourdomain.com CAA +short

- [ ] MFA enforced on all accounts with DNS or email configuration access
      (registrar account, DNS provider, email provider admin panel)

Evidence:

- [ ] Continuous monitoring active — not just point-in-time scans
- [ ] DMARC RUA reports being received and reviewed (not just published)
- [ ] Timestamped history of all controls for the full audit period
- [ ] DMARC compliance rate above 95% in aggregate reports
- [ ] No unauthorized senders appearing in DMARC RUA reports

The MFA Requirement Under CC6.6

CC6.6 is specifically about logical access controls — and that extends beyond DNS records to the accounts that can modify them.

Every account with write access to your DNS records, your email provider configuration, or your domain registrar must have MFA enforced. This includes:

The Cloudflare, Route53, or Google Cloud DNS dashboard account
The domain registrar account (GoDaddy, Namecheap, etc.)
The email provider admin panel (Google Workspace Admin, Microsoft 365 Admin Center)
Any CI/CD service accounts that can push DNS configuration changes

For SOC2, MFA must be enforced — not optional. If a user can disable or bypass MFA on an admin account, the control is not in place. Document which accounts have admin access and confirm MFA enforcement for each.

What the Audit Evidence Package Should Contain

When your auditor requests CC6.6 evidence for DNS and email security, hand them this:

Evidence item	Format	Period covered
DMARC record with p= value	`dig` output or monitoring export	Start of audit period + current
DMARC RUA compliance trend	Dashboard export or report screenshots	Full audit period
SPF record	`dig` output	Start of audit period + current
DKIM records per sender	`dig` outputs	Current
MTA-STS policy file	`curl` output	Start of audit period + current
DNSSEC validation	`dig` DNSKEY output or DNSViz screenshot	Start of audit period + current
CAA records	`dig` output	Start of audit period + current
MFA enforcement log	Admin console screenshots	Current policy
Continuous monitoring history	Automated scan log with timestamps	Full audit period

The column "start of audit period + current" is the key. Auditors want to see that the control was in place when the clock started, not just that it is in place now.

TL;DR

CC6.6 covers external threat controls — email authentication (SPF, DKIM, DMARC), DNS integrity (DNSSEC, CAA), and transport security (MTA-STS in enforce mode) all map directly to CC6.6 and CC6.1
p=none DMARC fails CC6.6 — enforcement is the requirement; monitoring is not. Move to p=quarantine or p=reject before your audit window opens, not before the auditor arrives
SOC2 auditors look back, not just at current state — if p=none was in place for any portion of the audit period, those months fail the control regardless of what you fix afterward
Unauthorized senders in DMARC reports are a red flag — audit every service sending email as your domain and ensure SPF and DKIM cover all of them
Evidence must show continuity, not a point in time — timestamped automated monitoring history is what satisfies "how do we know this was in place on day one?"
MFA on all DNS and email admin accounts is part of CC6.6 — document which accounts have access and confirm enforcement, not just availability

*Part of an ongoing series on DNS security and compliance.

NIS2 Compliance for Small Businesses: The Ultimate 2026 Checklist

Regő Botond Ronyecz — Sat, 30 May 2026 01:11:28 +0000

NIS2 enforcement started in October 2024. There is no grace period. There is no "we're working on it" exemption for small businesses. If your organization falls under the directive, the obligations are active now.

The fines are real: up to €10,000,000 or 2% of global annual turnover for Essential Entities, up to €7,000,000 or 1.4% for Important Entities — whichever is higher. Your national competent authority (NCA) administers enforcement, and the first wave of formal audits is already underway in several member states.

Most NIS2 compliance guides are written for enterprise legal and security teams. This one is written for the IT manager, founder, or sysadmin at a 30–200 person business who needs to know exactly what to do, in what order, and what constitutes sufficient evidence.

Step 0: Confirm Whether NIS2 Applies to You

Before building a compliance program, confirm your scope. NIS2 applies to medium-sized and larger organizations — 50+ employees or €10M+ annual turnover — operating in covered sectors.

Essential Entities (higher fine exposure, stricter supervision):

Energy (electricity, oil, gas, district heating, hydrogen)
Transport (air, rail, water, road)
Banking and financial market infrastructure
Health (hospitals, labs, pharmaceutical manufacturers)
Drinking water and wastewater
Digital infrastructure — this is the catch-all that captures many SaaS companies. Cloud providers, data centers, CDNs, DNS providers, internet exchange points, and trust service providers all fall here above certain thresholds.
ICT service management (managed service providers, managed security providers)
Public administration
Space

Important Entities (lower fine exposure, reactive supervision):

Postal and courier services
Waste management
Manufacture and distribution of chemicals
Food production, processing, and distribution
Manufacturing of medical devices, electronics, machinery, motor vehicles
Digital providers: online marketplaces, online search engines, social networking platforms
Research organizations

If you provide B2B software or infrastructure services to organizations in any of the above sectors, you may fall under NIS2 as an ICT third-party provider even if your own sector is not listed.

If you are outside the EU but provide services to EU organizations in covered sectors, NIS2 may still apply to you.

If your organization is below the size thresholds, you may still be covered if a member state has designated you as critical infrastructure. When in doubt, check with your national competent authority.

The Core Legal Requirement: Article 21

Everything in NIS2 compliance for technical teams flows through Article 21 — Cybersecurity Risk-Management Measures. It requires "appropriate and proportionate technical, operational and organisational measures" across ten areas.

For small businesses, the areas that translate directly into auditable technical controls are:

Article 21 Sub-Clause	What it covers	Technical equivalent
21.2c	Business continuity	Redundant DNS, MX failover
21.2d	Supply chain security	Email authentication (SPF, DKIM, DMARC)
21.2g	Cryptography and encryption	DNSSEC, MTA-STS, TLS
21.2h	Human resources, access control	Staff training, access management
21.2i	Multi-factor authentication	MFA on all admin accounts
21.2j	Secure communications	Encrypted email transport, TLS-RPT monitoring

The critical word in Article 21 is "appropriate." Auditors do not expect a 20-person business to operate a 24/7 SOC. They do expect documented controls that are proportionate to your size, sector, and risk exposure — and evidence that those controls are actively maintained, not configured once and forgotten.

The NIS2 Technical Checklist for Small Businesses

Work through this in order. The first section covers the technical DNS and email controls that map directly to Article 21. The second covers the documentation and process evidence auditors look for on top of the technical layer.

Section 1: DNS and Email Security Controls

These are the technical measures that auditors check first because they are objectively verifiable. Pass or fail is deterministic — either the record exists and is correctly configured, or it does not.

1.1 — SPF record is published and valid (Article 21.2d)

SPF (Sender Policy Framework) lists which mail servers are authorized to send email from your domain. Without it, anyone can send forged email claiming to be from your address.

Check:

dig yourdomain.com TXT +short | grep spf

Pass condition: a TXT record starting with v=spf1 exists, includes all your sending services, and ends with ~all or -all. The record must not exceed 10 DNS lookups. Two v=spf1 records on the same domain is an automatic fail — only one is allowed.

NIS2 mapping: Article 21.2d — supply chain. Email sent from your domain on behalf of business processes is part of your ICT supply chain. Unauthenticated email is an uncontrolled attack surface.

1.2 — DKIM is configured for all sending services (Article 21.2d)

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing email. Receiving servers verify the signature against a public key you publish in DNS. If the signature doesn't match, the email is flagged or rejected.

Check:

dig selector._domainkey.yourdomain.com TXT +short

Replace selector with the selector name from your email provider (commonly google, selector1, or default).

Pass condition: a TXT record starting with v=DKIM1; k=rsa; p= exists for each active email service. Key length must be 2048 bits — 1024-bit keys are considered weak and should be rotated. Selectors with empty p= values indicate a revoked key and should be removed from DNS.

NIS2 mapping: Article 21.2d — supply chain security, and Article 21.2g — cryptography. DKIM is a cryptographic control on email transmission.

1.3 — DMARC policy is p=quarantine or p=reject (Article 21.2d)

This is the single most common NIS2 compliance failure on email. p=none does not satisfy Article 21.2d because it does not enforce the policy — it only monitors. Auditors will explicitly check this.

Check:

dig _dmarc.yourdomain.com TXT +short

Pass condition: a TXT record exists at _dmarc.yourdomain.com with p=quarantine or p=reject. A rua= address for receiving aggregate reports must also be present — without it you have no visibility into what is failing.

NIS2 mapping: Article 21.2d. p=none explicitly does not qualify as an enforced control under NIS2. The requirement is enforcement, not observation.

If you are currently at p=none:

Monitor DMARC reports for 2–4 weeks using a parser (Postmark DMARC Digests, DMARC Analyzer)
Confirm all legitimate sending services pass SPF and DKIM
Move to p=quarantine
After another 2–4 weeks of clean reports, move to p=reject

Do not jump directly to p=reject — it will block legitimate emails if any sending service is not yet authenticated.

1.4 — DNSSEC is enabled (Article 21.2g)

DNSSEC adds cryptographic signatures to your DNS records, allowing resolvers to verify that answers have not been tampered with in transit. Without DNSSEC, cache poisoning attacks can redirect your domain's traffic to an attacker's server — silently, with no warning to your users.

Check:

dig yourdomain.com DNSKEY +short

Pass condition: DNSKEY records are present and a DS record exists in the parent zone (your TLD). The full chain of trust can be verified at dnsviz.net.

Setup on managed providers:

Cloudflare: DNS → Settings → DNSSEC → Enable → copy DS record to registrar
Route53: Hosted zone → DNSSEC signing → Enable → add DS record at registrar (KMS key must be in us-east-1)
Google Cloud DNS: Cloud DNS → zone → DNSSEC → Enable → copy DS record to registrar

NIS2 mapping: Article 21.2g — cryptography and encryption. DNSSEC is explicitly a cryptographic measure for DNS integrity.

1.5 — MTA-STS is configured in enforce mode (Article 21.2g / 21.2j)

MTA-STS (Mail Transfer Agent Strict Transport Security) instructs other mail servers to use TLS when connecting to yours, and prevents downgrade attacks that would allow email to be transmitted unencrypted. Without MTA-STS, an attacker on the network path between two mail servers can strip TLS and read email in transit.

MTA-STS requires two components:

A policy file hosted at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
A TXT record at _mta-sts.yourdomain.com

The policy file content for enforce mode:

version: STSv1
mode: enforce
mx: mail.yourdomain.com
max_age: 86400

The DNS record:

_mta-sts.yourdomain.com TXT "v=STSv1; id=20240101000000"

The id value must change whenever you update the policy file — it signals to other mail servers that they should fetch the new policy.

NIS2 mapping: Article 21.2g (cryptography) and Article 21.2j (secure communications). MTA-STS is a transport encryption enforcement measure for email.

1.6 — TLS-RPT is configured (Article 21.2j)

TLS-RPT (TLS Reporting) sends you daily reports from other mail servers about TLS negotiation failures when they attempt to deliver email to your domain. Without it, you have no visibility into whether your email transport encryption is working correctly in practice.

dig _smtp._tls.yourdomain.com TXT +short

Pass condition: a TXT record exists at _smtp._tls.yourdomain.com with a rua= address to receive reports.

NIS2 mapping: Article 21.2j — secure communications monitoring.

1.7 — Redundant nameservers in separate geographic locations (Article 21.2c)

NIS2 Article 21.2c requires business continuity measures for ICT systems. For DNS, this means at minimum two nameservers that are geographically and network-separated — so a single regional outage does not take your domain offline entirely.

Check:

dig yourdomain.com NS +short

Pass condition: at least two nameservers are returned. Managed DNS providers (Cloudflare, Route53, Google Cloud DNS) satisfy geographic redundancy by default through their Anycast networks — if you are using one of these, this control is met.

If you are running self-hosted DNS, verify that your secondary nameserver is on a different ASN and in a different data center region from your primary.

NIS2 mapping: Article 21.2c — business continuity and crisis management.

1.8 — Blacklist monitoring is active (Article 21.2d)

If your sending IP or domain appears on a major blacklist (Spamhaus, Barracuda, Microsoft SNDS), your email is rejected by large portions of the internet. This is an active and ongoing supply chain risk — blacklistings happen without warning and can persist for days before anyone on your team notices through manual checks.

Manual check:

# Spamhaus combined zone (SBL + XBL + PBL):
dig {reversed-ip}.zen.spamhaus.org A
# NXDOMAIN = clean. Any other response = listed.

For continuous coverage, automated blacklist monitoring across 50+ databases is the practical requirement — manual checks only tell you the status at the moment you run them.

NIS2 mapping: Article 21.2d — supply chain security. Blacklist status directly affects whether your business communications reach their intended recipients.

1.9 — SSL certificate expiry monitoring (Article 21.2g)

An expired SSL certificate causes browser trust errors on your website and can break encrypted services. For NIS2 purposes, certificate expiry monitoring is part of cryptographic hygiene under Article 21.2g.

Check:

echo | openssl s_client -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates

Pass condition: notAfter is at least 30 days in the future. Automated monitoring that alerts before expiry eliminates the failure mode entirely.

1.10 — CAA records restrict certificate issuance (Article 21.2g)

CAA (Certification Authority Authorization) records specify which certificate authorities are permitted to issue SSL certificates for your domain. Without CAA records, any of the hundreds of publicly trusted certificate authorities in the world can issue a certificate for your domain — including in response to a phishing or social engineering attack.

dig yourdomain.com CAA +short

Pass condition: at least one CAA record authorizing your current CA exists. Add one issue record for each CA you actively use.

NIS2 mapping: Article 21.2g — cryptographic controls on certificate issuance.

Section 2: Documentation and Evidence

The technical controls in Section 1 are necessary but not sufficient. NIS2 auditors require documented evidence that controls exist and are continuously maintained. Point-in-time evidence — a scan result you generate the day before the audit — does not demonstrate continuous monitoring.

2.1 — ICT risk register includes DNS and email infrastructure

Your risk register must document DNS zone and email infrastructure as critical ICT assets. For each asset, document: the threat, the likelihood, the impact, and the current control in place.

Minimum entry format:

Asset: DNS zone (yourdomain.com)
Threat: DNS hijacking / cache poisoning
Likelihood: Medium
Impact: High (complete service outage, credential harvesting)
Control: DNSSEC enabled, nameserver monitoring active
Review date: [quarterly]

The register must be dated and versioned. Version history is itself evidence of ongoing maintenance.

2.2 — Incident response plan covers DNS and email incidents

Your IRP must cover the scenario where DNS records are modified without authorization, or where your sending IP is blacklisted. For NIS2, significant incidents must be reported to your national CSIRT within 24 hours of detection, with a full report within 72 hours.

The plan must document:

Detection (how will you know?)
Containment (what do you do immediately?)
CSIRT notification (who contacts them, with what information?)
Recovery (how do you restore correct state?)
Post-incident review (what changed?)

A three-page document that covers these five points is sufficient. It must exist, be dated, and be tested at least annually via tabletop exercise.

2.3 — Continuous monitoring evidence with timestamps

This is the hardest requirement to satisfy with manual processes. Auditors look for a continuous, timestamped record of monitoring activity — not a report you generated for the audit.

Acceptable continuous monitoring evidence:

Automated scan results with timestamps covering the audit period (90+ days)
Alert history showing that when a control changed, your team was notified
Remediation records showing that alerts were investigated and resolved

Not acceptable as continuous monitoring evidence:

A single clean scan report dated the week before the audit
A spreadsheet of manual checks without timestamps
Screenshots of current DNS records without historical context

Tools like ZeroHook run continuous DNS and email security scans, maintain a timestamped audit log, and generate compliance-mapped evidence packages for NIS2 auditors — the kind of output that directly answers "show me your continuous monitoring" without manual assembly.

2.4 — Supply chain vendor register

NIS2 Article 21.2d requires you to assess the security posture of ICT suppliers that have access to your systems or handle your data. This includes your email provider, DNS host, cloud hosting, and any SaaS tools with access to sensitive data.

Minimum vendor register entry:

Vendor: [Name]
Service: [What they provide]
Data accessed: [Customer data / employee data / none]
Security certification: [ISO 27001 cert no. / SOC2 report / N/A]
Last reviewed: [Date]
Contractual DPA: [Yes / No]

Requesting a vendor's security certification or sending a brief questionnaire — documented in an email thread — constitutes active supply chain due diligence. The fact of having asked, with a date, is evidence.

2.5 — Staff security training records

Article 21.2h requires human resources security including cybersecurity awareness. For small businesses, the minimum viable evidence is:

A security awareness training session covering phishing, password hygiene, and incident reporting — at least annually
Attendance records or completion certificates
A written policy for reporting suspected incidents (even a one-page document)

Phishing simulation results are a strong positive signal in an audit — they demonstrate active testing of human controls, not just training delivery.

2.6 — MFA is enforced on all administrative accounts (Article 21.2i)

Article 21.2i explicitly requires multi-factor authentication for remote access and administrative access to systems. This is one of the clearest mandatory requirements in NIS2.

Document:

List of administrative accounts (email, DNS, cloud, critical SaaS)
MFA method for each (TOTP, hardware key, etc.)
Enforcement status (is MFA enforced by policy, or optional?)

MFA must be enforced, not optional. If users can bypass MFA on admin accounts, the control is not in place for NIS2 purposes.

NIS2 Compliance Status: A Quick Self-Assessment

Use this scoring table to gauge where you stand before a formal audit.

Control	Status	NIS2 Article
SPF published and valid	✅ Pass · ❌ Fail · ⬜ Pending	21.2d
DKIM configured, 2048-bit keys	✅ Pass · ❌ Fail · ⬜ Pending	21.2d, 21.2g
DMARC at p=quarantine or p=reject	✅ Pass · ❌ Fail · ⬜ Pending	21.2d
DNSSEC enabled	✅ Pass · ❌ Fail · ⬜ Pending	21.2g
MTA-STS in enforce mode	✅ Pass · ❌ Fail · ⬜ Pending	21.2g, 21.2j
TLS-RPT configured	✅ Pass · ❌ Fail · ⬜ Pending	21.2j
Redundant nameservers	✅ Pass · ❌ Fail · ⬜ Pending	21.2c
Blacklist monitoring active	✅ Pass · ❌ Fail · ⬜ Pending	21.2d
SSL expiry monitored	✅ Pass · ❌ Fail · ⬜ Pending	21.2g
CAA records in place	✅ Pass · ❌ Fail · ⬜ Pending	21.2g
ICT risk register maintained	✅ Pass · ❌ Fail · ⬜ Pending	21.2a
Incident response plan documented	✅ Pass · ❌ Fail · ⬜ Pending	21.2b
Continuous monitoring evidence	✅ Pass · ❌ Fail · ⬜ Pending	21.2 (general)
Vendor security register	✅ Pass · ❌ Fail · ⬜ Pending	21.2d
Staff security training records	✅ Pass · ❌ Fail · ⬜ Pending	21.2h
MFA enforced on admin accounts	✅ Pass · ❌ Fail · ⬜ Pending	21.2i

12 or more passes, with no critical failures in DMARC, DNSSEC, or MTA-STS: you are in defensible shape for an initial audit.

Fewer than 8 passes: prioritize the technical controls in Section 1 before addressing documentation. Auditors verify technical controls first, then look for documentation.

The Two Controls That Get Small Businesses in Trouble Most Often

Based on the pattern of NIS2 compliance gaps, two controls account for the majority of Article 21 failures in SMB audits.

DMARC at p=none. This is the most common. Organizations set up DMARC for monitoring, never advance to enforcement, and arrive at an audit with a p=none record they believe is compliant. It is not. NIS2 requires enforcement. A DMARC record with p=none is treated the same as no DMARC record from a compliance perspective.

No continuous monitoring evidence. The second most common. An organization has all the correct technical controls in place but cannot produce timestamped evidence that those controls were continuously active during the audit period. Running a scan the morning of the audit does not demonstrate that the controls were in place three months ago.

Both of these are solvable. The DMARC fix is a record update. The monitoring evidence problem requires putting automated, continuous monitoring in place before the audit cycle starts — not after you receive the audit notice.

TL;DR

NIS2 enforcement is active as of October 2024 — fines up to €10M for Essential Entities, €7M for Important Entities — there is no grace period for small businesses in scope
The core technical requirement is Article 21 — DNS security (DNSSEC, redundant nameservers, CAA), email authentication (SPF, DKIM, DMARC at p=quarantine or p=reject), and transport encryption (MTA-STS in enforce mode, TLS-RPT)
p=none DMARC does not satisfy Article 21.2d — enforcement is required, not monitoring. This is the single most common compliance gap in SMB audits
Continuous monitoring evidence is mandatory — point-in-time scan results do not satisfy the requirement. Timestamped automated monitoring covering the audit period is what auditors ask for
Documentation requirements are proportionate — a dated risk register, a 3-page incident response plan, a vendor register, and staff training records are sufficient for most small businesses
MFA on all administrative accounts is explicitly required under Article 21.2i — optional MFA does not satisfy the requirement

*Part of an ongoing series on DNS security and compliance.

BIMI and VMC: Should Your Business Add a Logo to Emails?

Regő Botond Ronyecz — Sat, 30 May 2026 01:05:45 +0000

Your logo appears in the inbox, next to your email, before the recipient opens it. No subject line tricks. No sender name optimization. Just your brand mark, visible in the inbox the same way a verified checkmark signals trust on social media.

That's BIMI. It's real, it's live in Gmail, Yahoo Mail, and Apple Mail, and the setup is more straightforward than most people expect — with one significant exception that determines whether it costs you 15 minutes or $1,499 a year.

This guide covers exactly what BIMI requires, what the VMC certificate is and when you actually need it, and the precise steps to get your logo showing in inboxes.

What BIMI Actually Is

BIMI (Brand Indicators for Message Identification) is a DNS TXT record that links a verified logo to your email domain. When a recipient's mail client supports BIMI and sees your domain, it checks for the BIMI record, fetches the logo from the URL in that record, and displays it in the inbox next to the sender name.

The result is visible in:

Yahoo Mail — BIMI logo shown without any additional certificate requirement
Apple Mail (iOS 16+ and macOS Ventura+) — BIMI logo shown without additional certificate
Gmail — BIMI logo shown, but only if you have a VMC certificate (more on this below)

The key distinction: Gmail treats BIMI differently from other clients. Everyone else will show your logo with a correctly configured BIMI record. Gmail requires an additional paid certificate on top of that.

BIMI is not a spam filter signal. It does not directly improve your deliverability or affect whether emails reach the inbox. What it does is make your emails visually identifiable in the inbox at a glance — which affects open rates, trust, and phishing resistance (recipients learn to recognize your logo and notice when it's missing).

The Prerequisites: What Has to Be in Place First

BIMI has hard requirements. If any of these are missing, the logo will not appear regardless of how correctly your BIMI record is configured.

DMARC at p=quarantine or p=reject

This is the most common blocker. BIMI requires your domain to have DMARC enforcement active — p=quarantine or p=reject. If your DMARC policy is p=none, BIMI will not activate.

Check your current DMARC policy:

dig _dmarc.yourdomain.com TXT +short

If you see p=none in the output, fix that first. The standard approach is to start at p=none to collect reports, then move to p=quarantine once you've confirmed all legitimate email sources pass SPF and DKIM, then eventually to p=reject.

Do not skip to p=reject immediately. Start at p=quarantine, monitor DMARC reports for two to four weeks to confirm no legitimate mail is failing, then advance to p=reject if everything is clean.

A publicly accessible SVG logo

BIMI requires a logo file hosted at a public HTTPS URL. This is not just any SVG file — it must be SVG Tiny 1.2, a strict subset of the SVG specification. Regular SVG files produced by Illustrator, Figma, or most design tools will not pass BIMI validation, even if they render correctly in browsers.

Common SVG Tiny 1.2 failures:

CSS <style> blocks — SVG Tiny 1.2 requires inline attributes, not stylesheets
Missing viewBox attribute
Gradients and filters — not supported in SVG Tiny 1.2
Non-square aspect ratio — the spec requires a square logo

The BIMI Group publishes an official converter at bimigroup.org/svg-conversion that converts standard SVG files to Tiny 1.2 compliant format. Run your logo through it, then validate the result at validator.bimi-group.org before adding the DNS record. An invalid SVG means no logo — and no error message telling you why.

The logo file must be hosted at a URL you control over HTTPS. A common convention is https://yourdomain.com/logo.svg, but any publicly reachable HTTPS URL works.

The BIMI DNS Record

Once your DMARC policy is at p=quarantine or p=reject and your SVG logo is validated and hosted, the DNS record is a single TXT entry:

Record type: TXT
Name:        default._bimi
Value:       v=BIMI1; l=https://yourdomain.com/logo.svg; a=

The l= field is the URL of your logo file. The a= field is where the VMC certificate URL goes — leave it empty if you don't have one (the field is still required, just with no value).

Cloudflare:

1. dash.cloudflare.com → select domain → DNS → Add record
2. Type: TXT
3. Name: default._bimi
4. Content: v=BIMI1; l=https://yourdomain.com/logo.svg; a=
5. Proxy status: DNS only (grey cloud — never proxy BIMI records)
6. Save

GoDaddy:

1. My Products → DNS next to your domain → Add → Type: TXT
2. Host: default._bimi
3. TXT Value: v=BIMI1; l=https://yourdomain.com/logo.svg; a=
4. TTL: 1 Hour → Save

Namecheap:

1. Domain List → Manage → Advanced DNS → Add New Record
2. Type: TXT Record
3. Host: default._bimi
4. Value: v=BIMI1; l=https://yourdomain.com/logo.svg; a=
5. TTL: Automatic → green checkmark

AWS Route53:

1. Route 53 → Hosted zones → click your domain → Create record
2. Type: TXT
3. Record name: default._bimi
4. Value: "v=BIMI1; l=https://yourdomain.com/logo.svg; a="
   (Route53 requires the value wrapped in double quotes)
5. TTL: 300 → Create records

Verify the record is live:

dig default._bimi.yourdomain.com TXT +short

The VMC Question: Do You Actually Need It?

This is where most BIMI guides either oversimplify or overstate the requirement. The answer depends entirely on which inbox providers matter most to your recipients.

Without a VMC:

✓ Logo appears in Yahoo Mail
✓ Logo appears in Apple Mail (iOS 16+, macOS Ventura+)
✗ Logo does not appear in Gmail

With a VMC:

✓ Logo appears in Yahoo Mail
✓ Logo appears in Apple Mail
✓ Logo appears in Gmail

A Verified Mark Certificate (VMC) is a certificate issued by a Certificate Authority that cryptographically ties your logo to your trademarked brand. The only current VMC issuer is DigiCert — Entrust discontinued VMC issuance in 2023. The cost is approximately $1,499–$2,499 per year.

The VMC is not just a paid certificate. It has its own prerequisite: your logo must be a registered trademark in the jurisdiction where you operate. DigiCert verifies this during the application process. If your logo is not formally registered as a trademark, you cannot obtain a VMC regardless of budget.

The decision framework is simple:

Situation	Recommendation
Your audience is primarily Yahoo Mail or Apple Mail users	BIMI without VMC — free, 15-minute setup
Your audience is primarily Gmail users and logo visibility in Gmail is a priority	BIMI + VMC — $1,499+/year, requires trademark registration
Your logo is not a registered trademark	BIMI without VMC — VMC is not available to you yet
You send primarily B2B email to corporate domains on Google Workspace	Consider VMC — most corporate Gmail users are on Workspace
You're a small SMB testing deliverability improvements	Start without VMC — validate the impact before investing

For most SMBs, the right starting point is BIMI without a VMC. Your logo will appear in Yahoo and Apple Mail immediately. If you later decide Gmail visibility justifies $1,499/year and you have a registered trademark, adding a VMC is a straightforward upgrade — you add the VMC URL to the a= field in your existing BIMI record.

Full Setup Checklist

Walk through these in order. Each one is a hard dependency on the next.

□ 1. DMARC record exists with p=quarantine or p=reject
      dig _dmarc.yourdomain.com TXT +short

□ 2. SPF and DKIM both passing (DMARC requires both)
      Send a test email and check headers for spf=pass and dkim=pass

□ 3. Logo file is SVG Tiny 1.2 compliant
      Convert: bimigroup.org/svg-conversion
      Validate: validator.bimi-group.org

□ 4. Logo file is hosted at a public HTTPS URL
      curl -I https://yourdomain.com/logo.svg
      (Should return 200 OK)

□ 5. Logo has a square aspect ratio
      Check viewBox in the SVG file — width and height values should be equal

□ 6. BIMI TXT record added at default._bimi
      dig default._bimi.yourdomain.com TXT +short

□ 7. (Optional) VMC purchased from DigiCert and URL added to a= field
      Only if trademark is registered and Gmail logo display is a priority

□ 8. Full BIMI setup validated
      bimigroup.org/bimi-generator

What Breaks When You Skip Steps

DMARC at p=none. The most common reason a correctly configured BIMI record produces no visible logo. Mail clients check DMARC enforcement before rendering BIMI. A p=none policy fails silently — your BIMI record is technically present, the logo URL is reachable, and nothing shows in the inbox.

Invalid SVG. Standard SVG files fail BIMI validation. The failure is silent — the mail client simply doesn't display the logo. The validator at validator.bimi-group.org is the only way to confirm compliance before you add the DNS record.

HTTP instead of HTTPS for the logo URL. The logo must be served over HTTPS. HTTP will not work, even if the file is reachable.

Expecting the Gmail logo without a VMC. Gmail requires the VMC certificate. If your BIMI record is correctly configured but the a= field is empty, your logo will appear in Yahoo and Apple Mail and not in Gmail. This is expected behavior, not a configuration error.

Entrust VMC certificates. Entrust discontinued VMC issuance in 2023. If you have an Entrust VMC from before that date, check its expiry — renewal is not available through Entrust. DigiCert is the only current VMC issuer.

Is BIMI Worth It?

For most businesses sending high-volume B2C email — e-commerce, financial services, SaaS with a large end-user base — the answer is yes, for the no-VMC setup. The cost is 15 minutes and a compliant SVG file. Your logo appears in Yahoo and Apple Mail inboxes immediately.

The case for a VMC is narrower. If your audience is primarily Gmail users, your logo is a registered trademark, and open rate impact on $1,499–$2,499/year is worth modeling for your email volume, the VMC adds Gmail coverage. For SMBs with smaller lists, the math typically favors starting with BIMI-only and revisiting VMC when volume justifies it.

BIMI is a late-stage optimization. Get SPF, DKIM, DMARC, and blacklist status right first. Those affect whether your emails reach the inbox at all. BIMI affects how they look once they get there.

ZeroHook's 30-point audit includes BIMI validation — it checks whether your logo is reachable at your domain, whether your DMARC policy meets the p=quarantine or p=reject threshold, and whether the DNS record is correctly formatted. The fix guide walks through SVG requirements and provider-specific setup steps: zerohook.org

TL;DR

BIMI is a DNS TXT record at default._bimi that links a verified SVG logo to your email domain so it appears in Yahoo Mail, Apple Mail, and (with a VMC) Gmail
Two hard prerequisites: DMARC at p=quarantine or p=reject, and an SVG Tiny 1.2 compliant logo hosted over HTTPS — standard SVG files will silently fail
VMC is optional for most setups — without it, your logo shows in Yahoo and Apple Mail but not Gmail; with it ($1,499+/year from DigiCert, trademark required), it shows in Gmail too
Entrust VMCs are discontinued — DigiCert is the only current issuer
Setup without VMC takes 15 minutes once DMARC is enforced and the SVG is validated
Fix SPF, DKIM, and DMARC first — BIMI is a branding layer on top of working email authentication, not a replacement for it

*Part of an ongoing series on email deliverability and DNS security.

Why Most DNS Audit Tools Don't Give You the Actual Fix (And Why We Do)

Regő Botond Ronyecz — Thu, 28 May 2026 20:23:45 +0000

You run the audit. The results come back. SPF: Fail. DMARC: Not configured. Blacklist status: Listed on 3 databases.

You stare at the screen. The tool has done its job. It found the problems. Now what?

There is no "what." The tool stops there. The next step is yours: figure out what the record should say, find the right panel in your DNS provider, format it correctly, and hope propagation confirms the fix worked. Most teams open a new tab and start Googling. Some open a support ticket and wait. Some close the browser and move on.

The audit found the problem. The problem stays unfixed.

This is not a small gap. It is the reason email deliverability issues persist for weeks at companies that have already run three separate audits. The diagnostic and the remedy are disconnected, and almost no tool in this space has tried to close that gap — until you understand why.

The Diagnostic Business Model

Most DNS and email security tools were built by network engineers for network engineers. The design assumption is that whoever runs the audit knows what to do with the results.

That assumption made sense in 2008. DNS was managed by sysadmins who had memorized RFC 7208 and could write a DKIM TXT record from scratch. The tool's job was to surface the data. The engineer's job was to interpret and fix it.

The market has changed substantially. Today, DNS is managed by:

Founders at early-stage SaaS companies who registered the domain themselves
Marketing managers who inherited the domain when the previous IT person left
Office administrators at 40-person logistics companies who have DNS access because someone has to
Developers who know their stack cold and DNS not at all
MSPs managing 80 client domains across 12 different registrars

None of these people want a DNS audit result. They want to know what to type and where to type it.

The tool vendors didn't adapt because their core customers — enterprise security teams, MSSPs, large IT departments — didn't need them to. The diagnostic was sufficient. The rest of the market was either too small to matter or too fragmented to serve with a standardized fix.

What "Not Giving You the Fix" Actually Looks Like

Here is what a standard DNS audit result looks like across the tools most people use:

MXToolbox

SPF Record Published: YES
SPF Contains characters after ALL: ERROR
SPF Record Syntax Check: ERROR

Useful diagnostic. Clear that something is wrong. No indication of what the correct record should say.

Google Admin Toolbox (CheckMX)

✓ Domain has SPF records
✗ Domain's SPF record does not include all sending sources

Accurate. Clean output. Still no record to copy.

dig (command line)

$ dig TXT yourdomain.com +short
"v=spf1 include:sendgrid.net ~all"

Shows you the current record. Does not tell you what's missing or what to add.

Generic audit PDF from a compliance scanner

Finding: SPF record missing include for third-party ESP
Severity: High
Recommendation: Update SPF record to include authorized sending services

The recommendation is technically correct and operationally useless.

In every case, the tool has correctly identified that something is wrong. In no case does it tell you the specific string to add to your DNS provider's TXT record field.

Why the Fix Is Harder Than It Looks

Giving an actionable fix is not a UI decision. It requires solving several non-trivial problems simultaneously.

Problem 1: The fix depends on your sending stack

An SPF record is not a universal string. It is a list of the specific mail servers authorized to send on your behalf. If you use SendGrid, the correct include is include:sendgrid.net. If you use Google Workspace, it is include:_spf.google.com. If you use both, plus Mailchimp and a Salesforce marketing instance, the record has to cover all of them — and stay under the 10 DNS lookup limit.

A generic audit tool has no idea which ESPs you use. It can tell you your SPF is broken. It cannot tell you which services to add without knowing your sending infrastructure. The right approach is not to guess — it's to show you the email provider options and let you identify your own stack.

Problem 2: The fix depends on your DNS provider

Every DNS provider has a different interface. Adding a TXT record in Cloudflare is different from Route53. The field labels in GoDaddy are named differently. Namecheap's Advanced DNS tab splits host and value in a way that confuses first-time users. AWS Route53 requires TXT values wrapped in double quotes — a detail that breaks records silently when you get it wrong.

A fix that says "add this TXT record" without provider-specific steps leaves you to figure out the interface yourself. That step is exactly where non-technical users give up.

Problem 3: The fix has to account for what's already there

DNS records interact. Adding an SPF include without checking the current lookup count can push you over the 10-lookup limit and break SPF for every email you send. Adding a DMARC record without knowing your current DKIM alignment state can trigger quarantining of legitimate mail. The most common SPF mistake — creating a second TXT record starting with v=spf1 instead of editing the existing one — instantly invalidates both records and breaks all email delivery.

A correct fix requires reading the existing zone state, not just flagging a missing record.

Problem 4: Building the provider database has no clear ROI for most tools

Every DNS provider has its own UI patterns, field naming conventions, and record validation logic. Building and maintaining step-by-step instructions for Cloudflare, GoDaddy, Namecheap, Route53, DigitalOcean, Hostinger, and the rest — and keeping those instructions current as providers update their interfaces — requires ongoing investment.

For tools that charge per scan or sell to enterprise security teams, that investment has no direct revenue justification. The enterprise buyer doesn't need the step-by-step. The SMB buyer who does need it isn't the primary customer.

What a Real Fix Looks Like

Here is what the same SPF finding looks like when the tool gives you the actual remedy.

If you already have an SPF record, the fix shows your current record, modifies it correctly, and gives you the exact string to replace it with:

Your current record:
v=spf1 include:sendgrid.net ~all

Updated record (soft fail — recommended to start):
v=spf1 include:sendgrid.net ~all

Hard fail version (once you've confirmed all services pass):
v=spf1 include:sendgrid.net -all

If you don't have a record yet, the fix doesn't guess which email provider you use. Instead, it presents email provider tabs — Google Workspace, Microsoft 365, Zoho Mail, Fastmail, Protonmail, SendGrid, Amazon SES — each showing the exact include: value to add for that provider. You identify your own stack, pick the right tab, and copy the value.

Then, for adding the record to DNS, a second set of tabs covers each major DNS provider with numbered steps specific to that interface. For Cloudflare:

1. Log in at dash.cloudflare.com and select your domain.
2. Click DNS in the left sidebar.
3. Click Add record.
4. Set Type to TXT.
5. Set Name to @ (root domain).
6. Paste your complete SPF record into the Content field.
7. Leave Proxy status as DNS only (grey cloud). SPF records must never be proxied.
8. Click Save.

If a TXT record starting with 'v=spf1' already exists, click Edit on that
record instead of adding a new one — having two SPF records breaks all email delivery.

For Route53, the instructions include the detail that TXT values must be wrapped in double quotes in the Value field — a provider-specific requirement that isn't documented anywhere in the AWS console UI itself.

The person reading this does not need to know what SPF is, what RFC 7208 says, or how SMTP authentication works. They need to know what to copy and where to paste it. The fix guide is structured to make that possible.

The Provider Tab System, Across Every Check

This isn't limited to SPF. Every fix guide in ZeroHook's 30-point audit follows the same structure: a corrected record or configuration, email provider tabs where relevant, and DNS provider tabs with numbered steps for each interface.

Check	What the fix guide provides
SPF	Corrected record built from your existing one + email provider tabs + DNS provider steps
DKIM	Key generation path at your email provider + DNS provider steps for adding the TXT/CNAME
DMARC	Starter record with correct policy + rollout timeline + DNS provider steps
CAA	CA auto-detected from your SSL certificate + CAA record for that CA + DNS provider steps
MX	Email provider detected from your MX records + correction steps
DNSSEC	Enable signing at your DNS provider + DS record → registrar steps
MTA-STS	Policy file content + hosting instructions + TXT record + DNS provider steps
Blacklist	Direct link to the removal form for the specific list + what to include in the request
SSL expiry	Renewal path for your certificate provider
Subdomain takeover	Delete this specific DNS record — with the exact record name shown

The CAA guide is worth noting specifically: it reads your current SSL certificate to detect which certificate authority issued it, then pre-populates the CAA record with that CA's domain. If you're on Let's Encrypt, the record authorizes letsencrypt.org. If you're on DigiCert, it authorizes digicert.com. You're not choosing from a generic list — the fix is pre-filled from what your certificate already tells the system.

Why Continuous Monitoring Without Fixes Is a Treadmill

Most DNS monitoring tools alert you when something changes or breaks. That is genuinely useful. If your SPF record gets corrupted or someone removes your DMARC policy, you want to know immediately.

But alerting without fixing creates a loop:

Alert fires → Team acknowledges → Ticket opened → DNS person assigned
→ DNS person researches → Fix applied (maybe) → Next alert fires

At SMB scale, the "DNS person" is often whoever has the registrar login. The research step is where the fix dies. The ticket stays open until it gets closed as stale or until a deliverability problem becomes bad enough to force action.

Continuous monitoring solves the detection problem. Provider-specific fix guides solve the remediation problem. Without both, you have a very good early warning system for problems that don't get fixed.

The Economics of Staying Broken

Here is what a persistent DNS misconfiguration actually costs.

An e-commerce company sending 10,000 transactional emails per month with a 15% spam rate is losing roughly 1,500 emails to spam folders. If those emails contain order confirmations, shipping notifications, and password resets, the downstream effects are customer service contacts, abandoned carts, and churn from users who assume the product is broken.

Industry estimates put the revenue impact of a 1% deliverability improvement at $10,000–$100,000 per year depending on email volume and order value. A 15% spam rate is not a 1% problem.

The audit tool that tells you something is wrong but doesn't tell you how to fix it contributes nothing to that number. It identifies the cost without reducing it.

A fix takes five minutes with the right instructions. The fix is worth five minutes.

TL;DR

Most DNS audit tools were built for engineers — the output assumes you already know how to fix what they find
The fix is non-trivial to generate — it depends on your existing records, your email sending stack, and your DNS provider's specific interface conventions
No major competitor builds the provider-specific fix database — it requires ongoing maintenance investment with no direct revenue justification for tools selling to enterprise teams
The right approach is not to guess your stack — email provider tabs let you identify which include: values apply to your own setup; DNS provider tabs give you numbered steps for the interface you're actually looking at
CAA and MX guides go one step further — they read your existing certificate and MX records to pre-fill the correct values before you touch anything
Monitoring without remediation is a treadmill — alerts tell you something is broken; fix guides tell you what to type
See it on your own domain, free: zerohook.org

*Part of an ongoing series on DNS security and email deliverability.

SecurityScorecard vs. ZeroHook: Enterprise Security at 82% Less Cost

Regő Botond Ronyecz — Thu, 28 May 2026 20:17:14 +0000

The sales call goes well. The SecurityScorecard demo is polished. The dashboards are impressive. Then the quote arrives: $26,000 per year.

For an enterprise with a dedicated security team and a compliance budget measured in six figures, that number is unremarkable. For an SMB trying to pass a NIS2 audit or satisfy a customer security questionnaire, it ends the conversation immediately.

The gap SecurityScorecard fills — continuous DNS monitoring, email security validation, compliance reporting — is real. The need doesn't disappear because the price is out of reach. What changes is where you look to fill it.

This is a direct comparison between SecurityScorecard and ZeroHook across the specific capabilities that matter for SMBs: what each monitors, what evidence each produces for auditors, and what you actually pay.

What SecurityScorecard Is Built For

SecurityScorecard was designed as a third-party risk management platform. Its primary use case is not monitoring your own infrastructure — it's giving large enterprises a way to score the security posture of their vendors, partners, and supply chain at scale.

The scoring model assigns letter grades (A through F) to domains based on passive signals: leaked credentials on dark web forums, open ports, DNS misconfigurations, certificate issues, and IP reputation. It's continuous, it's automated, and the dashboards are visually clear.

That's genuinely useful if you're a procurement team at a Fortune 500 company evaluating hundreds of vendors. You need a standardized, comparable score across all of them.

It is a significantly worse fit if what you need is:

To fix your own DNS and email security configuration
To generate compliance evidence for an NIS2 or ISO 27001 auditor
To monitor your own domain continuously and receive actionable alerts
To do any of this at SMB budget levels

SecurityScorecard's passive scoring model tells you that something is wrong. It does not tell you what the DNS record should say, or how to fix it in Cloudflare vs. GoDaddy vs. Route53.

Side-by-Side: What Each Platform Actually Covers

Email Security Monitoring

Check	SecurityScorecard	ZeroHook
SPF record validation	✓ (scored)	✓ (validated + fix provided)
DKIM verification	✓ (scored)	✓ (key strength analysis + fix)
DMARC policy enforcement	✓ (scored)	✓ (policy check + rollout guidance)
BIMI setup validation	✗	✓
MTA-STS configuration	✗	✓
TLS-RPT monitoring	✗	✓
Blacklist monitoring	✓ (some databases)	✓ (50+ databases, real-time)
MX record validation	✓ (scored)	✓ (multiple servers)
Copy-paste DNS fixes	✗	✓ (provider-specific)

The last row is the operational difference. SecurityScorecard shows you a C grade for your DMARC configuration. ZeroHook shows you the exact record to paste into your Cloudflare DNS panel.

For a security team with a DNS engineer on staff, the grade alone is enough to start the fix. For an SMB where the founder or a generalist IT manager is handling DNS, the copy-paste fix is the difference between the problem getting resolved and the problem sitting open for six months.

DNS Security Monitoring

Check	SecurityScorecard	ZeroHook
DNSSEC validation	✓	✓
CAA records	✓	✓
Nameserver configuration and redundancy	✓	✓
CNAME chain analysis	Partial	✓
SOA parameters	✗	✓
TTL optimization	✗	✓
PTR / Reverse DNS	✓	✓
Open resolver detection	✓	✓
DNS performance benchmarking	✗	✓
DANE / TLSA records	✗	✓
Subdomain takeover detection	✓	✓
Zone transfer vulnerability	✗	✓

Compliance Evidence and Reporting

This is where the gap becomes most significant for SMBs going through a formal audit.

Feature	SecurityScorecard	ZeroHook
NIS2 compliance mapping	Partial (vendor risk angle)	✓ (Article 21 direct mapping)
ISO 27001 Annex A mapping	✓	✓
SOC2 CC6.6 mapping	✓	✓
GDPR mapping	✗	✓
PCI-DSS mapping	✗	✓
Tamper-proof audit log	✗	✓ (hash-verified, 365 days)
Auditor PDF export	✗	✓
Auditor portal access	✗	✓
Automated evidence collection	✗	✓
Excel compliance export	✗	✓

SecurityScorecard produces dashboards and score reports. Those are useful for executive presentations and vendor risk reviews. They are not the same as a tamper-proof, timestamped audit log that an NIS2 auditor can verify independently.

NIS2 auditors specifically look for continuous monitoring evidence with an unbroken chain of records. A SecurityScorecard PDF showing your score on a specific date is a point-in-time snapshot. An automated audit log with hash verification covering the past 365 days is continuous monitoring evidence.

The Copy-Paste Fix Differentiator

This deserves its own section because no competitor at any price point offers it.

When SecurityScorecard flags that your SPF record is misconfigured, the remediation workflow is:

Note the finding
Open a ticket for your DNS team (or figure it out yourself)
Research what the correct SPF record should look like for your sending services
Find the right DNS panel for your registrar
Make the change
Wait for propagation and re-scan to confirm

When ZeroHook flags the same issue, the remediation workflow is:

Click the finding
See the exact record to add, formatted for your specific DNS provider (Cloudflare, GoDaddy, Namecheap, Route53, and others)
Copy and paste it
Confirm

The time difference is 2 minutes versus 2 hours if you know what you're doing, or 2 minutes versus "we'll get to it next sprint" if you don't.

At SMB scale, security issues that require specialist DNS knowledge to resolve frequently don't get resolved. The provider-specific copy-paste fix removes the specialist knowledge requirement and puts the fix in reach of whoever manages the domain.

Pricing: The 82% Gap Explained

Platform	Annual Cost	Per Domain
SecurityScorecard (mid-market)	~$26,000/year	High, opaque
ZeroHook Compliance Pro	$4,790/year	From $10/domain/mo
ZeroHook Business Security	$1,430/year	From $15/domain/mo
ZeroHook Deliverability	$470/year	From $29/domain/mo
ZeroHook Free	$0	1 domain

The 82% figure comes from the direct comparison between ZeroHook Compliance Pro ($4,790/year) and SecurityScorecard's mid-market pricing (~$26,000/year). The Compliance Pro tier covers 50 domains continuously, includes the full 30-point audit, tamper-proof audit logs, compliance report generation, auditor portal access, and automated evidence collection.

What SecurityScorecard doesn't include at any price: copy-paste DNS fixes, provider-specific remediation guidance, or a direct path from "flagged issue" to "resolved configuration."

When SecurityScorecard Makes Sense

This comparison isn't arguing that SecurityScorecard is a bad product. It's a good product built for a different problem.

SecurityScorecard is the right choice when:

You're a large enterprise managing third-party vendor risk — you need to score hundreds of external organizations, not fix your own DNS records
You need a standardized score your board or investors recognize — SecurityScorecard grades carry weight in certain enterprise procurement contexts
You're building a vendor risk program from scratch — their platform is built around that workflow
Budget is not a constraint — the product is priced for organizations where $26,000/year is a rounding error in the security budget

ZeroHook is the right choice when:

You need to fix and monitor your own DNS and email security — not score external vendors
You're preparing for a NIS2, ISO 27001, or SOC2 audit — and need compliance-ready evidence, not a dashboard grade
You're an SMB with a budget under $500/month — and need the full capability set, not a stripped-down version
You're an MSP managing multiple client domains — white-label option at $15/domain/month with 300% reseller margin
You need actionable fixes, not just scores — copy-paste DNS remediation included in every paid tier

The MSP Angle: A Category SecurityScorecard Doesn't Serve

SecurityScorecard has no MSP or white-label offering at SMB price points. Their partner program is aimed at large MSSPs and enterprise channel partners.

ZeroHook's white-label tier is explicitly built for IT agencies and MSPs managing 20–500 client domains. At $15/domain/month cost and a recommended resale price of $60+/domain/month, the margin structure is 300% before any service fees.

The deliverables — branded PDF audit reports, per-domain compliance summaries, continuous monitoring alerts — become a product an MSP can sell rather than a tool they use internally. SecurityScorecard offers no equivalent path for a 10-person IT shop managing 50 SMB clients.

How to Run a Direct Comparison Yourself

If you're currently evaluating SecurityScorecard or have a renewal coming up, the fastest way to compare is to run ZeroHook's free tools against your own domain before paying for anything.

ZeroHook's free tier (no credit card, no sales call) gives you:

SPF, DKIM, DMARC validation
Blacklist monitoring
Email Health Score (0–100)
Weekly automated scans
Copy-paste DNS fixes
Basic NIS2 and ISO compliance summary

https://zerohook.org

Start with the DNS Visualizer for a visual map of your current infrastructure:

https://zerohook.org/dns-visualizer

For a quick revenue-impact calculation on your current deliverability rate:

https://zerohook.org/email-roi-calculator

The full 30-point audit and continuous compliance monitoring are on paid tiers starting at $49/month. No enterprise sales process, no custom quote, no minimum contract length.

TL;DR

SecurityScorecard was built for enterprise third-party vendor risk management — it scores external organizations, not to fix your own infrastructure
The 82% cost difference ($26,000 vs. $4,790/year) is real — and the cheaper option includes features the expensive one doesn't: copy-paste DNS fixes, tamper-proof audit logs, and direct NIS2/GDPR/PCI-DSS compliance mapping
Copy-paste provider-specific DNS fixes exist nowhere else at this price point — this is the single most operationally significant differentiator for SMBs
NIS2 auditors want continuous monitoring evidence, not dashboard grades — hash-verified audit logs with 365-day retention satisfy that requirement; a SecurityScorecard PDF does not
MSPs have a clear path with ZeroHook — white-label at $15/domain/month, resell at $60+; SecurityScorecard has no equivalent SMB reseller model
Start for free — zerohook.org gives you SPF/DKIM/DMARC validation, blacklist monitoring, and copy-paste fixes before you spend a dollar

*Part of an ongoing series on DNS security and compliance tools.