As soon as SPF, DKIM, and DMARC policies are set up, reports will start to appear in your URIports account. I'm going to explain the different report elements, what they mean and what to do with them.
The default view shows the most important report data. Let's work through these columns first:
Here you'll find the timestamp of the last time we received a report for this subset.
Disposition can have one of three values and tells you what happened to the messages:
- none - No specific action was taken regarding delivery of the message. This usually means the message was delivered.
- quarantine - The message was treated as suspicious. Depending on the capabilities of the receiver, this can mean the message was placed into the spam folder, scrutinized with additional intensity, and/or flagged as suspicious.
- reject - The message was rejected during the SMTP transaction.
If you have a DMARC 'pct' value of less than 100, you will receive reports for exempted messages. The 'Sampled Out' column will then have the value 'Yes'. This would explain why a DMARC policy was not applied to messages where DKIM, SPF, and ARC did not produce a 'pass' value.
This shows you the domain name of the 'From:' mail header. This field specifies the author of the message, that is, the mailbox of the person or system responsible for writing the message.
The source IP is the address the message was sent from.
This shows the DMARC-aligned authentication results of DKIM and SPF that can either be pass or fail.
ARC helps preserve email authentication results and verifies the identity of email intermediaries that forward a message to its final destination. A forwarded message would normally break DKIM and SPF. If a message has ARC headers, the column will contain either a pass or fail value.
Shows the reason a policy was overridden that affected the DMARC disposition and can hold one of five values:
- Forwarded - The message was relayed via a known forwarder, or local heuristics identified the message as likely having been forwarded. There is no expectation that authentication would pass.
- Local Policy - The Mail Receiver's local policy exempted the message from being subjected to the Domain Owner's requested policy action.
- Mailing List - Local heuristics determined that the message arrived via a mailing list, and thus authentication of the original message was not expected to succeed.
- Other - Some policy exception not covered by the other entries in this list occurred.
- Trusted Forwarder - Message authentication failure was anticipated by other evidence linking the message to a locally maintained list of known and trusted forwarders.
This is the entity or organization responsible for the report and the receiving party of the messages.
The sum of the number of messages in that particular report subset. The data is sorted based on this column (descending) so that you see the largest report group at the top.
When you press the 'Inspect' button on the right you'll get in-depth information about the selected subset of reports. We'll have a look at the additional information elements:
This is the domain of the RFC5321.MailFrom reverse-path. The domain name that was specified by the sending server during SMTP transmission (MAIL FROM: <email@example.com>). This element is not always specified in reports.
DKIM Auth Result
This element contains the DKIM result, uninterpreted with respect to DMARC. While a message can be successfully signed, it doesn't have to be valid for the sending domain. We show the result and the domain (d=) and selector (s=) value of the signature. Let me walk you through the 7 result types.
- none - The message was not signed.
- pass - The message was signed and the signature(s) passed verification tests.
- fail - The message was signed but failed the verification test(s).
- policy - The message was signed, but some aspect of the signature(s) was not acceptable to the ADMD (ADministrative Management Domain).
- neutral - The message was signed, but the signature(s) contained syntax errors or were not otherwise able to be processed. This result is also used for other failures not covered elsewhere in this list.
- temperror - The message could not be verified due to some error that is likely transient in nature, such as a temporary inability to retrieve a public key. A later attempt may produce a final result.
- permerror - The message could not be verified due to some error that is unrecoverable, such as a required header field being absent. A later attempt is unlikely to produce a final result.
SPF Auth Result
This column displays the domain, scope, and result of the SPF validation. The scope is not always specified but can be either 'mfrom' (MAIL FROM) or 'helo'. This specifies what source was used for the SPF validation. The result can be one of 7 values:
- none - The SPF verifier had no information at all about the authorization or lack thereof of the client to use the checked identity or identities.
- neutral - Indicates that although a policy for the identity was discovered, there is no definite assertion (positive or negative) about the client.
- pass - The client is authorized to inject mail with the given identity.
- fail - The client is not authorized to use the domain in the given identity.
- softfail - This result is treated as somewhere between "fail" and "neutral"/"none". The host is not authorized but the receiving server did not make a strong policy statement.
- temperror - The SPF verifier encountered a transient (generally DNS) error while performing the check.
- permerror - The domain's published records could not be correctly interpreted.
This column holds the domain's DMARC policy. It contains the different tags (adkim, aspf, p, sp, pct, fo) and their respective values.
When DKIM, SPF, or ARC checks pass, the message will have a disposition of 'none' which usually means the message was delivered successfully.
Whenever both DKIM and SPF fail and ARC is not available or fails too, the 'p' (domain) or 'sp' (subdomain) policy should be applied to the message unless the receiving server had a good reason for ignoring the policy. In that case, most reports will specify an explanation in the 'reason' column.
If you have DKIM and SPF configured correctly, you should only see messages fail that were not sent by your domain. If a lot of legit messages fail, you might have missed an allowed source in your SPF configuration and/or have a sending server that is not DKIM signing your messages (correctly). Use the 'inspect' data to see where the messages are coming from and what is causing the DMARC alignment to fail.
If you have a DMARC policy of 'none,' you should harden your policy to 'quarantine' or 'reject' as soon as you are happy with the DMARC results and no legit email fails DMARC alignment.