Nomenclature

• Domain Owner:   The administrator for a domain which has published a DMARC policy and is receiving DMARC aggregate reports in response to the “rua” term of that policy.
• Owned Server:   A mail system which originates messages under control of the domain owner.   Outbound messages use the same domain or organization for both SMTP Mail From and message From addresses.   Owned servers should be configured to provide both aligned SPF Pass and aligned DKIM Pass
• ESP Server:   An Email Service Provider originates messages as an agent for the domain owner.   The SMTP Mail From domain indicates the ESP and the message From domain indicates the client.   ESP Messages should produce unaligned SPF Pass on the SMTP Mail From address and aligned DMARC Pass based on a client domain signature applied by the ESP.
• Forwarding Server without SMTP changes:   A mail system which receives a message intended for one recipient and relays it to a recipient in a different domain.   Because the SMTP Mail From address is not modified, the message will lose SPF Pass.    As long as the message is unmodified, the message will still produce DMARC Pass based on an aligned DKIM signature.
• Forwarding Server without SMTP changes:   A mail system which receives a message intended for one recipient and relays it to a recipient in a different domain.   Because the SMTP Mail From address is modified, the message will produce unaligned SPF Pass.    As long as the message is unmodified, the message will still produce DMARC Pass based on an aligned DKIM signature.
• Intermediate Server with content changes:   A mail system which receives messages and alters content in a way that invalidates DKIM signatures.   If DMARC is evaluated after these changes, the SPF test will not pass because it is based on the Intermediate Server’s IP address, and the DKIM test will not pass because of the content changes.  However, a message which was originated by an authorized server should include an aligned but unverified DKIM signature.
• Reporting Entity:   The mail system which generates a DMARC report to the domain owner.
• Benign Impersonator:   A mail system which originates mail for the domain outside control of the domain owner, but does so for acceptable purposes.   Benign impersonators may be annoying, but they can be ignored.
• Malicious Impersonator:   A mail system which originates mail for the domain outside control of the domain owner, but does so for unacceptable purposes.   If malicious impersonators use legitimate infrastructure components, an abuse report sent to the infrastructure owner may be sufficient to get the impersonator de-platformed.  If malicious impersonators use their own infrastructure, an abuse sent to a reputation block list or law enforcement may be able to disrupt the attacker.

Suggested configuration steps for receiving DMARC reports

• Create a dedicated email account to receive reports
• Update DMARC policy in DNS to add a term for: rua=<emailaddress>
• Configure a database to hold reports.   The reports break naturally into three tables:   report header, server results, and DKIM results.   A fourth table, based on the static portion of the report header, is desirable for associating multiple reports from the same reporting entity.
• Create a stored procedure to parse XML reports into SQL data.
• Create a mechanism to extract report attachments from email messages
• Create a script to convert compressed attachment files into uncompressed XML files
• Create a script to load each XML file using the stored procedure
• Create data cleanup tools to purge processed email messages, purge processed attachment files, purge processed XML files, and purge obsolete SQL data.  None of this data has much long-term value.

Preparing to analyze Results

• Some reporting entities provide one report for each recipient domain.  The recipient domain is identified in the “file domain” field.  [Yahoo servers]
• Some report entities provide a comprehensive report, but a separate server result record is provided for each recipient domain.  The recipient domain is identified in the “envelope_to” field.   [Outlook.com servers]
• Some reporting entities represent a single organization, and the recipient domain can be inferred by matching report header data to MX server names in the outbound message log.   Once this match is performed manually, the recipient domain is inserted into the reporting entity record.
• Some reporting entities provide a comprehensive report with no breakout between recipient domains.  When this is the case, the recipient domain is unknowable.

• If the report indicates SPF was tested against a different domain, then that domain appears to be the forwarder (or impersonator.)   However, if the SPF result is not Pass, the identity may be fraudulent.
• If the report reports a DKIM signature for a different domain, that domain appears to be the forwarder.   However, if the signature cannot be verified, the identity may be fraudulent.   In some cases, multiple verified DKIM signatures may be present, creating ambiguity.
• In a few cases, the Reverse DNS server name may be sufficient to identify the forwarding domain.
• When these techniques fail, the forwarding domain will be unknowable.

Categorizing the Results

• Normal direct message:   The message was received directly from an owned or ESP server to the reporting entity.    The message should have both SPF Pass and DKIM Pass.
• Normal Forward without changes:   The message produces DMARC pass based on DKIM Pass but not based on SPF Pass.
• Normal Forward with changes (most commonly, messages posted to a mailing list):   The message will produce a DMARC failure, but the failure is outside control of the domain owner.   If the Reporting Entity indicates that the message was blocked based on DMARC failure, and the domain owner wants the message accepted, a problem results.  The domain owner may be able to work with the intended recipient to request a local policy exception in the recipient’s domain.   If this cannot be accomplished, the domain owner may need to weaken his DMARC policy to p=”none”, on the expectation that this will cause the Receiving Entity to stop requiring DMARC Pass.
• Configuration Errors:    A message stream which consistently fails to produce both SPF Pass and aligned DKIM Pass, even when received directly by the Reporting Entity.  The domain owner should take action to ensure that the configuration problem is corrected.
• False error:    The message was pre-processed by an Intermediate Server acting as an incoming gateway.  The gateway makes intentional content changes as part of its defense measures, then  DMARC is evaluated after the message has been altered.   (This problem is currently unique to Outlook.com.)   Outlook.com ignores the DMARC failure because it has been configured to trust the incoming gateway, but it reports a DMARC failure as if the domain owner policy was enforced.
• Red Flags:    Any message which is not signed, or is signed using a non-existent or inactive DKIM scope ID.   Assuming that all configuration errors have been resolved, the absence of a signature or use of an inactive scope indicates that the message was originated by an impersonator and not simply a forward.  Additional data will need to be collected to determine if the impersonator is benign or malicious.