Non-RFC Compliant Characters

What happens when an email address contains non-RFC compliant characters?

You send a campaign. Everything looks correct. The list is clean. Then one recipient bounces — hard. No error message, no log entry. Just a silent rejection. You check the address. It’s valid, mostly. But it has a symbol you didn’t notice: a curly quote, a space, or a less-than sign that should’ve been encoded.

SMTP servers don’t guess. They follow rules. If the recipient field has a single non-RFC compliant character — whether it's a Unicode symbol, an unescaped space, or an improperly encoded special character — the server rejects the message immediately. It’s not about the domain. It’s about syntax.

This is a deliverability blocker: not a misconfigured server, not a spam trap. It’s a broken email address — and it happens far more often than you’d think in bulk sends.

Key takeaways

SMTP servers reject emails with invalid recipient syntax, even if the domain is valid.
Characters like unencoded spaces, curly quotes, or certain Unicode symbols violate RFC 5322 and trigger immediate rejection.
A single malformed address in a large send can degrade sender reputation and increase spam filter triggers.

Which characters violate RFC 5322 and cause delivery failures?

Characters like <, >, (, ), [ ], unescaped spaces, repeated dots, or non-ASCII Unicode in the local part of an email address break RFC 5322 rules and trigger hard bounces. Even if an address looks like it should work, invalid syntax prevents the email from being delivered. Let's break down exactly what to watch for before sending.

Invalid characters and syntax in the local part

<, >, (, ), [, ] are not allowed unless the entire local part is enclosed in double quotes — e.g., "user<name>@example.com.
Spaces in the local part — like john [email protected] — are invalid unless quoted: "john doe"@example.com.
Repeated dots — such as [email protected] — are rejected by mail servers; only single dots are permitted between parts.
Leading or trailing dots — [email protected] or [email protected] — are never valid and will be rejected.

Encoding and non-ASCII characters

Unicode characters beyond 7-bit ASCII — such as Cyrillic, emojis, or accented letters — are not allowed in raw form unless properly encoded via UTF-8 or explicitly quoted.
Without quotes or encoding, addresses like joñ@exampĺe.com will fail validation and result in a permanent bounce.
Validated addresses must comply with the full RFC 5322 grammar — including rules for dot-atom and quoted-string syntax, which define exactly what’s allowed.

RFC 5322 itself specifies these rules in detail. You can review the full specification at rfc-editor.org/rfc/rfc5322. Major providers like Google and Microsoft enforce these standards strictly. Even a single invalid character can cause a delivery failure, regardless of the recipient’s domain being active.

Let’s say you’re cleaning a list. You might run a quick check using our email checker to catch these issues early. It verifies syntax, checks for invalid characters, and flags malformed addresses before you send.

One non-compliant character in the local part can break delivery. Fixing it early saves bounces, protects sender reputation, and improves sender score.

You can’t rely on the recipient’s inbox to clean up invalid syntax. Mail servers reject non-RFC-compliant addresses during SMTP negotiation — and those errors don’t go away. If you’re managing a large send list, use bulk verification tools like our email list verify to scan for all types of syntax issues at scale.

How do non-RFC compliant addresses appear in bulk lists?

They show up as seemingly valid email addresses—correct format, no obvious typos—yet fail during SMTP transmission because they violate RFC 5322 syntax rules. These errors often stem from data copied from spreadsheets, legacy systems, or form submissions without validation, and they’re invisible to basic regex checks that only confirm basic structure, not compliance.

Where non-RFC addresses come from

These addresses typically originate from sources like old customer databases, imported spreadsheets with unverified inputs, or web forms that don’t enforce email syntax correctly. A user might type [email protected], but if the system stores it as [email protected] due to a data migration glitch, it’s technically invalid even if it looks fine.

Some systems store emails with trailing spaces, unescaped quotes, or comments in the local part—like john.doe (marketing)@company.com. While these may render visually correct, they’re non-compliant. Even the RFC 5322 specification explicitly limits what characters are allowed in the local part. Tools that only check for “@” and “.” miss these deeper violations.

Why regex checks aren’t enough

Basic email validation with regex (like the one used in many frontend forms) confirms only that an @ symbol and a dot exist—nothing more. It won’t catch a local part with two consecutive dots, spaces, or illegal characters like ; or >.

