\chapter{Experimental Email Testbed for DMARC Enforcement and Forensic Evidence Collection}

The efficacy of Domain-based Message Authentication, Reporting, and Conformance (DMARC) relies entirely on its interaction with the Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). To empirically evaluate this interaction and practically demonstrate the mechanisms of email spoofing prevention, a fully isolated, containerized email authentication laboratory was developed using Docker. This environment models a micro-scale Internet topology, implementing fully functional Mail Transfer Agents (MTAs) and a Domain Name System (DNS) infrastructure. By executing explicit SMTP transaction simulations, the laboratory isolates the cryptographic and policy-based evaluations that occur during the email delivery lifecycle, proving the necessity of strict DMARC alignment.

\section{Network Topology and Architecture}
The lab infrastructure design is specified with Docker Compose to enable a reproducible Infrastructure-as-Code (IaC) setup. The system is built on a dedicated IPv4 bridge network (\texttt{10.0.0.0/24}) to ensure isolation and prevent DNS resolution bleed.

\captionof{listing}{Snippet from \texttt{docker-compose.yml} defining the isolated network and MTAs}
\label{lst:dockercompose}

\begin{minted}[frame=single, breaklines, linenos]{yaml}
networks:
  mailnet:
    driver: bridge
    ipam:
      config:
        - subnet: 10.0.0.0/24
\end{minted}

The infrastructure includes three main components:
\begin{enumerate}
\item \textbf{Authoritative DNS} (\texttt{10.0.0.2}): this component includes a BIND9 instance that provides authoritative answers for the simulated local top-level domains. It includes the MX, A, and authentication TXT records (SPF, DKIM, DMARC) for all simulated domains.
\begin{figure}[h]
    \centering
    \includegraphics[width=1\linewidth]{Figures/dns_architecture2.png}
    \caption{DNS Architecture}
    \label{fig:dnsarchitecture2}
\end{figure}

\item \textbf{Sender MTA} (\texttt{10.0.0.10}): component that includes a Postfix MTA instance used for sending mail. It is tightly integrated with an \texttt{OpenDKIM} milter running in signing mode to inject signatures into legitimate mail. It also acts as a \texttt{swaks} (Swiss Army Knife for SMTP) launchpad to inject raw SMTP messages for simulating spoofing attacks. See Figure \ref{fig:senderarchitecture} for architecture details.
\begin{figure}[h]
    \centering
    \includegraphics[width=0.7\linewidth]{Figures/sender_architecture.png}
    \caption{Sender MTA Architecture}
    \label{fig:senderarchitecture}
\end{figure}

\item \textbf{Receiver-MTA} (\texttt{10.0.0.20}): The target inbound Postfix MTA. The \texttt{smtpd} daemon includes a verification pipeline with \texttt{policyd-spf} running as a postfix policy service and two milters: one for OpenDKIM verification and another for OpenDMARC verification. In Figure \ref{fig:receiverarchitecture} more details.
\begin{figure}[h]
    \centering
    \includegraphics[width=1\linewidth]{Figures/receiver_architecture.png}
    \caption{Receiver MTA Architecture}
    \label{fig:receiverarchitecture}
\end{figure}

\end{enumerate}
The sender and receiver container explicitly use the lab DNS as resolver (\texttt{10.0.0.2}), this guarantees that all SPF/DKIM/DMARC lookups are served by the controlled authoritative DNS instance.


\subsection{Authentication Infrastructure implementation}
The core research value of the laboratory lies in the configuration of the Receiver-MTA verification pipeline, which accurately reflects a modern email receiver.
All the authentication checks are triggered sequentially, via Postfix \texttt{main.cf} configuration. 
Specifically, SPF verification is enforced during the \texttt{RCPT TO} phase using a Unix socket policy service, while DKIM and DMARC are evaluated during the \texttt{DATA} phase via the milter protocol (port 8891 and 8893, respectively).

\captionof{listing}{Main Postfix configuration file on the receiver side}
\label{lst:maincf}
\begin{minted}[frame=single, breaklines, linenos]{bash}
# Milters: OpenDKIM (verify) then OpenDMARC
milter_protocol = 6
milter_default_action = accept
smtpd_milters = inet:127.0.0.1:8891, inet:127.0.0.1:8893

#SPF policy checks
smtpd_recipient_restrictions =
    permit_mynetworks,
    reject_unauth_destination,
    check_policy_service unix:private/policyd-spf
\end{minted}

The OpenDMARC daemon is explicitly configured to reject alignment failures rather than silently dropping or quarantining the messages, in this way the DMARC \texttt{p=reject} policies at the SMTP protocol level  are enforced (issuing a \texttt{550 5.7.1} error before accepting the body).
OpenDMARC is  also configured to independently validate SPF via DNS rather than relying explicitly on the \texttt{policyd-spf} headers, ensuring robust policy execution:

\captionof{listing}{Snippet from the OpenDMARC configuration file}
\label{lst:opendmarcconf}
\begin{minted}[frame=single, breaklines, linenos]{bash}
RejectFailures          true       # Reject messages failing DMARC p=reject
SPFSelfValidate         true       # OpenDMARC performs its own SPF validation
FailureReports          true       # Generate forensic (RUF) reports
\end{minted}


\section{DNS Configuration}\label{dns}
The lab defines four domains with intentionally different authentication postures.
\begin{itemize}
\item \textbf{legit.lab}: This domain represents a secure posture where spoofing attempts are expected to be rejected at SMTP time.
	\begin{itemize}
		\item \textbf{SPF}: \texttt{v=spf1 ip4:10.0.0.10 -all}.
		\item \textbf{DKIM}: \texttt{selector1.\_domainkey} TXT with the public key.
		\item \textbf{DMARC} (strictly enforced): \texttt{v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:dmarc-reports@legit.lab; ruf=mailto:dmarc-forensic@legit.lab; fo=1}
	\end{itemize}

\item \textbf{thirdparty.lab}, third party sender identity, with DMARC monitoring. SPF and DKIM both exist, DMARC is set with a permissive policy with \texttt{p=none}, record is: \texttt{\_dmarc IN TXT "v=DMARC1; p=none; adkim=s; aspf=s"}.
Domain used to demonstrate that SPF passing alone is insufficient without DMARC alignment.

\item \textbf{misconf.lab}: misconfigured domain, it allows spoofed emails to be delivered, even though they are logged as failing DMARC.

DMARC: \texttt{\_dmarc IN TXT "v=DMARC1; p=none; rua=mailto:reports@misconf.lab"}

