DMARC

DMARC, Domain-based Message Authentication, Reporting and Conformance, is a DNS-record policy that instructs recipients on how to handle messages claiming to originate from a domain but failing SPF and DKIM alignment checks. DMARC aligns these results with the visible “From” domain in email headers—what users see in their mail clients. It can also request recipients send aggregate reports back to the domain owner. Note that DMARC does not encrypt emails or automatically block all fraudulent messages; its effectiveness depends on proper configuration, recipient support, and correct management of legitimate sending systems.

The DMARC record is published as a TXT DNS entry under a standard name associated with the domain. Key parameters include the policy for non-compliant messages, alignment mode, reporting percentages, and addresses. Policies can begin in monitoring mode, progress to quarantine, and eventually reach rejection, following a controlled progression. Domain owners should analyze reports before tightening policies: forgotten business services or misconfigured newsletter providers may cause legitimate emails to fail. Increasing severity without inventory can lead to delivery issues.

SPF, DKIM and Alignment

A message might pass SPF or DKIM, but DMARC requires at least one mechanism to have an aligned domain with the “From” header according to the chosen mode. For example, a provider may sign with their own domain: the DKIM signature is technically valid but may not align with the brand shown to the recipient. SPF can fail when a message is forwarded because the delivering IP differs from the original infrastructure. These behaviors should be tested using real-world flows such as regular mail, newsletters, tickets, invoices, CRM messages, forwards, and marketing tools.

DMARC aggregate reports provide counts and results by source IP and domain, helping identify authorized systems, misconfigurations, or unexpected senders. They are not copies of received emails but summary technical data. Reporting addresses must be managed and secured, as they may reveal infrastructure details and email volumes. Report quality and detail vary by recipient. A high volume of failures is a signal to investigate, but does not automatically indicate abuse—it may stem from forwards, DNS errors, outdated signatures, or legacy configurations.

Prudent Implementation

Before publishing a restrictive DMARC policy, inventory all systems sending email for the domain and configure SPF and DKIM per official provider guidelines. Then collect reports over a representative period, classify IPs, and resolve any legitimate non-aligned flows. Proceed in stages, documenting changes and monitoring deliverability and tickets. DNS records must be concise and accurate: SPF has lookup limits, and DMARC should not be duplicated under multiple TXT records with the same name. If the domain uses subdomains, verify inherited policies and any exceptions.

DMARC is especially useful for preventing simple domain spoofing and gaining visibility into email sources. It does not prevent attackers from using similar domains, compromising authenticated accounts, or registering lookalike domains; such cases require additional controls, user authentication, and monitoring. A DMARC “pass” result does not guarantee message safety. In summary, DMARC coordinates SPF and DKIM with a public policy and reporting mechanism but should be introduced gradually to protect the domain without blocking legitimate mail.