Subject line and From address character limits are not one simple pair of numbers. They are the result of separate rules for message headers, SMTP transport, encoded Unicode, mailbox syntax, DNS names, and the receiving system’s own policy.

The short answer

For most transactional-email implementations, use these conservative engineering limits:

Keep an ordinary ASCII subject line at or below 78 characters per physical header line when possible, and always fold header lines before 998 octets.
Treat a UTF-8 subject’s size in encoded octets, not visible characters. Long non-ASCII subjects can expand substantially when MIME encoded-word syntax is used.
Keep the email address in a From header at or below 254 octets as a practical interoperability limit.
Keep the local part (the text before @) at or below 64 octets.
Keep each DNS label at or below 63 octets, and keep a fully qualified DNS name within 255 octets on the wire (commonly up to 253 characters in presentation form without a trailing dot).
Use a From domain that you control and authenticate with SPF, DKIM, and DMARC.

Those numbers are useful guardrails, but they answer different questions. A subject is a structured RFC 5322 header field. A From field contains one or more mailbox addresses, potentially with a display name. The sender address used for SMTP delivery is a separate envelope value, and it has its own constraints.

Why there is no single character limit

The word “character” hides several different measurements. An ASCII letter such as A occupies one octet. A Unicode character may occupy two, three, or four octets in UTF-8. A MIME-encoded representation of that character can be longer still.

Email also moves through layers:

Your application creates a subject, display name, envelope sender, and header sender.
An email library serializes those values into RFC-compliant headers.
An SMTP client sends command lines and message data to a relay.
A receiving relay and mailbox provider apply protocol checks, reputation checks, and local anti-abuse policies.
A mail client displays a decoded subject and a friendly sender name to the recipient.

A value that looks short in a product interface can exceed a wire-level limit after encoding. Conversely, a syntactically valid address can be rejected because a provider does not support SMTPUTF8, because its domain is not authenticated, or because a security policy disallows the sender.

This is why robust applications validate early, encode correctly, and treat a successful API request as only the first step in delivery.

Subject line limits: RFC header lines versus product policy

A Subject field does not have a universal semantic maximum such as “100 characters.” RFC 5322 instead defines line-length limits for Internet message format headers.

Each physical line of a message must be no more than 998 characters excluding CRLF, and should be no more than 78 characters excluding CRLF. These are line limits, not a statement that a subject may only contain 78 visible characters. A long Subject field can be folded across multiple physical lines by inserting a CRLF followed by whitespace.

For example, the following is one logical Subject field, folded into two physical lines:

Subject: Your monthly usage report is ready for review and includes
  account activity through 31 July

A recipient reconstructs the unfolded field by replacing the line break and leading whitespace with whitespace. Folding must happen between tokens or words; do not split an encoded sequence, a UTF-8 byte sequence, or a word in a way that changes meaning.

The 78-character recommendation

The 78-character recommendation is a practical interoperability target. It avoids problems with old software, terminal displays, log readers, header parsers, and downstream systems that are less tolerant than modern mailbox providers.

It does not mean every visible subject must be capped at 78 characters. A transactional confirmation such as this may be longer while still being valid when correctly folded:

Subject: Your order #A-10482 has shipped — tracking and delivery details inside

However, application teams commonly impose their own shorter content limit, often around 50 to 70 visible characters, for inbox preview and mobile rendering. That is a usability choice, not an SMTP requirement. It should not be confused with the RFC line-length rule.

The 998-octet hard limit

The 998 limit is the critical transport-oriented ceiling for a physical header line. An unfurled subject line exceeding it is malformed under RFC 5322 expectations and can be rejected, truncated, rewritten, or mishandled by intermediary software.

Use octets rather than JavaScript string length or a database’s character count when checking this boundary. A string containing emoji, accented letters, or non-Latin scripts can have a byte length much larger than its apparent length. In Node.js, for example, Buffer.byteLength(value, 'utf8') measures UTF-8 bytes; it is more relevant than value.length for transport validation.

A mature mail library should perform header folding itself. Avoid manually adding \r\n to a subject supplied by an application or user. Improper line breaks can create header-injection vulnerabilities.

Unicode subjects and MIME encoded-word expansion