\item \textbf{evil.lab}: The attacker domain, it has no email authentication at all.
No SPF/DKIM/DMARC records, this domain is used as envelope sender to represent commodity attacker infrastructure. SPF checks for this domain will return "\texttt{none}". 
\end{itemize}

\subsection{Deterministic Key Generation}
DKIM keys are generated through in the setup file. For each domain a 1024-bit RSA key pair is generated.

\captionof{listing}{DKIM key generation}
\label{lst:keygen}
\begin{minted}[frame=single, breaklines, linenos]{bash}
for DOMAIN in legit.lab thirdparty.lab misconf.lab; do
    KEY_DIR="sender-mta/keys/${DOMAIN}"
    mkdir -p "$KEY_DIR"

    if [ -f "$KEY_DIR/selector1.private" ]; then
        echo "DKIM key for ${DOMAIN} already exists - skipping"
    else
        echo "Generating DKIM key pair for ${DOMAIN} ..."
        openssl genrsa -out "$KEY_DIR/selector1.private" 1024 2>/dev/null
        openssl rsa -in "$KEY_DIR/selector1.private" \
            -pubout -outform DER 2>/dev/null | base64 -w 0 \
            > "$KEY_DIR/selector1.pub"
        echo "--> private: $KEY_DIR/selector1.private"
        echo "--> public:  $KEY_DIR/selector1.pub"
    fi
done


sed "s|__DKIM_PUBKEY__|${LEGIT_PUB}|g" \
    dns/zones/legit.lab.zone.template > dns/zones/legit.lab.zone
echo "--> dns/zones/legit.lab.zone"

sed "s|__DKIM_PUBKEY__|${THIRD_PUB}|g" \
    dns/zones/thirdparty.lab.zone.template > dns/zones/thirdparty.lab.zone
echo "--> dns/zones/thirdparty.lab.zone"

MISCONF_PUB=$(cat sender-mta/keys/misconf.lab/selector1.pub)
sed "s|__DKIM_PUBKEY__|${MISCONF_PUB}|g" \
    dns/zones/misconf.lab.zone.template > dns/zones/misconf.lab.zone
echo "--> dns/zones/misconf.lab.zone"
\end{minted}
The script first checks for existing keys, if a normal file named \texttt{selector1.private} already exists in that domain's key directory, it prints a success message and skips the rest of the loop. This makes the script idempotent, in this way it can be run multiple times safely without accidentally overwriting already existing keys.
If the key doesn't exist, it generates one by using the OpenSSL utility to generate a 1024 RSA private key and saves it in \texttt{selector1.private}.

The public key is then derived, forcing the output to be in binary DER format through \texttt{-outform DER}. Then \texttt{base64 -w 0} takes the binary output and encodes it into a Base64 string. The \texttt{-w 0} flag is crucial because it prevents the \texttt{base64} command from adding newlines, since DNS TXT records for DKIM require the key to be one continuous, unbroken Base64 string. At the end public and private keys are saved in the respective files.

Then, zone files are created from templates by substituting \texttt{\_\_DKIM\_PUBKEY\_\_} into DNS TXT records using \texttt{sed}. This provides reproducibility and ensures that DNS DKIM public keys match the private keys deployed in the sender container.

\section{Sender MTA implementation}
The main responsibility of the Sender MTA lies in the generation, formatting, and cryptographic signing of outgoing automated email traffic to mimic different kinds of sender postures. The system uses two main daemon processes to communicate with each other using the mail filter protocol, which are Postfix and OpenDKIM. The latter is an open-source implementation of the DKIM protocol and it has been used in this configuration to specifically target the sender MTA. Its main role is to sign outgoing email traffic and not to verify incoming traffic.
At the center of the sender architecture resides Postfix, configured as the primary outbound relay node. Its configuration is also constrained to operate securely within the laboratory’s closed network.

\captionof{listing}{Sender Postfix configuration}
\label{lst:postfixsender}
\begin{minted}[frame=single, breaklines, linenos]{bash}
# Identity
myhostname = mail.legit.lab
mydomain = legit.lab
myorigin = $mydomain

# Accept mail from localhost and lab network
inet_interfaces = all
inet_protocols = ipv4
mydestination = $myhostname, legit.lab, localhost
mynetworks = 127.0.0.0/8, 10.0.0.0/24

# Deliver directly via MX (no relay host)
relayhost =

# Route mail to receiver.lab directly (Docker DNS workaround)
transport_maps = inline:{ receiver.lab=smtp:[10.0.0.20] }

# -- OpenDKIM milter --
milter_protocol = 6
milter_default_action = accept
smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = inet:127.0.0.1:8891

# -- Logging --
maillog_file = /var/log/mail.log

# -- Misc --
smtpd_banner = $myhostname ESMTP DMARC-Lab
biff = no
append_dot_mydomain = no
compatibility_level = 2
$
\end{minted}
The MTA announces its identity as "\texttt{myhostname = mail.legit.lab}". Its standard SMTP socket is binded to all available interfaces (\texttt{inet\_interfaces = all}) but strict relay controls are enforced as well. All the emails are accepted from the loopback interface and the Docker bridge network only (\texttt{mynetworks = 127.0.0.0/8, 10.0.0.0/24}); otherwise, it is discarded as an open-relay attack.
In the case of outgoing mail routing, it bypasses the secondary relay host by using the "\texttt{relayhost=}" field. 
The entrypoint script injects the IP address of the lab’s DNS server (10.0.0.2) into \texttt{/etc/resolv.conf} (in the container) using the standard BIND9 resolver instead of the Docker DNS resolver at \texttt{127.0.0.11}. 
The latter tends to misroute MX queries for custom top-level domains (such as \texttt{.lab}). Additionally, a direct transport map is used: \texttt{transport\_maps = inline:{ receiver.lab=smtp:[10.0.0.20] }} - it sends SMTP traffic straight to the designated receiver node instead of looking up the MX record for the \texttt{.lab} domain.

% --- TO ADJUST ---

