\chapter{DMARC Forensics Tool Technical Analysis}
DMARC Forensics is implemented as a single-page client-side web application that performs on-demand DNS interrogation and evaluates DMARC/SPF/DKIM compliance locally in the browser. The application does not require authentication, does not transmit uploaded domain lists to an application backend, and does not ingest email traffic or DMARC aggregate (RUA) telemetry; instead, it derives conclusions from real-time DNS resolution and deterministic parsing logic.

In the server-side model proposed by other tools, the vendor acts as an intermediary, possessing full knowledge of the investigator's targets. In this tool, a client-side model is used, where the vendor is removed from the loop entirely. The browser acts as the direct agent of the investigator, interacting with the DNS infrastructure without passing data through the tool developer's systems.

\section{System architecture and workflow}
From an architectural standpoint, the tool follows a browser-executed execution model in which DNS resolution is performed via DNS-over-HTTPS (DoH) using the Google Public DNS JSON API endpoint:
\begin{Verbatim}[breaklines, breakanywhere]
https://dns.google/resolve?name=<QNAME>&type=<RRType>
\end{Verbatim}

In this way, the correctness of the analysis depends on the resolver’s view of DNS and on the integrity of the HTTPS communication channel between the client and the resolver. The privacy implications of this design are also explicitly acknowledged in the application’s policy, as DNS queries are transmitted to Google’s infrastructure and are subject to its data handling practices.

The operational workflow can be summarized as:
\begin{enumerate}
	\item User input acquisition and normalization (domain list, optional DKIM selector).
	\item Domain syntax validation.
	\item Parallel DNS resolution for SPF, DMARC, and DKIM-related records.
	\item Deterministic parsing and compliance evaluation.
	\item Report generation and optional export of structured results and raw query logs.
\end{enumerate}
Notably, the tool performs no SMTP-level simulation, no DKIM signature validation, and no analysis of actual message flows. Its conclusions are derived exclusively from DNS-published authentication policies.


\section{Functionalities}
\subsection{Client-side DNS quesrying}
All DNS resolution logic is performed entirely within the browser through asynchronous HTTP requests to the Google Public DNS DoH JSON service. TXT and CNAME records are dynamically retrieved. For the evaluation of DMARC records, the tool first attempts to resolve the record \texttt{\_dmarc.<domain>} as a CNAME record. If the CNAME record is present, the process will follow the result and subsequently resolve the TXT record of the effective name.

The function \texttt{analyzeDmarc} has been designed to execute a specific test for CNAME Redirection. The function begins by querying \texttt{\_dmarc.[domain]} with a query type of "CNAME". The function then proceeds to follow the target to retrieve a response, provided a response is found (i.e., DNS type is 5). The function is vital in auditing domains that delegate DMARC authority to a third-party service provider.
It appears that the analysis process is limited to a single-level CNAME follow, without any explicit inclusion of a redirection chain. It is, therefore, evident that DNSSEC authentication is left to the external DNS resolver service.


DKIM evaluation is implemented through heuristic selector enumeration. Recognizing that DKIM records are published at unpredictable selectors (e.g., \texttt{selector.\_domainkey}), the tool implements a brute-force discovery algorithm. The source code contains a hardcoded dictionary of common selectors: (e,g. ['default', 'mail', 'dkim', etc...]). The tool then iterates through this list, generating speculative queries to identify active keys without requiring prior knowledge of the selector.
Finally, this process confirms selector existence but cryptographic key length is not validated, the "\texttt{p=}" parameter is not inspected and signature verification is not performed.
On the other hand, SPF analysis is limited to record discovery and basic structural assessment.

\subsection{Record parsing and validation}
Once TXT records are retrieved, the tool parses them according to a tag-based tokenization process. 
The tool checks if \texttt{v=DMARC1} is present, checks validation of policy values (none, quarantine, reject), parses the optional tags (such as \texttt{sp}, \texttt{pct}, \texttt{aspf}, \texttt{adkim}, etc.) and then detects if multiple DMARC TXT records or malformed tag structures are present. As a result, domains using experimental or extension tags may be incorrectly classified as non-compliant, representing a methodological strictness that should be explicitly acknowledged in technical evaluation.

\subsection{External reporting authorization verification}
The tool implements verification logic for external DMARC reporting destinations. When a \texttt{rua} or \texttt{ruf} address references a domain different from the analyzed domain, the tool checks for the presence of a TXT record at:


\texttt{<requesting-domain>.\_report.\_dmarc.<report-domain>}


If a corresponding "\texttt{v=DMARC1}" TXT record is present, it will be interpreted as valid delegation. If the record is missing, it flags the error: "External reporting to [domain] is not authorized."