Header fields historically used ASCII. When a Subject includes non-ASCII text and the message is not using an SMTPUTF8-aware path for headers, mail software typically represents it with RFC 2047 encoded words.

A displayed subject such as:

Subject: ✅ Your résumé has been received

may be serialized approximately like this:

Subject: =?UTF-8?Q?=E2=9C=85_Your_r=C3=A9sum=C3=A9_has_been_received?=

The recipient’s client decodes it for display. The encoded form is what matters for header-line length. The exact encoding can be quoted-printable-like Q encoding or Base64 B encoding, and the size varies with the chosen method and characters present.

Encoded words have their own length rule

RFC 2047 limits each encoded-word to 75 characters or fewer, including the =?charset?encoding?...?= wrapper. Long non-ASCII header text must therefore be divided into multiple encoded words, with valid whitespace between them.

This is another reason not to implement subject encoding yourself. A naive implementation may create an encoded word longer than 75 characters, split a multi-byte UTF-8 character, or fold the header in the middle of encoded syntax. Any of those mistakes can produce garbled subjects or parser failures.

SMTPUTF8 does not eliminate all limits

SMTPUTF8, specified by RFC 6531, permits internationalized email addresses and UTF-8 content in relevant SMTP contexts when both sides support the extension. It improves support for native Unicode, but it does not remove RFC 5322 header structure or line-length requirements.

An SMTP client discovers support through the server’s EHLO response. A relay advertising SMTPUTF8 can accept an SMTPUTF8 transaction; a relay that does not advertise it cannot safely accept UTF-8 mailbox syntax requiring that extension. In API-based sending, the provider handles the SMTP exchange, but your input still needs to be valid for its supported delivery paths.

For broad compatibility, use Unicode subjects through a tested mail library or provider API, and test messages in the mailbox providers your audience uses most.

From header anatomy and address limits

The From header identifies the author(s) of the message. Its common form combines an optional display name with a mailbox address:

From: Acme Receipts <receipts@example.com>

The display name and the mailbox are different pieces with different rules. The mailbox has protocol and DNS constraints. The display name is a header phrase that may require quoting or RFC 2047 encoding.

Local part: 64 octets

The local part is the section before the at sign:

receipts@example.com
^^^^^^^^
local part

SMTP specifies a maximum local-part length of 64 octets. The word octets matters: a 64-character ASCII local part is normally 64 octets, but Unicode local parts under SMTPUTF8 can consume more than one octet per displayed character.

A conservative sender should use simple, stable ASCII local parts such as receipts, notifications, support, or billing. These are easy to read, easy to authenticate, and less likely to expose edge cases in legacy systems.

Domain part: DNS is the constraint

The domain part follows @:

receipts@example.com
         ^^^^^^^^^^^
         domain part

A single DNS label cannot exceed 63 octets. Labels are separated by dots. For example, mail.example.com has three labels: mail, example, and com.

A fully qualified domain name is limited to 255 octets in DNS wire format, where each label has a length octet and the name ends with a root-label octet. In ordinary textual presentation, a maximum is commonly described as 253 characters without a trailing dot, though practical use should leave room and avoid operating near this boundary.

Internationalized domain names require additional care. A domain such as münchen.example is represented in DNS using ASCII-compatible encoding, for example an xn-- label. Validate the resulting ASCII/Punycode form against DNS label limits rather than relying only on the visible Unicode form.

Mailbox: 254 octets in practice

The often-cited maximum mailbox length is 254 octets. It follows from SMTP’s maximum reverse-path or forward-path length of 256 octets, including the angle brackets around the path. It is a practical maximum for an email address used in modern systems.

Do not assume that every valid combination of a 64-octet local part and a maximum-length domain is operationally useful. User interfaces, databases, forms, CRM systems, and third-party integrations often enforce lower limits. When collecting customer addresses, accepting up to 254 octets is generally appropriate; when creating your own sender addresses, use much shorter values.

Display names are not email addresses

The display name is the human-facing portion of a From header:

From: Acme Customer Support <support@example.com>

It is not part of the mailbox address. Its practical length is governed by header-line handling, encoding, and mailbox-provider display behavior rather than a simple 64- or 254-character address limit.