To meet the criteria for DMARC testing, emails are required to be cryptographically signed using DomainKeys Identified Mail (DKIM) technology. This is done through the implementation of the OpenDKIM daemon as a pre-queue Milter.
For the Milter Integration, Postfix sends the raw email structure, headers, and body to the OpenDKIM daemon prior to its entry into the active mail queue. This is done through a communication using a local IPv4 socket address type: \texttt{inet:127.0.0.1:8891} with Milter protocol version 6.
Regarding the Operational Mode and the Canonicalization, OpenDKIM is restricted to "Sign-only" mode, denoted as "\texttt{Mode s}", hashes are generated using a relaxed/simple canonicalization method. \texttt{Relaxed} header canonicalization is used to ensure that minor header changes, such as those due to whitespace folding during message transport, do not affect the email's cryptographic hash. On the other hand, \texttt{simple} body canonicalization is used to strictly forbid any changes to the message payload, representing a secure baseline for the laboratory's deterministic test cases.
In order to simulate a multi-domain sender, the laboratory must simulate a sender with multiple independent domains: \texttt{legit.lab} and \texttt{thirdparty.lab}. For this reason, OpenDKIM uses mapping tables to dynamically manage multi-tenancy simulation:
\begin{itemize}
\item \texttt{signing.table}: This table parses the \texttt{From} header of the injected message to identify the sender domain and maps it to a specific Key ID.
\item \texttt{key.table}: This table maps the sender's Key ID to the absolute file path for the corresponding sender's RSA private key file (e.g., for example, \texttt{/etc/opendkim/keys/legit.lab/selector1.private}, which was previously generated during the laboratory initialization phase).
\end{itemize}
At the end, to prevent header injection attacks, in which a second malicious \texttt{From} header could potentially trick the MUA into displaying a sender address that does not match the actual sender, while passing the DKIM verification test for the original header (due to the inability to add additional headers after signing) the \texttt{OversignHeaders From} directive parameter is enabled. This cryptographically signs the number of \texttt{From} headers, causing the signature to break in the event of additional headers being injected after signing.

\section{Receiver MTA implementation}
The architecture of the receiver in the DMARC laboratory environment is designed to function like a containerized Mail Transfer Agent (MTA) (Listing \ref{lst:postfixreceiver}). Its main function is to receive automated mail traffic and verify it cryptographically. It is designed to mimic a strict receiving mail server that follows SPF, DKIM, and DMARC policy checking before it is delivered. It uses Postfix, OpenDKIM, OpenDMARC, and a Python SPF policy daemon.Postfix serves as the frontier ingress node. In the main configuration file (\texttt{main.cf}) the server’s identity and acceptance policies are established.

\captionof{listing}{Receiver configuration}
\label{lst:postfixreceiver}
\begin{minted}[frame=single, breaklines, linenos]{bash}
#identity
myhostname = mail.receiver.lab
mydomain = receiver.lab
myorigin = $mydomain

#accept mail for these domains
inet_interfaces = all
inet_protocols = ipv4
mydestination = $myhostname, receiver.lab, localhost
mynetworks = 127.0.0.0/8

# Milters: OpenDKIM (verify) then OpenDMARC
milter_protocol = 6
milter_default_action = accept
smtpd_milters = inet:127.0.0.1:8891, inet:127.0.0.1:8893
non_smtpd_milters = inet:127.0.0.1:8891, inet:127.0.0.1:8893

# SPF policy check
policyd-spf_time_limit = 3600

smtpd_recipient_restrictions =
    permit_mynetworks,
    reject_unauth_destination,
    check_policy_service unix:private/policyd-spf

# Logging
maillog_file = /var/log/mail.log

# misc 
smtpd_banner = \$myhostname ESMTP DMARC-Lab
biff = no
append_dot_mydomain = no
compatibility_level = 2
\end{minted}

The MTA starts by identifying itself as \texttt{mail.receiver.lab} and explicitly defines its administrative domain as \texttt{receiver.lab}. The \texttt{mydestination} directive configures Postfix to accept final delivery for emails addressed to the laboratory's recipient domains (\texttt{mydestination = \$myhostname, receiver.lab, localhost}), rather than acting as an open relay. The verification architecture relies on a strict, sequential pipeline of Mail Filters invoked prior to queueing (lines 13 to 16 in Listing \ref{lst:postfixreceiver}). This configuration ensures that incoming messages first go through the OpenDKIM milter (TCP port 8891) to cryptographically verify signatures, and then the OpenDMARC milter (TCP port 8893) for policy evaluation. The order is critical since DMARC requires the DKIM verification results to compute identifier alignment.
SPF evaluation is hooked directly into Postfix's SMTP dialog during the \texttt{RCPT TO} phase, achieved via \texttt{check\_policy\_service unix:private/policyd-spf}.
This directive calls the \texttt{postfix-policyd-spf-python} daemon, which passes the envelope sender (\texttt{MAIL FROM}) and connects IP address in order to validate the sender's authorization against the published DNS SPF records.


Unlike the sender, the receiver is configured with Verify mode (\texttt{Mode v}). It will not attempt to sign any outbound messages, thus focusing only on the cryptographic validation of incoming signatures.
Upon evaluating a DKIM signature using the public key retrieved via DNS, OpenDKIM injects the canonical \texttt{Authentication-Results} header into the email structure, using \texttt{AuthservID mail.receiver.lab} directive, this ensures that the header explicitly tags the results as generated by this specific host, providing a standardized auditable trail for downstream filters (like OpenDMARC) or user agents.


The last verification stage is managed by OpenDMARC, which synthesizes the results of the preceding SPF and DKIM checks to enforce the domain owner's stated policy.
While Postfix evaluates SPF at the SMTP envelope layer, OpenDMARC is configured to perform an independent, redundant SPF check (by specifying \texttt{SPFSelfValidate true}). This ensures the milter has a real-time access to the SPF results required for DMARC alignment computation, without relying solely on upstream header parsing. Regarding the alignment and the Policy Enforcement, OpenDMARC computes whether the authenticated identifiers (the DKIM "\texttt{d=}" domain and the SPF "\texttt{Return-Path}" domain) align with the human-readable "\texttt{From:}" header. If the message fails alignment, the "\texttt{RejectFailures true}" directive instructs the milter to strictly enforce the sending domain's policy. If the domain publishes "\texttt{p=reject}", the SMTP transaction is actively rejected with a \texttt{5xx} error code. The system fully supports DMARC's failure reporting mechanism (RUF). When a message fails DMARC evaluation, the daemon is configured to generate an AFRF (Authentication Failure Reporting Format) report, specified by:

\captionof{listing}{Forensic reports management}
\label{lst:reportrua}
\begin{minted}[frame=single, breaklines, linenos]{bash}
# Forensic reports for failures
FailureReports          true
FailureReportsBcc       dmarc-forensic@receiver.lab
FailureReportsSentBy    postmaster@receiver.lab
\end{minted}

These reports provide immediate feedback to the domain administrator containing granular forensic data regarding the failure.
Finally, the “continuous monitoring” represents persistent state about DMARC evaluations performed over time by the receiver, and it is provided by \texttt{HistoryFile /var/run/opendmarc/opendmarc.dat}.


