\chapter{Background}
This chapter aims to provide an essential foundation for a better understanding of the technical and practical components of email and the mechanisms used to combat the problem of spoofing. The discussion then foregrounds the role of DMARC within the broader context of email security. An analytical synthesis of domain fundamentals, major authentication protocols and the rules behind their work is provided, then followed by exploration of configuration vulnerabilities and practical real-world cases. The objective is to deliver readers a depth of conceptual and operational knowledge necessary for advanced investigation into email spoofing prevention.

\section{Domain and Email Fundamentals}
The Internet Mail protocol is predicated on the collaboration between various components: Mail User Agent (MUA), Mail Transfer Agent (MTA), and the Domain Name System (DNS) infrastructure. 
DNS provides a distributed naming infrastructure that maps human-readable domain names to IP addresses, but it does not inherently provide authentication or assurance regarding the legitimacy of entities using a given domain name. As a result, domain identity in email communication is fundamentally logical rather than cryptographic, relying on conventions and cooperative behavior between mail servers.

SMTP is the protocol underlying most email delivery. In particular, SMTP distinguishes between the envelope sender specified during the \texttt{MAIL FROM} command and the header sender indicated in the \texttt{From:} field of the message headers; these identities are independent and are not required to match. The inherent openness of SMTP facilitates the use but also introduces exposure to malicious manipulation; specifically, it does not enforce sender authentication by default. This structural weakness is the crucible in which various spoofing and impersonation attacks are forged, as attackers can craft messages that claim arbitrary sender domains without violating the SMTP protocol. For this reason, additional authentication layers become indispensable for organizational email security \cite{rfc5321}.

In the context of email communication, several actors are involved. The \textbf{Author} of the message is responsible for its composition and the specification of the \textbf{Recipient}'s address. Upon transmission, the message is relayed through an outgoing MTA, propagated through multiple intermediate MTAs and subsequently delivered to the recipient's inbox via an inbound MTA.


