Forwarded emails are occasionally brought up as a question in conversations with customers. Forwarding is a very small percentage of emails that are sent. While it can cause otherwise legitimate emails to be quarantined/rejected, the impact is almost always minimal to non existent.
What is a forward?
Forwarded emails, in this context, are emails that are sent to one email address but then automatically forwarded to another email address. This is different from a recipient of an email manually forwarding this to someone else.
Some people see forwards as a big problem when looking at DMARC. Forwards are, however, a very small percentage of overall emails so this is not a large issue. There is also work underway in the standards bodies to address this (See ARC below). Valimail is following this closely and has contributed open source code and is an editor on the proposed ARC standard.
The classic example of forwarding is as follows:
A person has an alumni email address from a school they attended that they use as their 'public' email address (The address that they tell people to email them at). In this case however, the person has configured their alumni account to automatically send all of these emails onto the person's Gmail (or other) account.
What issues can arise?
Forwarding has the potential to cause forwarded emails to fail DMARC authentication. This is much more likely to happen when the email can only use SPF to authenticate. When an email is forwarded, the forwarding server becomes the 'sending server' as far as the receiver is concerned. In the case above, the email is From the alumni email address (originated #1) but the receiver ( final destination # 3) sees the sender (who alumni intended to send it to #2) as the forwarding entity. Assuming the forwarding entity is not allowed sender on behalf of the alumni domain (which is almost guaranteed), the email will fail authentication.
If the email sent with an aligned DKIM signature, the email is much more likely to pass DMARC authentication. As long as the forwarding entity does not change any of the components of the email that are used by the receiver to compute the hash based on the DKIM key, the email will authenticate. If any of these components are modified, the email will fail authentication and will be quarantined/rejected (assuming the email does not pass SPF authentication).
What is the solution (ARC)?
Although forwarding is a minor issue in the email authentication world, the IETF has developed a way to address this. The standard Authenticated Received Chain (ARC). The standard is defined here. This allows a forwarder to assert the authentication status of an email. At a high level, the process is as follows:
- Forwarder (#2 intended recipient) receives an email ( #1 or original source)
- Forwarder validates the email to ensure that it is legitimate
- Forwarder adds an ARC signature to the header of the email
- Forwarder sends the email to the recipient (#3 or final destination)
- If the final recipient trusts the forwarder, it can accept the email, even though it fails DMARC
Note that multiple forwarders can be in the path and, as long as each recipient trusts the one before, the email can be delivered.
This solution requires the end recipient to trust the forwarder. Each receiver needs to decide who they will trust. At this point, it seems to be only G Suite → G Suite. It is unclear as to when this will change