When an email is sent from the sending server, directly to the receiving server, SPF and DKIM  (if set up correctly) authenticate the email normally and usually effectively validate it as legitimate or unauthorized. However, that is not the case if the email passes through an intermediary mail server before it gets delivered to the recipient, such as in the case of forwarded messages. This blog is intended to take you through the impact of email forwarding on DMARC authentication-results.

As we already know, DMARC makes use of two standard email authentication protocols, namely SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail), to validate inbound messages. Let’s discuss them in brief to get a better understanding of how they function before hopping on to how forwarding can affect them.

Sender Policy Framework

SPF is present in your DNS as a TXT record, displaying all the valid sources that are authorized to send emails from your domain. Every email that leaves your domain has an IP address that identifies your server and the email service provider used by your domain that is enlisted within your DNS as an SPF record. The receiver’s mail server validates the email against your SPF record to authenticate it and accordingly marks the email as SPF pass or fail.

DomainKeys Identified Mail

DKIM is a standard email authentication protocol that assigns a cryptographic signature, created using a private key, to validate emails in the receiving server, wherein the receiver can retrieve the public key from the sender’s DNS to authenticate the messages. Much like SPF, the DKIM public key also exists as a TXT record in the DNS of the domain owner.

The Impact of Email Forwarding on Your DMARC Authentication Results

During email forwarding the email passes through an intermediary server before it ultimately gets delivered to the receiving server. Firstly it is important to realize that email forwarding can be done in two ways- either emails can be manually forwarded, which does not affect the authentication results, or it can be automatically forwarded, in which case the authentication procedure does take a hit if the domain doesn’t have the record for the intermediary sending source in their SPF.

Naturally, usually during email forwarding SPF check fails since the IP address of the intermediary server doesn’t match that of the sending server, and this new IP address is usually not included within the original server’s SPF record. On the contrary, forwarding emails usually don’t impact DKIM email authentication, unless the intermediary server or the forwarding entity makes certain alterations in the content of the message.

Note that for an email to pass DMARC authentication, the email would be required to pass either SPF or DKIM authentication and alignment. As we know that SPF inevitably fails during email forwarding, if in case the sending source is DKIM neutral and solely relies on SPF for validation, the forwarded email will be rendered illegitimate during DMARC authentication.

The solution? Simple. You should immediately opt for full DMARC compliance at your organization by aligning and authenticating all inbound messages against both SPF and DKIM!

Achieving DMARC Compliance with PowerDMARC

It is important to note that in order to achieve DMARC compliance, emails need to be authenticated against either SPF or DKIM or both. However, unless the forwarded messages get validated against DKIM, and rely on only SPF for authentication, DMARC will inevitably fail as discussed in our previous section. This is why PowerDMARC helps you achieve complete DMARC compliance by effectively aligning and authenticating emails against both SPF and DKIM authentication protocols. In this way, even if authentic forwarded messages fail SPF, the DKIM signature can be used to validate it as legitimate and the email passes DMARC authentication, subsequently landing into the receiver’s inbox.

Exceptional Cases: DKIM Fail and How to Resolve It?

In certain cases, the forwarding entity may alter the mail body by making adjustments in MIME boundaries, implementation of anti-virus programs, or re-encoding the message. In such cases, both SPF and DKIM authentication fails and legitimate emails do not get delivered.

Incase both SPF and DKIM fail, PowerDMARC is able to identify and display that in our detailed aggregate views and protocols like Authenticated Received Chain can be leveraged by mail servers to authenticate such emails. In ARC, Authentication-Results header can be passed onto the next ‘hop’ in the line of the message delivery, to effectively mitigate authentication issues while email forwarding.

In case of a forwarded message, when the receiver’s email server receives a message that had failed DMARC authentication, it tries to validate the email for a second time, against the provided Authenticated Received Chain for the email by extracting the ARC Authentication-Results of the initial hop, to check whether it was validated to be legitimate before the intermediary server forwarded it to the receiving server.

So sign up with PowerDMARC today, and achieve DMARC compliance at your organization!

ARC or Authenticated Received Chain is an email authentication system that displays an email’s authentication assessment each step of the way, throughout handling. In simpler terms, the Authenticated Received chain can be termed as a “ chain of custody” for email messages that enable each entity that handles the messages to effectively see all the entities that previously handled it. As a relatively new protocol published and documented as “Experimental” in RFC 8617 on July 2019, ARC enables the receiving server to validate emails even when SPF and DKIM are rendered invalid by an intermediate server.