\section{Experimental scenarios}
The lab exposes four scenarios implemented as shell scripts. Each scenario uses \texttt{swaks} to generate SMTP traffic with controlled envelope and header identities.

\subsection{Scenario A - Legitimate mail delivered}
The first scenario is the classic mail delivery, where the mail is sent through the sender MTA (\texttt{--server 127.0.0.1} inside \texttt{sender-mta}), ensuring OpenDKIM signing the envelope sender and header.
The expected outcome is SPF, DKIM, and DMARC pass due to strict alignment.

\captionof{listing}{Scenario A}
\label{lst:scenarioa}
\begin{minted}[frame=single, breaklines, linenos]{bash}
swaks \
    --to bob@receiver.lab \
    --from alice@legit.lab \
    --h-From "Alice <alice@legit.lab>" \
    --h-Subject "Scenario A: Legitimate email from legit.lab" \
    --body "This is a legitimate email sent from alice@legit.lab.\nIt should pass SPF, DKIM, and DMARC checks." \
    --server 127.0.0.1 \
    --port 25 \
    --timeout 30
\end{minted}

Each scenario can be executed by running the command: 
\begin{Verbatim}
docker compose exec sender-mta bash /scripts/scenario-*.sh
\end{Verbatim}
In Figure \ref{fig:scenarioaexec} the output of the execution of this scenario is represented.
\begin{figure}[h]
    \centering
    \includegraphics[width=0.7\linewidth]{Figures/scenarioa-execution.png}
    \caption{Output of the execution of Scenario A}
    \label{fig:scenarioaexec}
\end{figure}




\subsection{Scenario B - Classic Spoof}
In this scenario the message bypasses the sender MTA and it is injected directly into the receiver (\texttt{--server 10.0.0.20}), thus no DKIM signing occurs. In this example the attacker uses as envelope address: \texttt{MAIL FROM:<random@evil.lab>}; and as spoofed header: \texttt{From: CEO <ceo@legit.lab>}.
Since the sender (\texttt{evil.lab}) has no SPF/DKIM and the receiver (\texttt{legit.lab}) is configured with \texttt{p=reject}, DMARC fails and the receiver rejects with SMTP error.

\captionof{listing}{Scenario B}
\label{lst:scenariob}
\begin{minted}[frame=single, breaklines, linenos]{bash}
# Send directly to receiver-mta, bypassing sender-mta's DKIM signing
swaks \
    --to bob@receiver.lab \
    --from random@evil.lab \
    --h-From "CEO <ceo@legit.lab>" \
    --h-Subject "URGENT: Wire transfer needed immediately" \
    --body "This is a spoofed email. I am the CEO.\nThe From header says legit.lab but the envelope says evil.lab.\nNo DKIM signature is present." \
    --server 10.0.0.20 \
    --port 25 \
    --timeout 30 \
    || true
\end{minted}
This scenario demonstrates the main preventive property of DMARC, it binds receiver action to the visible \texttt{From:} domain policy.

\subsection{Scenario C - Alignment demonstration}
In the third scenario, the envelope sender domain is \texttt{thirdparty.lab} (which authorizes the sender IP in SPF), but the visible \texttt{From:} is spoofed as \texttt{legit.lab}:

\captionof{listing}{Scenario C}
\label{lst:scenarioc}
\begin{minted}[frame=single, breaklines, linenos]{bash}
swaks \
    --to bob@receiver.lab \
    --from mailer@thirdparty.lab \
    --h-From "CEO <ceo@legit.lab>" \
    --h-Subject "Invoice #12345 - please review" \
    --body "This email has SPF=pass (envelope is thirdparty.lab, authorized IP).\nBut the From header says legit.lab.\nDMARC catches the alignment mismatch and rejects." \
    --server 10.0.0.20 \
    --port 25 \
    --timeout 30 \
    || true   # swaks will exit non-zero on SMTP reject - that's expected
\end{minted}
Since the envelope address is \texttt{thirdparty.lab}, an SPF pass is expected; but the \texttt{From:} header is spoofed. Here the key property is the alignment, DMARC indeed requires that the SPF-authenticated domain matches the \texttt{From:} domain (strict or relaxed). In this scenario, SPF passes for the wrong identity domain; therefore DMARC fails and the message is rejected under the \texttt{p=reject} policy.
This scenario is thus the didactic proof that SPF alone does not prevent impersonation, for this reason DMARC is required to enforce alignment between authentication identity and user-visible identity.


\subsection{Scenario D - Spoof delivered due to DMARC monitoring mode}
The last scenario is an example of how many organizations enable DMARC reporting but do not enforce rejection/quarantine policies, thus causing the actual delivery of a spoofed email in inboxes.

\captionof{listing}{Scenario D}
\label{lst:scenariod}
\begin{minted}[frame=single, breaklines, linenos]{bash}
swaks \
    --to bob@receiver.lab \
    --from attacker@evil.lab \
    --h-From "Admin <admin@misconf.lab>" \
    --h-Subject "Scenario D: Spoofed email from misconf.lab (p=none)" \
    --body "This email is spoofing misconf.lab.\nDMARC will FAIL due to alignment mismatch.\nHowever, because misconf.lab has p=none, this email should be DELIVERED." \
    --server 10.0.0.20 \
    --port 25 \
    --timeout 30
\end{minted}

OpenDMARC will compute \texttt{dmarc=fail}, but the policy is monitoring-only (see Section \ref{dns}); hence the receiver delivers the message rather than rejecting it.
From a prevention standpoint, this scenario demonstrates a crucial operational point: DMARC provides visibility under \texttt{p=none}, but not protection. Without enforcement, the receiver can log the failure while still delivering a spoofed message.

\section{Continuous Monitoring and Forensic Evidence Collection}
A key contribution of this project is the capability of forensic evidences creation, thus implementing practical monitoring utilities that aligns with realistic companies workflows.


\subsection{Log-based monitoring}
To provide comprehensive visibility into the milter pipeline's decision-making process, the 
\texttt{check-logs.sh} script was developed to parse the system mail log (/var/log/mail.log) on the \texttt{receiver-mta} in real-time.
The architecture of this script relies on sequential grep queries that target specific daemon facilities.
\captionof{listing}{SPF evaluation}
\label{lst:spfevaluationlogs}
\begin{minted}[frame=single, breaklines, linenos]{bash}
# -- SPF results --
echo ""
echo -e "---- SPF Results ----"
grep -i "policyd-spf\|Received-SPF" "$LOGFILE" 2>/dev/null | tail -20 | \
    sed "s/Pass/Pass/gI; s/Fail/Fail/gI; s/None/None/gI" || \
    echo "(no SPF entries found)"
