Forwarding is a bit of an edge case within DMARC. Forwarding happens when an email receiver forwards your email to another recipient. Log in on app.dmarcanalyzer.com and go to “DMARC aggregate reports” → “Per sending source” to see detailed statistics about your forwarded emails.
There are two types of forwarding:
1. Manual forwarding
Manual forwarding occurs when you receive an email in your inbox and manually forward it to another receiver. I.e.: You receive an email from peter@hotmail.com and open it. You find the email important and forward it to one of your colleagues at danny@gmail.com.
2. Automatic forwarding
There we multiple scenarios when automatic forwarding occurs. Some examples are:
- When you have an old email account and forward all incoming email a new (active) email account. I.e.: You have two email accounts. An old one peter@some-isp.com and a new one peter@another-isp.com. You don’t check your old peter@some-isp.com account anymore so you have set up automatic forwarding to your new email account. All email you receive at peter@some-isp.com will automatically be forwarded to peter@another-isp.com
- Colleges or universities offer email address to their students to inform them. However some students will not regularly check these accounts and set up forwarding on them. Incoming mail to student@university.com will be forwarded to personal-address@some-isp.com
- Email gateways which handle incoming messages for a company can be configured to forward mail to certain users to an external supplier. For instance: john.doe@gateway-user.com can be forwarded to john.doe@thirdparty-supplier.com.
When someone manually forwards your email, you will not experience problems with email authentication. This is because this new message will normally be send ‘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 email, you can experience problems with email authentication. SPF will normally break in this scenario. This is quite logical as 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 append to the mail. This hash is calculated using the message body and some of the mail headers and requires your private key. If these parts are not change 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 suggest to setup DKIM. It is important to implement DKIM before changing your policy to ‘Quarantine’ or ‘Reject’.
Local policy
When analyzing the DMARC data, you will often see the concept ‘local policy’ in your DMARC overviews. This is indicated by the ISPs sending us the DMARC reports and this indicates they have applied a certain ‘local policy’ to the messages which results in a different DMARC policy then you would expect based on the DKIM and/or SPF data for that message.
This could mean that a message 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 on what a local policy is. This can differ per ISP. For instance an ISP could decide to ‘trust’ messages which they believe where forwarded by a trusted source (which may not be a DKIM preserving forwarder) or based on a local whitelist.