The Beginner's Guide to DMARC with URIports

As soon as SPF, DKIM, and DMARC policies are set up, reports will start to appear in your URIports account. I will explain the different report elements, what they mean and what to do with them.

Default view

The default view shows the most critical report data. So let's work through these columns first:

Update 07/05/2021

We've added a DMARC column that allows you to filter and group the three different values (pass, fail and ignored) easily. If both DKIM and SPF fail, the result is false unless the receiving server ignores the policy. In that case, the DMARC value will be set to ignored. These are most likely forwarded messages. If DKIM or SPF validation passed, the DMARC value would be pass. The graph on the top of the page will follow this column instead of the Disposition column.

Last received

Here you'll find the timestamp of the last time we received a report for this subset.

Disposition

Disposition can have one of three values and tells you what happened to the messages:

1. none - No specific action was taken regarding the delivery of the message. This usually means the message was delivered.
2. quarantine - The message was treated as suspicious. Depending on the receiver's capabilities, this can mean the message was placed into the spam folder, scrutinized with additional intensity, and/or flagged as suspicious.
3. reject - The message was rejected during the SMTP transaction.

Sampled Out

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.

Header From

The "From:" header field indicates who the author of the message is. This is the address that is usually visible in the email client as sender. This information can be spoofed.

Source IP

The source IP is the address the message was sent from.

DKIM/SPF

This shows the DMARC-aligned authentication results of DKIM and SPF that can either be pass or fail.

ARC

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 usually break DKIM and SPF. If a message has ARC headers, the column will contain either a pass or fail value.

Reason

Shows the reason a policy was overridden that affected the DMARC disposition and can hold one of five values:

1. 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 will pass.
2. Local Policy - The Mail Receiver's local policy exempted the message from being subjected to the Domain Owner's requested policy action.
3. 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.
4. Other - Some policy exceptions not covered by the other entries in this list occurred.
5. Trusted Forwarder - Message authentication failure was anticipated by other evidence linking the message to a locally maintained list of known and trusted forwarders.

Report origin

This is the entity or organization responsible for the report and the receiving party of the messages.

Count

The sum of the number of messages in that particular report subset. The data is sorted based on this column (descending) to see the largest report group at the top.

In-depth Inspect

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:

Envelope from

This is the domain of the RFC5321.MailFrom reverse-path that was specified by the sending server during SMTP transmission (MAIL FROM: <mail@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, domain (d=), and selector (s=) value of the signature. Let me walk you through the seven result types.

1. none - The message was not signed.
2. pass - The message was signed, and the signature(s) passed verification tests.
3. fail - The message was signed but failed the verification test(s).
4. policy - The message was signed, but some aspect of the signature(s) was not acceptable to the ADMD (ADministrative Management Domain).
5. 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.
6. 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.
7. permerror - The message could not be verified due to some unrecoverable error, 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:

1. none - The SPF verifier had no information about the authorization or lack thereof of the client to use the checked identity or identities.
2. neutral - Indicates that although a policy for the identity was discovered, there is no definite assertion (positive or negative) about the client.
3. pass - The client is authorized to inject mail with the given identity.
4. fail - The client is not authorized to use the domain in the given identity.
5. 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.
6. temperror - The SPF verifier encountered a transient (generally DNS) error while performing the check.
7. permerror - The domain's published records could not be correctly interpreted.

Policy evaluated

This column holds the domain's DMARC policy. It contains the different tags (adkim, aspf, p, sp, pct, fo) and their respective values.

Analyzing

When DKIM, SPF, or ARC checks pass, the message will have a disposition of 'none', which usually means the message was delivered successfully.

Whenever 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 failed messages that your domain did not send. If many 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 messages are coming from and what 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.