ZeroHookZeroHook
Back to Blog

NIS2 Email Security Checklist (2026)

Article 21 asks for transmission security you can prove. This checklist maps SPF, DKIM, DMARC, and monitoring to what EU auditors actually request.

ZeroHook TeamJun 23, 2026~10 min read
NIS2 Email Security Checklist (2026)

Your auditor opens with a question that sounds simple: "Show me how you secure email transmission for your domain." You hand them a screenshot of your SPF record from 2022. They ask for DMARC aggregate reports from the last 90 days. You don't have them. They ask whether DNS changes are monitored continuously or checked once a year before the audit. The room gets quiet. A 62-person logistics company in Rotterdam hit this in February 2026 during a NIS2 readiness review. They had MFA on Microsoft 365, endpoint protection, and a firewall refresh project. Email DNS was "done" because IT published SPF when they migrated to M365 in 2021. DMARC was never published. MTA-STS did not exist. Nobody could produce tamper-proof evidence that mail-related DNS had been watched between audits. NIS2 (EU Directive 2022/2555, transposed by member states with enforcement rolling through 2024-2026) does not list "SPF record" in Article 21 by name. It requires appropriate technical and organizational measures for network and information systems, including transmission security and incident handling. In practice, EU auditors and cyber insurers map those obligations to email authentication, encrypted transport, DNS integrity, and provable monitoring. If you cannot show it, you cannot claim it. This is the nis2 email security requirements checklist we use when a regulated SMB asks what to fix before the next assessment. Not theory. DNS records, monitoring cadence, and evidence artifacts.

Who NIS2 Covers in 2026 (And Why Email DNS Shows Up First)

Essential and important entities

NIS2 expands cybersecurity obligations beyond the old NIS Directive scope. Member states classify organizations as essential or important entities based on sector and size. Sectors include energy, transport, banking, health, digital infrastructure, public administration, and more. Important entities often include mid-market manufacturers, MSPs, food distributors, and B2B SaaS vendors that never thought of themselves as "critical infrastructure."

The European Commission's NIS2 implementation tracker (updated through 2025) shows all 27 member states had transposed the directive; enforcement timelines vary, but 2026 is the year fines and supervisory action stop being theoretical for many SMBs.

Why auditors start with email

Email is still the primary exfiltration and fraud path for SMB breaches. Article 21 measures must address risks to network and information systems. Unauthenticated mail (missing or broken SPF/DKIM/DMARC) is both a spoofing risk and a transmission integrity gap. Auditors know it. It is easier to verify than your SIEM correlation rules.

Warning
Being "out of scope" for NIS2 does not mean your customers are. If you process data for an essential entity, their vendor questionnaires will ask for your DMARC posture anyway.

Article 21: What "Transmission Security" Means for Mail

Article 21(2) lists measure types: policies on risk analysis, incident handling, business continuity, supply chain security, security in acquisition and development, and policies on cryptography and human resources. Paragraph 2(g) explicitly references encryption where appropriate.

For email infrastructure, assessors typically expect:

  • Sender authentication (SPF, DKIM, DMARC with a documented policy path)
  • Transport encryption posture (TLS on SMTP paths, often validated via MTA-STS and TLS-RPT)
  • DNS integrity controls (no dangling records, CAA where applicable, change detection)
  • Evidence that controls are monitored over time, not point-in-time screenshots

What Article 21 does not require verbatim

No EU text says "publish p=reject by Q3." Enforcement is risk-proportionate. A 12-person consultancy and a regional hospital face different bars. But both need documented measures and evidence they operated in the assessment period.

Pro Tip
Map each checklist item below to a row in your risk register. Auditors trust controls tied to identified risks more than a DNS record pasted into a slide deck.
“A one-time SPF check is a photograph. NIS2 wants the security camera footage.”

The NIS2 Email Security Checklist (2026)

Work through these in order. Authentication before enforcement. Monitoring before you claim continuous compliance.

1. SPF published and valid

Root domain TXT includes v=spf1 with all authorized senders (M365, Google Workspace, ESP includes) and hard fail -all on production sending domains.

Check: no PermError (10 lookup limit), no duplicate SPF TXT records, no +all.

Quick fix reference: zerohook.org/fix/spf-permerror

2. DKIM signing enabled on all sending paths

Every system that sends as your domain signs with a published selector. M365: selector1/selector2 CNAMEs. Google Workspace: google._domainkey. ESPs: provider CNAME/TXT as documented.

Check: test message Authentication-Results shows dkim=pass for your domain.

3. DMARC published with aggregate reporting

_dmarc.yourdomain.com TXT exists with v=DMARC1, rua= to an address you actually read, and a documented policy roadmap (none → quarantine → reject).

Check: you can produce at least 30 days of aggregate XML or a parsed summary.

4. DMARC alignment on primary mail flows