\end{minted}
The first verification phase targets Postfix's \texttt{check\_policy\_service}. As the remote MTA issues the \texttt{MAIL FROM} envelope command, Postfix delegates authorization to the \texttt{policyd-spf} daemon. The script then extracts these authorization results by grepping for the \texttt{policyd-spf} facility. This surfaces critical, pre-queue routing details such as whether the connecting IP address (e.g., \texttt{10.0.0.10}) was authorized by the domain's TXT record, resolving either to a \texttt{Pass}, \texttt{Fail}, \texttt{Softfail}, or \texttt{None}.

\captionof{listing}{DKIM evaluation}
\label{lst:dkimevaluationlogs}
\begin{minted}[frame=single, breaklines, linenos]{bash}
# -- DKIM results --
echo ""
echo -e "${BOLD}---- DKIM Results (OpenDKIM) ----${NC}"
grep -i "opendkim\|dkim" "$LOGFILE" 2>/dev/null | tail -20 | \
    sed "s/pass/pass/gI; s/fail/fail/gI; s/none/none/gI" || \
    echo "(no DKIM entries found)"
\end{minted}
For the DKIM evaluation, once the message payload is transmitted via the \texttt{DATA} command, it is passed to the first milter: OpenDKIM. The script then isolates \texttt{opendkim} log events; this telemetry reveals the internal state of the cryptographic engine, detailing whether a \texttt{DKIM-Signature} header was detected (\texttt{no signature data} vs \texttt{signature verified}), if the RSA public key was successfully retrieved via DNS, and if the computed canonical hash matched the provided signature (\texttt{pass} vs \texttt{fail}).

\captionof{listing}{DMARC evaluation}
\label{lst:dmarcevaluationlogs}
\begin{minted}[frame=single, breaklines, linenos]{bash}
# -- DMARC results --
echo ""
echo -e "${BOLD}---- DMARC Results (OpenDMARC) ----${NC}"
grep -i "opendmarc\|dmarc" "$LOGFILE" 2>/dev/null | tail -20 | \
    sed "s/pass/pass/gI; s/fail/fail/gI; s/reject/reject/gI" || \
    echo "  (no DMARC entries found)"
\end{minted}
Following the DKIM checks, script goes into the extraction of \texttt{opendmarc} events. The logs demonstrate the milter extracting the organizational domain from the \texttt{From:} header, comparing it against the authenticated identifiers from the SPF and DKIM phases (identifier alignment), and evaluating the published DMARC policy (\texttt{p=none}, \texttt{p=quarantine}, or \texttt{p=reject}). If the message fails alignment and the policy is \texttt{reject}, this section highlights the milter instructing Postfix to abort the transaction.



\captionof{listing}{Postfix evaluation}
\label{lst:postfixevaluationlogs}
\begin{minted}[frame=single, breaklines, linenos]{bash}
# -- Postfix delivery status --
echo ""
echo -e "${BOLD}---- Postfix Delivery Status ----${NC}"
grep -i "status=\|reject\|550\|451" "$LOGFILE" 2>/dev/null | tail -20 | \
    sed "s/status=sent/status=sent/gI; s/status=delivered/status=delivered/gI; s/reject/reject/gI; s/550/550/gI" || \
    echo "(no delivery status entries found)"
\end{minted}
   
The final checks queries Postfix's internal queue manager and local delivery agent, or the SMTP daemon itself in the event of a rejection. By filtering for \texttt{status=}, \texttt{reject}, and standard SMTP error codes (\texttt{550}, \texttt{451}), the script surfaces the definitive outcome of the transaction. A \texttt{status=sent} represents the successful traversal of the entire DMARC pipeline, whereas a \texttt{550 5.7.1 rejected by DMARC policy} provides concrete proof of active policy enforcement by the receiving infrastructure.
In Figure \ref{fig:scenarioalogs} there is the logs output of the Scenario A (legitimate mail).
\begin{figure}[h]
    \centering
    \includegraphics[width=1\linewidth]{Figures/logs-scenarioa.png}
    \caption{Scenario A Logs}
    \label{fig:scenarioalogs}
\end{figure}


\subsection{Header-based verification}
The project provides also the possibility of verifying the application of cryptographic signatures and policy alignment, indeed the final state of an email message is analyzed after it traverses the entire milter pipeline. 
The \texttt{check-headers.sh} script is engineered to parse the local delivery sink (\texttt{/var/mail/bob}) and extract the canonical authentication headers appended by the receiver's evaluation engines.
The script starts by sequentially reading the mailbox file to identify the \texttt{mbox} envelope delimiter, in this way it accurately isolates all the individual SMTP transactions.

\captionof{listing}{Headers analysis}
\label{lst:headersevaluation}
\begin{minted}[frame=single, breaklines, linenos]{bash}
case "$line" in
            Authentication-Results:*|Received-SPF:*|DKIM-Signature:*)
                echo -e "${line}" | \
                    sed "s/pass/pass/gI; s/fail/fail/gI; s/none/none/gI"
                ;;
            From:*|To:*|Subject:*|Date:*|Return-Path:*)
                echo -e "${line}"
                ;;
            # Show continuation lines (start with whitespace)
            [[:space:]]*)
                if [ "$SHOW_CONT" = "1" ]; then
                    echo -e "${line}" | \
                        sed "s/pass/pass/gI; s/fail/fail/gI; s/none/none${NC}/gI"
                fi
                ;;
        esac
\end{minted}

The script, rather than dumping the entire header block, implements a specialized \texttt{case} statement to filter for identity and authentication telemetry injected during the SMTP transaction.
By performing these, it selectively captures:
\begin{itemize}
\item the envelope sender: (\texttt{Return-Path:}), crucial for verifying the domain used during the SPF evaluation phase.
\item Author domain: (\texttt{From:}), which is required to compute DMARC identifier alignment.
\item Cryptographic traces: (\texttt{DKIM-Signature:}), proving the sender MTA successfully applied the RSA signature.
\item The Milter output: (\texttt{Authentication-Results:}), which contains the computed results of the SPF, DKIM, and DMARC evaluations.
\end{itemize}
The output is dynamically printed to provide a visual confirmation of the authentication posture during automated scenario execution. In Figure \ref{fig:scenariodheaders} the header of Scenario D (spoofed mail delivered due to \texttt{p=none} policy).
\begin{figure}[h]
    \centering
    \includegraphics[width=1\linewidth]{Figures/scenariod-headers.png}
    \caption{Scenario D headers}
    \label{fig:scenariodheaders}