\section{Comparative evaluation with other tools}
When compared to other tools in the DMARC ecosystem, DMARC Forensics occupies a distinct operational niche. Unlike enterprise monitoring platforms that ingest DMARC aggregate reports (RUA) and correlate authentication outcomes over time, DMARC Forensics performs no telemetry ingestion. Its analysis is entirely static and configuration-based.

While other tools (such as "dmarcian") excels at visualizing XML aggregate reports over time, DMARC Forensics is engineered for infrastructure auditing. Its use of "dns.google" provides a "neutral ground" truth, free from the caching artifacts that often plague server-side tools. The client-side execution ensures that the "observer effect" is minimized; the investigator does not leave a footprint on a third-party forensic vendor's logs.

Compared to lightweight DNS diagnostic services, it provides deeper protocol interpretation, including:
\begin{itemize}
	\item CNAME-following logic for DMARC records,
	\item External reporting authorization checks,
	\item Alignment mode assessment,
	\item Structured compliance classification.
\end{itemize}

Even if it lacks other capabilities, such as abuse detection visibility, source IP telemetry and SIEM integration capabilities.
The tool is therefore most appropriate for point-in-time configuration audits, compliance demonstrations, and educational or investigative contexts where deterministic DNS state evaluation is sufficient.

\section{User experience: strengths and weaknesses}
From a usability and security engineering perspective, several design characteristics deserve to be mentioned.

Among the pros there are:
\begin{itemize}
\item \textbf{Forensic Transparency}: tool provides raw DNS Response (JSON format) in the logs. This transparency is vital for explaining findings in court (e.g., proving a record existed but was malformed).
\item \textbf{Speed}: the use of \texttt{Promise.all} allows for checking 20 domains in nearly the same time as checking one, limited only by the browser's maximum concurrent connection limit to dns.google.
\item \textbf{Heuristic Reconnaissance}: the automated DKIM selector search effectively "guesses" hidden configurations, a feature often absent in free tiers of commercial tools.
\item Secure DOM manipulation using \texttt{textContent}, reducing XSS exposure risk.
\item Structured export capabilities including XLS and detailed TXT logs.
\item Transparent display of actionable remediation guidance.
\end{itemize}

On the other hand, there are some limitations as well:
\begin{itemize}
\item \textbf{Volatile State}: with a client-side SPA, refreshing the page clears all evidence. There is no persistent database.
	
\item \textbf{Rate Limiting}: there is a hard dependency on a single external resolver (Google public DNS), thus an heavy usage (e.g., checking hundreds of domains) may trigger Google's API rate limits (\texttt{HTTP 429}), as the requests originate from the user's IP.

\item Strict classification model that may over-report non-compliance.

\item \textbf{Absence of full SPF and DKIM semantic evaluation}.

\item \textbf{No Historical Data}: The tool captures the state now, so it cannot prove what the record was yesterday (unlike Passive DNS databases).
\end{itemize}

\section{Integration of forensic evidence}
One of the most technically significant aspects of the tool is its evidentiary potential. The application records: a timestamp for each analysis, the exact DoH query URL used for resolution and the raw JSON block returned by the resolver.
The code function \texttt{downloadTxtFile} generates a file named \texttt{dmarc-log-\${timestamp}.txt}. The log does not merely save the final table, it instead appends the raw transaction data during the analysis loop (\texttt{textLog+=...}).
The timestamp follows an ISO 8601 format (e.g., \texttt{2023-10-27T10:00:00.000Z}).
Queries integrity are kept by recording the exact URL queried (e.g., \texttt{https://dns.google/resolve?name=\_dmarc.example.com...}). The full JSON response from Google is recorded, including the \texttt{Answer} array, \texttt{TTL} (Time To Live), and \texttt{Status} codes.

These elements can be exported and preserved. This enables what may be termed configuration crystallization: the ability to capture a reproducible snapshot of a domain's authentication posture at a specific point in time.

As previously mentioned, digital evidence must be acquired in a manner that ensures its integrity and repeatability. The concept of "crystallization" refers to freezing the digital scene to prevent alteration.
Such crystallization can support the demonstration of enforcement level (e.g., p=reject vs p=none), the verification of reporting configuration and a proof of DNS state at analysis time.


In conclusion, the DMARC Forensics tool should be formally classified as:

A browser-executed, DNS-based DMARC compliance and spoofing exposure analyzer that performs deterministic policy evaluation using DNS-over-HTTPS queries, without ingesting runtime email authentication telemetry.

Its methodological strengths lie in transparency, configuration strictness, and evidentiary export capability. Its limitations derive from its stateless design and its exclusive reliance on DNS-published policy data.