Marketing ESP, transactional SaaS, and corporate M365/Google mail all achieve dmarc=pass on test sends. Alignment failures are tracked and remediated.

Quick fix reference: zerohook.org/fix/dmarc-alignment-failed

5. MTA-STS policy for inbound mail

DNS record at _mta-sts.yourdomain.com plus HTTPS policy file enforcing TLS for inbound SMTP to your domain.

Check: policy mode enforce or documented timeline to enforce after testing.

6. TLS-RPT reporting enabled

_smtp._tls.yourdomain.com publishes a reporting address. Someone reviews TLS failure reports quarterly minimum.

7. Outbound mail encryption posture documented

Document which systems send mail, which ports, and whether TLS is required/opportunistic. PCI-DSS v4.0 Requirement 4.2.1 (effective March 2025) and ISO 27001:2022 Annex A 8.24 both expect protection of information in transit; email is in scope for most cardholder and PII environments.

8. DNS change monitoring (continuous)

SPF, DKIM, DMARC, MX, and MTA-STS records are monitored on a defined cadence (daily or better for production domains). Changes trigger review within 24 hours.

Point-in-time scans before audit season fail the "continuous" question.

9. Blacklist and reputation monitoring

Domain and sending IPs checked against major DNS blocklists. Delisting procedures documented.

10. Subdomain and dangling DNS audit

Inventory of all subdomains that send or receive mail. No orphaned CNAMEs pointing at deprovisioned SaaS (common subdomain takeover path).

11. Incident playbooks for mail abuse

Documented steps if your domain is spoofed, listed on a blocklist, or if DMARC reports show an unknown sender above threshold.

12. Evidence retention with integrity

Audit logs, scan results, and remediation tickets retained for the period your auditor specifies (often 12 months minimum; regulated sectors may require longer). Excel exports on a shared drive are weak evidence; hash-verified or immutable logs are stronger.

13. Supply chain mail security for vendors

Critical vendors who send as your domain (payroll, e-sign, marketing) listed with their authentication method and review date.

14. Executive attestation cadence

Someone with authority reviews mail security posture quarterly. Paper trail: meeting notes or signed compliance summary.

Pro Tip
Free DNS tools at zerohook.org/spf-checker and zerohook.org/dmarc-checker cover items 1-4 for a single point-in-time baseline. Continuous monitoring and evidence export require a paid workflow.

Mapping Checklist Items to Frameworks Auditors Name

Assessors rarely say "fix your SPF." They cite framework controls.

Your controlCommon auditor reference
NIS2 Article 21(2) risk-based measuresTransmission security, incident detection
ISO/IEC 27001:2022 Annex A 8.5Secure authentication
ISO/IEC 27001:2022 Annex A 8.24Use of cryptography / transmission
SOC2 CC6.6Logical access and transmission security
GDPR Article 32Security of processing (appropriate technical measures)

You do not need separate DNS for each framework. One well-monitored authentication stack supports multiple attestations if evidence is mapped correctly.

We've seen teams maintain four spreadsheets for four frameworks. One monitoring export with control tags beats four stale screenshots every time.

Implementation Order (90 Days)

1

Week 1-2: Baseline every production domain. Run SPF, DKIM, DMARC, MX, and MTA-STS checks. Log failures in a single tracker (domain, check, owner, due date). In Cloudflare, DNS records live under the domain's DNS tab; export a CSV for your asset inventory.

2

Week 3-4: Fix authentication gaps before policy enforcement. Publish DMARC at p=none with rua= if missing. Enable DKIM on M365 (Admin center → Domains → DKIM → publish CNAMEs) or Google Workspace (Admin → Gmail → Authenticate email). Add ESP includes to SPF.

3

Week 5-8: Turn on aggregate report collection. Parse RUA weekly. Fix alignment failures. Stage DMARC to p=quarantine with pct=25, then increase. See zerohook.org/blog/dmarc-p-reject-rollout-8-weeks for the full rollout path.

4

Week 9-10: Publish MTA-STS and TLS-RPT. Start in testing mode for MTA-STS if you have legacy inbound relays; move to enforce when TLS failures are understood.

5

Week 11-12: Enable continuous monitoring on all in-scope domains. Define alert recipients and response SLA. Export first monthly evidence pack (scan history, change log, remediation tickets).

6

Week 13: Tabletop exercise. Simulate domain spoofing or blocklist listing. Time how long until detection and documented response. Gaps go into the risk register.

What Evidence Auditors Actually Request

Minimum viable evidence pack

  • Current DNS exports for SPF, DKIM, DMARC, MTA-STS (dated)
  • 90 days of DMARC aggregate summaries with pass/fail trends
  • Monitoring alert history showing at least one detected change and response
  • Change tickets linked to DNS modifications
  • Named owner for mail security posture (job title, not just "IT")

Strong evidence (reduces follow-up questions)

  • Tamper-verified audit log of monitoring results
  • Auditor read-only portal access to monitoring history
  • Generated PDF mapping controls to NIS2 Article 21 and ISO Annex A clauses
  • Excel export with domain-level scores over time

