Overview
Email message header syntax can be exploited to bypass authentication protocols such as SPF, DKIM, and DMARC. These exploits enable attackers to deliver spoofed emails that appear to originate from trusted sources. Recent research has explored using the originator fields, such as From: and Sender:, to deliver spoofed emails that appear to come from trusted sources. Attackers can abuse these fields to impersonate an originator email address for nefarious purposes.
Description
Email is a primary medium for both personal and business communication. In recent years, mechanisms such as DKIM, SPF, and DMARC have been developed to verify the identity of email senders; however, end-to-end secure email remains an unsolved challenge.
A previous disclosure, dubbed SMTP Smuggling, highlighted ways in which a sender's identity could be spoofed while abusing the SMTP protocol as defined in RFC 5321. Further research shows that email message headers, as defined in the Internet Message Format (RFC 5322, updated by RFC 6854), can also be used to spoof the identity of an email sender.
In a typical scenario, an email passes SPF, DKIM, and DMARC checks, and there is one sender with an envelope header MAIL FROM field that matches the mail header From: and optional Sender: fields. RFC 6854 defines how an email may be sent on behalf of a group, putting multiple email addresses in the mail header From: field.
Using specialized syntax, an attacker can insert multiple addresses in the mail header From: field. Many email clients will parse the From: field to only display the last email address, so a recipient will not know that the email is supposedly from multiple addresses. In this way, an attacker can pretend to be someone familiar to the user.
More specifically, user attacker@example.com could send an email with the From: field formatted as <attacker@example.com>:<spoofed@example.com>. The receiving server may display spoofed@example.com as the sender. Additionally, the sending server may add DKIM signatures and forward the email in a way that aligns with SPF policies, causing the receiving system to treat the message as trusted.
These crafted email headers can take several forms, using combinations of quotation marks and angle-address notation (e.g., <attacker@example.com>), as discussed in Solnser's 2024 blog post: https://blog.slonser.info/posts/email-attacks/. Attackers can also use the null sender <>, or "null reverse path," as specified in RFC 5321 Section 4.5, further complicating genuine sender authentication.
Impact
An attacker can craft email headers to impersonate other users, bypassing DMARC policies and sender verification enforced by a domain owner. Research has demonstrated that multiple email service providers are susceptible to this type of attack.
Solution
Email Service Providers and Administrators
Email service providers should implement measures to ensure that authenticated outgoing email headers are properly verified before signing or relaying messages. Additionally, software built using the Mail Filter (milter) protocol, such as Milterfrom version 1.0.4, has recent updates to better verify authenticated senders for milter-compliant email servers.
Email End Users
Because email sender verification remains challenging, users should exercise caution when responding to emails requesting sensitive information or clicking links that may download or install malicious software. Users that want to verify the originator of an email before clicking links or sharing sensitive information can check the original headers for the From: and Sender: fields by viewing the "Original Message" or "Message Source," depending on the email client.
Acknowledgements
Thanks to Hao Wang and Caleb Sargent from PayPal for reporting these issues. This document was written by Vijay Sarvepalli and Renae Metcalf.
References
- https://kb.cert.org/vuls/id/244112
- https://kb.cert.org/vuls/id/302671
- https://datatracker.ietf.org/doc/html/rfc6854
- https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/
- https://blog.slonser.info/posts/email-attacks/
- https://learn.microsoft.com/en-us/archive/blogs/tzink/what-do-we-mean-when-we-refer-to-the-sender-of-an-email
Other Information
| API URL: | VINCE JSON | CSAF |
| Date Public: | 2025-10-28 |
| Date First Published: | 2025-10-28 |
| Date Last Updated: | 2025-10-28 14:35 UTC |
| Document Revision: | 1 |