NIS2 and Transactional Email: A Technical Checklist for Engineering Teams

TL;DR

• NIS2 makes your email integration part of your compliance evidence. Article 21 of Directive (EU) 2022/2555 covers encryption, access control, MFA, incident handling and business continuity. Each of them touches how your application sends email.
• Who is in scope: Essential and Important entities across 18 EU sectors, typically from 50 employees or €10M turnover. Their suppliers get pulled in through contracts.
• What engineering owns: SPF, DKIM and DMARC on sending domains, TLS on every hop you control, API keys kept out of code and rotated, 2FA and IP restrictions on the provider panel, delivery event logging, and a fallback path for outages.
• The clock: an early warning within 24 hours of becoming aware of a significant incident, a notification within 72 hours, and a final report within one month. A leaked SMTP credential can start that clock.

Most NIS2 content is written for compliance officers. An auditor will ask how your organization secures its communications. For email, the answer usually sits in a code repository, a DNS zone and a provider dashboard, which makes it an engineering question.

This guide turns Article 21 into concrete tasks for teams that own a transactional email integration: password resets, order confirmations, alerts and invoices. It covers what NIS2 requires, which measures touch your sending stack, how to harden it and what to do when something goes wrong.

If you’re assessing messaging vendors across channels (SMS, push, email, RCS and OTT apps), MessageFlow covers the procurement side in its NIS2 supply chain guide.

NIS2 in two minutes

NIS2 (Directive (EU) 2022/2555) replaced the original NIS Directive and entered into force in January 2023. Member states had until 17 October 2024 to transpose it, and most major EU economies have now done so or are close.

The directive sets two tiers of covered entities:

• Essential entities: energy, transport, banking, health, digital infrastructure, public administration and space. Typically 250 or more employees, or turnover above €50M.
• Important entities: postal and courier services, waste management, chemicals, food, manufacturing, digital providers and more. Typically 50 or more employees, or turnover above €10M.

The European Commission estimates that NIS2 covers over 160,000 organizations, up from roughly 10,000 under NIS1. Falling below the thresholds doesn’t always mean you’re out. If your customers are in scope, their supplier assessments will likely reach you.

Penalties (Art. 34) go up to €10M or 2% of global annual turnover for Essential entities, and €7M or 1.4% for Important entities. Management bodies must approve and oversee the measures, and they can be held liable for failures (Art. 20).

Where Article 21 meets your email stack

Seven of the ten measures in Article 21(2) turn directly into engineering work on a transactional email integration. The other three cover risk policy, effectiveness reviews and training. Those stay with security and compliance.

Article 21(2) measure	What it means for transactional email	Evidence to keep
(b) Incident handling	Detect credential abuse, sending spikes and authentication failures	Alert rules, event logs, incident runbook
(c) Business continuity and disaster recovery	Critical email keeps flowing, or degrades predictably, during provider or network outages	Queue and retry design, fallback route, failover test results
(d) Supply chain security	Your email provider is an ICT supplier you have to assess	Provider certificates, DPA, completed security questionnaire
(e) Secure development and maintenance	Integration code, SDKs and templates go through your normal SDLC and vulnerability handling	Code review records, dependency scanning
(h) Cryptography and encryption	TLS on SMTP submission and API calls, managed DKIM signing keys	TLS configuration, DKIM key length and rotation log
(i) Access control and asset management	Who holds API keys and panel access, plus an inventory of sending domains and keys	Key inventory, access reviews, offboarding records
(j) MFA and secured communications	2FA on the provider panel, authenticated email	2FA policy, published DMARC policy

NIS2 doesn’t name SPF, DKIM or DMARC. Article 21 asks for risk management of communication channels, and these three standards are the common technical answer to domain spoofing, so auditors tend to ask about them.

Hardening your email integration: Five areas

These five areas cover most of what an auditor will ask about your sending setup. Each one also leaves evidence you can file.

1. Authenticate every sending domain

• SPF: list only the services that send on your behalf, and stay under the 10 DNS lookup limit.
• DKIM: use 2048-bit keys. Rotate them on a schedule, and immediately after any suspected exposure.
• DMARC: start at p=none with aggregate reporting (rua). Move to quarantine, then to reject once all legitimate sources pass.
• Subdomains: send transactional and marketing email from separate subdomains. An incident or a reputation drop on one then stays off the other.

mail.example.com.         TXT  “v=spf1 include:<your-provider-spf-domain> ~all”

_dmarc.mail.example.com.  TXT  “v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=s; aspf=s”

2. Encrypt every hop you control

• Call the email API over HTTPS only.
• For SMTP, submit on port 587 with STARTTLS required, or on port 465 with implicit TLS. Don’t let your application fall back to plaintext.
• Consider publishing MTA-STS and TLS-RPT for your domains. MTA-STS enforces TLS for mail coming in to you, and TLS-RPT sends you reports when delivery over TLS fails.
• Encrypt stored templates and logs that hold personal data.

3. Treat credentials as secrets

• Keep API keys and SMTP passwords in a secrets manager or CI vault. They should never be in the repository or in committed .env files.
• Issue separate keys per environment and per service. A leak then exposes less, and you can revoke one key without stopping all sending.
• Rotate keys on a schedule and whenever someone with access leaves.
• Turn on 2FA for every user of the provider panel, and restrict panel and API access to known IP addresses.
• Add secret scanning to CI so leaked keys are caught before they reach a shared branch.
• Review who has production sending access at least once a quarter.

4. Log delivery events and watch for anomalies

