Automatic Forwarding typically breaks DMARC.
- 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@Karima ben .com and open it. You find the email important and forward it to one of your colleagues at danny@Stuff .com. - 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’.
Office 365 leverages SRS to help mitigate this, but this will not fix DMARC failure issues
https://learn.microsoft.com/en-us/office365/troubleshoot/antispam/sender-rewriting-scheme
SRS rewriting does not fix the issue of DMARC passing for forwarded messages. Although an SPF check will now pass by using a rewritten P1 From address, DMARC also requires an alignment check for the message to pass. For forwarded messages, DKIM always fails because the signed DKIM domain does not match the From header domain. If an original sender sets their DMARC policy to reject forwarded messages, the forwarded messages are rejected by Message Transfer Agents (MTAs) that honor DMARC policies.