How Can Authenticated Received Chain Help?

As we already know, DMARC allows an email to be authenticated against the SPF and DKIM email authentication standards, specifying to the receiver how to handle the emails that fail or pass authentication. However, if you implement DMARC enforcement at your organization to a strict DMARC policy, there are chances that even legitimate emails such as those sent through a mailing list or a forwarder, may fail authentication and not get delivered to the receiver! Authenticated Received Chain helps mitigate this problem effectively. Let’s learn how in the following section:

Situations in Which ARC Can Help

  • Mailing Lists 

As a member of a mailing list, you have the power to send messages to all members in the list at one go by addressing the mailing list itself. The receiving address then subsequently forwards your message to all list members. In the current situation, DMARC fails to validate these types of messages and the authentication fails even though the email has been sent from a legitimate source! This is because SPF breaks when a message is forwarded. As the mailing list often goes on to incorporate extra information in the email body, the DKIM signature can also be invalidated due to changes in the email content.

  • Forwarding Messages 

When there is an indirect mail flow, such as you are receiving an email from an intermediate server and not directly from the sending server as in the case of forwarded messages, SPF breaks and your email will automatically fail DMARC authentication. Some forwarders also alter the email content which is why the DKIM signatures also get invalidated.



In such situations, Authenticated Received Chain comes to the rescue! How? Let’s find out:

How Does ARC Function?

In the situations listed above, the forwarders had initially received emails that had been validated against DMARC setup, from an authorized source. Authenticated Received Chain is developed as a specification that allows the Authentication-Results header to be passed on to the next ‘hop’ in the line of the message delivery.

In case of a forwarded message, when the receiver’s email server receives a message that had failed DMARC authentication, it tries to validate the email for a second time, against the provided Authenticated Received Chain for the email by extracting the ARC Authentication-Results of the initial hop, to check whether it was validated to be legitimate before the intermediary server forwarded it to the receiving server.

On the basis of the information extracted, the receiver decides whether to allow the ARC results to override the DMARC policy, thereby passing the email as authentic and valid and allowing it to be delivered normally into the receiver’s inbox.

With ARC implementation, the receiver can effectively authenticate the email with the help of the following information:

  • The authentication results as witnessed by the intermediate server, along with the entire history of SPF and DKIM validation results in the initial hop.
  • Necessary information to authenticate the sent data.
  • Information to link the sent signature to the intermediary server so that the email gets validated in the receiving server even if the intermediary alters the content, as long as they forward a new and valid DKIM signature.

Implementation of Authenticated Received Chain

ARC defines three new mail headers:

  • ARC-Authentication-Results (AAR): First among the mail headers is the AAR that encapsulates the authentication results such as SPF, DKIM, and DMARC.

  • ARC-Seal (AS) – AS is a simpler version of a DKIM signature, that contains information on authentication header results, and ARC signature.

  • ARC-Message-Signature (AMS) – AMS is also similar to a DKIM signature, which takes an image of the message header which incorporates everything apart from ARC-Seal headers such as the To: and From: fields, subject, and the entire body of the message.

Steps performed by the intermediate server to sign a modification:

Step 1: the server copies the Authentication-Results field into a new AAR field and prefixes it to the message

Step 2: the server formulates the AMS for the message (with the AAR) and prepends it to the message.

Step 3: the server formulates the AS for the previous ARC-Seal headers and adds it to the message.

Finally, to validate the Authenticated Received Chain and find out whether a forwarded message is legitimate or not, the receiver validates the chain or ARC Seal-headers and the newest ARC-Message-Signature. If in case the ARC headers have been altered in any way the email consequently fails DKIM authentication. However, if all mail servers involved in the transmission of the message correctly sign and transmit ARC then the email preserves the DKIM authentication results, and passes DMARC authentication, resulting in the successful delivery of the message in the receiver’s inbox!

ARC implementation backs-up and supports DMARC adoption in organizations to make sure that every legitimate email gets authenticated without a single lapse. Sign up for your free DMARC trial today!

