Interpreting DMARC, SPF, and DKIM Authentication Reports

A guide to understanding and analyzing the reports generated by email authentication protocols to improve deliverability and security.

SpamBarometer Team
April 5, 2025
9 min read
Deliverability Authentication Best Practices Technical
Understanding Metrics

Email authentication protocols like DMARC, SPF, and DKIM are critical for ensuring the security and deliverability of your email communications. However, interpreting the reports generated by these protocols can be complex and overwhelming. This comprehensive guide will walk you through the process of understanding and analyzing DMARC, SPF, and DKIM authentication reports, providing you with the knowledge and tools to improve your email performance and protect your domain from abuse.

Understanding Email Authentication Protocols

Before diving into the reports, it's essential to have a solid grasp of how DMARC, SPF, and DKIM work together to authenticate email messages.

SPF (Sender Policy Framework)

SPF is a protocol that allows domain owners to specify which mail servers are authorized to send email on behalf of their domain. This is done by publishing a TXT record in the domain's DNS settings that lists the permitted IP addresses or hostnames.

Here's an example of an SPF record:

example.com IN TXT "v=spf1 ip4:192.0.2.0/24 ip6:2001:db8::/32 include:example.net -all"

This record states that only mail servers with IP addresses in the range 192.0.2.0/24 or 2001:db8::/32, as well as those specified in the SPF record for example.net, are allowed to send emails for the domain example.com. The "-all" at the end indicates that any other mail servers should be rejected.

The following diagram illustrates the basic SPF authentication process:
Diagram 1
Diagram 1
The diagram should show: 1. A mail server attempting to send an email on behalf of example.com 2. The receiving mail server retrieving the SPF record for example.com from DNS 3. The receiving mail server comparing the sending mail server's IP address to the permitted IP addresses in the SPF record 4. The email being accepted or rejected based on the SPF check result

DKIM (DomainKeys Identified Mail)

DKIM is a protocol that uses cryptographic signatures to verify that an email message was sent by an authorized mail server and that its content hasn't been altered in transit. The sending mail server adds a digital signature to the email headers, which the receiving mail server can validate using a public key published in the sending domain's DNS.

Here's an example of a DKIM signature header:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=20210101; c=relaxed/relaxed;
                q=dns/txt; t=1620135000; h=from:to:subject:date:message-id;
                bh=lFBEJkrlFGuCsUZtXgUk5p5j8LGwVQjL6xoYeREVphk=;
                b=tNGdHrM1J5WC5fkxPShjbFyvM/zF6ZL6EKhGUwmPVGxEgwBWm6wNq6d9xK6WB2zGw
                  Qr6Kg6NN4ckCp84D6ioGE+9TRjgpg7oZUzJOxnTu3f0RWQs/4OMxLc2SF9t5f0eiNk
                  jYLfJQZt0xVj3UtK/0bwzLw7UqTsakfJ1EzAn9+E=

The receiving mail server extracts the "d=" (domain) and "s=" (selector) values from the DKIM signature header and retrieves the corresponding public key from the domain's DNS. It then uses this key to verify the signature and ensure the email's authenticity and integrity.

The following diagram illustrates the DKIM signing and verification process:
Diagram 2
Diagram 2
The diagram should show: 1. The sending mail server generating a DKIM signature for the email using the private key 2. The DKIM signature being added to the email headers 3. The receiving mail server retrieving the public key from the sending domain's DNS based on the selector and domain values in the DKIM signature 4. The receiving mail server using the public key to verify the DKIM signature and authenticate the email

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC builds upon SPF and DKIM to provide a higher level of email authentication and policy enforcement. Domain owners publish a DMARC policy in their DNS as a TXT record, which specifies how receiving mail servers should handle messages that fail SPF and/or DKIM checks, and how they should report these failures back to the domain owner.

Here's an example of a DMARC record:

_dmarc.example.com IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com; fo=1"

This record states that:

  • The DMARC policy is in version 1 ("v=DMARC1")
  • Messages that fail SPF and/or DKIM should be rejected ("p=reject")
  • Aggregate reports should be sent to dmarc-reports@example.com ("rua=mailto:dmarc-reports@example.com")
  • Forensic reports should be sent to dmarc-forensics@example.com ("ruf=mailto:dmarc-forensics@example.com")
  • Forensic reports should be generated for both SPF and DKIM failures ("fo=1")
