The RFC allows 254 characters, but some platforms quietly cap email addresses far lower. Here's who, why it happens, and how to build addresses that survive.
I spend a lot of my week in client support, which means I get a front-row seat to the weird little ways email breaks in the real world. This is one of those stories. It’s cost me two separate afternoons now, so I figure it’s earned a write-up.
When we built the seed system for Postmaster+, the inbound side was almost too easy. We use Postmark’s inbound API to receive seed mail. It hands us clean, parsed messages by webhook, and we never have to babysit an inbound mail server. (We may bring that in-house during our KumoMTA migration down the road, but that’s a story for another post.) We did our homework on the addresses too. Every seed we generate is RFC-compliant: valid local part, valid domain, well under the 254-character ceiling the standard allows (see RFC 5321). What I was naive about was assuming everyone else honored that ceiling.
The first crack: 75 characters
Our very first client came to us from Keap (formerly Infusionsoft), and it’s not uncommon for senders to be on both platforms. Pretty quickly, we started hearing that those users couldn’t add our seeds to their lists. Keap caps email addresses at 75 characters, and ours were longer.
It was an easy fix. We swapped the seed domain from optipub.com to opti.pub, saved a handful of characters, and slid under 75. I also finally found a use for the .pub domain I’d been sitting on. Problem solved. On to the next fire.
The second crack: 50 characters
A couple of days ago we hit the same wall again, this time at 50 characters. Fifty.
Sit with that for a second. A UUID, the thing half of us reach for to guarantee a unique address, is 32 characters on its own without the hyphens. Add the @ and even a lean domain and you’re already brushing the ceiling. There’s almost no room left to work with.
So for the second time, I went digging, and this fix taught me something about Postmark worth passing on. On their default inbound domain, you have to use the randomly generated local part so Postmark can route the message. That meant we were carrying Postmark’s UUID on top of our own identifier, which pushed us past 50 before we’d added anything else. On a custom domain, that requirement disappears. The local part can be whatever you want, because the domain already tells Postmark where to send it.
Our dev team missed that when we first built this, so we’d been carrying Postmark’s long random local part on our custom-domain seeds for no reason at all. Our addresses were far longer than they needed to be. The fix was to drop the random string and set the local part to a plain opti@. Every existing seed still works, and we now sit at 47 characters max.
Two rounds of this got me curious, so I went and mapped where the major platforms actually land. Every number below comes from the platform’s own public documentation or API schema. But if I got something wrong here, or you can fill in a gap, shoot me a message and I’ll update the post.
| Platform | Max email length | What the limit covers | Source |
|---|---|---|---|
| RFC 5321 (the standard) | 254 (64 local + 255 domain) | The ceiling every system should accept | RFC 5321 |
| Stripe | 512 | Customer email, API — above the standard | API docs |
| OptiPub, Mailchimp, Klaviyo, HubSpot, SendGrid, Amazon SES, Postmark, Shopify, Pipedrive | No field cap (full length) | Verified from each platform’s public API schema | example: Mailchimp |
| GetResponse | 128 | Import limit (syntax error above this) | Import help |
| Zoho CRM | 100 | Standard Email field | Field reference |
| Microsoft Dynamics 365 | 100 | emailaddress1 attribute | Entity reference |
| WordPress (account email) | 100 | wp_users.user_email (varchar 100) | DB description |
| Salesforce (Sales/Service Cloud) | 80 | Standard Email field type | Field types |
| Keap (Infusionsoft) | 75 | Quick-add form | Create a contact |
| Constant Contact | 50 | Import Contacts API | Import guide |
| AWeber | 50 | Create-subscriber API | API reference |
The good news is that most platforms do the right thing. The big ESPs and CRMs either accept the full RFC length or cap somewhere sane. It’s the bottom of that table that’ll bite you, and in my experience those platforms don’t budge when you ask.
There’s one more wrinkle that decides whether a low cap is a nuisance or a dealbreaker: where the limit actually lives. Some platforms only enforce it at the front door, on the signup or quick-add form, but will still let you add a longer address manually or through the full API. Keap is like this, where the quick-add form stops at 75 characters but the full contact form takes more. Others bake the limit into the database itself, so there’s no manual entry and no workaround. The address simply can’t exist in their system. So before you write off a platform, find out which kind you’re dealing with. One is a speed bump, the other is a brick wall.
Giving the other side its due
Here’s where I have to check myself. As a builder, my gut reaction to a sub-RFC limit is “why are you inventing your own rules?” I think the RFC exists for a reason. But these platforms aren’t doing it on a whim, so it’s worth asking what the reason really is.
The answer you usually hear is bots. A tight cap knocks out some junk signups, which tend to use long, randomized addresses. I’m not sold that’s the main driver, though. It’s easy to get under the limit, so any bot that cares just switches to a shorter address. What a low cap reliably does is shrink every stored address, and at the scale these platforms run, shorter columns and smaller indexes add up to real money. My guess is bots are the reason they’ll say out loud, and cost is the quieter one.
Either way, a low cap barely touches real users. AtData ran the numbers on roughly 90 million email addresses and found the average length was just 21.9 characters, with 95% of them fitting inside 31. Most humans don’t have long addresses, so a 50-character wall costs a platform almost nothing in genuine signups.
The catch is that “most” is not “all,” and the addresses out in the long tail are disproportionately the automated ones: deliverability seeds, plus-tagged addresses, machine-generated identifiers, long corporate domains. That’s exactly the mail a low cap quietly kills. It’s a real tradeoff, and I get it even when it stings.
What I’d tell anyone building on top of email
If you’re generating email addresses at all (seeds, subaddresses, plus-tags, anything automated, even addresses your users bring you) don’t assume the RFC’s 254-character limit is your working budget. It isn’t.
From experience, the practical target for maximum compatibility is 50 characters. Hit that and you’ll clear everyone in the table above. The way you get there is to keep the parts you control short and not carry uniqueness you don’t need. In our case that random local part didn’t have to be there at all. Audit your address format before you ship it, not after two platforms bounce it like I did.
One plea
To any platform folks reading: I get the reasons, and the AtData numbers back you up on real users. But please, don’t make it any shorter than 50. You’re already cutting it close for those of us who build on top of you, and every character you shave breaks something legitimate downstream that you’ll never see.
If you run seed lists or monitor deliverability and want to know which platforms will quietly drop your addresses before you ever find out, that’s exactly the kind of thing we obsess over at Postmaster+.