DMARC Analyzer 2.0 - What is Forwarding Within DMARC?

This article contains information on how DMARC Analyzer handles email forwarding, detailing manual and automatic forwarding, the impact on SPF and DKIM, and the role of local policies in email authentication.

Forwarding is an edge case within DMARC. Forwarding happens when an email receiver forwards your email to another recipient. Statistics about your forwarded emails can be found by navigating to DMARC aggregate reports | Per sending source.

The two types of forwarding:

Manual forwarding

Manual forwarding occurs when you receive an email in your inbox and manually forward it to another receiver. E.g. You receive an email from [e-mail] and open it. You find the email important and forward it to one of your colleagues, [e-mail].

Automatic forwarding

There are multiple scenarios when automatic forwarding occurs. Some examples are:

• When you have an old email account and forward all incoming emails to a new (active) email account. e.g., You have two email accounts; an old one [e-mail] and a new one [e-mail]. You don’t check your old [e-mail] account anymore so you have set up automatic forwarding to your new email account. All emails you receive to [e-mail] will automatically be forwarded to [e-mail]
• Colleges or universities that offer an email address to their students. Some students may not regularly check these accounts and set up forwarding on them. Incoming mail to [e-mail] will be forwarded to [e-mail]
• Email gateways that handle incoming messages for a company can be configured to forward mail to certain users to an external supplier. For instance: [e-mail] can be forwarded to [e-mail].

When someone manually forwards your email, you will not experience problems with email authentication. This is because this new message will normally be sent ‘From’ the receiver of your message. The new message will also contain new authentication, like a new DKIM signature.

However, when someone automatically forwards one of your emails, you can experience problems with email authentication. SPF will normally break in this scenario. This is because the sending server (for instance @some-isp.com) will not be included in the SPF record for your company. When you are on a Quarantine policy this will result in the email being delivered in the spam box and when you are on a ‘Reject’ policy the email will not be delivered at all.

DKIM is designed to survive automatic forwarding. With DKIM, a hash is appended to the email. This hash is calculated using the message body and some of the mail headers and requires your private key. If these parts are not changed in any way by the forwarder, the DKIM signature will be preserved and can still be validated by the final receiver of the message. This is why we always recommend setting up DKIM. It is important to implement DKIM before changing your DMARC policy to Quarantine or Reject.

Local policy

When analyzing DMARC data, you will often see the concept ‘local policy’ in your DMARC overviews. This indicates that the ISP sending us the DMARC report has applied a certain ‘local policy’ to the messages which results in a different DMARC policy being applied than you would have expected based on the DKIM and/or SPF data for that message.

This could mean that an email was still placed in the inbox even though the message should be rejected or quarantined based on the DMARC data.

ISPs are free to apply a local policy on incoming mail. There is no strict definition of what a local policy is. This can differ per ISP. For instance, an ISP could decide to ‘trust’ messages which they believe were forwarded by a trusted source (which may not be a DKIM preserving forwarder) or based on a local allowlist.