RFC 822 Failure: What It Means and How to Fix It

A contact you have emailed without issue for months suddenly sends back a bounce message that says something like "RFC 822 failure" or "554 5.6.0 Message rejected for RFC 822 violation." You did not change anything. The contact did not change anything. Or so it seems.

RFC 822 is the email format standard that has been around since 1982. Modern email runs on its successors, RFC 2822 and RFC 5322, but the core logic is the same. When a receiving server reports an RFC 822 failure, it is saying your message headers do not comply with the basic format rules for email. Here is what that means and how to get email working again.

What RFC 822 actually requires

RFC 822 defines the structure of a text email message. It specifies which header fields are required (From, Date), which are optional, and what makes a header field valid. The key rules are:

The Date and From headers are required. A message without them is not a valid RFC 822 message.
Header field names must be ASCII. Non-ASCII characters in header field names or values must be encoded.
The From header must contain a valid email address. The address format must follow the standard local-part@domain syntax.
Header continuation lines must start with a space or tab.
No header field name may appear more than once in a way that creates ambiguity.

These rules sound simple, and most mail servers handle them correctly. Problems appear when something changes on either end.

Why the failure suddenly appears

The most common reason an RFC 822 failure shows up out of nowhere is one of these:

The recipient changed their mail gateway or tightened filtering. Microsoft 365, Google Workspace, and enterprise email gateways sometimes update their header validation rules. A server that previously passed borderline headers may start rejecting them after a gateway update.

The sender changed mail software or made a configuration change. Upgrading Exchange Server, migrating to a new SMTP relay, or changing how the From header is set can introduce malformed headers. A Reply-To address that does not match the From domain is a common trigger for stricter gateways.

A forwarding chain modified headers. If the message passes through a forwarding service or mailing list that rewrites headers incorrectly, the final delivery attempt may fail RFC 822 validation at the destination server.

Missing or malformed Date header. Some mail servers generate messages without a Date header or with an incorrectly formatted one. This is rare in mainstream clients but appears when custom software sends email directly.

Non-ASCII characters in headers without proper encoding. If someone in the To or CC field has a display name with special characters and the sending software does not encode them, RFC 822 compliance fails.

How to diagnose the sender side

Start by pulling the raw headers from the bounced message. The bounce response usually contains the original message or at least the error detail.

Look for these common problems:

Missing Date header. If the Date field is absent or shows an impossible value (a date in the future, a malformed timestamp), that is a clear RFC 822 violation.

Malformed From address. Check for extra angle brackets, missing @ symbols, or unusual characters in the address itself.

Reply-To mismatch. If Reply-To points to a different domain than From, some gateways flag this as suspicious. The message is not necessarily wrong, but recipient servers are allowed to apply stricter rules here.

Header field name case sensitivity. RFC 822 treats header field names as case-insensitive, but some validation tools expect specific capitalization. Inconsistent capitalization is not a violation, but it can confuse gateways that are looking for specific patterns.

If you can reproduce the issue, send a test message through a known-good SMTP service and compare the raw headers. A header diff tells you which field is causing the problem.

How to diagnose the recipient side

Sometimes the sender side is fine and the issue is the recipient gateway applying stricter rules. Here is how to tell:

Ask for the full bounce text. The bounce message usually says something like "554 5.6.0 Message rejected for RFC 822 violation" but may not specify which header caused the rejection. If the contact can provide the full original headers, you can compare.

Check if the contact uses Microsoft 365. Exchange Online is known for strict header validation. If the contact switched to Microsoft 365 recently or had their tenant settings changed, their gateway may now enforce rules it previously ignored.

Ask whether their email gateway was updated recently. Gateway vendors push rule updates on their own schedule. A change on the recipient side is the most likely explanation when the sending side has not changed anything.

Distinguish permanent from temporary failures. A 554 or 550 code means the server permanently rejected the message. A 421 code means temporary degradation, usually worth retrying. If the gateway is in a heightened security state, temporary failures can persist for days.

How DMARC reports help

Here is the part that connects this to email authentication monitoring, and why DMARCFlow is the right tool for this problem.