Mail Transfer Agent-Strict Transport Security (MTA-STS) is a new standard that enables mail service providers with the ability to enforce Transport Layer Security (TLS)  to secure SMTP connections, and to specify whether the sending SMTP servers should refuse to deliver emails to MX hosts that that does not offer TLS with a reliable server certificate. It has been proven to successfully mitigate TLS downgrade attacks and Man-In-The-Middle (MITM) attacks. 

In simpler terms, MTA-STS is an internet standard that secures connections between SMTP mail servers. The most prominent problem with SMTP is that encryption is completely optional and isn’t enforced during mail transfer. This is why SMTP adopted the STARTTLS command to upgrade from plaintext to encryption. This was a valuable step towards mitigating passive attacks, however, tackling attacks via active networks and MITM attacks still remained unaddressed.

Hence, the issue MTA-STS is solving is that SMTP utilizes opportunistic encryption, i.e if an encrypted communication channel cannot be established, the connection falls back to plaintext, thereby keeping MITM and downgrade attacks at bay.

What is a TLS Downgrade Attack?

As we already know, SMTP did not come with an encryption protocol and encryption had to be retrofitted later on to enhance the security of the existing protocol by adding the STARTTLS command. If the client supports encryption (TLS), it will understand the STARTTLS verb and will initiate a TLS exchange before sending the email to ensure it is encrypted. If the client doesn’t know TLS, it will simply ignore the STARTTLS command and send the email in plaintext.

Therefore, since encryption had to be retrofitted into SMTP protocol, the upgrade for encrypted delivery has to rely on a STARTTLS command that is sent in cleartext. A MITM attacker can easily exploit this feature by performing a downgrade attack on the SMTP connection by tampering with the upgrade command. The attacker simply replaced the STARTTLS with a garbage string which the client fails to identify. Therefore, the client readily falls back to sending the email in plaintext.

The attacker usually replaces the command with the garbage string containing the same number of characters, rather than chucking it out, because this preserves the packet size and therefore, makes it easier. The eight letters in the garbage string in the option command allow us to detect and identify that a TLS downgrade attack has been executed by a cybercriminal, and we can measure its prevalence.

In short, A downgrade attack is often launched as a part of a MITM attack, so as to create a pathway for enabling a cryptographic attack that would not be possible in case of a connection that is encrypted over the latest version of TLS protocol, by replacing or deleting the STARTTLS command and rolling back the communication to cleartext.

While it is possible to enforce TLS for client-to-server communications, as for those connections we know that the apps and the server support it. However,  for server-to-server communications, we must fail open to allow legacy servers to send emails. The crux of the problem is that we have no idea if the server on the other side supports TLS or not. MTA-STS allows servers to indicate that they support TLS, which will allow them to fail close (i.e. not sending the email) if the upgrade negotiation doesn’t take place, thereby making it impossible for a TLS downgrade attack to take place.

tls reporting

How Does MTA-STS Come to the Rescue?

MTA-STS functions by increasing the EXO or Exchange Online email security and is the ultimate solution to a wide range of SMTP security drawbacks and problems. It solves issues in SMTP security such as lack of support for secure protocols, expired TLS certificates, and certificates that are not issued by reliable third parties. 

As mail servers proceed to send out emails, the SMTP connection is vulnerable to cryptographic attacks such as downgrade attacks and MITM. Downgrade attacks can be launched by deleting the STARTTLS response, thereby delivering the message in clear text. Similarly, MITM attacks can also be launched by redirecting the message to a server intruder over an insecure connection. MTA-STS allows your domain to publish a policy that makes sending an email with encrypted TLS compulsory. If for some reason the receiving server is found to not support STARTTLS, the email will not be sent at all. This makes it impossible to instigate a TLS downgrade attack.

In recent times, the majority of mail service providers have adopted MTA-STS thereby making connections between servers more secure and encrypted over TLS protocol of an updated version, thereby successfully mitigating TLS downgrade attacks and nullifying the loopholes in server communication.

PowerDMARC brings to you, speedy and easy hosted MTA-STS services which make your life a whole lot easier as we take care of all the specifications required by MTA-STS during and after implementation, such as an HTTPS-enabled web server with a valid certificate, DNS records, and constant maintenance. PowerDMARC manages all of that completely in the background so that after we help you set it up, you never even have to think about it again!