Agency tier ($89/month) covers multi-domain monitoring and basic compliance summaries. Full automated evidence collection, auditor PDFs, and 365-day tamper-proof logs sit on Compliance Evidence Pack ($199/month, $1,910/year). That is roughly 82% below SecurityScorecard-style enterprise ratings (~$26,000/year benchmark on pricing materials) while producing DNS-specific artifacts assessors can verify.

What fails reviews

  • "We check DNS before audits" with no dated history
  • DMARC p=none for 3+ years with no enforcement roadmap
  • Marketing sends through an ESP that is not in the SPF record
  • No named person accountable for DMARC report review

Fine Exposure vs Cost of Compliance

NIS2 sets maximum fines at €10 million or 2% of global annual turnover for essential entities, and €7 million or 1.4% for important entities, whichever is higher (per Directive 2022/2555). Member state implementation varies; the point is not the theoretical maximum but supervisory appetite in your jurisdiction in 2026.

Compare that to continuous compliance tooling:

  • Manual NIS2 readiness consulting: often $2,000-$5,000 for a one-time assessment (market range cited on compliance pricing pages)
  • ZeroHook Evidence tier: $1,910/year with monitoring, exports, and copy-paste DNS fixes
  • Cost of one successful BEC fraud via spoofed domain: FBI IC3 reported $2.9 billion in adjusted losses from business email compromise in 2023 (latest full-year IC3 report; 2024 edition showed similar order of magnitude)

Honestly, the fine is not always the first hit. Losing a enterprise renewal because your customer's vendor questionnaire flagged missing DMARC hurts sooner.

Common Mistakes We Still See in 2026

Treating M365 as "handled by Microsoft"

Microsoft secures their infrastructure. Your DNS records for your domain are still your problem. DKIM off by default until you publish CNAMEs.

Separate marketing subdomain with no DMARC

mail.yourdomain.com sends campaigns without its own SPF/DKIM/DMARC while root domain is "compliant." Auditors notice.

Evidence in personal inboxes

DMARC reports to a former employee's mailbox for 18 months. Continuous monitoring with team access fixes that.

Copy-pasting a consultant's template without ownership

A PDF checklist in SharePoint that nobody updates is not a measure. It is paperwork.

Frequently Asked Questions

Does NIS2 require DMARC p=reject?

No specific policy value is mandated. Article 21 requires risk-appropriate measures. Published DMARC with enforcement roadmap and alignment on legitimate mail is the defensible posture. p=none alone after years of operation is hard to defend as "appropriate" in 2026.

How often should we scan email DNS for NIS2?

Align cadence to risk. Daily monitoring for production domains is what SOC2 CC6.6-style "continuous" reviews increasingly expect. Annual scans satisfy almost nobody except the person who only runs the scan.

Is Gmail's 2024 bulk sender rules the same as NIS2?

No. Google's requirements are deliverability enforcement for mail to Gmail/Yahoo. NIS2 is EU legal obligation for in-scope entities. They overlap technically (SPF, DKIM, DMARC) but compliance with Google does not satisfy NIS2 evidence requirements by itself.

Can we use free tools only?

For baseline checks, yes (zerohook.org/dns-visualizer, SPF/DMARC checkers). For audit evidence over 90+ days with change history and exportable reports, you need retained monitoring data. Screenshots age out fast.

What if we are an MSP managing client domains?

Document which party owns DNS versus which operates mail. MSPs often need white-label monitoring per client domain with separate evidence exports. Agency tier supports multi-domain portfolios; Evidence tier adds auditor-ready packs per tenant if required.

Key takeaways

1

NIS2 Article 21 does not name SPF, but transmission security assessments converge on email authentication and provable monitoring.

2

Work the 14-item checklist in order: authenticate, report, enforce DMARC gradually, add MTA-STS/TLS-RPT, then continuous evidence.

3

Point-in-time DNS screenshots fail audits. Retained monitoring history with owners and remediation tickets passes.

4

Fine exposure is real; vendor questionnaire failure and BEC fraud often arrive first.

5

One monitoring stack can map evidence to NIS2, ISO 27001, SOC2, and GDPR Article 32 if tagged correctly.

For the full NIS2 control mapping and monitoring workflow, start at zerohook.org/nis2-guide — then baseline your domains before the next auditor asks for 90 days of proof.

Share this analysis

Help others discover this content

About the author

ZeroHook Logo
ZeroHook Team
Security Analysts

The ZeroHook Team tracks NIS2, ISO 27001, SOC2, and GDPR evidence requirements for EU SMBs. We write what auditors actually ask for, not what vendor decks claim.

Automate NIS2 DNS evidence
Compliance Evidence Pack maps 35 audit checks to NIS2, ISO 27001, and SOC2 controls from $199/month.
View pricing