\chapter{Legal Responsibility of Domain Owners}
The use of email as a critical infrastructure component for business communications has created a complex legal framework governing domain owner responsibilities regarding email security. As spoofing attacks demonstrate increasing sophistication and financial impact, legal systems worldwide are grappling with questions of liability allocation, duty of care standards, and the evidentiary role of authentication records. This chapter examines the regulatory landscape, establishing legal responsibilities, case law trends, and practical compliance frameworks that define the contemporary legal environment surrounding email spoofing prevention.

\section{Regulatory frameworks}
\subsection{GDPR}
The General Data Protection Regulation (GDPR) establishes comprehensive data protection obligations that encompass email communications security, creating duties for domain owners to implement appropriate technical and organizational measures. 
The "accountability" principle, specified in Article 5(2), requires the implementation and demonstration of data protection "by design" and "by default". Encryption and pseudonymization are explicitly cited as technical measures organizations can employ to minimize potential damage in the event of unauthorized access \cite{gdpr.eu}.

GDPR does not explicitly mandate specific email protocols such as DMARC, but instead establishes an implicit protection to protect personal data transmitted via email. Article 32 \cite{art32} specifies that if spoofing leads to a personal-data breach (e.g., staff fooled, credentials stolen, systems compromise), regulators may judge that failing to adopt widely recommended controls (like DMARC/SPF/DKIM, monitoring of DMARC reports, etc.) fell short of "appropriate security", exposing to regulatory action and damages claims. 

The GDPR establishes a specific regulatory framework for data protection, but liability arising from spoofing-related incidents cannot be reduced exclusively to data protection law. The legal foundation of responsibility must be analyzed within the broader framework of civil liability, both extracontractual (tort-based) and, where applicable, contractual.
Under Article 82 \cite{art82}, "\textit{any person who has suffered material or non-material damage as a result of an infringement of the Regulation has the right to receive compensation from the controller or processor}". However, this article operates within a structured liability model where the claimant must demonstrate: an infringement of the GDPR, damage, and a causal link between infringement and damage. The controller may avoid liability if it proves that it is not in any way responsible for the event giving rise to the damage.
Accordingly, the key legal question is not merely whether DMARC was implemented, but whether the domain owner complied with the standard of reasonable technical diligence applicable at the time of the incident.


A critical issue concerns whether failure to configure DMARC constitutes negligence per se (violation of established technical rules) or remains within the domain of discretionary technical judgment.
At the moment, DMARC is standardized by RFC 7489 \cite{dmarcRFC}, recommended by cybersecurity agencies (e.g., ENISA), required in certain national frameworks (e.g., ACN Email Authentication Framework), but it is not universally mandated by statute in all contexts.
Therefore, its legal qualification depends on the sector involved, the size of the organization, the foreseeability of spoofing risk and the availability and proportionality of the implementation. 
The failure to implement DMARC may increasingly be interpreted as a deviation from industry standards in sectors where email fraud risk is well-known (e.g., finance, public administration). Nevertheless, outside regulated sectors, it may still be evaluated under the flexible standard of “reasonable technical discretion.”

This nuanced approach avoids overstating DMARC as an automatic minimum legal requirement while recognizing its growing normative weight.


\subsection{ePrivacy}
The ePrivacy Directive (2002/58/EC) and Regulation \cite{eprivacy} establishes specific requirements for security of electronic communications, complementing GDPR requirements with additional protections for communications confidentiality. This directive imposes an obligation on companies that utilise electronic means of communication to implement security measures in order to protect personal data against accidental loss, destruction or damage, with a view to preventing the tampering of such communications by malicious users. ePrivacy Directive prohibites the use of false identities in electronic communications, establishing a legal basis for requiring accurate senders identification. 

Furthermore, the Directive requires companies to obtain explicit consent before sending marketing communications via email and mandate implementation of unsubscribe mechanisms. These security measures must be proportionate to the risk of unauthorized access; thus, the responsibility for determining the proportionality falls on the domain owner. This approach creates a legal framework where domain owners must assess their email communication risk profiles and implement authentication measures accordingly. The combination of privacy protections and authentication requirements effectively transforms email domain ownership into a responsibility requiring active security management rather than passive acceptance of default mail server configurations.



