Original Source: GitLab Repository

The Vulnerability

The issue lies in the “display name” of an email’s “From” header in Outlook. It appears that this display name can be manipulated to misrepresent the actual sender of the email, making phishing attempts more convincing.

Outlook Desktop

Two specific bugs in the Outlook desktop application contribute to this vulnerability:

  1. The display name and from email are presented in the same visual element without any isolation. This means that an authenticated piece of information (the from email) can be manipulated by an arbitrary string controlled by an attacker (the display name).
  2. If the combined length of the “display name” and “from email” is too long, it is quietly truncated. This allows an attacker to push the “from email” out of the visible screen area.

The severity of this issue is comparable to a browser bug that allows websites to choose what they display in the address bar.

Outlook Web App

The web version of Outlook also has a similar issue where the display name and from email are in the same visual element. However, exploiting this bug requires a bit more creativity as it’s not possible to force Outlook to hide the real from address as in the desktop version.

Proof of Concept

The original author of this discovery has provided detailed proof-of-concept examples in the original GitLab repository, demonstrating how an attacker could exploit these vulnerabilities. The examples involve using specific characters and formatting to manipulate the display of the email sender information.

Limitations and Anomalies

While these exploits can be highly effective, there are a few limitations and anomalies to note:

  • The real “To:” line has a slightly smaller font size than the fake one, but it’s unlikely that many users would notice this difference.
  • There is a small anomaly in the preview pane where the display name has “…” or the fake email address at the end. Again, this is not likely to alarm many people.

SPF and DMARC Recommendations

In light of the above vulnerability, it’s more important than ever to implement robust email authentication methods. Sender Policy Framework (SPF) and Domain-based Message Authentication, Reporting & Conformance (DMARC) are two such methods that can significantly enhance the security of your email communications.

  • SPF allows domain owners to specify which mail servers are permitted to send email on behalf of their domain. This helps protect against email spoofing, where attackers send email that appears to come from your domain.
  • DMARC builds on SPF and also includes DomainKeys Identified Mail (DKIM). It allows domain owners to define how to handle emails that fail SPF or DKIM checks. DMARC also provides reporting back to the domain owner about these failures, helping you understand who is sending email on your behalf (legitimately or not).

Implementing SPF and DMARC records for your domain can significantly reduce the risk of your domain being used in phishing attacks. However, it’s important to note that these measures protect your domain from being spoofed; they do not directly protect your users from receiving spoofed emails from other domains.


This discovery underscores the importance of constant vigilance in the cybersecurity landscape. It’s crucial for organizations to stay informed about such vulnerabilities and take appropriate measures to protect their systems and users.

For more details, including the proof-of-concept examples, please visit the original GitLab repository.

Remember, the best defense against phishing attacks is awareness and education. Always verify the sender’s email address and be cautious of unexpected or suspicious emails, even if they appear to come from a known contact. Implementing robust email authentication methods like SPF and DMARC can also significantly enhance your email security.