How to fix SMTP 554 5.6.0 corrupt message content and 451 4.3.0 errors on .eml files
These two replies mean a mail server could not process your message or an uploaded .eml file. A 451 4.3.0 is a temporary local problem the sending server retries by itself, while a 554 5.6.0 is a permanent rejection you have to fix. Jump to your situation below or work through the methods in order.
By Neeraj Singh ~17 min Updated Jul 2026 91% found this helpful
Error message
554 5.6.0 STOREDRV.Deliver; Corrupt message content / 554 5.6.0 Invalid message content / 451 4.3.0 Temporary local problem - please try later
Summary
SMTP 451 and 554 are opposite ends of the same family. A 451 4.3.0 Temporary local problem is transient: the receiving server could not process the message right now, so the sending server retries on its own schedule and it usually clears without action. A 554 5.6.0 is permanent and never retried, and on Exchange it arrives as an NDR reading 554 5.6.0 STOREDRV.Deliver; Corrupt message content or 554 5.6.0 Invalid message content. With an .eml the cause is nearly always the message itself: a broken MIME structure (mismatched multipart boundaries, a missing Content-Type or bad Content-Transfer-Encoding), corrupt TNEF content in a winmail.dat wrapper or a transport rule whose attachment scan timed out. Read the NDR, retry a 451 and, for a 554, re-export the .eml cleanly, rule out TNEF and rule timeouts, then check size and filters.
What 554 5.6.0 and 451 4.3.0 actually mean
An SMTP server sends a reply code for every message it handles. A 451 is a 4xx transient reply meaning try again later, and the standard text is 451 4.3.0 Temporary local problem - please try later. RFC 5321 defines reply code 451 as Requested action aborted: local error in processing, which is exactly what a temporary local problem is: the fault is local to the receiving mail system, not to your address or your file. Sending servers queue the message and retry on a schedule, so a one-off 451 4.3.0 usually resolves with no action at all.
A 554 is a 5xx permanent reply: the message was rejected and will not be retried. On Exchange and Microsoft 365 it is delivered back as a non-delivery report (NDR), typically 554 5.6.0 STOREDRV.Deliver; Corrupt message content or 554 5.6.0 Invalid message content. STOREDRV.Deliver is the Exchange store driver that hands the message to the mailbox, so its presence tells you the failure happened while the server was converting your content, not while routing it.
Figure 1: how to read the reply code
5ClassFirst digit. 4 is temporary and retried, 5 is permanent.
554Reply codeThe SMTP reply. 554 means the transaction failed.
.6SubjectSubject 6 is message content or media, so the fault is inside the message.
The enhanced status code is the useful part. In 554 5.6.0 the subject digit 6 tells you the server rejected the content itself, not the address, the network or your reputation. In 451 4.3.0 the subject digit 3 means a mail system problem on the receiving side, and the leading 4 means it is temporary.
Figure 2: 451 4.3.0 vs 554 5.6.0 at a glance
451 4.3.0 Temporary
Soft bounce, the message stays queued.
The sending server retries automatically for hours.
Cause sits on the receiving server: overload, resources or a transient mail system fault.
Action: usually none, let it retry.
554 5.6.0 Permanent
Hard bounce, you get an NDR and no retry.
Exchange could not parse or convert the content.
Cause sits in the message: broken MIME, corrupt TNEF or a rule timeout.
Action: repair or re-export the .eml, then resend.
Decide which one you have before you troubleshoot. Chasing a 451 wastes time, because it clears itself. A 554 will never deliver until you change the message or the rule.
Figure 3: where a message fails and why the component name matters
Stage 1SenderOutlook or the client builds the MIME and wraps Rich Text as TNEF.
Stage 2TransportMail flow rules scan and rewrite. A scan timeout here returns Invalid message content.
Stage 3Store driverSTOREDRV.Deliver converts the content for the mailbox. Conversion faults surface here.
Stage 4Store write[Stage: PromoteCreateReplay] is the write itself, so a failure here means the body was already altered.
This is why the component name in the NDR is worth more than the code. The code says permanent, but the name says which stage failed, and each stage has a different owner: transport faults are yours to fix in the rules, store driver faults are the message content, and a failure at the write stage points at whatever touched the message last.
Decode your exact 451 or 554 error
The words after the code matter more than the code itself. Match the exact string from your NDR or SMTP log to the row below, then jump straight to the fix that applies.
MeansConversion failed as Exchange wrote the message into the store. Something altered the body after it was composed, typically antivirus or an Outlook add-in. It shows up on meeting invites too.FixRule out antivirus and Outlook add-ins.
Every string above is a real server reply. If yours names a different component, the pattern still holds: the extended code tells you temporary or permanent, and the exception name tells you which part of the message failed.
Common causes of a 554 5.6.0 rejection
The .eml has corrupted or malformed MIME parts.
Multipart boundaries are missing, mismatched or not closed.
The Content-Type header or Content-Transfer-Encoding is invalid.
TNEF content in a winmail.dat wrapper is truncated or corrupt.
An encoded attachment fails to decode, for example a UU decoder integrity error.
A transport rule timed out extracting text from a Word or Excel attachment (554 5.6.0 Invalid message content).
A signature or disclaimer rule rewrote the message and broke conversion.
The message exceeds the receiving server's size limit, or the To header holds hundreds of recipients.
A content, spam or anti-malware filter blocked or quarantined the message.
Antivirus or an Outlook add-in altered the message body after it was composed.
A Mac client attached a file using non-standard Apple encoding (application/applefile).
The item is a meeting invite or calendar response, which converts differently to plain mail.
The receiving mail system was temporarily overloaded or out of resources (451 4.3.0).
Figure 5: anatomy of an .eml and where a 554 comes from
From: / To: / Subject:Envelope and header block. A hundreds-deep To header can itself trigger a rejection.
MIME-Version: 1.0Declares the message uses MIME. Missing here means older parsers give up.
Content-Type: multipart/mixed; boundary="_abc123_"Declares the separator string. If the boundary is missing or does not match below, the server cannot split the parts.
--_abc123_Opening boundary for part 1, the readable body.
Content-Transfer-Encoding: base64Must match how the part is actually encoded. A mismatch causes decode and conversion failures.
--_abc123_Opening boundary for part 2, the attachment.
Content-Type: application/ms-tnef; name="winmail.dat"Outlook TNEF wrapper. Corrupt TNEF is a classic corrupt message content cause.
--_abc123_--The closing boundary. If this final marker is absent, the message is structurally incomplete and gets rejected.
The shaded rows are where corruption usually sits, and all of them are structural. That is worth knowing before you open a text editor: a mail client regenerates every one of these fields for you, which is why the export route is faster than editing by hand and why hand-editing so often reintroduces the same fault.
Expert insight
“Read the digit first. A 451 4.3.0 is the server saying not now, and the queue almost always sorts it out by itself, so do not touch it. A 554 5.6.0 is the server saying no, and the word after it tells you everything: STOREDRV.Deliver means the store driver choked while converting your content. People burn hours hand-editing MIME when re-exporting the .eml from the client rebuilds every boundary and encoding for free. Two causes get missed constantly: corrupt TNEF in a winmail.dat, which you dodge by sending HTML instead of Rich Text, and a transport rule set to defer when scanning does not finish, which times out on a big Word or Excel file and throws Invalid message content. Always pull a message trace, it names the rule.”
Manager, Tech Support & Operations · 19+ years fixing Windows and system errors
✓ How to fix it, in order
Eleven methods is a lot to read through when your mail is bouncing. Use the questions below to land on the right one, then work from there. If your NDR quotes an exact string, Figure 4 is quicker.
Step 3 is the one people skip, and it saves the most time. Consistent failures are structural and live in the file. Intermittent failures almost never are, so re-exporting the same message repeatedly will not help.
Method 1
Read the NDR and identify the exact code
1Open the bounce or non-delivery report and find the reply code and the extended status, for example 554 5.6.0 or 451 4.3.0.
2Note any component or exception named after it, such as STOREDRV.Deliver, ConversionFailedException or TextConvertersException. That name tells you which part failed.
3A leading 4 means wait, a leading 5 means fix and resend. Match your string in Figure 4 and jump to that method.
Method 2
For a 451 4.3.0, let it retry
1A 451 4.3.0 Temporary local problem clears on its own, because the sending server queues the message and retries on a schedule.
2If you are sending manually or from an app, wait a few minutes and send again. Do not loop a fast resend, it will not help.
3If the same 451 persists for hours, the condition is not clearing: treat it like a 554 and investigate the message and the receiving server.
Method 3
Re-export the .eml cleanly (fixes most 554s)
1Rather than hand-editing, open the original message in a mail client and save it again as a fresh .eml.
2A clean export rebuilds the headers, the multipart boundaries and the transfer encoding correctly, which is exactly what a corrupt message content rejection is complaining about.
3Resend the new file. If it now delivers, the original file was structurally broken and no MIME editing was needed.
Method 4
Inspect and repair the MIME structure
1Open the .eml in a text editor and check it has valid headers, a correct Content-Type, matching multipart boundaries and a Content-Transfer-Encoding that matches the actual encoding.
2Confirm the closing boundary is present, ending with two trailing hyphens. A missing final boundary makes the message structurally incomplete.
3Mismatched boundaries and a wrong encoding are the most common structural causes of a 554 on .eml. Compare against Figure 5.
Method 5
Rule out corrupt TNEF (winmail.dat)
1If the NDR mentions Corrupt summary TNEF content or TNEF ConversionFailedException, or the message carries a winmail.dat, the Outlook Rich Text wrapper is the problem.
2Resend the message as HTML or plain text instead of Rich Text, which avoids TNEF entirely.
3For a recurring problem, set the Outlook or Exchange remote domain format to HTML or plain text so TNEF is never generated for that destination.
Method 6
Fix Mac attachments (application/applefile)
1If the sender uses a Mac client and the message is a multipart/mixed carrying an application/applefile part, Exchange treats the message as invalid and rejects it.
2The fix is at the sending end: attach the file in a standard format, or use the correct mac-binhex40 encoding. Exchange does not support non-standard Mac encodings.
3Sending the file from a different client, or zipping it first, sidesteps the Apple encoding entirely.
Method 7
Check transport rules and scan timeouts
1Microsoft documents that 554 5.6.0 Invalid message content appears when a mail flow rule has Defer the message if rule processing doesn't complete enabled and text extraction times out while scanning a Word or Excel attachment.
2Turn that option off on the rule, or password-protect the attachment so it is not scanned. The option can sit on any rule in the list, so check them all.
3Signature and disclaimer rules rewrite the message and can break conversion too. Temporarily disable them to test.
Method 8
Rule out antivirus and Outlook add-ins
1If the failure is intermittent and the NDR ends with [Stage: PromoteCreateReplay], something is altering the message after it is composed. Antivirus that scans or rewrites mail is the usual culprit, so add an exclusion or ask the vendor.
2Start Outlook with add-ins disabled to test:
outlook.exe /safe
3If it delivers in safe mode, re-enable add-ins one at a time to find the offender. Meeting invites and calendar responses are common triggers, because they convert differently to plain mail.
Method 9
Reduce message size and recipient count
1If the message is large it may exceed the receiving server's limit and be refused.
2Remove or shrink large attachments, or share them with a link instead.
3Check the To and Cc headers too. A header carrying hundreds of recipients can itself trigger an invalid message content rejection, so split the send.
Method 10
Check content and security filters
1On the receiving server, review the content, spam and anti-malware filters and any quarantine.
2A false positive can reject a clean message, so allow the sender or adjust the rule if appropriate.
3Quarantined or stripped attachments are a common permanent-rejection cause.
Method 11
Run a message trace and read the logs
1In the Exchange admin center run a message trace for the message. It shows the rejecting component and often the exact rule.
2On-premises, query the tracking log directly and read the RecipientStatus field, where the LED= value holds the full 554 string:
3Fix the named issue, then resend and re-trace to confirm delivery.
The fastest way to narrow this down is to ask whether it fails every time or only sometimes. A message that fails consistently is structural: the file itself is malformed, so re-export it and check the MIME. A message that fails intermittently, especially on meeting invites or with the same sender, is almost never structural: something is changing the message in flight, which points at antivirus, an Outlook add-in or a transport rule rather than the .eml.
Frequently asked questions
What does 554 5.6.0 corrupt message content mean?
It is a permanent Exchange rejection meaning the server could not parse or convert the message body or an attachment. The full NDR usually reads 554 5.6.0 STOREDRV.Deliver; Corrupt message content. The message is not retried, so you must repair or re-export the .eml and resend it.
What is the difference between SMTP 451 and 554?
451 is a 4xx transient reply, so the sending server queues the message and retries automatically. 554 is a 5xx permanent reply that will never be retried until you fix the message or the server-side rule that rejected it.
What does STOREDRV.Deliver mean in the NDR?
STOREDRV.Deliver is the Exchange store driver component that hands a message to the mailbox. When it appears with 5.6.0, the store driver failed while converting the message, so the fault is in the message content rather than the network or the recipient address.
What does [Stage: PromoteCreateReplay] mean?
It names the point where conversion failed, as Exchange promoted the message and wrote it into the store. It usually means something altered the body after it was composed, most often antivirus scanning or an Outlook add-in, and it appears frequently on meeting invites.
What is ConversionFailedException in a 554 5.6.0 NDR?
It means Exchange content conversion failed on the body or an attachment. Variants include TextConvertersException for body conversion and ByteEncoderException for a failed decode. Each points at a malformed part in the message, which a clean re-export usually rebuilds correctly.
Why does my .eml cause a 554 5.6.0?
Most often the MIME structure is broken, such as mismatched multipart boundaries, a missing Content-Type or a bad Content-Transfer-Encoding. Corrupt TNEF (winmail.dat) content and attachments a filter cannot scan are the other common triggers.
How do I fix a corrupt MIME .eml?
Re-export the message from a mail client as a fresh .eml rather than hand-editing it. A clean export rebuilds the headers, boundaries and encoding correctly, which resolves most structural 554s without any manual MIME work.
Can a transport rule cause 554 5.6.0 invalid message content?
Yes. Microsoft documents that a mail flow rule with Defer the message if rule processing doesn't complete enabled returns 554 5.6.0 Invalid message content when text extraction times out while scanning a Word or Excel attachment. Disabling that option or password-protecting the file works around it.
Can antivirus or an Outlook add-in cause 554 5.6.0?
Yes, and it is a common cause of intermittent failures. Antivirus that scans or rewrites mail, or an Outlook add-in that edits the body, can corrupt the content before it reaches the store. Test with Outlook started using outlook.exe /safe, then re-enable add-ins one at a time.
Why do Mac attachments cause 554 5.6.0?
When a Mac client sends a multipart/mixed message containing an application/applefile part, Exchange treats the message as invalid and rejects it, because it does not support non-standard Mac encoding. Resend the attachment in a standard format or use mac-binhex40 encoding.
What is winmail.dat and why does it break delivery?
winmail.dat is Outlook's TNEF wrapper for rich formatting and attachments. If the TNEF part is truncated or malformed, Exchange reports corrupt summary TNEF content and rejects the message. Sending the message as plain text or HTML instead of Rich Text avoids TNEF entirely.
Should I resend after a 451 4.3.0?
Usually not. A 451 4.3.0 temporary local problem clears on its own because the sending server retries on a schedule. Only investigate if the same 451 keeps returning for hours, which means the underlying condition is not clearing.
How do I find the exact reason for the rejection?
Read the full NDR and the receiving server's logs, and run a message trace in the Exchange admin center. On-premises, use Get-MessageTrackingLog and read the RecipientStatus field, where the LED value holds the complete 554 string.
Still not working?
If a 554 5.6.0 survives a clean re-export and you have ruled out TNEF, rule timeouts, size and filters, capture the full NDR and run a message trace, then send both to the receiving postmaster: the exception name identifies the failing component precisely. If the rejection is intermittent across many senders, suspect an add-in or a gateway rewriting messages in transit rather than the individual .eml. You can also submit your error to us for a tailored fix.
