What Do SMTP EHLO Extensions Like SIZE, 8BITMIME, and SMTPUTF8 Actually Do?

You send an email, but it fails silently. No bounce, no error—just gone. You check the logs, and the server said your message was too big. Or worse: a customer’s name shows up as garbled text. This isn’t random. It’s because your email didn’t negotiate the right rules during connection setup.

SMTP EHLO extensions like SIZE, 8BITMIME, and SMTPUTF8 are the handshake that determines how an email can be sent, sized, and encoded. They’re not optional extras—they’re the foundation of modern email compatibility. Without them, you’re sending blind.

Understanding these extensions matters. They prevent rejections, ensure content is preserved, and help deliverability at scale. When you know what SIZE, 8BITMIME, and SMTPUTF8 do—and how to use them—you avoid silent failures and build systems that work reliably across global inboxes.

Key takeaways

  • SMTP EHLO extensions are advertised during connection setup and define what a mail server supports.
  • SIZE lets senders declare the maximum message size, preventing silent rejections due to oversized content.
  • 8BITMIME enables non-ASCII text in message bodies without base64 encoding, reducing overhead and preserving readability.
  • SMTPUTF8 allows full UTF-8 support in email addresses and headers, enabling non-Latin scripts like Arabic, Cyrillic, and Chinese in email metadata.

Why Are SIZE, 8BITMIME, and SMTPUTF8 Important for Deliverability?

These SMTP extensions aren’t just technical details — they’re gatekeepers to reliable email delivery. Servers that support 8BITMIME and SMTPUTF8 can properly handle non-ASCII characters, ensuring multilingual emails arrive intact. SIZE tells senders how large a message can be, avoiding rejections from oversized sends. Missing any of these often means your email gets blocked, delayed, or demoted, even if the address is valid. You can verify your sending environment’s compatibility with tools like MailTester’s inbox placement test.

Modern Email Needs Modern Extensions

Let’s be clear: if your server doesn’t support 8BITMIME or SMTPUTF8, it’s running outdated infrastructure. These extensions allow full binary transfer of email content, including Unicode characters, which is essential for international domains, emojis, or non-Latin scripts. Without them, emails may arrive garbled, fail at the wire, or be flagged as suspect. The IETF’s RFC 6531 explicitly defines SMTPUTF8 for modern email, and it’s now expected by major email providers — including Google and Microsoft — for complex or multilingual content.

Even if your address is real, lacking these extensions damages sender reputation. Reputable inbox providers track technical compliance as part of their delivery decisions. An email that fails to negotiate proper encoding is likely to be throttled or rejected, especially if it appears to come from a high-volume sender. This is why you should verify compliance not just for addresses, but for your SMTP server stack.

Why SIZE Matters — And Why You Can’t Ignore It

SIZE is simple: it tells the sender the maximum message size the receiving server will accept. If the server doesn’t advertise a SIZE limit, your system has to guess. Guess wrong — and your message gets rejected after a full transfer, wasting bandwidth and risking a temporary blackhole. The RFC 5321 specification defines SIZE as an optional extension, but its absence forces senders into a state of uncertainty.

For example, a 15MB marketing PDF might be blocked by a server that caps at 10MB — but only if SIZE is negotiated. If your sending process doesn’t check before sending, you’re playing catch-up. Tools like MailTester’s bulk verification test this behavior at scale, flagging domains that don’t support standard extensions. This gives you real-time insight into technical readiness before your campaign launches.

These aren’t optional niceties. They’re part of a server’s technical profile — a signal of reliability. Email providers use such signals across their filtering stack. A server that refuses 8BITMIME, ignores SIZE, or doesn’t support SMTPUTF8 is seen as low-grade, not just technically backward, but a potential vector for abuse. The result? Lower inbox placement, higher spam filtering rates, and lost delivery rates. Verify your entire email workflow — every step — with data, not hope.

How Do Mail Servers Negotiate EHLO Extensions During Delivery?