Consider [email protected] vs [email protected]. The latter looks plausible but is rejected by SMTP servers during the RCPT TO phase. This is why deliverability breaks down silently: your list appears valid, but thousands of messages bounce without warning.

MailTester’s bulk verification process uses real SMTP validation and RFC-compliant parsing. It doesn’t just check format—it tests whether the address is actively accepted by the recipient’s mail server. For teams running campaigns, this means identifying and removing these hidden blockers before they damage sender reputation. Bulk list verification catches these issues at scale.

Why traditional email validation tools miss these errors

Most email validation tools only check if an address passes a basic syntax rule, like "[email protected]", and miss subtle RFC 5322 violations—such as non-RFC compliant characters in the local part (e.g., spaces or special symbols like user [email protected]). This means they flag valid-looking addresses as good, even when they’ll fail at the SMTP level. Without real protocol-level verification, these errors only surface when your message bounces, often too late to fix.

Basic regex checks aren’t enough

Many tools rely on simple regex patterns to validate email format—these are quick, but limited. They accept inputs like user [email protected] as long as the basic format matches, even though spaces in the local part are invalid per RFC 5322. The real email specification doesn’t allow unquoted spaces or certain control characters, but basic validation tools don’t parse the full grammar. It’s like checking if a driver has a license without verifying they can actually operate the vehicle.

Why SMTP-level testing matters

Only real, end-to-end SMTP verification can catch failures caused by protocol-level issues—such as invalid characters, oversized fields, or misformatted headers—because it simulates how actual mail servers process incoming messages. A tool that stops at syntax won’t see what happens when the server rejects the address due to a non-compliant local part. This is why even "valid" addresses can fail in production.

That’s where MailTester comes in. Our bulk verification and single-address checker don’t just scan syntax—they run real SMTP checks against the recipient server, revealing issues that no basic regex can catch. You’ll catch non-RFC-compliant characters and other deliverability risks before you send.

For context, the full email grammar is defined in RFC 5322, which governs how email addresses are structured and transmitted. Tools that ignore this standard may pass addresses that never reach the inbox.

How MailTester detects non-RFC compliant characters

You can catch syntax errors in recipient email fields before they cause bounces or delivery failures. MailTester validates every address using real SMTP connections, checking the full recipient field against RFC 5322 rules. It doesn’t guess— it tests the actual protocol behavior. If a character sequence breaks RFC compliance, the address is flagged as invalid with a clear reason, like "contains non-printable character" or "invalid local part syntax".

Here’s how we do it, step by step

Parse the full recipient field as it’s sent — Unlike tools that only check basic patterns, we examine the complete address as it would be handed to an SMTP server, including angle brackets, display names, and any whitespace.
Validate according to RFC 5322 — We check every part of the address against the standard for email syntax: local part, @ sign, domain, and quoted strings. This includes verifying that only allowed characters appear in the local part.
Initiate a real SMTP session — We connect directly to the receiving mail server using standard SMTP procedures. This means we see exactly how the server responds to malformed or non-compliant input, just like a real sender would.
Interpret the server’s response — If the server rejects the address early with a 5xx error (like 553 or 501), it confirms a syntax violation. We log that response precisely, so you know the exact reason.
Return detailed verdicts — Every address gets a verdict: valid, invalid, catch-all, risky, or syntax error. Invalid addresses include the specific reason, such as “non-RFC compliant character in local part” or “missing domain part”.

Why this matters

Many tools only scan for common patterns like “@” or dots. They miss hidden issues—like Unicode characters, control codes, or malformed quoted strings. These often slip through and cause hard bounces or spam filters to trigger. By testing actual SMTP behavior, we catch problems that would otherwise go unnoticed.

The 5 steps described in “Here’s how we do it, step by step”, in order.

For example, a local part with a null byte or a tab inside a quoted string may pass basic regex checks, but will fail in production. The RFC defines what’s allowed: Section 3.4.1 outlines the allowable characters in the local part—only some are considered valid in real systems.

Use MailTester’s email checker to test a single address on the fly. Or verify entire lists with our bulk verification tool. Every verification is backed by real protocol validation, not heuristics. You get actionable data, not guesses.