With the help of PowerDMARC, you can deploy Hosted MTA-STS at your organization without the hassle and at a very speedy pace, with the help of which you can enforce emails to be sent to your domain over a TLS encrypted connection, thereby making your connection secure and keeping TLS downgrade attacks at bay.

A widely known internet standard that facilitates by improving the security of connections between SMTP (Simple Mail Transfer Protocol) servers is the SMTP Mail Transfer Agent-Strict Transport Security (MTA-STS).

In the year 1982, SMTP was first specified and it did not contain any mechanism for providing security at the transport level to secure communications between the mail transfer agents. However, in 1999, the STARTTLS command was added to SMTP that in turn supported the encryption of emails in between the servers, providing the ability to convert a non-secure connection into a secure one that is encrypted using TLS protocol.

In that case, you must be wondering that if SMTP adopted STARTTLS to secure connections between servers, why was the shift to MTA-STS required? Let’s jump into that in the following section of this blog!

The Need for Shifting to MTA-STS

STARTTLS was not perfect, and it failed to address two major problems: the first being that it is an optional measure, hence STARTTLS fails to prevent man-in-the-middle (MITM) attacks. This is because a MITM attacker can easily modify a connection and prevent the encryption update from taking place. The second problem with it is that even if STARTTLS is implemented, there is no way to authenticate the identity of the sending server as SMTP mail servers do not validate certificates.

While most outgoing emails today are secured with Transport Layer Security (TLS) encryption, an industry standard adopted even by consumer email, attackers can still obstruct and tamper with your email even before it gets encrypted. If you email to transport your emails over a secure connection, your data could be compromised or even modified and tampered with by a cyber attacker. Here is where MTA-STS steps in and fixes this issue, guaranteeing safe transit for your emails as well as successfully mitigating MITM attacks. Furthermore, MTAs store MTA-STS policy files, making it more difficult for attackers to launch a DNS spoofing attack.

MTA-STS offers protection against :

  • Downgrade attacks
  • Man-In-The-Middle (MITM) attacks
  • It solves multiple SMTP security problems, including expired TLS certificates and lack of support for secure protocols.

How Does MTA-STS Work?

MTA-STS protocol is deployed by having a DNS record that specifies that a mail server can fetch a policy file from a specific subdomain. This policy file is fetched via HTTPS and authenticated with certificates, along with the list of names of the recipients’ mail servers. Implementing MTA-STS is easier on the recipient’s side in comparison to the sending side as it requires to be supported by the mail server software. While some mail servers support MTA-STS, such as PostFix, not all do.

hosted MTA STS

Major mail service providers such as Microsoft, Oath, and Google support MTA-STS. Google’s Gmail has already adopted MTA-STS policies in recent times. MTA-STS has removed the drawbacks in email connection security by making the process of securing connections easy and accessible for supported mail servers.

Connections from the users to the mail servers are usually protected and encrypted with TLS protocol, however, despite that there was an existing lack of security in the connections between mail servers before the implementation of MTA-STS. With a rise in awareness about email security in recent times and support from major mail providers worldwide, the majority of server connections are expected to be encrypted in the recent future. Moreover, MTA-STS effectively ensures that cybercriminals on the networks are unable to read email content.

Easy and Speedy Deployment of Hosted MTA-STS Services by PowerDMARC

MTA-STS requires an HTTPS-enabled web server with a valid certificate, DNS records, and constant maintenance. PowerDMARC makes your life a whole lot easier by handling all of that for you, completely in the background. Once we help you set it up, you never even have to think about it again.

With the help of PowerDMARC, you can deploy Hosted MTA-STS at your organization without the hassle and at a very speedy pace, with the help of which you can enforce emails to be sent to your domain over a TLS encrypted connection, thereby making your connection secure and keeping MITM attacks at bay.

With the ongoing surge in phishing attacks, email and domain spoofing attacks, BEC, and other fraudulent activities by cybercriminals, an extra layer of security and email protection is always a good idea! Recipients of emails are growing more and more suspicious of the messages landing in their inboxes due to the rise in cyber attacks. The solution? A well-rounded email security suite that includes BIMI implementation.