When a mail client connects via SMTP, it sends an EHLO command listing the extensions it supports—like SIZE, 8BITMIME, and SMTPUTF8. The receiving server responds with its own list of supported extensions, setting the rules for the message transfer. If your message exceeds the advertised SIZE limit, the server will reject it mid-transmission. Modern systems use 8BITMIME for binary content and SMTPUTF8 for Unicode only if both are explicitly declared during the handshake. This negotiation prevents surprises later in the delivery path.

  1. Client opens a connection and sends EHLO. The client identifies itself and lists its supported extensions. A properly configured client will include SIZE, 8BITMIME, or SMTPUTF8 if it expects to send larger or non-ASCII messages.
  2. Server responds with supported extensions. The server replies with a list of extensions it will honor. If it advertises SIZE 10240000, it expects messages under 10MB. Rejects happen if you exceed that limit.
  3. Client checks server limits before transmission. You should validate the received SIZE value before sending, especially for bulk or attachment-heavy campaigns. Sending a 15MB email to a server that only allows 10MB triggers a rejection during DATA phase.
  4. Extensions are applied based on mutual support. If both client and server support 8BITMIME, binary content can be sent directly. SMTPUTF8 is only used if both sides agree—otherwise, UTF-8 text is rejected or truncated.
  5. Invalid or inconsistent extension use breaks delivery. If the server advertises SMTPUTF8 but you send non-UTF-8 encoded headers, or if you misreport your SIZE limit, the server may reject the message with a 5xx error.

Why the order matters

The EHLO handshake happens before any message data. That means delivery failure due to extension mismatch occurs early—before you’ve sent a single byte of content. This is why validating your setup during inbox placement testing matters. A tool like MailTester's inbox placement tester simulates real-world conditions, including extension negotiation, to catch such issues before you send.

Real-world implications

Many servers, especially at large providers like Gmail, enforce SIZE limits strictly. If you send a 25MB attachment to a server that only allows 10MB and didn’t advertise SIZE during EHLO, the message will be rejected before it ever reaches the inbox. This is a common cause of failed email delivery in bulk campaigns.

Always ensure your mail server or platform advertises correct, accurate limits. You can test your server's behavior using tools that simulate real SMTP handshakes and verify the responses. MailTester's bulk verification checks not just syntax, but also server-level behaviors like extension negotiation indirectly by validating deliverability patterns at scale.

What Does It Mean When a Server Says '8BITMIME' or 'SMTPUTF8' Is Supported?

When a mail server lists support for 8BITMIME or SMTPUTF8, it means it can handle email content without requiring 7-bit ASCII encoding restrictions—8BITMIME allows raw 8-bit message bodies, while SMTPUTF8 lets you send addresses and headers with non-ASCII characters like é, 你好, or नमस्ते. This is standard in modern services like Gmail, Microsoft Outlook, and SendGrid. Lack of support likely points to outdated systems, conservative filtering policies, or misconfiguration.

8BITMIME: Bypassing 7-bit Encoding Limits

8BITMIME is an SMTP extension that tells the receiving server: "I can process 8-bit data in the message body without needing Base64 or Quoted-Printable encoding." This means binary attachments like PDFs or images are transmitted more efficiently, with no overhead from conversion.

Without 8BITMIME, every message body must be encoded into 7-bit ASCII—slowing down delivery and increasing size. Most modern production systems support this extension. If a server doesn’t, you're likely dealing with legacy infrastructure, overly strict filtering, or a misconfigured mail server.

SMTPUTF8: Sending Non-ASCII Email Across Languages

SMTPUTF8 extends the protocol to allow non-ASCII characters in email addresses and headers. It enables sending emails to internationalized domain names (IDNs) or addresses like user@域名.abc, or subject lines with accents or Cyrillic text.

Support for SMTPUTF8 is now expected in global email services. If a server doesn’t support it, you’ll face delivery failures when sending to non-Latin scripts—common in markets like China, Japan, Russia, or parts of Europe. This isn’t just about language; it’s about reliability.

Even if your mail system says it “supports 8BITMIME,” that doesn’t imply UTF-8 readiness. You need both. The absence of either extension can result in rejected or misrouted messages—even if the email address is technically valid.

Before you send bulk campaigns, verify real-world server support for these extensions. Tools like MailTester’s inbox placement test simulate real delivery conditions, uncovering issues like missing extensions early. Don’t rely on address syntax alone—true deliverability depends on server capability. If you’re seeing high bounce rates from non-English domains, check for 8BITMIME and SMTPUTF8 support on the receiving end. That’s where the real problem often hides.

How to Test Server Support for EHLO Extensions Including SIZE?

You can test SMTP server support for EHLO extensions like SIZE, 8BITMIME, and SMTPUTF8 by connecting directly via a command-line tool like Telnet or OpenSSL, then examining the server’s response after the EHLO command. Look for the presence of these keywords in the response line — their inclusion means the server supports that feature. Tools like MailTester’s inbox placement tests automate this verification at scale, while manual testing gives full visibility into each server’s capabilities.

