Email Forwarding and DMARC DKIM SPF

Usually, you can see some problems with email authentication protocols during the email forwarding. To prevent cybercriminals from sending emails that look like they are coming from your domain you have to use email authentication mechanisms such as DMARC, DKIM, and SPF. Email authentication secures your domain and at the same time increases your domain reputation so your emails end up in the Inbox instead of Spambox.

Email Authentication Protocols: SPF DKIM and Email Forwarding

Here are the protocols for email authentication:

SPF (Sender Policy Framework)  is a TXT record in your DNS and basically shows sources that are authorized to send emails on behalf of your domain.
For example, if you send emails from the server  130.130.130.130 and you use G Suite for your domain your SPF record will look like this:

v=spf1 ip4:130.130.130.130/32 include:_spf.google.com -all

This means that emails coming only from the server with the IP address 130.130.130.130 and from the G Suite will pass SPF check for your domain. The receiver mail server reads your SPF record every time it receives mail from you and marks them as either SPF pass or fail. 

You can check results in the EasyDMARC dashboard: It is also possible to see SPF check results (pass or fail) by looking at the received email header in mail client: Receiving mail server performs SPF validation, during the email transition, by checking if the MAIL FROM address domain contains the sender’s IP address. (Process is described in the RFC 7208). This mechanism fails during the email forwarding process and will be described later in this article.

DKIM (Domain Keys Identified Mail) – uses a cryptographic signature mechanism to check and validate email authentication and integrity. The mail server puts the encrypted hash of the message body in the email header and then sends it out. Receivers can retrieve the public key from the sender’s domain DNS and perform validation. DKIM public key is a TXT record published in the domain  DNS zone and looks like this:

v=DKIM1; k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAeSn0k+xBRnQgu2+94pt
A6c7l/3N3B Oa1nF+0Fb2gBZg30g+NmMuGRRAKiQfr9ZHHScUsATjF2OevxcjBkDeF4OrVGNs/taCjr
Uwi0H nlVepBzdJ57a2DkPrdfxRYOAn1x1U9cr10eBTg3dUrenux3SkEwd/8eOOgeLqUUe1pQwIDAQAB

The following diagram shows how DKIM works:

 DKIM check results are visible in the EasyDMARC’s dashboard:and also you can check them with your email client, by looking at the email header:You can refer to RFC 6376 for DKIM details and specifications.

The fact remains that DKIM is the part of the email header, therefore it works even when a message has been forwarded.

Forwarding cases and how they affect your Email Authentication (SPF/DKIM) results

SPF: When it comes to Forwarding, SPF Authentication checks will mostly fail, this is logical since a new entity, not included in the original sender’s SPF Record, send the forwarded email.

DKIM: Email forwarding does not affect DKIM, as long as you have not altered the content and the structure of the original Email.

Why passing and aligning both SPF and DKIM are vital to achieving full DMARC Compliance

As per DMARC specs, you need either SPF or DKIM to pass authentication.
But, because of SPF limitations as discussed above, any sources that rely only on SPF, and are DKIM neutral will instantly fail DMARC checks when forwarded.
Whereas, forwarding does not impact the DKIM Signature.
This is why EasyDMARC always advises reaching full DMARC Compliance by authenticating both SPF and DKIM on all legitimate sending sources.

Common DKIM Failures resulting from Forwarding

Message-Forwarding systems Modifying Email content
Modifications caused by Malware scanning and Antivirus solutions
ReSenders and Gateways

Common Forwarding, Indirect Mailflows, Mailing lists are described in RFC 7960

How to identify mail forwarders

When you look at aggregate reports in EasyDMARC, under the “Forwarded” tab you will definitely see many sources, unfamiliar to you. You will also notice that all those unfamiliar sources are passing the DKIM check but failing the SPF check.

These are forwarded emails, i.e. emails which were sent by you / your domain and were automatically forwarded by the recipient mail server to another mail recipient. That is due to the forwarding rule set in the particular mailbox. So what happens when you auto-forward an email in this way?

Emails generated from Email providers’ mailboxes have the same sender address in Header From and Return-path (Mail From). Some Email providers (e.g. Outlook/Hotmail, iCloud, MailRu) preserve the original sender’s Return-path (Mail From) address when forward. Others (e.g Gmail/G Suite, O365 Exchange, Yahoo, Yandex mail) substitute original sender’s Return-path (Mail From) address with the email address of their own domain.
When the recipient’s mail server (mailbox) auto-forwards an email, that came from your server to another destination mail server (mailbox), it actually retransmits your email via his own IP address, so the destination mail server sees the IP address of the forwarding server in the header of an email coming from you.

SPF mechanism was historically designed for checking a domain in Return-path (Mail From) address and not for a domain in Header From address, which remains persistent while auto-forwarded. Thus, for forwarded emails, we can have 2 different cases primarily.

Reasons for SPF DKIM pass/fail in the Email Forwarding Process

Case 1. Return-path email address or original sender is preserved (e.g. Outlook/Hotmail, iCloud, MailRu)

Since the Return-path address in forwarded mail is preserved, the SPF Authentication Result column shows Header From domain alignment with Return-path (Mail From) domain.
SPF check performs against the SPF record of the Return-path (Mail From) domain. It fails because the Return-path (Mail From) address’ domain SPF record does not include the IP address of the forwarding server. So, for this case, you will see aligned / fail.

Case 2. Return-path email address or original sender is substituted with forwarder’s email address (e.g Gmail/G Suite, O365 Exchange, Yahoo, Yandex mail)Since the forwarding server’s email substitutes Return-path address in a forwarded mail, the SPF Authentication Result column shows Header From domain misalignment with Return-path (Mail From) domain.
SPF check performs against the SPF record of the Return-path (Mail From) domain and it passes because the Return-path (Mail From) address’ domain SPF record includes the IP address of the forwarding server. So, for this case, you will see unaligned / pass.
Besides “pass”, in the SPF Authentication Result column you may also see other values – none, neutral, fail, etc – which indicates that the forwarding domain’s SPF record needs proper configuration.

To be precise, there could also be a 3rd case for forwarded emails, which we describe below.

Case 3. Such emails appear in the “Forwarded” tab. In these emails, the DKIM signature integrity broke on the way to the final destination, but the recipient server still identified them as either obvious or sure forwarder (see 2 screenshots below).If you have set your domain’s DMARC policy to “reject”, the actual policy applied to such emails normally downgrades to “quarantine.”If you have set your domain’s DMARC policy to “quarantine”, the actual policy applied to such emails normally downgrades to “none”.

Sign Up to automatically analyze and process your DMARC records.