\begin{figure}[h]
    \centering
    \includegraphics[width=0.7\linewidth]{Figures/mailstructures.png}
    \caption{Email Architecture Scheme (source: \href{https://en.wikipedia.org/wiki/Email}{Wikipedia})}
    \label{fig:emailarchitecture}
\end{figure}

\section{The problem of Spoofing}

Email spoofing represents a fundamental weakness of the email ecosystem rooted in the original design of SMTP, which lacks native mechanisms for sender authentication. As a result, attackers can forge email header fields(most notably the “From” address) to impersonate trusted domains, organizations, or individuals. Unlike traditional spam campaigns, modern spoofing attacks are often highly targeted and leverage social engineering rather than malicious payloads. For these reasons, these attacks nowadays frequently appear indistinguishable from legitimate business communications, allowing them to bypass content-based filters and reach recipients without triggering any security alerts.

In Business Email Compromise (BEC), adversaries exploit impersonation techniques to induce victims into performing fraudulent financial transactions. In such scenarios, attackers either spoof executive identities or compromise legitimate email accounts, thus observing ongoing conversations to inject fraudulent instructions at critical moments.

One of the most effective attacks happened in 2015, where the company "Ubiquiti Networks" disclosed a large-scale financial fraud, resulting in losses of approximately \$$46.7$ million \cite{ubiquitiNetworks}.
The forensic reconstruction reported that the attackers conducted a targeted spoofing campaign impersonating senior executives and trusted external partners. Emails were crafted to appear as much legitimate as possible, leading the finance department of the company to execute a series of international bank transfers. The attack exploited email header spoofing combined with social engineering techniques, leveraging the lack of enforced sender authentication and domain alignment controls. The spoofed emails exhibited forged header fields, particularly within the "\texttt{From:}" and "\texttt{Reply-To:}" headers, which visually matched legitimate executive identities. However, the SMTP envelope sender (\texttt{MAIL FROM}) and the originating IP addresses were not cryptographically bound to the claimed sender domain. In the absence of enforced DMARC policies, receiving mail servers accepted these messages despite potential misalignment between the header "\texttt{From:}" domain and the authenticated identifiers. Since the messages did not contain vindictive attachments, embedded URLs, or abnormal content, content based spam filters and malware detection engines were not triggered. Traditional email security mechanisms, such as blacklist-based filtering and reputation scoring, were then ineffective, as the sending infrastructure was either newly registered or indistinguishable from legitimate mail servers. 
This case demonstrates how spoofed emails that are syntactically valid and contextually plausible can bypass classical defenses without exploiting any software vulnerability.


\section{SPF (Sender Policy Framework)}
Sender Policy Framework is an email authentication protocol that helps protect email senders and recipients against spoofing and phishing attacks. It allows a receiving mail server verify whether the sending IP address is authorized to send email on behalf of a given domain. SPF verifies that incoming emails originate from authorized mail servers by checking IP addresses against DNS records. An SPF record is a \textit{TXT} record published in the Domain Name System (DNS). This DNS \textit{TXT} record contains a list of all the IP addresses that are authorized to send emails from a given domain \cite{rfc7208}.

\subsection{SPF record}
Now let's see what an SPF record is composed of.
\begin{figure}[h]
    \centering
    \includegraphics[width=0.7\linewidth]{Figures/spfrecord.png}
    \caption{SPF record example (source: \href{https://datatracker.ietf.org/doc/html/rfc7208}{RFC $7208$})}
    \label{fig:spfrecord}
\end{figure}


SPF records use some specific Mechanisms to determine which IP ranges, hostnames and subdomains are allowed to send mails. Among these Mechanisms there are: "\textit{ip4}", "\textit{ip6}", "\textit{mx}", "\textit{include}", and "\textit{exists}". Qualifiers, such as "+" (pass), "-" (fail), "$\sim$" (softfail), "?" (neutral), are then used to determine how strictly these policies are enforced.

This SPF record (Figure \ref{fig:spfrecord}) has:
\begin{itemize}
	\item "\texttt{v=spf1}" - version of SPF
	\item "\texttt{+mx}" - mechanism that authorizes all hosts listed in the domain's MX records to send email; "\texttt{+}" qualifier indicates a "\texttt{Pass}" result; basically if the sending IP matches any IP address associated with the domain’s MX hosts, the SPF check returns Pass.
	\item "\texttt{a:colo.example.com/28}" - the "\texttt{a}" mechanism authorizes IP addresses; associated with the IPv4 or IPv6 record of the specified hostname (colo.example.com); "/28" is the CIDR mask that limits authorization to a subnet of 16 IPv4 addresses;
	\item "\texttt{-all}" - "\texttt{all}" mechanism matches any IP address not previously matched, "\texttt{-}" qualifier represents "\texttt{Fail}": any sending IP that does not match one of the preceding mechanisms is explicitly unauthorized. 
\end{itemize}

\subsection{SPF functioning}
At network level, when an email arrives at the recipient's mail server, it performs the following steps:
\begin{enumerate}
	\item TCP connection establishment: the sending MTA initiates a TCP connection to the receiving MTA, without authentication;
	
	\item SMTP handshake: client sends "HELO" command, identifying himself;

	\item MAIL FROM command: the sending MTA transmitsS the SMTP command "\texttt{MAIL FROM:<user@example.com>}". This command defines the "\texttt{Return-Path}" address; SPF validation will then be based on the domain extracted from this field, authenticating only the envelope sender domain.

    \item The receiving MTA extracts, through a DNS TXT query, the domain name from the "\texttt{MAIL FROM}" or "\texttt{Return-Path}" address in the email header:
\begin{Verbatim}[breaklines, breakanywhere]
example.com. IN TXT "v=spf1 ip4:x.x.x.x/24 include:_spf.provider.com -all"
\end{Verbatim}
	
	
	
	\item IP authorization check: the receiving MTA compares the source IP address of the SMTP connection with the mechanisms specified in the SPF record. 
	
	\item The SPF evaluation produces one of several results:
		\begin{itemize}
        \item \textbf{SPF Pass}: The sending IP matches an authorized IP; message accepted
        \item \textbf{SPF Fail}: The sending IP is explicitly unauthorized; message potentially rejected
        \item \textbf{SPF Softfail}: The sending IP is probably unauthorized but treated leniently
        \item \textbf{SPF Neutral}: No definitive authorization or rejection
        \item \textbf{SPF None}: No SPF record found for the domain
    \end{itemize}
These results are then recorded internally and often surfaced in the message header.

\end{enumerate}



\section{DKIM (DomainKeys Identified Mail)}
DomainKeys Identified Mail (DKIM) is a protocol that uses public key cryptography to verify the authenticity of emails and to detect any tampering attempt during transmission. DKIM is a digital signature technology that confirms the authenticity of an email's sender. Unlike SPF, DKIM operates at the message level - rather than the transport level - and remains valid across message forwarding \cite{rfc6376}.

\subsection{DKIM Signature}
Looking at the Figure \ref{fig:dkimsignature}, let's analyze the various fields of a DKIM Signature:
\begin{figure}[h]
    \centering
    \includegraphics[width=0.7\linewidth]{Figures/dkimsignature.png}
    \caption{DKIM Signature example (source: \href{https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail}{Wikipedia})}
    \label{fig:dkimsignature}
\end{figure}

\begin{itemize}
	\item "\texttt{v=1}" represents the DKIM version
	\item "\texttt{a=rsa-sha256}" is the cryptographic algorithm used
	\item "\texttt{d=example.net}" is the Signing Domain Identifier (SDID), ensures that mail has been signed by that specific address; 
	\item "\texttt{s=brisbane}" is the selector, it is used to locate the public key to adopt and allows key rotations
	\item "\texttt{c=relaxed/simple}" is the canonicalization, represents how header and body have been normalized before the hash
	\item "\texttt{t}" and "\texttt{x}" are the timestamp and expiration date, useful against replay attacks;
	\item "\texttt{h}" represents all the headers that are included in the signature, if one of them changes, DKIM check fails;
	\item "\texttt{bh}" is the hash of the body, which is compared from the recipients;
	\item "\texttt{b=dzdV}..." is the signature.
\end{itemize}
This entire signature ensures that the domain "\texttt{example.net}" is the one who signed the message at the time "\texttt{t}", the headers "\texttt{h}" have not been modified and the body respects the integrity checks.

\subsection{DKIM functioning}
The first step performed by the sender domain to use DKIM is to generate an asymmetric key pair, one public and one private, that will then be used in the authentication process. The private key will be securely stored in the sending MTA, while the public key will be published in DNS as a TXT record:
\begin{Verbatim}[breaklines, breakanywhere]
selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
\end{Verbatim}
Once the message is submitted, the MTA sender computes hashes on header fields using canonicalization algorithms ("simple" or "relaxed"). Subsequently, the sender's private DKIM key is used to encrypt the hash, thus producing the DKIM signature. Before the email transmission, the digital signature is appended and incorporated into the DKIM Signature field header of the email.
The signed message is then transferred using the SMTP "\texttt{DATA}" command. Looking at packet level, DKIM signature is part of the email payload, for this reason it will not be altered by intermediate MTAs.

The recipient's MTA, once it receives the email, extracts the DKIM parameters ("\texttt{d}", "\texttt{s}", "\texttt{h}") and performs a DNS query for retrieving the public key. After this, hashes are recomputed using the same canonicalization rules and the retrieved public key will be used for the cryptographic validation of the signature. The result will be recorded in the authentication metadata:
\begin{Verbatim}[breaklines, breakanywhere]
"Authentication-Results: dkim=pass header.d=example.com"
\end{Verbatim}

Once the receiving server has verified the presence of a valid DKIM signature on an email, it can be deduced that the integrity of the email has been maintained. It is important to note that, in the majority of cases, DKIM signatures are not visible to end-users, and the validation process occurs at the server level. This entire process ensures that the integrity of the email has been maintained since its transmission.


\section{DMARC (Domain-based Message Authentication, Reporting and Conformance)}
%%%%% -------------- DA RISCRIVERE -----------------
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is an email authentication protocol designed to limit email spoofing and domain impersonation attacks. DMARC is built on SPF and DKIM, and the combined work of these protocols helps strengthen the effectiveness by addressing authentication gaps that neither protocol can resolve independently. DMARC was originally developed as an email security protocol at the DNS level, designed in 2012 by Microsoft, Google and Yahoo \cite{dmarcRFC}.

When an email arrives, the recipient's server performs a DNS lookup searching for a DMARC record (after conducting SPF and DKIM checks). DMARC checks that the authenticated identifiers match the domain contained in the "\texttt{From}" header. For SPF alignment, DMARC checks if the domain from the "\textit{envelope from}" address (used in SPF) matches the "\texttt{From}" header domain. However, for DKIM alignment, it verifies whether the "\texttt{d=}" domain in the DKIM signature matches the "\texttt{From}" header domain. Alignment can be configured as: "\texttt{strict}", meaning that it requires the exact domain match; or "\texttt{relaxed}", thus allowing matching base domains with different subdomains. The DMARC check is satisfied if either SPF or DKIM passes authentication controls with respect of the alignment test, one is already sufficient.
Domain owners have the possibility, with DMARC, to publish their policies that specify how receivers should handle messages that failed authentication. 
There are three policy levels:
\begin{enumerate}
    \item \textbf{p=none}: no action taken for unauthenticated emails, but DMARC records are sent to the domain owner;
    \item \textbf{p=quarantine}: failed messages are sent to SPAM inbox; 
    \item \textbf{p=reject}: messages are not delivered to the recipient inbox.
\end{enumerate}
Usually, domain owners start with \texttt{p=none} in order to monitor the authentication requests and then go into more restrictive policies. 

\begin{figure}[h]
    \centering
    \includegraphics[width=1\linewidth]{Figures/dmarcarchitecture.png}
    \caption{DMARC Architecture (source: \href{https://emailauth.io/what-is-dmarc\#architecture}{emailauth.io})}
    \label{fig:dmarcarchitecture}
\end{figure}


There is an example of DMARC TXT record:
\begin{figure}[h]
    \centering
    \includegraphics[width=1\linewidth]{Figures/dmarcexample.png}
    \caption{DMARC record (source \href{https://nvlpubs.nist.gov/nistpubs/TechnicalNotes/NIST.TN.1945.pdf}{nist.gov})}
    \label{fig:dmarcexample}
\end{figure}

Let's analyze the tag present:
\begin{itemize}
    \item \textbf{v=DMARC1} - specifies that this TXT is a DMARC record;
    \item \textbf{adkim=r} - says that the DKIM domain must be evaluated with a relaxed basis, so the organizational domain in the record must be the same as the one in the "From" domain;
    \item \textbf{aspf=s} - specifies that the SPF domain must be evaluated in a strict way;
    \item \textbf{p=none} - DMARC policy not applied on failing messages;
    \item \textbf{pct=100} - percentage of messages which policies are applied to;
    \item \textbf{rf=afrf} - specifies the individual forensic report format (AFRF in this case);
    \item \textbf{ri=86400} - interval in seconds to deliver summary reports;
    \item \textbf{ruf=mailto:forensics.example.com} - address where the forensic report (which contains messages that fail DMARC checks) should be sent.
\end{itemize}

For domain owners, DMARC implementation reduces spoofing risks, provides unprecedented visibility into email ecosystems, and improves deliverability by signaling rigorous authentication practices to major email providers. For recipients, DMARC offers enhanced protection against phishing and business email compromise attacks by ensuring only authenticated emails from verified sources reach the inbox. The protocol's evolution from voluntary best practice to industry requirement reflects its proven effectiveness in combating email-based threats.

\section{How SPF, DKIM and DMARC work together}
The joint effort between these three protocols helps strengthen protection against the threat of email spoofing, adding an additional layer of security. SPF asserts the authenticity of the sending infrastructure, while DKIM evaluates the cryptographic identity of the message. 
Although SPF and DKIM are often deployed together, their independent validation does not inherently prevent domain impersonation. SPF authenticates the SMTP envelope sender, while DKIM authenticates the domain accountable for applying the cryptographic signature. In the absence of a definitive alignment mechanism, a message may successfully pass SPF and DKIM checks while still presenting a deceptive sender identity in the “\texttt{From}” header. Consequently, relying on SPF or DKIM alone (or even both) without correlation does not provide sufficient protection against spoofing attacks targeting the domain identity perceived by the end user.
Meanwhile, DMARC integrates these two mechanisms, ensuring that the authentication results and the domain presented to the end-users match.

The workflow is typically the following:
\begin{enumerate}
    \item The recipient's server performs SPF and DKIM controls;
    \item DMARC policy is consulted to determine if at least one check between SPF or DKIM is satisfied;
    \item based on DMARC conditions, the recipient performs the preferred action
    \item optionally, reporting mechanisms allow administrators to review authentication statistics.
\end{enumerate}


\subsection{Authentication results correlation and data flow}
These three protocols, when combined, establishe a layered defense model, thus reducing opportunities for attackers to exploit isolated weaknesses.
The combined operation of SPF, DKIM, and DMARC occurs within a single SMTP transaction, during which multiple authentication mechanisms are evaluated at different stages of message processing and their results are subsequently correlated. Rather than introducing an additional authentication layer, DMARC acts as an orchestrator, consuming the outputs of SPF and DKIM and enforcing domain-aligned policy decisions.

From a protocol-level perspective, during the SMTP envelope phase SPF evaluation is triggered, specifically after receiving the "\texttt{MAIL FROM}" command. At this stage, the receiving MTA extracts the envelope sender domain and performs a DNS TXT query to retrieve the corresponding SPF record, comparing the source IP address of the SMTP connection to the authorized sending mechanisms defined in the record, as specified in RFC 7208 \cite{rfc7208}. The evaluation result (pass, fail, softfail etc.) will be then determined before the message transmission and it is bound to the envelope sender.

On the other hand, DKIM is performed after SMTP "\texttt{DATA}" command, thus after the full message (including header and boy) has been received. The recipient MTA extracts the DKIM-Signature header, retrieves the public key through a DNS TXT query and then verifies cryptographically both message integrity and domain authorizaion, according to RFC 6376 \cite{rfc6376}. DKIM validation is thus independent from the sending IP address and it is kept valid across message forwarding, but DKIM alone does not asseverate that the signing domain corresponds to the sender identity that arrives to the user.

After SPF and DKIM results are available, DMARC evaluation is executed. Through a DNS TXT query the DMARC record is retrieved, then the domain is extracted from the visible "\texttt{From}" header. DMARC does not re-evaluate SPF or DKIM, but instead it correlates their authentication results with the domain shown to the recipient and verifies the alignment conditions, requiring that either the SPF-authenticated domain or the DKIM signind domain match the "\texttt{From}" domain. After this, the receiving system applies the policy specified by the domain owner \cite{dmarcRFC}.

During the entire process, the receiving MTA performs multiple DNS lookups within the same authentication context, including the SPF records for the envelope sender, DKIM key records for the signing domain and DMARC policy records for the header sender. The results of all these evaluations are put in the "\texttt{Authentication-Results}" header. This header documents SPF, DKIM and DMARC results and provide a strong forensic trace of all the authentication decisions applied to a given message during its transmission \cite{rfc8601}.

This integrated workflow addresses the structural weaknesses of SMTP’s trust model and establishes a deterministic mechanism for preventing domain impersonation and large-scale spoofing attacks.


\section{Additional relevant technologies (MTA-STS, BIMI)}
MTA-STS (Mail Transfer Agent Strict Transport Security) and BIMI (Brand Indicator for Message Identification) extend the email architecture, securing the transport layer and providing visual authentication indicators to recipients. MTA-STS allows domain owners to publish policies via DNS and HTTPS, specifying that the recipient's mail server must support TLS encrypted connections, in this way malicious users are prevented to perform TLS downgrade attacks. However, if security requirements cannot be met, the message is rejected rather than transmitted in plaintext. Three policies are offered by MTA-STS: \textbf{none} (no enforcement at all), \textbf{testing} (messages are monitored but not blocked), \textbf{enforce} (full compliance is mandatory).

BIMI, on the other hand, works as a visual trust signal. It allows verified companies to display the sender's logo in the recipient's inboxes. Only those emails that pass rigorous DMARC controls (with quarantine or reject policy), are eligible to display logos. BIMI is implemented by companies through the publication of a DNS record that specifies the location of the logo and links it to a certificate (Verified Mark Certificate or Common Mark Certificate), cryptographically binding the ownership of the logo to that organization.
Despite this multi-layered approach reduces exposure to spoofing, phishing, and man-in-the-middle attacks, the actual adoption of MTA-STS and BIMI remains incomplete due to implementation complexity, cost, and incomplete support across all email clients.


\section{Possible configuration errors}
The effectiveness of SPF, DKIM and DMARC heavily relies on correct configuration, errors can directly undermine security or reduce communications's reliability. 

Among the common missteps there are: 
\begin{itemize}
    \item \textbf{Incomplete or outdated SPF records} - if all the legitimate mail sources are not specified, this will cause a lot of false positives; 
    \begin{itemize}
    		\item From a technical perspective, this error manifests when the source IP address of the SMTP connection is not included in the domain’s SPF record. Typical results include "\textit{SPF fail}" when the record terminates with "\texttt{-all}", or "\texttt{SPF softfail}" when "$\sim$all" is used. Furhtermore, complex SPF records that rely on multiple "\texttt{include}" mechanisms may exceed the RFC-mandated limit of 10 DNS lookups, resulting in a "\texttt{permerror}".
    \end{itemize}
    
    \item \textbf{DKIM key erroneous management} - rotating keys without updating DNS record entries can cause verification failures;
    \begin{itemize}
    \item These failures usually arise when the public key published in the DNS does not match the private key used to sign messages. This may happen during key rotation if the DNS record is not updaated, or if the selector referenced in the "\texttt{DKIM-Signature}" ("\texttt{s}" in the Figure \ref{fig:dkimsignature}) does not exist. Moreover, if the message is modified after signing or if strict canonicalization ("\texttt{c=simple/simple}") is adopted, may conduct to a signature invalidation.
    \end{itemize}

    \item \textbf{Misalignment of DMARC policies} - not enforcing strict alignment may lead to insufficient protection;
    \begin{itemize}
    \item Misalignment failures occur when the domain authenticated by SPF or DKIM does not match the one present in the "\texttt{From}" header. Due to this failure, an email may pass SPF authentication using a third-party envelope sender while presenting a different organizational domain to the user (e.g. "\texttt{From: example.com}" and "\texttt{MAIL FROM: mail.thirdparty.com}"). Additionally, when subdomains are involved, strict alignment (like "\texttt{asps=s}" or "\texttt{adkim=s}") may increase failure likelihood.
    \end{itemize}

    \item \textbf{Inadequate monitoring} - overlooking reports can allow unnoticed attacks or misconfigurations to persist.
	\begin{itemize}
	\item If DMARC policies are set to "\texttt{p=none}", monitoring is enabled but it does not enforce any action against unuthorized messages. As a result, spoofed emails may be delivered as well, making DMARC controls ineffective.
	\end{itemize}

\end{itemize}
The mitigation of all these errors necessitates a combination of technical expertise and institutional processes that are oriented towards ongoing maintenance, monitoring, and periodic validation of authentication frameworks.

\section{Practical implications and case studies}
This framework of SPF, DKIM and DMARC finds a lot of critical application in real-world scenarios, since implementation decisions carry measurable security and operational consequences.

It is evident that public-access tools such as Emkei and AnonyMailer empower individuals, even without technical expertise, to formulate communications that appear being originated from arbitrary email addresses, including potentially sensitive institutional accounts. This accessibility underscores the necessity of robust authentication infrastructure. Absent proper configuration of SPF, DKIM and DMARC at the DNS and mail server levels, receiving mail servers possess no technical means to distinguish legitimate correspondence from spoofed impersonations.

In a direct spoofing scenario (typical of the CEO fraud scenario), the attacker establishes an SMTP session with a receiving mail server and forges the \texttt{From} header to impersonate a trusted domain. If SPF \texttt{fail} or \texttt{pass} is not aligned and DKIM is not present (\texttt{dkim=none} or \texttt{d $\neq$ From}) and if the target domain lacks a DMARC record or publishes a permissive policy (\texttt{p=none}), the receiving server will accept the message \cite{dmarcRFC, rfc7208, rfc6376, rfc8601}.

\begin{Verbatim}[breaklines, breakanywhere]
Authentication-Results:
  spf=fail smtp.mailfrom=attacker.com;
  dkim=none;
  dmarc=fail (p=none)
\end{Verbatim}

More sophisticated attacks leverage legitimate third-party email infrastructure (e.g., marketing platforms or cloud mail relays) to bypass basic authentication checks. In such cases, SPF may pass for the envelope sender, while the visible sender identity remains misleading \cite{spoofingpaper}.
Technical detail:
\begin{itemize}
	\item SPF: \texttt{pass} (third-party is authorized)
	\item DKIM: \texttt{pass} (\texttt{d=thirdparty.com})
	\item \texttt{From: ceo@victim.com}
	\item DMARC: if relaxed alignment is set, it will fail the check; if \texttt{p=none}, the mail si going to be delivered. 
\end{itemize}

The header could be:
\begin{Verbatim}[breaklines, breakanywhere]
spf=pass smtp.mailfrom=mailer.thirdparty.com;
dkim=pass header.d=mailer.thirdparty.com;
dmarc=fail header.from=victim.com
\end{Verbatim}


The ability of receiving servers to detect and reject counterfeited mails depend entirely on correct configuration choices. 

The practical forensic significance of DMARC configuration emerges in the investigation of email-based fraud (Man-In-The-Mail) \cite{dmarcDalChecco}. In such cases, attackers intercept organizational communications to redirect financial transfers to their accounts. These fraudulent messages are injected into existing threads, often reusing original message headers and subjects to evade detection. A verification that a domain maintained strict DMARC enforcement, valid DKIM signatures, and appropriate SPF restrictions at the time of the disputed communication establishes that spoofed messages impersonating the organization would have been technically rejected by properly configured receiving systems. On the other hand, the presence of a permissive (or the total absence) of authentication configuration demonstrates the organization vulnerability to spoofing. The heterogeneity of institutional authentication maturity demonstrates that email security is a field where organizational choices are crucial in real-world security outcomes.