How to verify and clean a list for non-RFC compliant addresses

You can catch non-RFC compliant characters in recipient addresses by uploading your list to MailTester, running a bulk verification, and filtering out only valid addresses. The tool detects syntax issues—like invalid characters, improper formatting, or invalid domain labels—before they cause bounces. This reduces delivery failures and protects sender reputation.

You upload your email list directly to MailTester’s bulk verification tool via the web interface. No need to pre-format or clean input. The system handles malformed entries, trailing spaces, or incorrect capitalization.
Run a full bulk verification. MailTester checks each address against industry-standard email validation rules, including RFC 5322 syntax specifications—those that define how email addresses are structured. This includes evaluating local parts (before @), domain parts (after @), and character limits.
Review the results. Focus on addresses flagged as invalid—these often include non-RFC compliant characters like ç, à, or + used in ways that violate syntax (e.g., [email protected] is valid unless the domain explicitly blocks it). You’ll also see catch-all or risky entries, but invalid is your priority for syntax errors.
Export only the valid addresses. Remove invalid, catch-all, or risky entries. This ensures your campaign sends only to addresses that meet basic syntax and delivery expectations.
Use the MailTester API for real-time verification in your workflows. It’s ideal for catching non-RFC issues before adding new subscribers.

Why validation before sending matters

Non-RFC compliant addresses are not just risky—they break SMTP communication. Mail servers reject them early, leading to hard bounces and reputational harm. The RFC 5322 standard defines email syntax rigorously. Tools that skip syntax checks fail at this layer, resulting in poor inbox placement and domain reputation damage. Even one malformed address in a large list can trigger ISP scrutiny.

What to watch for in your list

