Chapter 5: Defining a DMARC Policy

This chapter focuses on defining an effective DMARC policy by explaining the difference between aggregate and forensic DMARC reports and SPF/DKIM alignment. It also sheds light on the reading of a DMARC record and the 3 DMARC policies.

Understanding the difference between Aggregate and Forensic Reports

DMARC Aggregate Reports

DMARC aggregate reports are obtained with details on the source and authenticity of emails issued on behalf of a domain that reveals information on the following points:

  • If the emails authenticate against DKIM (DomainKeys Identified Mail) and SPF (Sender Policy Framework).
  • The transmitting domain for DKIM/SPF.
  • The originator of a message.
  • Messages that were sent on a given day.
  • The DMARC result.

DMARC Aggregate reports are timely sent in an XML file format and do not include any details on the emails themselves. You may analyze the content from aggregate reports to recognize all valid email sources, as well as the sender’s capabilities for sending out emails and authorizing them suitably.

DMARC Forensic Reports

Forensic reports are received every time an email from your domain fails both SPF & DKIM authentications. A forensic report is used to conduct a thorough investigation of emails spoofing your domain since it contains message-level data, including:

  • Email addresses of the sender and recipient
  • Subject lines for emails
  • The message ID and message time
  • Information about IP (Internet Protocol), ISP (Internet Service Provider), and domain
  • Results from SPF, DKIM, and DMARC

Data collected in forensic reports reveal trouble associated with a particular source, mailstream, or transmitting IP.

In summation, aggregate reports assist in identifying and authorization of authentic emails, whereas forensic reports aid in the analysis of falsified emails and the identification of attack traits.

SPF & DKIM Alignment Defined

SPF and DKIM alignment mean the matching of domains. A DMARC requires validating the authenticity of the sender’s address as the message’s legitimate sender, which is accomplished by authenticating the sender’s DKIM and SPF.

  1. DKIM  Alignment: The DomainKeys Identified Mail alignment checks if the root domain of the email used to construct the signature (specified in “d =” argument) is aligned with, i.e., matches the domain in the “From” header.
  1. SPF Alignment: The Sender Policy Framework Alignment checks the alignment, i.e., the matching of the domains specified in the two headers of the email, namely the “From” and “MailFrom / Return Path.”

You can use the “aspf” and “adkim” parameters for SPF and DKIM alignment, respectively, in a DMARC record to stress the severity of the alignment, i.e., relaxed or strict alignment for flexible or absolute matching of the domains. By default, the option is set to “relaxed.”

Configuring SPF and DKIM alignments for authentication adds an extra degree of security to your outbound emails, and pairing SPF and DKIM for authentication is a powerful strategy for preventing malicious emails from reaching the inbox.

Reading a DMARC record

A DMARC record notifies email recipients if a domain has been configured for DMARC and includes the domain owner’s policy. A DMARC record is enclosed in the <policy_published> tag and encloses subtags that provide information, such as:

  • The <domain> tag encloses the name of your domain
  • The <adkim> tag contains information about relaxed (r) or strict (s) DKIM alignment
  • The <aspf> tag contains information about relaxed (r) or strict (s) SPF alignment.
  • The <p> tag indicates the requested policy (none, quarantine, or reject) when an email fails DMARC authentication
  • The <sp> tag is for subdomain policy used to indicate a separate DMARC record for the subdomain.
  • The <pct> tag is used to specify the percentage of emails to be checked for authentication in an email stream but is optional.

The 3 DMARC Policies

There are 3 DMARC policies for handling emails that fail authentication, which are:

  1. Monitor: Monitor, also called none policy, is the most basic DMARC policy and specified by “p=none.” The monitor enables monitoring and sends all emails (including failed authentication) to maintain regular traffic flow. The monitor generates data on your domain usage and helps you understand how DMARC functions by revealing the emails handled by a specific email provider and the ones that failed verification.
  1. Quarantine: The quarantine policy is specified by “p=quarantine,” which sends unqualified emails (those that fail authentication) to the recipient’s trash or spam folder. The quarantine policy is advised as a second level in DMARC implementation. The quarantine policy prevents your domain from being used for malicious purposes and helps you control misclassification. As a result, genuine emails and data can be analyzed that were banned and spammed due to configuration errors.
  1. Reject: The Reject policy prevents unqualified emails (those with failed authentication) from reaching their intended recipient. The reject policy, specified by “p=reject,” is the most effective DMARC policy against cybercrime. Still, it requires a more significant stage of sophistication to ensure that authentic emails are not rejected. The reject policy requires proper allowlisting permissions for third-party senders such as CRM systems or Email Service Providers.

⏪ Chapter 4: What is DKIM?

Quick Links

Understanding Phishing & Other Email Borne Cyber Threats
What is DMARC?
What is SPF?
What is DKIM?
Defining a DMARC Policy ☜

Ready to Start?

DMARC Report is designed for large scale reporting needs, with a combination of domains and message volume.

Get Started