\subsection{Email Authentication Framework (ACN)}
The Italian Agenzia per la Cybersicurezza Nazionale published a comprehensive Email Authentication Framework establishing specific requirements for email security, specifying the mandatory implementation of SPF, DKIM and DMARC. The ACN framework emphasizes that proper configuration of these protocols drastically reduces the likelihood of successful fraudulent email delivery. Furthermore, the framework positions email authentication as a prerequisite for risk reduction across all other email security domains, which means that, without proper authentication infrastructure, organizations cannot effectively implement layered security approaches. \cite{acn}

\subsection{NIS2}
The NIS2 Directive \cite{nis2} is a cybersecurity framework aimed at strengthening the security standards in EU countries and organizations, thus providing a high level of security for networks and information systems.
This Directive introduces cybersecurity obligations for specific categories of entities classified as:
\textbf{Essential} entities and \textbf{Important} entities.
First are typically large enterprises operating in highly critical sectors whose disruption could cause severe cascading effects. Sectors include energy, healthcare, banking, transport, drinking/waste water, and core digital infrastructure. The latter generally encompass medium-sized enterprises in the highly critical sectors, as well as medium and large enterprises in other critical sectors such as postal services, waste management, chemical manufacturing and food production and distribution.
There are Entities falling within the Directive’s scope and Organizations outside its scope.

For essential and important entities, email authentication controls such as SPF, DKIM, and DMARC can potentially be regarded as risk management measures, especially where the risk of spoofing impacts service continuity or public trust. Failure to implement these controls may potentially be regarded as non-compliance with Article 21 risk management obligations.

Article 21 \cite{art21nis2} requires these entities to implement “\textit{appropriate and proportionate technical, operational and organisational measures}” to manage risks to network and information systems. 
Risk management measures must be implemented by companies, that need also to report incidents and be compliant with cybersecurity standards. NIS2 represents the most explicit regulatory framework, mandating email security measures using specific protocols. 
Since NIS2 requires the implementation of security measures by design and by default, email authentication protocols (SPF/DKIM/DMARC) are a great example of security-by-design controls for communications, for this reason the implementation of DMARC can be seen as a proportionate technical measure mandated by NIS2. In particular, companies that send more than $5,000$ emails per day will have to implement these protocols to maintain email deliverability and demonstrate regulatory compliance. Failure to implement these measures constitutes a breach of Article 21 risk management obligations, exposing organizations to substantial financial penalties (which go up to \texteuro$7,000,000$ or $1.41\%$ of the annual global revenue for Important Entities and \texteuro$10,000,000$ or $2\%$ of the global yearly revenue for Essential Entities) and management liability. Importantly, the Directive does not prescribe specific protocols. It mandates outcome-oriented security measures. For this reason, DMARC cannot be considered legally mandatory per se under NIS2, but may represent a proportionate measure depending on the risk profile of the entity.


\section{Duty of care: What is reasonable DNS/email configuration?}
The concept of "duty of care" in the email security context requires analysis of what domain owners should implement, in terms of expected security practices.
For email domain owners, industry standards are increasingly coalescing around implementation of SPF, DKIM, and DMARC protocols. The reasonable care standard encompasses not only initial implementation but also ongoing monitoring and maintenance of authentication records. Domain owners must regularly audit their SPF records to ensure that they accurately reflect authorized mail sources, rotate DKIM keys according to industry practices (typically annually), and review DMARC reports to identify unauthorized senders or configuration errors. Failure to maintain these records in response to organizational changes-such as the adoption of new email service providers, business acquisitions, or infrastructure migrations-constitutes a breach of reasonable care obligations.

\section{Case law: Liability in email fraud (Man in the Mail)}
Litigation regarding email compromise and fraudulent financial transfers provides a concrete illustration of how courts allocate liability and what evidence they examine when establishing negligence in email infrastructure.

