Current standard
What this RFC defines
RFC 6152 defines the 8BITMIME SMTP extension, which allows email messages containing 8-bit content to be transmitted without base64 or quoted-printable encoding. Servers that support it advertise 250-8BITMIME in their EHLO response, and senders include BODY=8BITMIME in the MAIL FROM command.
Where you see it in practice
Without 8BITMIME, SMTP is restricted to 7-bit ASCII, which is why email body content is traditionally encoded in base64 or quoted-printable. When your ESP sends a plain-text email with UTF-8 content using 8BITMIME instead of encoding, the message is smaller and faster to transmit. Most modern mail servers support 8BITMIME, making it the preferred transport for text content that does not need base64 encoding.
Why 8-bit MIME needed a keyword
The original SMTP protocol from RFC 821 assumed 7-bit ASCII. Any byte with the high bit set was undefined behavior, which meant messages containing non-ASCII characters had to be encoded with Base64 or Quoted-Printable before transmission. RFC 1652 (obsoleted by RFC 6152) introduced the 8BITMIME extension in 1994, allowing MTAs to declare that they can accept and transmit 8-bit clean data without re-encoding. This mattered because encoding adds roughly 33% overhead (for Base64) and complicates content inspection.
The transport chain problem
An 8BITMIME message can only travel end-to-end if every MTA in the delivery path supports the extension. If any intermediate MTA lacks 8BITMIME support, the message must be down-converted, which typically means re-encoding the body as Quoted-Printable and updating the Content-Transfer-Encoding header. This down-conversion is a known interoperability trap: some MTAs perform it incorrectly, corrupting UTF-8 payloads or producing invalid MIME. In practice, 8BITMIME is universally supported in 2026 among internet-facing MTAs, so down-conversion is rare on the public internet but can still occur in restricted enterprise gateways.
Relation to internationalized email
8BITMIME allows 8-bit bytes in the message body. It does not address 8-bit bytes in envelope commands (MAIL FROM and RCPT TO) or headers, which are covered by the SMTPUTF8 extension (RFC 6531). A modern SMTP session sending an internationalized email to a mailbox like alice@ไพใ.jp requires BOTH extensions: SMTPUTF8 for the envelope, and 8BITMIME for the body content. Without SMTPUTF8, a non-ASCII domain can still travel in its Punycode form (an A-label starting with xn--), but a non-ASCII local part (the part before the @) cannot, so delivery fails.
RFC 6152 (March 2011) defines 8BITMIME: an RFC 5321 extension that lets SMTP transport 8-bit clean message content (bodies with byte values above 127). Advertised as 8BITMIME in EHLO response. Historically, SMTP was 7-bit only; 8-bit content had to be encoded (quoted-printable or base64 per MIME). 8BITMIME lets senders skip the encoding overhead when both peers support it. Prerequisite for SMTPUTF8 (which needs 8-bit clean transport). Obsoletes RFC 1652.
RFC 6152 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Allow SMTP to transport 8-bit clean message bodies without encoding overhead |
| Advertised as | 8BITMIME in EHLO response |
| Requested by | BODY=8BITMIME parameter on MAIL FROM |
| Default parameter | BODY=7BIT if not specified (legacy safe) |
| Enables | Native UTF-8 text bodies; lines still limited to 998 octets and no NUL bytes, so binary attachments still need base64 (or BINARYMIME, RFC 3030) |
| Prerequisite for | SMTPUTF8 per RFC 6531 |
| Published | March 2011 (obsoletes RFC 1652) |
| Deployment | Universal in 2026; all mainstream MTAs support |
The BODY parameter on MAIL FROM
| BODY value | Meaning | Content constraints |
|---|---|---|
BODY=7BIT | Legacy 7-bit ASCII only | Byte values 0-127 only; lines under 998 chars |
BODY=8BITMIME | 8-bit clean; MIME-declared encoding | Octets above 127 allowed; no NUL; lines up to 998 octets plus CRLF |
BODY=BINARYMIME | Binary (requires CHUNKING per RFC 3030) | Any byte value; no line length limit |
8BITMIME session example
S: 220 mx.example.com ESMTP
C: EHLO client.sender.com
S: 250-mx.example.com
S: 250-SIZE 52428800
S: 250-8BITMIME
S: 250-STARTTLS
S: 250 ENHANCEDSTATUSCODES
C: MAIL FROM:<alice@sender.com> BODY=8BITMIME
S: 250 2.1.0 Ok
C: RCPT TO:<bob@example.com>
S: 250 2.1.5 Ok
C: DATA
S: 354 End data with .
C: From: Alice <alice@sender.com>
C: To: Bob <bob@example.com>
C: Subject: Test with UTF-8 body
C: Content-Type: text/plain; charset=utf-8
C: Content-Transfer-Encoding: 8bit
C:
C: Hello Bob. Ceci contient des caractรจres 8 bits: รฉ, ร , รผ, รฑ.
C: ใใใฏ 8 ใใใใฎๆฌๆใงใใ
C: .
S: 250 2.0.0 Ok
Content-Transfer-Encoding: 8bit indicates the body is 8-bit clean.
Without 8BITMIME advertised, the same body would need to be
quoted-printable or base64 encoded, adding overhead.
Downgrade behavior when 8BITMIME unavailable
| Situation | Sender behavior |
|---|---|
| Next hop advertises 8BITMIME | Forward as-is with BODY=8BITMIME |
| Next hop does not advertise 8BITMIME, message is 7-bit | Forward as-is; no conversion needed |
| Next hop does not advertise 8BITMIME, message is 8-bit | Convert body to quoted-printable or base64 per MIME (adds Content-Transfer-Encoding header) |
| Body containing bare CR or bare LF | Not valid SMTP regardless of 8BITMIME; normalize to CRLF before sending. Many receivers now reject such messages at the end of DATA |
Common 8BITMIME mistakes
BODY=8BITMIME parameter on MAIL FROM. Sending 8-bit content without the parameter is a protocol violation. Receivers may accept, reject, or corrupt the body.Content-Transfer-Encoding MIME header. Setting this incorrectly (declaring 8bit for a base64 body, or 7bit for an actual 8-bit body) confuses parsers. The declared value should match reality.Related standards and further reading
- Content-Type and MIME Structure: how bodies are described
- RFC 2047 Guide: alternative for non-ASCII in 7-bit paths
Frequently asked questions
Do modern mail servers still need 8BITMIME advertised?
Yes, per RFC 6152. While near-universal, the advertisement is what allows senders to skip 7-bit encoding. A server that supports 8-bit content but does not advertise 8BITMIME forces senders to encode unnecessarily. Postfix, Exim, Exchange, Sendmail, and all major MTAs advertise 8BITMIME by default in 2026.
What is the difference between 8BITMIME and BINARYMIME?
8BITMIME allows 8-bit bytes but preserves SMTP line semantics (CRLF terminators, line length limits). BINARYMIME (RFC 3030) allows arbitrary binary content with no line semantics, transferred via BDAT commands (CHUNKING). Most email uses 8BITMIME because messages are line-structured (headers, body separator, text bodies); BINARYMIME is for scenarios where line handling is inappropriate (large binary attachments, streaming). 8BITMIME is universal; BINARYMIME is niche.
Why is 8BITMIME a prerequisite for SMTPUTF8?
SMTPUTF8 puts UTF-8 bytes in envelope addresses and headers. UTF-8 requires 8-bit clean transport (bytes above 127 are common). Without 8BITMIME, the transport is nominally 7-bit only, which conflicts with UTF-8. RFC 6531 requires SMTPUTF8-capable servers to also advertise 8BITMIME. In practice, since 8BITMIME is universal, this is not a practical obstacle.
Should I encode message bodies even when 8BITMIME is available?
Encoding overhead versus compatibility trade-off. base64 adds ~33% size; quoted-printable adds less for mostly-ASCII content but more for non-ASCII heavy content. On paths advertising 8BITMIME, skip encoding (declare Content-Transfer-Encoding: 8bit). On paths without 8BITMIME, encode (base64 for binary, quoted-printable for mostly-text with some non-ASCII). Modern mail libraries handle this automatically based on EHLO advertisement.
What is 7-bit and why did SMTP originally require it?
The original SMTP specification (RFC 821, 1982) was designed when many network paths used 7-bit ASCII terminals and gateways that stripped the high bit of each byte. Restricting SMTP to 7-bit ensured messages survived transit. As infrastructure modernized to 8-bit clean, this restriction became unnecessary overhead. RFC 1652 (1994) and its successor RFC 6152 introduced 8BITMIME as an opt-in escape, backward compatible with legacy 7-bit paths that do not advertise the extension.
Did this guide save you time?
SMTPedia is free and independent. A coffee helps keep every guide accurate.
Buy SMTPedia a coffeeAbout the Author
Alaa ยท LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. Iโve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.