Interpreting DMARC, SPF, and DKIM Authentication Reports

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. Receivers check it against the envelope sender (MAIL FROM or Return-Path) domain, not the visible From address. 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 means mail from any other server should fail SPF; what the receiver then does with it is up to the receiver, guided by your DMARC policy.

DKIM (DomainKeys Identified Mail)

DKIM is a protocol that uses cryptographic signatures to verify that an email message was signed by the domain in the signature and that the signed headers and body haven'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.

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 DMARC, and where to send reports. A message passes DMARC when SPF or DKIM passes using a domain that aligns with the From domain; it fails only when neither gives an aligned pass.

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 DMARC (no aligned SPF or DKIM pass) 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 if either SPF or DKIM fails to give an aligned pass, rather than only when both fail, which is the default ("fo=1")

The following diagram illustrates the DMARC policy enforcement and reporting process:

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:

• Each sending IP address and how many messages it sent using your domain
• Whether those messages passed SPF and DKIM with an aligned domain (policy_evaluated)
• The DMARC policy action applied (none, quarantine, or reject)
• The domains actually used for SPF and DKIM checks (auth_results)

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>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>198.51.100.2</source_ip>
      <count>100</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>
      <spf>
        <domain>example.com</domain>
        <result>fail</result>
      </spf>
    </auth_results>
  </record>
</feedback>

To make sense of these reports, you can use a DMARC report analyzer tool or parse the XML data yourself. Look for rows where both dkim and spf under policy_evaluated are "fail". In the example above, 500 messages from 192.0.2.1 passed, while 100 messages from 198.51.100.2 failed both checks and were rejected. If a failing IP belongs to one of your own services, fix its SPF or DKIM setup; if it's unknown, it's probably spoofing that your policy is stopping. If failing mail shows a disposition other than your policy, the receiver has applied a local override (often for forwarded or mailing-list mail), and the report may include a reason.

Forensic Reports

Forensic reports, also known as failure reports, are sent shortly after an individual message fails, to the address specified in the "ruf" field of your DMARC record. They can include the headers (and sometimes the content) of the failed message, allowing you to investigate and diagnose authentication issues more closely.

Failure reports are not XML. They use the Abuse Reporting Format (ARF, RFC 6591): an email with a short human-readable part, a machine-readable part, and a copy of the failing message's headers. A trimmed example of the machine-readable part:

Feedback-Type: auth-failure
User-Agent: ExampleReceiver/1.0
Version: 1
Original-Mail-From: <bounce@example.net>
Arrival-Date: Tue, 4 May 2021 12:30:00 -0400
Source-IP: 203.0.113.2
Reported-Domain: example.com
Auth-Failure: dmarc
Authentication-Results: mx.example.org; dmarc=fail header.from=example.com;
  spf=fail smtp.mailfrom=example.net; dkim=fail header.d=example.com

Here the message claimed to be from example.com, was sent from an IP that isn't in your SPF record, and carried a DKIM signature that didn't verify, so it failed DMARC. If the source is one of your own services, fix its configuration; if not, it's spoofing that your policy is handling. Treat failure reports as a bonus: many large mailbox providers, including Gmail, don't send them at all, and those that do often redact them for privacy. Aggregate reports remain your main source of data.

Reading SPF and DKIM Results

SPF and DKIM don't produce reports of their own. You see their results in two places: in the auth_results section of DMARC aggregate reports, and in the Authentication-Results header of any message you receive. When reviewing them, check:

• Pass or fail: An SPF fail usually means a sending service is missing from your SPF record or the record exceeds the 10 DNS lookup limit. A DKIM fail usually means signing isn't set up, the selector's public key isn't published correctly, or the message was modified after signing.
• Alignment: A pass only counts for DMARC if the domain matches your From domain. SPF is checked against the envelope sender (Return-Path) domain, and DKIM against the d= domain in the signature. With relaxed alignment, a subdomain such as mail.example.com aligns with example.com.
• Forwarding: Forwarded mail often fails SPF because it arrives from the forwarder's IP. DKIM usually survives, which is why every source should sign with your own domain.

Conclusion

Start every domain with a DMARC record at p=none and an rua address, then use the aggregate reports to list every service sending as your domain. Fix SPF and DKIM for each legitimate source until it passes with an aligned domain, and only then move to p=quarantine and p=reject. A DMARC reporting tool makes the XML far easier to read, and sending a test message through each service confirms the fixes work before you tighten your policy.