A case of December 18, 2024 showed how liability is managed in Germany, within the GDPR rules. 
A contractor (plaintiff) performed work for a private customer (defendant) and later sent the final invoice by email. However, the email was intercepted and manipulated by unknown third parties, who altered the bank account details on the invoice before forwarding it to the defendant. Believing the invoice to be legitimate, the defendant transferred \texteuro$15,385.78$ to the fraudulent account.
The fraud was discovered only after the plaintiff noticed the missing payment. The plaintiff demanded that the defendant pay the amount again, arguing that the debt had not been fulfilled under Section 362(1) of the German Civil Code (BGB), since the payment never reached his account.

The defendant, however, contended that she had already fulfilled her obligation by paying the invoice as received. Furthermore, she claimed that the plaintiff had failed to implement adequate security measures when sending bank details by unprotected email, which enabled the fraud. The defendant invoked Article 82 of the GDPR, alleging that the plaintiff's negligent handling of personal data led to the incident. \cite{emailcompromise}


When the email account of the sender of funds is compromised and fraudulent payment instructions is issued, courts examine whether the recipient exercised reasonable diligence in verifying payment instructions. The case of "Jane Group Limited v. Heritage Gas Limited" \cite{emailcompromise2} established that recipients receiving apparently legitimate payment instructions from known business partners generally must pay per those instructions, even if they are originated from compromised email accounts, absent evidence that recipients should have suspected fraud. However, courts will examine whether recipients ignored unusual payment circumstances, such as changes to established banking relationships or unusual urgency requests that deviate from normal business patterns.


\section{Forensic evidence as leverage: Linking DMARC records and responsibility}
The preservation of digital evidence and the analysis of email authentication records have become fundamental to establish liability in legal proceedings. Particular emphasis has been placed on the use of DMARC records as objective indicators of organizational security posture.

Maintaining DMARC records can serve as a form of evidence regarding the company's or victim's security intentions and implementation choices.
When a domain maintained a DMARC policy of "\textit{p=reject}" (mandatory rejection of unauthenticated emails), the domain owner can present forensic evidence that any email impersonating their domain would have been rejected by properly configured receiving mail servers. The strength of this evidence is twofold: firstly, it is objective and therefore not subject to expert interpretation; secondly, it is demonstrable without requiring access to the compromised email account or the fraudster's infrastructure.


On the other hand, when a domain operated with a DMARC policy of "\textit{p=none}" (monitoring without enforcement) at the time of the disputed transaction, the domain owner effectively demonstrated that they prioritized email deliverability over security and accepted the risk that spoofed emails might be delivered. 


Courts interpret this choice as evidence that the domain owner was aware of authentication capabilities but chose not to implement them, constituting a form of negligence even if the specific fraud attack was sophisticated.


In addition, the process of deriving DNS records through web forensics techniques facilitates the documentation of DMARC, SPF, and DKIM configuration states at particular historical points in time by enabling the retrieval of DNS historical databases, certificate transparency logs, and DMARC report collections. While this forensic capability is not universally available for all historical periods, it can establish what defensive measures were technically available at specific times and whether domain owners had knowledge of these measures through receipt of DMARC reports or other sources.

Finally, courts examining DMARC evidence are required to address questions regarding the probative value of the evidence in relation to its prejudicial effect. While a domain maintaining "\textit{p=none}" policies may be probative evidence of inadequate security, courts must assess whether such evidence unfairly prejudices the defendant by suggesting negligence without adequate consideration of industry standards at the specific time period or the sophistication of the attack employed.

\subsection{DMARC policy and defensive positioning}
Looking at defensive positioning closer, the evidentiary value of DMARC records must be analyzed within the broader framework of civil procedure and burden of proof allocation. In general civil litigation, the burden of proof lies initially with the claimant. The injured party must, in fact, demonstrate: the occurrence of damage, the defendant’s unlawful conduct or breach of duty, and the causation.
In this context, DMARC records serve not as automatic proof of negligence or diligence, but as objective technical evidence of security posture at a given time.