RFC 822 failures often appear alongside DMARC alignment failures. A receiving server that is strict about header formatting may also be evaluating whether the From header aligns with the authenticated sending domain. If your domain publishes a DMARC record, aggregate reports capture these signals automatically.

DMARC reports tell you:

Whether your domain is passing DKIM and SPF alignment checks at each receiving server
How many messages are being rejected before DMARC evaluation, which may include RFC 822 violations
Which receiving servers are rejecting your messages and why

The critical point: when a recipient gateway starts applying stricter RFC 822 validation, the first sign on your end is often a drop in DMARC pass rates for that specific domain. You see it in the data before any user reports a bounce.

DMARCFlow processes your DMARC aggregate reports and alerts you when authentication pass rates shift unexpectedly. That means you can investigate and reach out to the recipient before a cascade of RFC 822 failures hits your helpdesk.

How to fix it

The fix depends on where the problem lives.

If it is your side:

Fix the malformed headers. Common fixes:

Ensure your mail server software sets a valid Date header on every message.
Make sure the From address matches the authenticated sending domain.
If you set a Reply-To on a different domain, remove it unless you have a specific reason for it.
Audit any custom code that generates email headers for non-ASCII character encoding.
Check your SMTP relay configuration if you use one. Some relays modify headers in transit.

If it is the recipient side:

Contact the recipient's IT team or email administrator. Explain that their gateway is rejecting messages that previously delivered fine, citing RFC 822 compliance. Provide the full bounce headers if you have them.

If they use Microsoft 365, their admin can check Exchange Online message tracking for the specific rejection reason. They may find a transport rule or connector policy that changed.

If the recipient cannot fix their gateway, you may need to work around the restriction. This could mean adjusting how your mail software formats headers, or routing through a different sending IP that the gateway accepts.

How to monitor for this going forward

RFC 822 failures are easier to prevent than to cure. A few monitoring habits help:

Review DMARC aggregate reports monthly. A drop in DKIM pass rate or an increase in DMARC failures often signals header problems before they become full outages.

Set up alerts for sudden authentication failures. DMARCFlow can notify you when pass rates to a specific domain drop unexpectedly. That early signal lets you investigate before users report bounces.

Audit your sending mail software after any upgrade or configuration change. Header problems introduced by a software update are easy to miss until they start causing bounces.

Track bounce patterns from specific domains. If one contact domain starts generating failures while others do not, the problem is almost certainly on their end.

FAQ

Does RFC 822 failure mean my email was spam?

Not necessarily. An RFC 822 violation is a format problem, not a content problem. Many legitimate messages fail RFC 822 validation due to misconfigured headers. However, some spam filters use RFC 822 compliance as one signal among many, so a genuinely malformed message may end up in spam alongside other filtering signals.

Can SPF or DKIM problems cause RFC 822 failures?

SPF and DKIM are authentication mechanisms, not header format rules. A message can pass SPF and DKIM but still fail RFC 822 validation if the headers are malformed. That said, some gateways apply authentication checks and header validation together, so you may see both failures cited in a bounce.

Is RFC 822 the same as RFC 5322?

RFC 5322 is the current standard that supersedes RFC 822. RFC 2822 was the intermediate update. Most mail servers implement RFC 5322. Bounce messages that cite RFC 822 are usually citing the original standard as shorthand for header compliance issues. The practical implications are the same.

My messages pass RFC 822 validation but still get rejected. Why?

A server can reject a message for reasons beyond RFC 822 compliance. Content filtering, reputation scoring, authentication failures, and local policy rules all cause rejections. RFC 822 compliance means the message is formatted correctly, not that it is welcome.

Bottom line

An RFC 822 failure after months of smooth delivery usually points to a change on one side or the other. The sending server may have changed software or configuration. The recipient gateway may have tightened its header validation. The fix requires examining the raw message headers, comparing them against RFC 822 requirements, and working with the relevant side to correct the problem.

Ongoing monitoring of DMARC aggregate reports helps catch these problems early. A sudden shift in authentication pass rates often shows up in the data before users report bounces. DMARCFlow tracks these reports and alerts on anomalies so you can investigate before RFC 822 failures turn into long-running delivery outages.