Step-by-step verification checklist

  • Open a terminal and connect to the target mail server using Telnet or OpenSSL: telnet mail.example.com 25 or openssl s_client -connect mail.example.com:587 -starttls smtp.
  • After the initial connection, send the EHLO command: EHLO example.com.
  • Examine the server’s response line for keywords such as SIZE, 8BITMIME, and SMTPUTF8.
  • If SIZE appears, the server accepts limits on message size during transmission — important for large attachments.
  • Presence of 8BITMIME indicates support for 8-bit data, allowing non-ASCII content in the body. Without it, only plain ASCII is safe.
  • SMTPUTF8 support enables non-ASCII characters in email headers and addresses — critical for international domains.
  • Pay attention to servers that report SIZE but not 8BITMIME. Such servers may reject non-ASCII content even if the message size is acceptable.
  • Use tools like RFC 5321 or RFC 6152 to understand the specification behind these extensions.
  • Automate testing across multiple domains with MailTester’s inbox placement tests to catch issues before sending bulk campaigns.

When manual testing isn’t enough

For high-volume senders, real-time verification at scale is essential. You can use MailTester’s verification API to check email addresses and infer server capabilities during bulk validation. This includes detecting issues like missing 8BITMIME that might otherwise go unnoticed during manual inspection.

Support for these extensions is not optional in modern email delivery — it’s foundational to reliable, universal inbox placement.

Always validate both the presence and behavior of these extensions. A server may advertise support but still reject valid data. Only confirmed compatibility prevents delivery failures, bouncebacks, and reduced sender reputation.

Can You Verify Email Addresses Using SMTP EHLO Extension Support?

Not directly. SMTP EHLO extensions like SIZE, 8BITMIME, and SMTPUTF8 indicate what a mail server can handle, not whether a specific address exists. A server supporting 8BITMIME doesn’t mean the mailbox is valid—only that it can receive non-ASCII or larger messages. These extensions are capabilities, not confirmations.

What EHLO Extensions Actually Tell You

When a server advertises 8BITMIME, it means it accepts 8-bit data in messages—no encoding required. SMTPUTF8 allows non-ASCII characters in email addresses and headers. SIZE tells you the maximum message length the server will accept. These are infrastructure signals, not validation results.

For example, a server that doesn’t support 8BITMIME might reject modern messages or strip content—leading to poor deliverability, even if the address is real. But the presence of these extensions doesn’t prove the address exists. A mailbox could still be invalid, inactive, or caught in a catch-all rule.

Why Support Still Matters

Even if you can’t verify an address from extensions alone, their absence can highlight risk. Servers that don’t support modern standards often run outdated software, increasing the chance of spam filtering or rejection. Poorly configured servers are more likely to be on blocklists or fail authentication checks like DMARC.

That’s why MailTester doesn’t just check extensions—it uses real SMTP connections to validate the server’s ability to receive mail, then cross-references it with address-level testing across 100+ real mail servers. We evaluate whether the server supports 8BITMIME and SMTPUTF8, but treat that as one data point among many, not a verdict.

Our approach combines real-time protocol checks, DNS lookups, and behavioral signals to assess validity. You can test bulk lists with our bulk verification tool, integrate with your stack via our API, or verify inbox placement with our inbox tester.

SMTP extensions are technical footprints, not truth markers. The real test is whether the server accepts mail—and that’s what we measure.

Can You Test EHLO Extension Support for Multiple Addresses at Once?

Yes — you can test EHLO extension support for hundreds or thousands of email addresses at once using MailTester’s bulk verification tools. The API or list uploader connects directly to live SMTP servers for each address, checking real-time responses, including advertised extensions like SIZE, 8BITMIME, and SMTPUTF8. You get technical results per address, showing exactly which features the receiving server supports.

How It Works in Practice

Let’s say you’re sending to a large list and want to know how many domains support 8BITMIME or accept large message sizes. You upload your list to MailTester’s bulk verifier, and it performs a live SMTP handshake with each recipient’s mail server during verification. The tool captures the server’s EHLO response — including advertised capabilities — and returns structured data.

For example, if a server says “SIZE 52428800 8BITMIME SMTPUTF8”, MailTester logs that the server supports message size limits up to 50MB, binary content, and UTF-8 encoding. You can filter results by extension support, helping you identify domains with outdated or restrictive mail server configurations.

Why This Matters for Deliverability

Not all mail servers support modern extensions. If your emails contain attachments or non-ASCII text, and the recipient’s server doesn’t support 8BITMIME or SMTPUTF8, delivery can fail or messages may be silently dropped. Testing at scale reveals infrastructure gaps across your list — for instance, if 12% of your list comes from domains that reject UTF-8, you’re at risk of message corruption.