A domain that operates with \texttt{p=reject} must demosntrate that: 
\begin{itemize}
\item security enforcement mechanism were active;
\item receiving servers were properly configured and for this reason would have rejected misaligned messages;
\item spoofing success required bypassing external receivers enforcement or exploiting different vectors.
\end{itemize}

On the other hand, if a domain has a "\texttt{p=none}" policy, this indicates that there is some form of authentication awareness but also shows there is no attempt to stop mail. 
But the only presence of "\texttt{p=none}" by itself is not sufficient to establish negligence. The courts will consider: industry standards at the time, technical and practical limits, proportionality, and whether the risk analysis justified a temporary monitoring mode. 
Therefore, the DMARC policy is just part of the overall picture in determining negligence.

\subsection{Accountability and proof of diligence}
In GDPR, Article 5(2) \cite{art5} states that controllers must be able to demonstrate compliance. This shifts practical emphasis toward documentation and monitoring.
During disputes the domain owner may need to demonstrate the existence of SPF/DKIM/DMARC configuration,
a progression toward enforcement, monitoring of DMARC reports (RUA ingestion) with related documented audits and corrective actions. Any failure to maintain logs or historical DNS records may weaken the defensive position, as the inability to demonstrate security posture can be interpreted unfavorably under accountability logic. For this reason, the probative value of Authentication-Results headers, DNS record snapshots, DMARC aggregate reports and SIEM logs, lies not only in proving technical facts, but in evidencing structured governance.

\section{Mitigation strategies and defensible compliance practices}
The foundational mitigation strategy involves the implementation of comprehensive email authentication aligned with the recommendations of ACN Framework and industry best practices.
This encompasses:
\begin{itemize}
    \item \textbf{SPF configuration}: publishing accurate SPF records listing all systems authorized to send emails on the domain's behalf, including mail servers, third-party marketing platforms, and any acquired companies' mail infrastructure. Regular audits ensure that SPF records remain accurate.
    \item \textbf{DKIM configuration and Key Management}: companies should implement DKIM signing for all outbound email; key rotation should also occur at least annually and immediately upon suspicion of key compromise. Documentation of key generation, rotation, and retirement procedures demonstrates defensible key management practices in case of litigation.
    \item \textbf{DMARC Policy Progression}: organizations should implement DMARC using the graduated progression recommended by ACN. Starting with policy "\textit{p=none}" to collect authentication data and identify legitimate senders; then analysis of DMARC records useful to identify and remediate false positives. After this, the policy should be set to "\textit{p=quarantine}" in order to redirect unauthenticated emails to spam folders. Finally, "\textit{p=reject}" policy should be implemented, reflecting organizational risk tolerance and business impact assessment.
\end{itemize}

This graduated approach acknowledges the operational realities that organizations face while establishing that these organizations have explicit intentions to achieve enforcement-level policies rather than indefinitely maintaining permissive configurations.

\section{Legal Defensibility through Technical Controls}

Figure \ref{fig:legal-responsibility-dmarc} depicts the relationship between legal responsibility, technical email authentication mechanisms, monitoring practices, and evidentiary readiness in the context of disputes arising from email spoofing.

The diagram represents the conceptual framework of the incremental chain of events leading to the formulation of legal responsibility, technical email authentication mechanisms, and ultimately to the formulation of defensible evidence. In the event of an invoice fraud case involving email spoofing, the organization’s position relative to its duty of care is evaluated as prescribed by relevant regulatory requirements. 
In the European Union, the relevant regulations include Article 32 of the GDPR and Article 21 of the NIS2 Directive, which require the adoption of “appropriate technical and organizational measures” to be evaluated in the context of the state of the art and the specific risk profile. \cite{art32} \cite{nis2}

Domain authentication mechanisms, including SPF, DKIM, and DMARC, form the foundation of technical email authentication mechanisms. However, the adoption of these mechanisms is only the beginning. Policy enforcement mechanisms involving an incremental chain of events leading to the formulation of the relevant policy (from \texttt{p=none} to \texttt{p=quarantine} and ultimately to \texttt{p=reject}) signify the maturity of the organization.