ASCII display names containing only ordinary phrase-safe characters may be emitted directly. Names containing commas, quotes, parentheses, or other special characters often need quoting. For example:

From: "Acme, Inc." <receipts@example.com>

A double quote inside a quoted display name needs escaping. Non-ASCII names may need RFC 2047 encoding when SMTPUTF8 is not applicable. Let a standards-aware library handle this.

Avoid misleading display names

A technically valid display name can still cause deliverability and trust problems. Display names that impersonate another organization, contain excessive punctuation, use deceptive Unicode lookalikes, or are dramatically different from the sending domain can trigger filtering or confuse recipients.

Use a recognizable, stable pairing such as:

From: Northwind Billing <billing@northwind.example>
Reply-To: support@northwind.example

Do not put an email address inside the display name to work around address validation. For example, From: support@northwind.example <random@other.example> is confusing and may be treated suspiciously. The visible identity, header From domain, and authenticated domain should align as closely as possible.

Header From, envelope sender, and Reply-To are different

Developers often call all sender values “the From address,” but they serve separate functions.

Header From

The From: header is displayed by mail clients and identifies the message author. It is required for normal Internet email messages. It can contain a display name and mailbox.

SMTP envelope sender

The SMTP envelope sender is passed in the MAIL FROM command during delivery:

MAIL FROM:<bounces@bounce.example.com>

It is also called the return path or bounce address in many systems. Delivery-status notifications and some automated bounces are directed here. It may differ from the visible header From address.

The envelope sender is subject to SMTP path limits and domain authentication requirements. It can be empty (MAIL FROM:<>) for certain automated messages such as delivery status notifications, where an empty reverse path prevents mail loops.

Reply-To

Reply-To: tells a recipient’s email client where a human reply should go:

Reply-To: help@northwind.example

It does not change the visible From identity or the bounce destination. Use it when replies should reach a different monitored mailbox, but avoid using it to hide an unrelated sender identity.

Sender

The Sender: header is different again. It may be needed when the person or system that transmits a message differs from the author listed in From, especially when From contains multiple mailboxes. Most application-generated transactional messages have one From mailbox and do not need a separate Sender field.

DNS and authentication constraints on the From domain

A syntactically valid From address is not enough to send trustworthy mail. The domain must be configured so that receiving systems can authenticate and evaluate the message.

SPF record syntax

SPF is published as a DNS TXT record. A basic example is:

example.com. IN TXT "v=spf1 ip4:198.51.100.25 -all"

This says that 198.51.100.25 is authorized to send for the SPF identity being evaluated, and other sources should fail. In real deployments, the SPF record may use an include mechanism supplied by an email service:

example.com. IN TXT "v=spf1 include:_spf.email-provider.example -all"

Use exactly one SPF TXT record per domain. Multiple records beginning with v=spf1 can result in an SPF PermError. SPF checks the SMTP envelope identity, typically the MAIL FROM domain, not necessarily the visible header From domain.

DKIM record syntax

DKIM signs selected message headers and publishes the public key under a selector-specific DNS name. A simplified TXT record looks like this:

s1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

The outbound service signs with selector s1; receivers retrieve s1._domainkey.example.com to verify the signature. Production keys are long, and DNS interfaces may show one long TXT value as multiple quoted strings. DNS resolvers concatenate adjacent quoted strings, so that presentation is normal.

DKIM is particularly important for the visible From domain because DMARC can use DKIM alignment. A valid DKIM signature from an unrelated domain may pass DKIM but not align with the From domain for DMARC.

DMARC record syntax

DMARC is also a TXT record, placed under _dmarc:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"

The example requests aggregate reports and strict alignment for DKIM (adkim=s) and SPF (aspf=s). A domain may later use p=quarantine or p=reject after monitoring and validating all legitimate senders.

DMARC evaluates the RFC 5322 header From domain. It passes when either SPF passes and aligns, or DKIM passes and aligns, subject to the domain’s alignment settings. This is why sending From: billing@example.com through an unconfigured or unrelated infrastructure can fail even when the address is short and syntactically correct.

