NIS 2 Email Security: A Compliance Playbook

The EU Network and Information Security Directive 2 (NIS 2) came into force for essential and important entities on 18 October 2024. Article 21 is the part that matters for anyone running a mail system: it enumerates the cybersecurity risk-management measures covered organizations must implement, and subsection (2)(h) specifically names the use of cryptography and authentication for electronic communications.

National implementations vary, but the underlying control expectation is consistent. This playbook maps the email-security portion of NIS 2 to the specific technical controls that satisfy it, the evidence an auditor will ask for, and the order to roll them out.

The clauses that touch email

NIS 2 does not mention DMARC, SPF, DKIM, MTA-STS, or BIMI by name. It describes outcomes, not implementations. Three clauses drive the email-security program:

• Article 21(2)(g) — basic cyber hygiene practices and cybersecurity training. Phishing is the single largest attack vector against covered entities, so anti-phishing controls live here.
• Article 21(2)(h) — policies and procedures regarding the use of cryptography and, where appropriate, encryption. In the email context this means SPF / DKIM / DMARC for authentication and MTA-STS / TLS-RPT for transport encryption.
• Article 21(2)(i) — human resources security, access control policies, and asset management. Brand impersonation attacks target staff; monitoring for lookalike domains feeds into the detection half of this clause.

The control mapping

Here is the concrete list of controls, in rollout order. Each maps back to at least one clause above.

1. SPF in hard-fail mode (-all)

Publishes which servers are authorised to send as your domain. Without SPF, any server on the internet can claim to be yours and most receivers will do nothing about it. Hard-fail (-all) tells compliant receivers to reject unauthorised senders.

Auditor evidence: the SPF TXT record terminates in -all; the total DNS lookup count stays under 10 (RFC 7208 cap); you have no stale include: entries for services you no longer use. Our SPF checker counts lookups automatically.

2. DKIM signing on every outbound path

DKIM cryptographically signs each outbound message so receivers can verify it was not altered in transit. Every sender (marketing platform, transactional platform, ticketing system) needs its own DKIM selector published under your domain.

Auditor evidence: a published _domainkey selector for each sender, keys at RSA-2048 or higher, no selectors with empty p= tags (which revoke signing), and no t=y test-mode flags left on production selectors. Use the DKIM checker to verify.

3. DMARC at p=reject

DMARC is the policy layer that ties SPF and DKIM together. p=reject means receivers block mail that fails authentication; p=quarantine means spam folder; p=none is monitoring-only and satisfies nothing.

Auditor evidence: published DMARC record with p=reject, a monitoring inbox in rua= that ingests aggregate reports, and 30+ days of report retention showing no recent authentication failures. Roll out in order: none → quarantine → reject, not straight to reject.

4. MTA-STS in enforce mode

MTA-STS forces sending servers to deliver only over TLS, blocking downgrade attacks. It is two pieces: a DNS TXT record announcing the policy, and a policy file served over HTTPS with a valid certificate.

Auditor evidence: the _mta-sts DNS record and the /.well-known/mta-sts.txt file both resolve; mode: enforce is set; the MX hosts listed match your actual MX records; max_age is at least 604800 (7 days) in production. Our MTA-STS checker fetches both sides.

5. TLS-RPT for failure visibility

TLS-RPT tells receivers where to send nightly reports of TLS handshake failures. Without it, a silent downgrade can go undetected for months.

Auditor evidence: published _smtp._tls record with a rua= endpoint, and evidence of a daily report pipeline (an inbox or ingest endpoint).

6. Continuous lookalike-domain monitoring

The authentication-layer controls stop attackers from spoofing your domain directly. They do not stop attackers from registering yourbrand-support.com and phishing from that. This is a separate detection problem: who has registered domains that look like yours, in the last 24 hours, and what are they doing with them?

Auditor evidence: documented monitoring process covering at minimum typosquat variants, TLD swaps, homoglyph substitutions, and certificate-transparency-sourced domains; alert triage records showing confirmed phishing detections and the takedown outcome.

The evidence package an auditor expects

For the annual review (or the incident response retrospective when something fails), prepare a four-part binder:

1. Current state snapshot. DNS records as of today: SPF, DKIM selectors, DMARC, MTA-STS policy, TLS-RPT. Screenshot each from an independent lookup tool, not your own admin panel. Auditors want third-party evidence.
2. Aggregate DMARC reports. At least 90 days of reports covering every production-sending IP. The story the reports tell should match the story your sending-domain inventory tells. Unexplained senders are the exception that needs an explanation.
3. Lookalike detections. A log of every suspicious domain the monitoring flagged, classified (registered lookalike, suspected impersonation, confirmed phishing), and for the confirmed cases, evidence of the takedown action filed.
4. Incident retrospectives. When authentication failed (a marketing platform fell off SPF; a DKIM key rotation broke signing), what happened, how long the gap lasted, what recipients saw, and how you closed it.

Where PhishFence fits

The authentication-layer controls (1-5 above) are free to implement — DNS changes on your existing domains. The continuous-monitoring control (6) is where a tool earns its place. PhishFence handles continuous lookalike-domain monitoring, DMARC aggregate-report ingestion, and the takedown workflow out of the box. The audit log export available on the Business plan produces the fourth-item-in-the-binder automatically.

None of this substitutes for a qualified legal or audit review against your specific national NIS 2 implementation. What it does give you is an evidence-rich starting point that covers the email-security surface most compliance programs under-invest in.