Most importantly, the diagram points out the need to monitor the preventive controls. This can be done through the ingestion of the aggregate reports, alerting mechanisms of anomalous senders, change management procedures, and auditing. This indicates that authentication has to be an ongoing process rather than just a static process.

The third column of the diagram points out the evidentiary requirements. This indicates that in case of any legal disputes, the organization has to be able to provide concrete evidence. This can be done through the provision of email headers with the authentication results, DNS configurations showing the enforcement of the policy at a particular time, and logs of the system.

Finally, the bottom part of the diagram indicates that authentication of emails is just part of the overall security of the organization. This can be done through business process controls and transport hardening.

Ultimately, the diagram reveals that the legal defensibility of an organization in the event of email spoofing can be achieved through the integration of authentication, monitoring, governance, and evidentiary requirements.

\begin{figure}[t]
\centering
\resizebox{\textwidth}{!}{%
\begin{tikzpicture}[
  font=\sffamily,
  box/.style={
    draw, rounded corners=6pt, thick,
    align=center, inner sep=10pt,
    minimum width=6.3cm,
    minimum height=3.0cm
  },
  arr/.style={-Latex, thick},
  node distance=12mm and 12mm
]

% --- Row 1
\node[box] (r1c1) {Legal risk / dispute\\(e.g., invoice fraud,\\spoofing allegation)};
\node[box, right=of r1c1] (r1c2) {Duty of care\\\textquotedbl appropriate measures\textquotedbl\\(GDPR Art.32,\\NIS2 Art.21)};
\node[box, right=of r1c2] (r1c3) {Defensible evidence\\(what you can prove)};

% --- Row 2
\node[box, below=of r1c1] (r2c1) {Domain authentication\\controls (DNS)\\
  \(\bullet\) SPF\\
  \(\bullet\) DKIM + key rotation\\
  \(\bullet\) DMARC policy\\
  (none\(\rightarrow\)quarantine\(\rightarrow\)reject)};
\node[box, below=of r1c2] (r2c2) {Monitoring + response\\
  \(\bullet\) DMARC RUA ingestion\\
  \(\bullet\) alerting on new senders\\
  \(\bullet\) change management\\
  \(\bullet\) periodic audits};
\node[box, below=of r1c3] (r2c3) {Forensic artifacts\\
  \(\bullet\) full headers\\
  (Authentication-Results)\\
  \(\bullet\) DNS record snapshots\\
  \(\bullet\) DMARC reports\\
  \(\bullet\) SIEM/ticket logs};

% --- Row 3
\node[box, below=of r2c1] (r3c1) {Business-process layer\\(anti-invoice fraud)\\
  \(\bullet\) signed invoices/portal\\
  \(\bullet\) out-of-band IBAN check\\
  \(\bullet\) approved vendor list};
\node[box, below=of r2c2] (r3c2) {Transport hardening\\
  \(\bullet\) TLS policy (MTA-STS/DANE)\\
  \(\bullet\) monitoring downgrade\\
  \(\bullet\) secure mail gateways};
\node[box, below=of r2c3] (r3c3) {Outcome\\[2pt]
  Reduced spoofing success\\
  + stronger legal posture\\
  + faster incident triage};

% --- Arrows
\draw[arr] (r1c1.east) -- (r1c2.west);
\draw[arr] (r1c2.east) -- (r1c3.west);

\draw[arr] (r1c1.south) -- (r2c1.north);
\draw[arr] (r2c1.south) -- (r3c1.north);

\draw[arr] (r1c2.south) -- (r2c2.north);
\draw[arr] (r2c2.south) -- (r3c2.north);

\draw[arr] (r1c3.south) -- (r2c3.north);
\draw[arr] (r2c3.south) -- (r3c3.north);

\end{tikzpicture}%
}
\caption{Legal responsibility, email authentication controls, monitoring, and defensible forensic evidence.}
\label{fig:legal-responsibility-dmarc}
\end{figure}