A recent survey conducted by security professionals in the US disclosed that 60% of US citizens claim to have fallen prey to a cyber scam or know of someone who has been affected by the same, in their close circle, post-pandemic. Therefore, in order to provide their emails with an additional layer of protection, businesses need to implement a new standard like Brand Indicators for Message Identification (BIMI), as it promises to take consumer confidence to the next level.

What is BIMI?

BIMI stands for Brand Indicators for Message Identification, which is a newly formed standard of email authentication that affixes your brand’s logo to all emails authorized by you. This may feel like a very small step, but visual verification can in fact increase your brand’s credibility by allowing receivers to recognize and trust the emails you send out from your business email domain.

You might be wondering, if you already have DMARC implemented in your organization, that makes use of SPF and DKIM authentication standards, do you even need BIMI? Let us discuss in brief how each of these standards functions to authenticate inbound emails:

  • SPF authenticates your emails to identify the mail servers that are allowed to send emails from your email domain, enlisted in the SPF record.
  • DKIM authenticates emails by adding a digital signature to them, allowing the receiver to check whether an email claiming to be coming from a specific domain was indeed authorized by the owner of that domain.
  • DMARC specifies to inbox providers how to respond to emails that fail SPF and DKIM email authentication.
  •  BIMI affixes your brand’s logo to the emails you send out to your employees, partners, and customers so that they can promptly identify that it is from an authorized source.

Therefore it is quite evident from the discussion above that among all the email authentication protocols, BIMI is the only standard that provides a scope for visual identification, offering email receivers a visual clue to identify the email source and recognize its authenticity.

PowerDMARC Logo Mobile

BIMI Implementation- A Brief Guide

While BIMI is an emerging and still evolving authentication standard, it is still relatively new. As of yet, only Yahoo! Mail has officially adopted the technology. Due to this reason, BIMI does not guarantee the display of your brand logo as it works with only supported email clients. There are a few essential steps to follow, prior to BIMI implementation, which are:

  • In order to implement BIMI at your organization, your domain requires to be DMARC- authenticated at a policy level of enforcement, i.e. either reject or quarantine.
  • You must create and upload an SVG file of your brand’s logo as per the BIMI requirements to a server so that it is accessible from anywhere.
  • You have to create a BIMI record, which, similar to a DMARC record is essentially a string that consists of multiple tags, separated by semicolons.
  • You need to have access to your domain’s DNS to publish this new BIMI record.
  • It is a rather useful practice to check the validity of your BIMI record after it is published in your DNS.

How can BIMI implementation prove to be advantageous for your business?

BIMI is an email authentication protocol that exercises visual identification to help email receivers recognize and trust your brand in the inbox. This trust prevents customers and partners from unsubscribing your services and keeps spam complaints at bay as well, which can subsequently lead to a  boost in email deliverability.

Without BIMI, a generic placeholder logo with brand initials is displayed by email clients. Due to this reason, the recipient might have a hard time recognizing your brand without resorting to the brand name. However, with BIMI implemented, the brand logo is displayed next to your email message, boosting brand awareness.

In addition to that, it is an extra layer of email security against domain spoofing attacks, phishing attacks, and other attempts at impersonation as receivers would be more wary about cybercriminals posing to be you.

Furthermore, BIMI allows you to market your brand. Yes, you heard me right! Sometimes recipients do not have a lot of time in hand, and your subject line might not be compelling enough to click on at the moment. Regardless of that, your recipients will connect your sender address, subject line, and preheader text with your logo, helping further build your brand.

Lastly, BIMI implementation also has a very positive impact on your email deliverability rate! For mailbox providers who do support BIMI, it will add another layer of email authentication to your messages, thereby increasing the chance of them delivering your email more promptly. In addition to that, your email receivers can visually identify and recognize your brand, through the displayed logo, decreasing the chances of them marking it as spam.

Ease up Your BIMI Implementation Process with PowerBIMI

With PowerBIMI we make BIMI record publishing very speedy and simple for you! All you have to do is simply upload your SVG image, we will host it securely and provide you with a DNS record instantly, so that you can publish it in your DNS. We take off from your shoulder the pain of hosting the image and securing it.

With PowerBIMI you can update, delete or do any changes to your image, at any time, without the need for updating your DNS records again. PowerBIMI provides you with a very speedy and easy one-click implementation procedure to upload your logo and shift to BIMI authentication successfully, adding it as a part of your email security suite after signing up for free BIMI record.