\end{figure}


\subsection{Forensic report generation}
Another feature provided is the creation of a report, which is useful for a deeper forensic analysis.
The script executes in the context of the "\texttt{receiver-mta}" container and aims at collecting and aggregating all forms of authentication telemetry across the entire mail delivery pipeline in a single forensic artifact. 
The script starts by capturing a point-in-time snapshot of the authoritative DNS state for all participating domains in the system.

\begin{minted}[frame=single, breaklines, linenos]{bash}
echo "  SPF (TXT):" >> "$REPORT"
    dig @${DNS_SERVER} ${DOMAIN} TXT +short 2>/dev/null | grep -i spf >> "$REPORT" || echo "  (none)" >> "$REPORT"

    echo "  DKIM (selector1._domainkey):" >> "$REPORT"
    dig @${DNS_SERVER} selector1._domainkey.${DOMAIN} TXT +short 2>/dev/null >> "$REPORT" || echo "  (none)" >> "$REPORT"
\end{minted}

In this phase, the dedicated BIND9 resolver (\texttt{10.0.0.2}) is queried to bypass localized caching. In this way, the script provides critical context for why specific SPF or DKIM validations may have succeeded or failed during subsequent log analysis.


Since the core diagnostic data resides within the system mail log (\texttt{/var/log/mail.log}), the script utilizes stream filtering to extract isolated events pertaining to each step of the authentication pipeline.

\begin{minted}[frame=single, breaklines, linenos]{bash}
echo "--- SPF Events ---" >> "$REPORT"
    grep -i "policyd-spf\|Received-SPF" "$LOGFILE" 2>/dev/null >> "$REPORT" || echo "  (none)" >> "$REPORT"

    echo "" >> "$REPORT"
    echo "--- DKIM Events ---" >> "$REPORT"
    grep -i "opendkim\|DKIM" "$LOGFILE" 2>/dev/null >> "$REPORT" || echo "  (none)" >> "$REPORT"

    echo "" >> "$REPORT"
    echo "--- DMARC Events ---" >> "$REPORT"
    grep -i "opendmarc\|dmarc" "$LOGFILE" 2>/dev/null >> "$REPORT" || echo "  (none)" >> "$REPORT"
\end{minted}

This phase separates the flow of intertwined logs into specific chronological events for SPF policy evaluation (\texttt{policyd-spf}), DKIM verification, DMARC alignment and policy rules, and final Postfix delivery disposition.

For messages that successfully bypass rejection and are delivered to the recipient, the script extracts the unmodified message headers. Later, since OpenDMARC keeps an internal file (data source for DMARC Aggregate Reports generation) that records telemetry for every processed message, the script dumps this binary-structured text file. 
This data contains deep internal metrics computed by the milter, including some specific alignment integers (\texttt{align\_dkim}, \texttt{align\_spf}) or policy evaluation actions as well as the exact authenticated domains used for DMARC evaluation. 

In the final phase, the script parses the aggregated log files dynamically to compute high-level summary statistics of the system run. It calculates the total number of connections, successes, failures, and strict rejections(\texttt{550}); thus this section provides an immediate overview of the authentication posture demonstrated during the specific scenario execution.
This design produces an artifact that is both technically useful for debugging and conceptually aligned with the argument that continuous monitoring provides evidentiary value (visibility of spoofing attempts even when blocked).


\section{Results and discussion}
The containerized experimental testbed successfully validated the sequential verification pipeline of SPF, DKIM, and DMARC. By isolating specific authentication variables across four distinct SMTP transactions, the results provide empirical, protocol-level evidence that DMARC identifier alignment is the sole deterministic defense against domain impersonation.

By correlating SMTP dialogue traces, Authentication-Results headers, and all the other logs, it is visible how policy enforcement and alignment semantics determine final delivery outcomes. The results provide concrete evidence that DMARC enforcement (rather than SPF or DKIM alone) is the decisive mechanism in spoofing prevention.

\subsection{Scenario A}
In the case of Scenario A, the successful delivery of legitimate mail was achieved and demonstrated that the alignment of "\texttt{aspf=s}" and "\texttt{adkim=s}" does not inhibit the flow of authorized mail if the infrastructure is properly synchronized.

\begin{figure}[h]
    \centering
    \includegraphics[width=0.6\linewidth]{Figures/scenarioa-execution.png}
    \caption{Scenario A SMTP transaction output}
    \label{fig:scenarioaexec}
\end{figure}
The SMTP dialogue (Figure: \ref{fig:scenarioaexec}) shows successful transaction completion, starting from the command \texttt{MAIL FROM:<alice@legit.lab>} and \texttt{RCPT TO:<bob@receiver.lab>}; these commands are then accepted by \texttt{250 2.0.0 Ok: queued}. Since no policy rejection or temporary failure occurs, it menas that the message successfully traversed all filtering stages.

\begin{figure}[h]
    \centering
    \includegraphics[width=0.8\linewidth]{Figures/headers-scenarioa.png}
    \caption{Scenario A headers}
    \label{fig:scenarioaheaders}
\end{figure}

Looking at Figure \ref{fig:scenarioaheaders}, the extracted \texttt{Authentication-Results} header confirms full authentication success:
\begin{Verbatim}
spf=pass smtp.mailfrom=legit.lab
dkim=pass
dmarc=pass (p=reject) header.from=legit.lab
\end{Verbatim}
Since a valid DKIM-Signature header (with \texttt{d=legit.lab}; \texttt{s=selector1}) is present, it confirms the correct cryptographic signing at the sender and successful public-key retrieval from DNS by OpenDKIM in verify mode.

\begin{figure}[h]
    \centering
    \includegraphics[width=0.8\linewidth]{Figures/logs-scenarioa.png}
    \caption{Scenario A logs}
    \label{fig:scenarioalogs2}
\end{figure}

Logs in Figure \ref{fig:scenarioalogs2} confirm that:
\begin{itemize}
\item SPF is evaluated via \texttt{policyd-spf};
\item DKIM verification succeeded;
\item OpenDMARC reported alignment success;
\item Postfix final status is \texttt{status=sent}, so the mail has been delivered to mailbox.
\end{itemize}

Finally, the mail is successfully delivered because all three mechanisms succeed. SPF authenticates the envelope domain; DKIM authenticates message integrity and origin domain; DMARC confirms alignment between authenticated domain and \texttt{From:} header domain.
This scenario validates the correctness of the lab configuration and establishes a reference baseline.