Many organizations rely on RFC 1869 and RFC 3030 for SMTP extension handling, and modern mail systems expect these features. A server that only advertises a basic EHLO response (like “EHLO mail.example.com”) likely lacks features needed for reliable delivery. You can use the data from MailTester to segment risky domains, improve sender reputation, and reduce bounces.

You can run this kind of test on any list — from a new campaign list to a customer database. The results help you adjust your sending strategy, avoid blacklists, and improve inbox placement.

Learn more about bulk verification: MailTester’s bulk email list verification. Or explore the real-time API for integration with your workflow: MailTester API. All credit packs never expire, and you get 100 free verifications to start.

How Does MailTester Use EHLO Extensions to Improve Verification Accuracy?

MailTester boosts accuracy by performing real SMTP handshakes and analyzing EHLO responses to check if a server supports modern extensions like SIZE, 8BITMIME, and SMTPUTF8. Servers that support these extensions are more likely to accept messages and deliver them to inboxes—indicating a healthier mail environment. This helps us flag high-risk addresses on outdated or restrictive systems before they waste your sends.

What EHLO Extensions Tell Us About Mail Server Health

When MailTester connects to a mail server, it starts with the EHLO command and reads the server’s response. That response lists the extensions the server supports—like 8BITMIME, which allows non-ASCII content, or SIZE, which tells senders the maximum message size it can handle. We record whether each extension is present so we can assess the server’s capabilities.

Servers that don’t support 8BITMIME or SMTPUTF8 often reject messages with modern content—like non-English characters or large attachments. In testing, we’ve seen that addresses on such servers have significantly higher bounce or block rates. This isn’t just a technical detail; it’s a direct signal of deliverability risk.

Linking Extension Support to Deliverability Performance

Extended support (especially 8BITMIME and SMTPUTF8) correlates strongly with better inbox placement. RFC 6531 outlines SMTPUTF8 as a way to handle internationalized email, and servers supporting it are more likely to be actively maintained and compliant with modern email standards.

Based on real-world inbox placement tests across major providers, domains with servers supporting these extensions see a measurable improvement in delivery success. You can test this yourself with our inbox-placement tester, which evaluates how likely your message is to land in a real inbox, not just a spam folder.

Using this data, MailTester doesn’t just check if an email exists—it evaluates whether the server is likely to deliver your message. This gives you a clearer picture of your list quality than tools that only check syntax or basic address existence.

For teams that need to verify thousands of emails at once, we offer a bulk verification solution that applies these same checks at scale. Our API version https://mailtester.com/api-email-checker does the same in real time. Every verification includes this layer of server capability analysis—not just for accuracy, but for deliverability.

What Are the Practical Limits of EHLO Extension Detection?

EHLO extension detection tells you what a server claims to support, but not what it actually enforces. Some servers advertise SIZE, 8BITMIME, or SMTPUTF8 in their EHLO response even if they don’t fully implement them. Firewalls, graylisting, and rate limits can delay or block EHLO exchanges altogether, leading to false negatives. Even if a server says it supports SMTPUTF8, it may still reject emails with non-ASCII content. Detection results should be just one signal among many — never the sole basis for deliverability decisions.

Not All Responses Are Honest

Let’s be clear: a server saying it supports 8BITMIME doesn’t mean it can handle every 8-bit byte safely. Some servers advertise support for extensions they only partially enable — or disable after a few messages. This is especially true with older or misconfigured infrastructure. You can’t assume protocol-level claims equate to functional reliability.

Infrastructure Can Disrupt the Process

Firewalls or security appliances sometimes interfere with the initial SMTP handshake. Graylisting can delay the EHLO response, making timing-based detection unreliable. Rate limiting may drop your connection before you even receive the full extension list. These conditions cause what looks like missing or inconsistent EHLO responses — but the real problem isn’t the server, it’s the path between you and it.

Even if you detect that a domain supports SMTPUTF8, that doesn’t mean all content will pass. A server might block certain Unicode sequences, specific language tags, or email bodies with non-UTF8 encoding. Deliverability depends on more than protocol detection — it depends on policy, content filtering, and sender reputation.

That’s why tools that use EHLO extension data need to combine it with other signals. Check real-world delivery with inbox placement testing. Validate syntax and content against industry standards. Use real-time verification to catch invalid or risky addresses early. This layered approach is how serious senders avoid wasted sends and deliverability drops.

For example, MailTester’s bulk verification checks EHLO responses alongside DNS, syntax, and mailbox behavior, giving you a much clearer picture of what will actually deliver. Our inbox placement tests simulate real inboxes across providers, showing you where your emails land — or don’t. These signals work together, not in isolation.