Characters like !`, =, $, %, &, <, >, {, }, [ are not allowed in the local part unless properly escaped. Domain labels can’t start or end with a hyphen, and must not exceed 63 characters. Some domains also restrict subaddresses (like [email protected])—MailTester flags these cases so you can assess whether to allow them.

How MailTester’s real-time API prevents delivery failures

You can stop delivery failures caused by non-RFC compliant characters in recipient fields by validating every email address in real time. When you plug MailTester’s API into your signup, onboarding, or CRM workflow, it checks each address immediately—flagging invalid syntax like unescaped @ signs, unsupported Unicode, or spaces before or after the @—before it ever gets stored or sent to. This eliminates sender reputation damage from hard bounces at scale.

Check syntax and SMTP rules in one flow

Let’s say someone signs up with [email protected]—standard, valid. But someone else submits user@domain+tag.com with a plus tag they think is standard. It isn't. RFC 5322 says local parts must not contain unquoted special characters beyond a few allowed ones. Our API knows this—and blocks it before anything else happens.

Validation doesn’t stop at syntax. The API also runs a full SMTP check. This means it doesn’t just say “this looks legal,” it confirms the domain has an active mail server and that the address is actually accepted for delivery. Only addresses that pass both syntax and SMTP checks return a valid status. That’s not a guess—it’s a real-world test.

Integrate early, catch failure early

By integrating the API at the point of entry—just after form submission, before storing or sending—you catch issues before they become expensive problems. No more bulk sends to lists with dozens of malformed addresses. No more complaints from ISPs about invalid addresses. No more wasted credits on delivery to addresses that will never receive mail.

For example, a + symbol in the local part is common but non-compliant by RFC standards unless properly encoded. Without validation, you risk sending to an address that’s not just invalid—it might be flagged as suspicious if it appears in large volumes. RFC 5322 clearly defines the grammar for email addresses, and while some systems accept extensions, they’re not guaranteed to deliver. The real-time API ensures you follow the standard.

Use the real-time verification API to catch these issues as they happen. It’s not a one-time audit—it’s a permanent gatekeeper for every new address. No more cleaning old lists. No more guessing. Just accurate, standards-compliant data from day one.

What's the impact of delivering to invalid email addresses?

Delivering to invalid addresses—especially those with non-RFC compliant characters in the recipient field—can tank your sender reputation, trigger bounces, and even get your domain blocked by major email providers. Even one bad address in a large batch can cause problems, especially on shared infrastructure. The real cost? Lost inbox placement and long-term deliverability damage.

How invalid addresses hurt your domain

Every hard bounce from an invalid address, especially one caused by malformed syntax (like unescaped special characters), signals to ESPs that your list hygiene is poor. Over time, this degrades your sender reputation.
Even a small percentage of invalid addresses—say, 0.5%—can trigger automated penalties from providers like Gmail or Outlook. They monitor bounce trends and may throttle or block senders who consistently deliver to non-existent accounts.
On shared email infrastructure (common with transactional sends via platforms like SendGrid or Amazon SES), one problematic sender can affect the reputation of the whole IP pool. A single malformed address might not hurt you alone—but repeated issues across the same IP can.
Non-RFC compliant characters in recipient fields (like [email protected] with spaces, unquoted @ signs, or invalid domain parts) break SMTP parsing. The server rejects the message outright, leading to a permanent hard bounce.
Major ESPs use DNSBLs and behavioral heuristics. Persistent invalid delivery attempts—especially from the same IP or domain—may result in placement on blacklists such as Spamhaus or Blocklist.de.

Prevent these issues before they happen

Lets face it: you can’t fix delivery failures after the fact if the address was never valid. The solution starts before sending.

Use a real-time email verification API to catch syntax errors at point of capture. MailTester’s API checks RFC compliance, domain validity, and mailbox existence in milliseconds.
Before a major campaign, run a bulk verification on your list. MailTester’s bulk tool identifies invalid email addresses—including those with non-RFC compliant syntax—before you send.
Verify individual addresses when signing up or updating profiles. Our real-time checker confirms syntax, DNS records, and mailbox availability in seconds.
Monitor your bounce rate. A sustained increase above 2% is a red flag. Use tools like MxToolbox or RFC 5322-compliant checks to validate formatting before sending.
Test inbox placement with real messages before sending to large audiences. MailTester’s inbox tester shows where your message lands—spam, trash, or inbox—based on real provider feedback.

For more on how email syntax and formatting affect deliverability, see the official RFC 5322 standard. The rules aren’t just technical—they’re essential for staying on good terms with email providers.

How to prevent non-RFC issues at the source

Non-RFC compliant characters in the recipient field cause immediate SMTP rejection. The fix starts before sending: validate every email address in real time using standards-compliant checks. Catch issues like invalid characters (e.g., spaces, angle brackets, or unquoted special symbols) before they ever leave your system. This stops bounces and blocks at the source, not after they hit your inbox.

Validate input at the point of entry

Let’s be honest: people type email addresses wrong — or with unencoded characters. A form that accepts any string without checking isn't just lazy, it's risky. Use input validation that rejects addresses with invalid syntax before submission. This includes stripping or rejecting spaces, unescaped special characters, or malformed local parts. Tools like RFC 5322 define the proper format — stick to it.

Verify in real time during data collection

Don’t wait until send time to check an email’s validity. Use a real-time verification API to test every address as it’s entered. That way, you catch non-RFC issues, role accounts, disposable domains, or typoed addresses instantly. This isn’t just cleanup; it’s prevention. With tools like MailTester’s real-time verification API, you validate syntax, domain status, and deliverability in milliseconds — before the address even enters your database.

Manual entry is the worst offender. Humans introduce errors, including characters that break email transport. Automate data collection through validated forms, CRM integrations, or email signup widgets that run checks upfront. If your data comes from a third-party tool, run it through a bulk verification service like MailTester’s list verification to catch issues across thousands of entries.

Non-RFC characters aren’t the only problem, but they’re among the most predictable. Fixing them early avoids sender reputation damage and deliverability blacklists. Every address that fails to meet basic syntax rules should never make it past filtering. By embedding validation, real-time verification, and automation at every stage, you build a foundation that’s resilient to the basics — and ready for scale.

Common real-world scenarios where non-RFC errors occur

You’re not alone if your email bounces due to a non-RFC compliant character in the recipient field—these sneaky issues commonly stem from invisible Unicode symbols pasted from PDFs, legacy data with wrong encoding (like ISO-8859-1 misinterpreted as UTF-8), or user-submitted addresses with unescaped spaces or special characters. A single hidden zero-width space or soft hyphen can break delivery silently. These aren't bugs in your system; they're artifacts of real-world data quirks. Tools like MailTester’s bulk verification can catch them before sending.

Pasting from PDFs or scanned documents

PDFs sometimes embed invisible Unicode control characters—like zero-width spaces (U+200B) or non-breaking hyphens (U+2011)—that aren't visible in the text but are parsed as part of the email address.
When you copy email addresses from a scanned document or converted PDF, these characters hitch a ride. You’ve likely seen them as "[email protected]" where a hard-to-detect character sits after the TLD.
Use a tool like Unicode’s official chart to debug; it's common for OCR systems to insert these during conversion.

Legacy data and encoding mismatches

Older systems often used ISO-8859-1 encoding, which doesn't support many Unicode characters. When this data is imported into UTF-8 systems, misencoded characters show up as garbled or invalid.
An address like "café@example.com" in ISO-8859-1 might become "[email protected]" if misinterpreted as UTF-8.
Always validate encoding during import. Tools that normalize input before verification can prevent delivery issues tied to character misreading.

User-generated input with poor sanitization

Forms that accept email inputs without real-time validation often receive addresses with extra spaces, unescaped parentheses, or unusual Unicode punctuation like smart quotes (U+201C).
For example, “[email protected]” might be submitted as “user @example.com” or “[email protected]” with a typographic quote.
Always sanitize and normalize addresses at entry. MailTester’s email checker can flag these issues in real time.

Why you need SMTP-level validation — not just syntax checks

Validating email syntax alone is insufficient. Many addresses pass basic checks but fail during actual SMTP transmission due to non-RFC compliant characters in the recipient field.

Domain-level policies vary. An address may be syntactically correct but rejected by a receiving server if it doesn't support non-standard formatting, even if the email format appears valid on paper.

MailTester’s 98.9% accuracy stems from real SMTP connections and response analysis. It doesn’t rely on theoretical rules — it tests delivery under the actual protocol, detecting issues that syntax checks and DNS lookups alone miss.

Sources

Gmail's filters stop more than 99.9% of spam, phishing, and malware, blocking nearly 15 billion unwanted emails every day. — Google (The Keyword blog) (2023)
Only about one quarter of email senders report spam complaint rates below 0.1% — the best-practice band — leaving three quarters exposed to some degree of deliverability degradation. — Validity 2025 Email Deliverability Benchmark Report (2025)

Keep reading

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

Frequently asked questions

Can an email address be valid in format but still fail delivery?

Yes. Valid syntax is not enough. Non-RFC compliant characters, rejected by the receiving server, cause immediate delivery failure even if the domain is real.

How does MailTester detect non-RFC compliant characters?

It sends a real SMTP connection to the receiving mail server with the full recipient address and checks the response for syntax-level rejections.

Do common email regex patterns catch all valid email issues?

No. Regex validation often fails to detect non-RFC compliant entries like multiple dots or unquoted spaces, which only real SMTP verification can catch.

Can an invalid email address hurt my sender reputation?

Yes. Even a single invalid address in a large send can trigger bounce tracking, harm domain reputation, and lead to filtering or blocking.

What does 'invalid' mean in MailTester’s results?

An invalid verdict means the recipient address failed syntax or delivery checks — including non-RFC compliant characters, incorrect format, or SMTP-level rejection.

How does MailTester compare to basic email validation tools?

Unlike tools that rely on regex or domain checks, MailTester uses real SMTP connections, offering higher accuracy and detection of protocol-level issues.

Can I integrate MailTester with Mailchimp or HubSpot?

Yes. MailTester integrates with Mailchimp, HubSpot, Klaviyo, and SendGrid to clean lists before sending and verify addresses in real time.

Do I lose my purchased credits if I don’t use them?

No. MailTester credits never expire, so you can use them when needed without time pressure.

How many free verifications do I get to start?

You get 100 free verifications to test MailTester’s accuracy and performance before purchasing.

Is MailTester accurate for international email addresses?

Yes. It properly evaluates UTF-8 encoded international addresses and flags any non-compliant syntax violations.

Can MailTester help with list hygiene and low inbox placement?

Yes. By removing invalid and non-compliant addresses, it reduces bounces, improves sender reputation, and supports better inbox placement.

Does MailTester detect role accounts or disposable domains?

Yes. Alongside syntax checks, it flags role accounts (e.g. admin@, sales@) and disposable domains as risky or invalid.