What is this article for?

This article aims to give information which may assist you when analysing a DMARC report.

Brief summary on DMARC

DMARC or Domain-based Message Authentication Reporting and Conformance, is a technical feature which can be implemented so that messages are authenticated according to SPF and DKIM alignment.

How to setup DMARC for your domain and how this can influence/effect the DMARC report

To setup a DMARC, you must first create a DMARC TXT DNS record for your domain. From here you can then specify how DMARC influences email. In a DMARC record, you specify tag-value pairs which tell the email server what to do. For example, lets look at the following DMARC record.

>nslookup -q=txt _dmarc.example.com          
"v=DMARC1;p=reject;pct=100;fo=1;aspf=s;rua=mailto:user@example.com;ruf=mailto:user@example.com"
Tag Description
Version (v=)  This tag represents the DMARC protocol version and is required. As seen above it is specifying version 1.
Policy (p=) This is another required tag which specified the policy for the domain. This tag defines what will happen upon authentication. There are 3 policy options, p=none, p=quarantine and p=reject.
Percentage (pct=)  This tag is not required although it specifies the percentage of emails which will be subject to filtering. Furthermore if the tag is set to 100, then every email will be filtered by the recipient.
Failure Reporting Options (fo=)  This tag refers to how forensic reports are created and presented to DMARC users.
aspf (aspf=)  This tag specifies the SPF alignment configuration. This can be either strict (aspf=s) or relaxed (aspf=r). If the tag is not specified then the SPF alignment for DMARC is relaxed by default.
adkim (adkim=)  This tag specifies the DKIM alignment configuration. This can be either strict (adkim=s) or relaxed (adkim=r). If the tag is not specified then the DKIM alignment for DMARC is relaxed by default.
rua tag (rua=)  This tag specifies the email address/URI of the mailbox which should receive the aggregate DMARC reports.
ruf tag (ruf=)  This tag specifies the email address/URI of the mailbox which should receive the failure/forensic DMARC reports.

**For further info, an aggregated DMARC report will help you identify and/or authorise legitimate emails. Whereas a forensic report will aid you in analysing spoofed emails.

Now that we understand DMARC and its associated tags more, lets breakdown an actual DMARC report.

Example aggregate report

I was able to receive this DMARC report as I sent email to a gmail address (hence why the <org_name> field states http://google.com). Google or Gmail, knew where to send it as this is what was specified in my DMARC DNS record.

<?xml version="1.0" encoding="UTF-8" ?>
  <feedback>	
    <report_metadata>
      <org_name>google.com</org_name>    <---- ISP/ESP/Organisation in which you sent email to.
      <email>noreply-dmarc-support@google.com</email>    <---- Contact information from the sending org.
      <extra_contact_info>https://support.google.com/a/answer/2466580</extra_contact_info>    <---- Contact information from the sending org.
      <report_id>1234567890</report_id>
      <date_range>
	<begin>1659052800</begin>    <---- These two fields in the date range show the beginning (creation) and end date of the report (in Unix time).
	<end>1659139199</end>
      </date_range>
    </report_metadata>
    <policy_published>                <---- These fields/tags defines the DMARC DNS record tag-value pairs. (Refer to above table for more info).
      <domain>example.com</domain>    <
      <adkim>r</adkim>                <
      <aspf>s</aspf>                  <
      <p>reject</p>                   <
      <sp>reject</sp>                 <
      <pct>100</pct>                  <
    </policy_published>               <---- These fields/tags defines the DMARC DNS record tag-value pairs.
    <record>
      <row>
        <source_ip>192.168.0.1</source_ip>    <---- The sender IP of the message.
        <count>1</count>    <---- How many times a message as sent from the source_ip.
        <policy_evaluated>                    <---- This section of the report is a DMARC result summary for the individual record itself.
          <disposition>none</disposition>     <---- This field refers to what a receiving mail server should do if the message does not pass the rules specified in the DMARC record. E.g. relates to the policy flag, hence why it states none as DMARC passed. As my DMARC DNS record states 'p=reject', this is what it would've stated if DMARC failed.
          <dkim>pass</dkim>    <---- The DKIM and SPF section here show whether or not they passed DMARC.
          <spf>fail</spf>      <---- This failed due to the strict alignment configured for aspf. We can see below in the SPF auth_results that the domain isn't an exact match to the domain in the policy_published which is why this here states fail.
        </policy_evaluated>
      </row>
      <identifiers>
        <header_from>example.com</header_from>    <---- This section is self-explanatory and shows the Mail From address.
      </identifiers>
      <auth_results>    <---- The auth_results tag shows the individual DKIM and SPF results.
        <dkim>
          <domain>example.com</domain>    <---- If DKIM is enabled (which it should be) you should see your domain here.
          <result>pass</result>           <---- The result of DKIM, this can tell you if the email has been tampered in transit or not.
      <selector>b6j8ksnghzzkajzkrecnq62c3tapnr5m</selector>    <---- This section will show the DKIM selector chosen.
	</dkim>
	<dkim>
      <domain>amazonses.com</domain>    <---- SES signs every email by default, this can be ignored (this DKIM record is only here as I used the Amazon SES service to send my email).
      <result>pass</result>
      <selector>o6ptibvfbl2hpdhrxd7klizy2rsobquz</selector>
	</dkim>
	<spf>
      <domain>custommailfrom.example.com</domain>    <---- This will be the Mail FROM or a Custom MAIL FROM if this has been configured (Please note in a lower example, the SPF domain states an amazonses.com domain, this is because they are the service I used to send email).
      <result>pass</result>
	</spf>
      </auth_results>
    </record>
    <record>    <---- Another example record.
      <row>
	<source_ip>192.168.0.2</source_ip>
	<count>1</count>
	<policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
	</policy_evaluated>
      </row>
      <identifiers>
	<header_from>example.com</header_from>
      </identifiers>
      <auth_results>
	<dkim>
      <domain>example.com</domain>
      <result>pass</result>
      <selector>b6j8ksngehzkajzdkrcnq62ca3trnr5m</selector>
	</dkim>
	<dkim>
      <domain>amazonses.com</domain>
      <result>pass</result>
      <selector>o5ptibafbllepdhtxr7klizy2rlobquz</selector>
	</dkim>
	<spf>
      <domain>ap-southeast-2.amazonses.com</domain>
      <result>pass</result>
	</spf>
      </auth_results>
    </record>
  </feedback>

In a nut-shell, each record in the DMARC report summarises the following:

  • The servers or third-party senders that are sending mail for your domain.
  • The total number of messages sent from a single IP address.
  • The authentication results from SPF, DKIM and DMARC on each message.
  • Any further actions taken by the recipient server.
  • The report also states the information which can be found in the email headers (such as Mail From/DKIM selectors etc).

Other important thing/s to take away from the report

What you should do after reviewing your DMARC report/s

  • Configure and review your SPF DNS record.
  • Potentially black-list IPs or domains which are attempting to send mail on your behalf that are not authenticated.
  • Configure the DMARC policy to either reject or quarantine the messages as a lot of DMARC records are configured as p=none which is not utilising DMARC to its fullest potential.