\subsection{Scenario B}
In this scenario a direct spoofing attack is shown with: envelope sender \texttt{random@evil.lab}, Header \texttt{From: ceo@legit.lab} and no DKIM signature.

\begin{figure}[h]
    \centering
    \includegraphics[width=0.6\linewidth]{Figures/scenariob-execution.png}
    \caption{Scenario B SMTP output}
    \label{fig:scenarioboutput}
\end{figure}

As represented in Figure \ref{fig:scenarioboutput}, the SMTP session terminates with \texttt{550 5.7.1 rejeceted by DMARC policy for legit.lab}. This response demonstrates that the message will never be accepted in the receiver's queue, thanks to the DMARC policies correctly configured.


\begin{figure}[h]
    \centering
    \includegraphics[width=0.6\linewidth]{Figures/logs-scenariob.png}
    \caption{Scenario B logs}
    \label{fig:scenarioblogs}
\end{figure}

Receiver logs in Figure \ref{fig:scenarioblogs} shows: \texttt{SPF(mailfrom): evil.lab none}, \texttt{legit.lab fail}, \texttt{milter-reject ... rejected by DMARC policy for legit.lab}.
These lines indicate that SPF does not authenticate legit.lab, DKIM is absent and DMARC alignment fails; for these reasons the policy \texttt{p=reject} triggers enforcement.

This scenario demonstrates the critical enforcement property of DMARC. Even though SPF is evaluated and DKIM is checked, neither alone determines delivery. Instead DMARC extracts the domain from the visible \texttt{From:} header and verifies alignment with SPF/DKIM authenticated domains. Then, it applies the domain owner’s published policy, thus the rejection occurs at SMTP time, which is the strongest possible mitigation strategy.

\subsection{Scenario C}
This scenario represents the most critical technical proof of the study: an SPF "\texttt{Pass}" is entirely insufficient for identity protection without DMARC alignment validation.
\begin{figure}[h]
    \centering
    \includegraphics[width=0.6\linewidth]{Figures/scenarioc-execution.png}
    \caption{Scenario C SMTP output}
    \label{fig:scenariocexec}
\end{figure}

As shown in Figure \ref{fig:scenariocexec}, the DMARC daemon successfully intercepts the structural mismatch and forces a \texttt{550 5.7.1 rejection}, preventing the exploitation of the legitimate third-party relay.

\begin{figure}[h]
    \centering
    \includegraphics[width=0.6\linewidth]{Figures/scenarioc-logs.png}
    \caption{Scenario C logs}
    \label{fig:scenarioclogs}
\end{figure}


The receiver logs in Figure \ref{fig:scenarioclogs} show that the attacker successfully bypassed initial SPF filters. The \texttt{policyd-spf} daemon, in fact, registers a valid authorization (\texttt{Pass...envelope-from=mailer@thirdparty.lab}). So, SPF authentication succeeded, but it authenticated the wrong domain (\texttt{thirdparty.lab}). Since the user visible header is spoofed as \texttt{ceo@legit.lab}, the organizational domains do not align, thus it is going to be detected by DMARC. Consequently, the milter computes a \texttt{legit.lab fail}. Finally, it was demonstrated that even if an attacker was able to obtain a "\texttt{SPF Pass}" by using authorized third-party infrastructure, the OpenDMARC milter was able to successfully invoke a rejection at the SMTP protocol level if a "\texttt{p=reject}" policy was in place.

\subsection{Scenario D}
From the assessment of Scenario D, it was recognized that an organization was at critical risk if they chose to implement a "\texttt{p=none}" policy, in which case the authentication failure was logged and mail was still delivered, thereby leaving the organization open to "Man in the Mail" and CEO fraud types of attack, even with monitoring in place.

\begin{figure}[h]
    \centering
    \includegraphics[width=0.6\linewidth]{Figures/scenariod-execution.png}
    \caption{Scenario D SMTP output}
    \label{fig:scenariodexec}
\end{figure}
Since the \texttt{misconf.lab} has a \texttt{p=none} policy, the message will be delivered in the recipient's inbox, as shown in Figure \ref{fig:scenariodexec}: \texttt{250 2.0.0 Ok: queued}, here no rejection occurs.


\begin{figure}[h]
    \centering
    \includegraphics[width=0.8\linewidth]{Figures/scenariod-logs.png}
    \caption{Scenario D logs}
    \label{fig:scenariodlogs}
\end{figure}
The system logs (Figure \ref{fig:scenariodlogs}) confirm the complete absence of cryptographic integrity (\texttt{opendkim: no signature data}) and authorization (\texttt{opendmarc: SPF(mailfrom): evil.lab none}), thus the Postifx delivery status is \texttt{sent}.



\begin{figure}[h]
    \centering
    \includegraphics[width=0.8\linewidth]{Figures/scenariod-headers.png}
    \caption{Scenario D headers}
    \label{fig:scenariodheaders2}
\end{figure}

Finally, headers exposes the resulting forensic artifact. The \texttt{Authentication-Results} explicitly log \texttt{spf=none} and \texttt{dmarc=none}. Because the domain is configured with the disposition as \texttt{none}, the receiver MTA is forced to deliver the actively spoofed email (\texttt{admin@misconf.lab}) directly to the user's inbox, exposing the organization to immediate BEC or phishing risks.


\section{Limitations of the experimental scenarios and real-world considerations}
Despite the experimental lab environment effectively illustrates the fundamental operational mechanisms of SPF, DKIM, and DMARC enforcement, it remains a simplified model of actual operational infrastructures. The four scenarios outlined in the testbed essentially highlight key authentication results, including successful authenticated delivery, rejection of spoofing attempts, rejection on the basis of alignment, and monitoring-only results. However, it should be noted that a critical evaluation of these limitations remains crucial in order to effectively understand the results of the experiments.

\subsection{Simplified mail infrastructure}
In a lab, email setup is straightforward: a sending MTA, a receiving MTA, and a dedicated DNS service. But in a real-world email system, things are a lot more complex and distributed. There are many sending relays, third-party cloud email services, inbound filters, and so on, all the way down to reputation-based filters.

In a large organization, there are often third-party email service providers, cloud transactional email services, marketing automation systems, and helpdesk systems, all sending email from the same domain. In this case, SPF must specify a large number of approved sending hosts via \texttt{include} mechanism, and there might be a number of different key holders for a given DKIM setup. This is a level of complexity that is difficult to replicate in a testbed environment.