• Consume your provider’s delivery webhooks (delivered, bounced, deferred, complaint) and send them to your central logging or SIEM.
• Set alerts for:
  • volume spikes outside normal patterns
  • sending from unknown IP addresses
  • a sudden rise in hard bounces
  • new sources appearing in DMARC aggregate reports
  • repeated failed logins to the panel
• Set a log retention period that fits both your security policy and GDPR data minimization. Recipient, timestamp, status and message ID usually cover it.

5. Plan for provider or network outages

• Queue outbound email and retry with exponential backoff. Use message IDs or idempotency keys so retries don’t produce duplicates.
• Put critical flows (2FA codes, password resets) on a separate queue from bulk notifications.
• Add a circuit breaker and a fallback route, such as an alternate endpoint (API or SMTP) or a secondary provider for critical messages.
• Test failover at least once a year and keep the results. That record is your BCP/DRP evidence for Art. 21(2)(c).

When something goes wrong: A leaked API key and the 24-hour clock

A leaked email credential is one of the likelier ways NIS2 incident reporting lands on an engineering team. Picture a production API key pushed to a public repository. Within hours, someone uses it to send phishing from your verified domain to your customers.

Whether that counts as a significant incident depends on its impact (Art. 23(3)): serious operational disruption, financial loss, or considerable damage to others. Phishing sent to customers from your own domain can meet that bar. A typical runbook:

1. Revoke the key and issue a new one through your secrets manager.
2. Pause or rate-limit sending from the affected key or domain.
3. Pull the logs: what was sent, to whom, from which IP addresses and since when.
4. Notify your security lead right away. The 24-hour window starts when the organization becomes aware of the incident, not when the investigation ends.
5. If the incident is significant, send an early warning to your CSIRT or competent authority within 24 hours, an incident notification within 72 hours, and a final report within one month (Art. 23(4)).
6. Afterwards, find out how the key leaked, add the missing control (secret scanning, narrower key scope) and document the change.

If personal data was exposed, check your GDPR breach notification duty as well. It has its own 72-hour deadline.

NIS2 email security checklist

The left column is work your team does. The right column is what to collect from your email provider.

Your integration	Your email provider
☐ SPF, DKIM (2048-bit) and DMARC at enforcement on every sending domain	☐ ISO 27001 / SOC 2 certification, current and covering the services you use
☐ TLS-only API and SMTP submission	☐ TLS support and encryption of stored data
☐ API keys in a secrets manager, separate per environment, rotated	☐ 2FA and IP restrictions available for panel and API access
☐ 2FA enforced for every panel user	☐ Data processed in the EEA, with named locations
☐ Delivery webhooks logged centrally, with anomaly alerts	☐ Incident notification terms that fit your 24h/72h obligations
☐ Incident runbook covering leaked credentials	☐ Delivery SLA, plus BCP/DRP documentation
☐ Queue, retry and fallback route for critical email, with a tested failover	☐ Signed GDPR data processing agreement
☐ Inventory of sending domains, keys and their owners	☐ Willingness to answer security questionnaires and support audits

A few practical points when you collect provider evidence:

• Check the certificate’s scope. It should cover the services you use, not only part of the provider’s operations.
• Ask for specific locations. “Data stays in the EEA” should come with country or region names.
• Put notification timing in the contract. Your 24-hour window runs from detection, not from when your provider tells you.

How EmailLabs supports NIS2 readiness

Your email platform covers part of the evidence trail. Here is what EmailLabs provides:

• Sender authentication: SPF, DKIM and DMARC configuration, plus BIMI support.
• Encryption in transit: TLS support for message delivery.
• Account protection: 2FA by SMS, mobile app or hardware key, and IP authorization that limits access to approved addresses.
• Abuse monitoring: detection of unusual sending patterns and unauthorized access, with dynamic thresholds and sending limits.
• Dedicated IP addresses on Pro and Enterprise plans, which keep your sending reputation separate from other senders.
• GDPR data processing agreement, with the panel storing only the data it needs: sender and recipient addresses and the message subject.
• ISO 27001 / SOC 2 certification.
• Data processed exclusively in the EEA, within Germany and Poland.

Next steps: Three things to do this quarter

1. Take inventory. List every sending domain, API key and SMTP credential, the services that use each one and who owns it.
2. Close the gaps. Move DMARC to enforcement, put keys in a vault, turn on 2FA and IP restrictions, and route delivery webhooks to your logging.
3. Package the evidence. Gather DNS records, the key inventory, alert rules, failover test results, provider certificates and the signed DPA in one place before the audit, not during it.

Teams that start early have time to fix what they find. Teams that wait end up collecting evidence under deadline pressure.

FAQ: NIS2 and email security

Does NIS2 require DMARC?

Not by name. Article 21 requires risk management of communication channels and secured communications. SPF, DKIM and DMARC are the widely accepted technical way to meet that for email, so auditors commonly check for them.

Does NIS2 require TLS for email?

Article 21(2)(h) requires policies on cryptography and encryption. In practice, that means TLS for data in transit, including SMTP submission and API calls to your email provider.

Is my email service provider covered by NIS2?

That depends on the provider’s own sector and size. For your organization, it’s an ICT supplier either way, and you have to assess it under Article 21(2)(d).

Is a leaked API key a reportable NIS2 incident?

It is if the incident is significant: it caused or could cause serious operational disruption or financial loss, or considerable damage to others. Phishing sent from your domain to customers can meet that threshold.

What are the NIS2 incident reporting deadlines?

An early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report within one month of the notification.

What is the penalty for non-compliance with NIS2?

Up to €10 million or 2% of global annual turnover for Essential entities, and up to €7 million or 1.4% for Important entities. Management bodies can also be held liable.