What is SMTP smuggling, and how do you protect your mail server?

SMTP smuggling is a way to send forged email that appears to come from someone else's domain and still passes SPF and DMARC. It doesn't exploit a weak password or a phishing page. It exploits a disagreement between two mail servers about where one message ends and the next begins. This guide explains how it works, which software was affected, which versions fix it, and how to check the servers you run.

What is SMTP smuggling?

SMTP smuggling is an email spoofing technique in which an attacker hides a second, forged message inside a normal one by using a non-standard end-of-data sequence. It was published by Timo Longin of SEC Consult on December 18, 2023, ahead of a talk at the 37th Chaos Communication Congress (37C3). The name borrows from HTTP request smuggling, which abuses the same kind of parsing disagreement in web traffic.

The research put it simply: "If SMTP servers have a different understanding of where the message data ends, an attacker can potentially break out of the message data." Once outside the message data, the attacker can send fresh SMTP commands, and the receiving server treats them as a brand new email.

To follow the attack you need two terms:

• SMTP (Simple Mail Transfer Protocol) is the plain-text protocol mail servers use to hand messages to each other. Our guide to SMTP walks through a full session.
• End-of-data sequence is the marker that tells the receiving server the message body is finished. After the DATA command, the client sends headers and body, then a line containing only a period.

How does SMTP smuggling work?

SMTP smuggling works because some servers accept line endings that the standard doesn't allow. RFC 5321, section 2.3.8 says lines end with a carriage return (CR, hex 0D) followed by a line feed (LF, hex 0A), and that "conforming implementations MUST NOT recognize or generate any other character or character sequence as a line terminator." The message ends with <CR><LF>.<CR><LF>: the end of the last line, a period, and one more line ending.

Many Unix mail servers were more forgiving. Postfix's author, Wietse Venema, explains that "the vulnerability was introduced many decades ago in Sendmail, by allowing the non-standard <LF> line ending in addition to the standard <CR><LF>," and that Postfix and Exim allowed it too "for compatibility with programs that expect Sendmail behavior."

The attack needs a combination of two services, as Postfix describes it:

1. An outbound service (A) where the attacker has an account. It accepts a message containing a non-standard sequence such as <LF>.<CR><LF> and passes it on unchanged.
2. An inbound service (B) that reads that non-standard sequence as if it were the real <CR><LF>.<CR><LF>.

Service A thinks it's sending one message. Service B receives two: the attacker's harmless message, and a second one built from the "smuggled" commands that followed the fake end marker.

What does a smuggled message look like?

Here is a simplified example of what the attacker submits to service A as the body of a single message. Domain names are placeholders, and <LF> and <CR> stand for the raw control characters.

Example only (simplified):

From: attacker@provider-a.example
To: victim@company-b.example
Subject: Hello

This part is the visible first message.
<LF>.<CR><LF>
MAIL FROM:<payments@victimbrand.example>
RCPT TO:<victim@company-b.example>
DATA
From: Accounts <payments@victimbrand.example>
To: victim@company-b.example
Subject: Updated bank details

Please use the new account below for this week's invoice.
<CR><LF>.<CR><LF>

If service B accepts <LF>.<CR><LF> as the end of data, it finishes the first message there and reads MAIL FROM, RCPT TO and DATA as new commands. The second message, "from" payments@victimbrand.example, arrives from service A's IP address.

Which end-of-data sequences were tested?

SEC Consult tested several malformed sequences. The table lists the main ones from the research and the Postfix advisory.

Why does a smuggled email pass SPF and DMARC?

A smuggled email passes SPF and DMARC because it really is sent from the outbound provider's servers. SPF (RFC 7208) checks whether the connecting IP is authorized for the envelope sender's domain. If the forged domain's SPF record includes the outbound provider, which is common when a domain uses that provider for its mail, the check passes.

DMARC (RFC 9989) then asks whether SPF or DKIM passed for a domain aligned with the visible From address. In a smuggled message the attacker sets the envelope sender and the From header to the same forged domain, so SPF passes in alignment and DMARC passes too. Postfix summarizes the impact: the spoofed message "will pass SPF-based DMARC checks at email service B, because the spoofed message has a MAIL FROM address whose domain is hosted at email service A, and because the message was received from an IP address that belongs to email service A."

That's the worrying part. Most spoofing guidance, including our own on stopping spoofing of your domain, relies on SPF, DKIM and DMARC. Smuggling sidesteps them for every domain whose SPF includes a vulnerable outbound service. SEC Consult notes that content filtering can still catch these messages, so smuggled mail isn't automatically delivered to the inbox.

Which providers and mail servers were affected?

The research found vulnerable combinations on both sides. On the sending side, SEC Consult reported:

• GMX passed <LF>.<CR><LF> through unfiltered. Domains hosted at IONOS could be spoofed through the same route. GMX fixed it in August 2023.
• Microsoft Exchange Online also passed it through. Microsoft rated the issue moderate and fixed it on October 16, 2023, according to the SEC Consult timeline. Postfix's advisory names Microsoft's outlook.com as an example of the sending side.

On the receiving side, the default configurations of Postfix and Sendmail were affected, along with some hosted mail services and gateway appliances. Postfix says critical information from the researcher wasn't passed on to its maintainers before publication, and Venema called the result "a presumably unintended zero-day attack". CVEs followed on December 24, 2023:

NVD rates all three 5.3 (medium). CERT/CC Vulnerability Note VU#302671, first released on January 16, 2024, tracks other affected vendors.

How do you fix SMTP smuggling on your mail server?

You fix SMTP smuggling by making your receiving server accept only the standard <CR><LF>.<CR><LF> end of data. The steps depend on your software.

Postfix

Postfix 3.9 and later protect you by default: smtpd_forbid_bare_newline defaults to normalize, which requires the standard end-of-data sequence while still accepting bare LF inside lines from sloppy clients. On 3.5.24, 3.6.14, 3.7.10 and 3.8.5, the same feature exists but is off by default, so add it to main.cf:

smtpd_forbid_bare_newline = normalize
smtpd_forbid_bare_newline_exclusions = $mynetworks

The exclusion keeps working for devices on your own trusted networks. Postfix says the older value yes "is now an alias for" normalize, and that reject is stricter but "more likely to reject legitimate email". On releases too old for either setting, Postfix's short-term workaround is:

smtpd_data_restrictions = reject_unauth_pipelining
smtpd_discard_ehlo_keywords = chunking, silent-discard

Sendmail

Upgrade to 8.18.1 or later. The release notes say it accepts "only CRLF as end of a line and hence only CRLF . CRLF as end of a message as required by the RFCs." That behavior can be switched off with the srv_features option O, and the notes recommend turning such protections off "only for trusted networks".

Exim

Upgrade to 4.97.1 or later, and preferably to the current release. At the time of writing (November 2026), exim.org lists 4.100.1 as current and says all earlier versions are now obsolete. The ChangeLog shipped with the 4.100.1 release records a further fix to "avoid more 'SMTP smuggling' attack types" that "extends the fixes for CVE-2023-51766".

Gateways, appliances and other MTAs

Check your vendor's advisory or the CERT/CC note for your product. Some gateways "clean" messages by converting a bare CR or LF into CRLF, which is exactly what turns a malformed sequence into a valid one. Look for a setting that rejects or strips bare line endings rather than normalizing them into an end-of-data marker.

How do you check whether your servers are exposed?

Use this checklist for every server that receives mail from the internet, including relays and backup MX hosts:

1. List your internet-facing MTAs. Run an MX lookup on each domain, and add any relays or smart hosts that accept mail from outside.
2. Find the software and version. On Postfix, postconf mail_version shows it. On Exim, exim -bV. On Sendmail, the version is in the SMTP banner or sendmail -d0.1 -bv root.
3. Compare with the fixed versions in the table above. Distribution packages often backport fixes, so check your distribution's security tracker for the CVE too.
4. Check the setting, not just the version. On Postfix, postconf smtpd_forbid_bare_newline should return normalize, note, reject or the older yes, not no.
5. Be careful with scanners. Postfix warns that "some test tools may make false vulnerability claims based on non-viable attack patterns", and keeps a separate page on false smuggling claims. Test only servers you're allowed to test.
6. Apply the change and watch logs. Postfix's note mode logs notes=bare_lf for clients that send bare line feeds, which helps you find old devices before you tighten further.

If your mailboxes are on Microsoft 365 or Google Workspace with no servers of your own in the path, there is nothing for you to patch. The receiving software is the provider's.

What should domain owners do about SMTP smuggling?

Domain owners can't stop someone else's vulnerable server from accepting a smuggled message, but they can limit the damage and spot it:

• Keep SPF narrow. Smuggling borrows the trust that your SPF record gives to a shared provider. Remove services you no longer use, as covered in authenticating third-party senders.
• Sign everything with DKIM. A smuggled message won't carry your real DKIM signature. It still passes DMARC through SPF, but a missing signature is a useful signal when you investigate.
• Read your DMARC reports. Aggregate reports won't show smuggling directly, because the mail comes from your own provider's IPs. Unexplained volume from a provider you use is still worth checking with the DMARC Report Analyzer.
• Train for the content, not just the sender. Smuggled mail is still phishing. Requests to change bank details should be checked by phone, as in our guide to vendor invoice fraud.

If you're investigating a suspicious message, open its headers in the Email Header Analyzer and read the Received: lines from the bottom up. A message that claims to be from a partner but entered through a free webmail provider's outbound servers, with no DKIM signature for the partner's domain, deserves a closer look. How to read email headers explains each field.

Is SMTP smuggling the same as HTML smuggling?

No. SMTP smuggling is a transport-level trick between mail servers that forges the sender. HTML smuggling is a payload trick: an HTML attachment assembles a malicious file inside the recipient's browser, so the file never crosses the mail filter as an attachment. Both use the word "smuggling" because something slips past a checkpoint, but they need different defenses.

Next steps

• Patch every internet-facing Postfix, Sendmail or Exim server you run, and confirm the bare-newline setting is active.
• Review your SPF record and remove includes for services you no longer send through. The SPF Checker lists each include.
• Publish DMARC at an enforcing policy and keep reading the reports; the DMARC Checker shows your current policy.
• If you'd rather not patch and maintain an internet-facing MTA yourself, an MX-level filtering service such as iBlockSpam receives mail from the internet for you; see how it works.

Browse our other email threat guides.