Use DNS inspection tools such as MXToolbox, dig, or nslookup to confirm published records. For a full-message view of authentication results, content signals, and common formatting issues, send a test to mail-tester.com. Test results are diagnostic evidence, not a guarantee of inbox placement.

Validation rules for applications and APIs

Validation should prevent malformed input without rejecting legitimate addresses unnecessarily. Email syntax is broader than many regular expressions suggest, and the best validation strategy depends on whether you are validating an address your system creates or an address supplied by an end user.

Validate sender addresses strictly enough

For addresses your application sends from, enforce a narrow policy:

Require one mailbox address, not a comma-separated list.
Use a controlled, authenticated domain.
Keep local parts simple ASCII and below 64 octets.
Reject CR, LF, and other control characters everywhere.
Keep the complete mailbox below 254 octets.
Validate DNS labels and the final ASCII domain representation.
Serialize display names separately from mailbox addresses.

This policy is intentionally stricter than the theoretical grammar. It reduces ambiguity, header-injection risk, and provider-specific surprises.

For recipient addresses entered by people, do not use a simplistic regex as proof of deliverability. Check basic syntax and length, then verify ownership through a confirmation flow when appropriate. A free email address verification tool can help identify obvious address and domain issues before sending, but no verifier can guarantee that a mailbox will accept every future message.

Validate subjects as untrusted header input

Treat a subject as text, not as preformatted header content. Your application should:

Reject or remove carriage return (\r) and line feed (\n) characters from untrusted values.
Apply a product-level visible-character limit appropriate to your UI, such as 100 to 150 grapheme clusters.
Measure encoded byte length when constructing raw messages.
Delegate RFC 2047 encoding and header folding to a trusted library or sending service.
Preserve meaningful transactional identifiers, but avoid leaking secrets, full payment data, or password-reset tokens into a subject.

The last point has operational consequences. Subjects are frequently visible in notifications, lock-screen previews, forwarded threads, logging systems, and support screenshots. A subject like Reset code: 483921 may be technically legal but is a security and privacy mistake.

SMTP and API failures you may see

When limits or syntax are wrong, the error can appear at different stages. SMTP uses three-digit reply codes; REST APIs often use HTTP status codes plus a provider-specific error body.

An SMTP server may return:

500 for a command syntax error, such as an invalidly formed SMTP command.
501 for invalid command arguments or parameters, such as a malformed path argument.
552 when an allocation or message-size limit is exceeded; exact use varies by server.
550 for a permanent mailbox, policy, or sender rejection.
554 for a transaction failure or policy rejection, often with explanatory enhanced status text.

Enhanced status codes can add useful detail. For example, a response may include 5.1.7 for a bad sender mailbox syntax or 5.7.1 for a delivery not authorized or policy-related rejection. Their usage is not perfectly uniform across providers, so log the complete server response rather than branching solely on one code.

With a REST email API, malformed JSON or invalid field types commonly produce HTTP 400 Bad Request. A semantically invalid sender or subject field may yield 400 or 422 Unprocessable Content, depending on the service. A message that exceeds a provider’s body-size cap may yield 413 Content Too Large. These are common HTTP patterns, not universal email-API guarantees.

A REST API or SMTP relay may accept a message and later record a delivery failure after the recipient system evaluates DMARC, mailbox existence, reputation, or content policy. Build event handling and retry logic around failure class: retry temporary SMTP 4xx failures with backoff, but do not repeatedly retry permanent 5xx syntax or policy failures without changing the cause.

For implementation-level request formats, SMTP relay setup, and message construction guidance, consult your provider’s email API reference and setup guides rather than guessing at field names or endpoint behavior.

Practical examples and safe defaults

A straightforward transactional sender might use:

From: Northwind Notifications <notifications@northwind.example>
Reply-To: support@northwind.example
Subject: Your invoice INV-10482 is ready

This is readable, short, and easy to align with an authenticated domain. The visible display name explains why the recipient is receiving the message. The local part is stable, and the subject communicates the event without exposing sensitive details.

A more complex but valid display name requires careful serialization:

From: "Northwind’s EU Support Team" <support@eu.northwind.example>
Subject: Votre demande a bien été reçue

A mail library may encode the display name and subject for transport. Your code should pass structured values—display name, address, subject—not concatenate a raw From: line itself.