EHLO extensions are helpful, but they’re just a starting point. Treat them as one layer in a larger system. The goal isn’t just to detect extensions — it’s to deliver reliably. That happens by combining detection with real-world validation.

Ensure your mail server advertises supported extensions like SIZE, 8BITMIME, and SMTPUTF8 in its EHLO response, respects the advertised SIZE limit, uses UTF-8 only when SMTPUTF8 is confirmed supported, and validates compliance with real SMTP tools before sending large campaigns. This prevents rejection due to unsupported extensions or oversized messages.

Check Your Server’s EHLO Response

  • Verify your mail server sends a clean, consistent EHLO response that lists only truly supported extensions.
  • Use tools like MXToolbox or RFC 5321 to inspect outgoing EHLO responses in real-time.
  • Remove any extensions from the response that your server doesn’t properly handle—overclaiming breaks compatibility.

Adhere to Advertised Limits and Encoding

  • Never send messages larger than the SIZE limit your server advertises; exceeding it leads to immediate rejection.
  • Use 8BITMIME only if your receiving server explicitly announces support—otherwise, stick to 7-bit encoding.
  • Only enable SMTPUTF8 for non-ASCII content if the remote server’s EHLO explicitly lists it—don't assume support.
  • Test large or non-ASCII messages using an inbox placement test first to validate delivery across real mail environments.
Proper EHLO extension handling isn't optional—it’s how SMTP communication agrees on what each side can do. Misalignment here is a leading cause of silent delivery failures.

Let’s be clear: if your server claims to support SIZE but doesn’t enforce it, or announces SMTPUTF8 but fails on UTF-8 content, you’ll see hard bounces or graylisting. These aren’t "glitches"—they’re protocol rules enforced strictly at scale.

Use MailTester’s bulk verification to scrub lists before sending, ensuring all addresses are live and compliant—this helps avoid sending to ill-behaved domains that may choke on extension mismatches.

And yes, you can test your own server’s EHLO behavior against real-world recipients using MailTester’s inbox placement tool. It shows you exactly how your message is treated on real systems, not just test servers.

Bottom line: if you’re not checking your EHLO response for correctness, you’re flying blind. Fix it early, test it rigorously, and stay compliant.

The Bottom Line: Using EHLO Extensions to Build Reliable Email Infrastructure

EHLO extensions like SIZE, 8BITMIME, and SMTPUTF8 are not just protocol details — they signal a mail server’s readiness to handle modern email traffic safely and reliably.

When a server advertises these extensions, it confirms support for larger messages, non-ASCII content, and size limits. Missing or improperly implemented extensions can lead to silent bounces, rejected messages, and degraded sender reputation.

Tools like MailTester validate EHLO responses as part of real-time verification and inbox placement testing. This helps identify infrastructure gaps before they impact deliverability.

Proactive validation of these extensions prevents technical failures, reduces bounce rates, and strengthens sender reputation by ensuring your setup meets industry standards.

Sources

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What does 8BITMIME mean in SMTP?

8BITMIME enables the transfer of non-8-bit clean content (like most text) in email bodies without requiring base64 encoding, improving efficiency for non-ASCII content.

What is the SIZE extension in SMTP?

SIZE is an SMTP extension that informs the sender of the maximum message size a server will accept, helping avoid large message rejections.

What is SMTPUTF8 used for?

SMTPUTF8 allows SMTP to transmit email addresses and headers using UTF-8 encoding, enabling full support for non-Latin scripts in email.

Do all mail servers support 8BITMIME and SMTPUTF8?

Most modern servers do, especially major providers like Gmail and Outlook. Legacy systems may not, especially in regulated or older environments.

Can I test EHLO extensions manually?

Yes — using command-line tools like Telnet or OpenSSL to connect directly to an SMTP server and observe the EHLO response.

How does MailTester check for EHLO extensions?

MailTester performs real SMTP handshakes and parses EHLO responses to detect whether servers support SIZE, 8BITMIME, and SMTPUTF8 during verification.

Why should I care about SMTP extensions if I only send newsletters?

Modern extensions affect deliverability, especially with international or complex content. Support ensures your messages aren’t blocked on technical grounds.

What happens if a server doesn’t support 8BITMIME?

The sender must use 7-bit encoding like base64, reducing efficiency and increasing message size, but the email can still be delivered.

Does having SMTPUTF8 support mean my emails will land in the inbox?

No — SMTPUTF8 enables Unicode support but doesn’t guarantee inbox placement. It’s one factor among many, including reputation and content quality.

Can you test EHLO extensions for disposable email addresses?

Yes — MailTester checks both the extension support and address validity, including for disposable domains that may offer limited or inconsistent SMTP features.