Furthermore, in real receiving infrastructures there are multiple levels of filters such as spam, malware, reputation, and behavioral filters using machine learning algorithms. In a lab scenario, acceptance of a message depends entirely on authentication results. In a real-world case, acceptance of a message is a result of a combination of authentication results, reputation of the sender, and content and heuristic filters.

\subsection{Absence of Email Forwarding and Mailing List Transformations}
Another important limitation concerns the absence of forwarding mechanisms and mailing list processing. In real email ecosystems, messages are frequently forwarded across multiple intermediate mail servers, which may modify headers, alter message bodies, or change envelope information.

Such transformations can affect authentication results in several ways.Since the forwarding server becomes the new sending host without being authorized in the original domain's SPF record, it often happens that SPF fails during the forwarding phase. DKIM signatures may break if the message body is modified by mailing lists that append footers or reformat message content. DMARC alignment may therefore fail even for legitimate messages, creating operational challenges for domain owners.

These scenarios intentionally avoid such transformations in order to isolate the core authentication logic. However, real-world deployments must often adopt mitigation mechanisms such as Authenticated Received Chain (ARC) to preserve authentication results across forwarding chains. The absence of ARC or similar mechanisms in the laboratory means that the scenarios do not fully reflect authentication challenges encountered in operational email ecosystems.

\subsection{Lack of Sender Reputation and Behavioral Filtering}
Modern email security systems heavily rely on sender reputation and behavioral analysis. Receiving mail servers often maintain reputation scores based on historical sending behavior, complaint rates, spam trap hits, and sending volume patterns. In the experimental testbed, all SMTP sessions originate from controlled IP addresses within a closed Docker network. As a result, the scenarios do not incorporate reputation-based filtering or rate-limiting mechanisms that are widely used by large email providers. In practice, spoofing detection frequently depends on the interaction between authentication signals and reputation metrics rather than on authentication alone.
Additionally, many modern email security gateways apply machine-learning models that analyze message structure, linguistic patterns, and historical communication relationships between senders and recipients. These systems can detect sophisticated phishing campaigns even when authentication checks pass successfully. Such behavioral detection mechanisms fall outside the scope of the experimental laboratory.

\subsection{Absence of Large-Scale DMARC Monitoring Infrastructure}
In the developed scenarios, evaluation of the DMARC policy is considered at the receiving server, as well as the logging of the authentication results. However, in the real world, the effectiveness of DMARC is dependent on the constant monitoring of aggregate reports (RUA) and forensic reports (RUF) that the mail server sends out. RUA and RUF allow domain owners to monitor where authentication failures are happening, as well as where unauthorized senders are trying to send emails that impersonate their domain. The test setup that is being utilized in this laboratory is more dependent on the local authentication results, as opposed to the entire system that needs to be managed in the real world to effectively implement DMARC.

\subsection{Limited adversarial model}
The laboratory setup for the attack scenarios is quite simple, it involves spoofing attacks such as domain misalignment or the absence of authentication signatures. They can be used for illustrating how the protocol works, but real-world attackers may use even more sophisticated attacks.

For example, attackers may use lookalike domains, where they can evade the DMARC protocol by taking advantage of slight differences between characters, such as homoglyphs, which can be used for sending spam mail. They may also gain unauthorized access to legitimate accounts, which can be used for sending authenticated mail that passes SPF, DKIM, and DMARC. All of this highlights the fact that the DMARC protocol can only be used for protecting against domain impersonation attacks, while other attacks may not be completely covered by the protocol. To protect against such attacks, other measures may be necessary, such as domain similarity analysis, behavioral analysis, and awareness training.


\subsection{Implications for experimental interpretation}
These constraints do not disprove the findings; rather, they indicate the environment to which the findings are applicable. In the lab environment, the basic mechanics behind domain-based email authentication are simplified to the essential components necessary to understand how SPF, DKIM, and DMARC all come together to determine whether or not a message passes through or if it is blocked.

However, it should be understood that the simplified environments should not be taken as actual simulations of the real world of email systems. In the real world, the actual results of email authentication combine the outcomes of many other factors, both technological, organizational, and behavioral, that contribute to the actual effectiveness of anti-spoofing measures.
Recognizing such limitations is essential to fully understanding the laboratory results and the role that the mechanisms described in the experiments play in the actual world of modern email systems’ security infrastructures.

\section{Security Implication and Conclusions}
Finally, the experimental results validate several theoretical claims discussed in earlier chapters. 
One of the main points to point at is the distinction between authentication and identity assurance. This is perhaps best illustrated in the case of Scenario C. While SPF authenticated the envelope domain (\texttt{thirdparty.lab}),  the visible identity presented to the user (\texttt{ceo@legit.lab}) remained unauthenticated and misaligned. Without DMARC, this message might have been delivered anyway, even though SPF was successful, thus creating a false sense of authenticity. This highlights the importance of DMARC and its role in preventing messages with incorrect authentication results. This underlines the fact that DMARC’s alignment requirement isn’t optional but rather a fundamental requirement to prevent impersonation.


Scenario D, where \texttt{p=none} is configured, reveals an important real-world phenomenon: domains may appear to have implemented DMARC, yet remain fully susceptible to spoofing. The Authentication-Results header records \texttt{dmarc=none}, and logs confirm evaluation failure; however, the message is delivered because the published policy explicitly disables enforcement. This illustrates a separation between telemetry generation and preventive capability. Monitoring-only deployments provide visibility but do not modify message handling behavior. Consequently, organizations that remain indefinitely in \texttt{p=none} mode benefit from reporting but do not meaningfully reduce spoofing exposure.


From a governance perspective, the findings underscore the importance of continuous monitoring. Even in rejection scenarios, the receiver logs preserve structured evidence of SPF evaluation, DKIM verification status, DMARC alignment decisions, and final delivery outcomes. These logs then represent a concrete record of the attempt to spoof. In a production environment, these kind of statistics can feed SIEM pipelines, generate alerts, and support incident response workflows. Without active log analysis, however, these signals remain dormant and offer no protective value. Thus, enforcement and monitoring must be understood as complementary components of an effective defense strategy.

Finally, these findings have broader strategic relevance. Email security is often perceived as a binary state (configured or not configured). The experimental evidence contradicts this view. Security emerges from the interaction between protocol semantics, DNS publication accuracy, receiver behavior, and policy enforcement configuration; misalignment between these layers results in exploitable gaps.


These implications substantiate the central thesis of this work: effective spoofing prevention requires not only technical deployment but deliberate enforcement and ongoing monitoring.