Examples to avoid

Avoid this subject if user input can reach it unchanged:

Subject: Welcome, Alice
Bcc: attacker@example.net

That CRLF sequence is header injection. Even if your API blocks it, relying on the provider as the only defense is unsafe.

Avoid an overlong generated local part such as:

very-long-per-user-identifier-that-keeps-growing-with-metadata-and-exceeds-sixty-four@example.com

Use a compact identifier or a mapping in your own database instead. Local parts are not a good place to embed unbounded data.

Avoid a From domain that is only visually similar to your real domain. Unicode lookalikes and unrelated subdomains increase phishing risk and can create DMARC alignment failures. Choose one canonical sending domain and document which systems are authorized to send from it.

Deliverability implications beyond validity

Meeting character limits makes a message valid; it does not make the message wanted or trusted. Deliverability depends on authentication, reputation, recipient engagement, complaint rates, content, and sending consistency.

Subject lines influence engagement, but transactional mail should prioritize clarity over marketing-style urgency. “Your password was changed” is better than “Important action required!!!” when describing a security event. Clear subjects reduce support load and help recipients recognize legitimate notifications.

From identities have an equally strong trust effect. Recipients learn to recognize a consistent sender name and domain. Frequent changes in display name, local part, or authenticated domain make legitimate mail harder to distinguish from phishing and may complicate filtering and support workflows.

Separate streams when the operational purpose differs. For example, use distinct but aligned identities for receipts, security notices, and product updates. Do not undermine that clarity by using a generic or opaque From address for every category.

A pre-send checklist

Before putting a sender identity into production, verify the following:

The header From mailbox is no more than 254 octets, and its local part is no more than 64 octets.
The sender domain’s labels are valid and no longer than 63 octets each.
The display name is serialized by a standards-aware mail library or provider.
Subjects contain no CR or LF characters and are folded safely by the message generator.
Non-ASCII subjects and display names are tested in the languages your customers use.
SPF is published as one valid record for the relevant envelope-sender domain.
DKIM signing is enabled and the published selector record resolves correctly.
DMARC exists for the visible From domain and authentication alignment is understood.
A seed message has been inspected in multiple mailbox providers and with a testing service.
SMTP/API responses, message IDs, and downstream delivery events are retained for troubleshooting.

This checklist catches the most common distinction that teams miss: formatting success is not authentication success, and authentication success is not necessarily inbox success.

Conclusion

Subject line and From address character limits are best handled as a set of layered constraints. Keep physical headers under RFC line limits, let a trusted library encode Unicode and fold long fields, keep mailbox addresses within SMTP’s practical boundaries, and validate the DNS and authentication identity behind the visible From domain.

For everyday transactional email, short and structured values are the safest choice: a concise subject, a recognizable display name, a simple local part, and an authenticated domain. That approach is easier to implement, easier to monitor, and more likely to remain compatible as messages pass through relays, filters, and recipient mail clients.

FAQ

Is there a maximum number of characters in an email subject line?

There is no single universal visible-character maximum. RFC 5322 limits physical header lines to 998 characters maximum and recommends no more than 78 characters per line. Long subjects can be folded, but Unicode encoding increases byte length, so use a standards-aware mail library.

Is an email address limited to 254 characters?

Use 254 octets as the practical maximum mailbox length. The local part is limited to 64 octets, while the domain must also comply with DNS limits, including a maximum of 63 octets per label.

Does the display name count toward the 254-character email address limit?

No. The display name, such as Northwind Support in Northwind Support <help@example.com>, is not part of the mailbox address. It is still constrained by header syntax, encoding, and line-length rules.

Can I use emoji or accented characters in a subject line?

Yes, when your email library or provider correctly encodes and folds the header. Do not calculate safety using only visible character count; encoded UTF-8 and RFC 2047 representations can be significantly longer.

Why does a valid From address still get rejected?

The address may be syntactically valid but fail provider policy, domain authentication, DMARC alignment, SMTPUTF8 support, or anti-abuse checks. Verify SPF, DKIM, DMARC, the envelope sender, and the exact SMTP or API error response.

Subject Line and From Address Character Limits: A Developer Guide