The following diagram illustrates the DMARC policy enforcement and reporting process:
Diagram 3
Diagram 3
The diagram should show: 1. The receiving mail server retrieving the DMARC policy for the sending domain from DNS 2. The receiving mail server evaluating the SPF and DKIM results for the email 3. The receiving mail server applying the DMARC policy based on the SPF and DKIM results (e.g., reject, quarantine, or none) 4. The receiving mail server generating and sending aggregate and/or forensic reports to the designated email addresses in the DMARC record

Interpreting DMARC Reports

DMARC reports provide valuable insights into your email authentication performance and can help you identify and mitigate issues that may impact your deliverability or leave your domain vulnerable to spoofing.

Aggregate Reports

Aggregate reports are generated daily by receiving mail servers and sent to the address specified in the "rua" field of your DMARC record. These reports provide a high-level overview of your email authentication results, including:

  • The total number of messages processed
  • The number and percentage of messages that passed or failed SPF, DKIM, and DMARC checks
  • A breakdown of the DMARC policy actions applied (none, quarantine, or reject)
  • The top sending IP addresses and hostnames for your domain

Here's an example of an aggregate report in XML format:

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <report_metadata>
    <org_name>Example Mail Receiver</org_name>
    <email>dmarc-reports@example.org</email>
    <report_id>1620135000</report_id>
    <date_range>
      <begin>1620050400</begin>
      <end>1620136799</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>reject</p>
    <sp>reject</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>192.0.2.1</source_ip>
      <count>500</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <row>
      <source_ip>198.51.100.2</source_ip>
      <count>100</count>
      <policy_evaluated>
        <disposition>reject</disposition>
        <dkim>fail</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
  </record>
</feedback>

To make sense of these reports, you can use a DMARC report analyzer tool or parse the XML data yourself. Look for any unexpected failures or misalignments between your SPF and DKIM configurations and your DMARC policy. For example, if you have a "p=reject" policy but see a significant number of messages with a "disposition" of "none" or "quarantine," you may need to investigate and correct any SPF or DKIM issues.

The following diagram shows an example of how to visually represent and interpret aggregate DMARC report data:
Diagram 4
Diagram 4
The diagram should include: 1. A pie chart showing the percentage of messages that passed or failed SPF, DKIM, and DMARC checks 2. A bar chart showing the count of messages for each DMARC policy disposition (none, quarantine, reject) 3. A table or list of the top sending IP addresses or hostnames and their respective message counts 4. Annotations or callouts highlighting any notable trends, anomalies, or misalignments in the data

Forensic Reports

Forensic reports, also known as failure reports, are generated in real-time when a message fails SPF, DKIM, or both, and are sent to the address specified in the "ruf" field of your DMARC record. These reports include the full headers and content of the failed message, allowing you to investigate and diagnose authentication issues more closely.

Here's an example of a forensic report in XML format:

<?xml version="1.0" encoding="UTF-8"?>
<feedback>
  <report_metadata>
    <org_name>Example Mail Receiver</org_name>
    <email>dmarc-forensics@example.org</email>
    <report_id>1620135000.1</report_id>
    <date_range>
      <begin>1620135000</begin>
      <end>1620135000</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>reject</p>
    <sp>reject</sp>
    <pct>100</pct>
    <fo>1</fo>
  </policy_published>
  <record>
    <row>
      <source_ip>203.0.113.2</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>reject</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>fail</result>
        <human_result>Failed DKIM verification</human_result>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <result>softfail</result>
      </spf>
    </auth_results>
    <reported_header>
      Received: from [203.0.113.2] (HELO example.net)
        by mx.example.org with ESMTPS id 1620135000.1
        for <recipient@example.org>;
        Tue, 4 May 2021 12:30:00 -0400
      DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=20210101;
        c=relaxed/relaxed; q=dns/txt; i=@example.com;
        t=1620135000; h=From:To:Subject;
        bh=lFBEJkrlFGuCsUZtXgUk5p5j8LGwVQjL6xoYeREVphk=;
        b=tNGdHrM1J5WC5fkxPShjbFyvM/zF6ZL6EKhGUwmPVGxEgwBWm6wNq6d9
         xK6WB2zGwQr6Kg6NN4ckCp84D6ioGE+9TRjgpg7oZUzJOxnTu3f0RWQs
         /4OMxLc2SF9t5f0eiNkjYLfJQZt0xVj3UtK/0bwzLw7UqTsakfJ1
Was this guide helpful?
Related Tools
Try SpamBarometer Test
Need More Help?

Our team of email deliverability experts is available to help you implement these best practices.

Contact Us