AS2 MDN Errors: Authentication Failed, Decryption Failed

An AS2 MDN is a transport receipt, not a business acceptance. A disposition of processed means your trading partner decrypted the message, verified the signature and handed the payload to their system. It says nothing about whether the purchase order inside was valid or whether their ERP accepted a single line of it. Every AS2 error you will actually chase is written in the disposition modifier: authentication-failed, decryption-failed, integrity-check-failed, unexpected-processing-error, insufficient-message-security or decompression-failed.

Last updated August 2026.

This is a reference for the AS2 MDN failures that stop purchase orders moving between trading partners, written against RFC 4130, the specification that defines AS2 itself. The codes are short and the wording is terse, which is why so much AS2 troubleshooting starts in the wrong place. Below is what each one means, what usually causes it in practice, and the order to check things in.

What an AS2 MDN actually tells you

MDN stands for Message Disposition Notification. When you POST an AS2 message, the receiver returns an MDN describing what happened to it. That MDN has three useful parts: the disposition field, the Received-content-MIC, and the reference back to your original Message-ID. Everything else is envelope.

The critical thing to understand up front is that the MDN reports on message handling, not on the business document. The receiver decrypted your file, checked your signature, confirmed the content was not altered in transit, and put the payload somewhere. Whether their order management system then accepted your 850 is a separate question, answered by a separate document.

How to read the AS2 disposition field

The disposition field is assembled from a mode, a type, and an optional modifier. Read it left to right.

A clean receipt looks like automatic-action/MDN-sent-automatically; processed with no modifier at all. Anything after a semicolon and the word error is a failure you need to act on.

The full AS2 MDN error code table

RFC 4130 defines a closed set of disposition modifiers. There are six error codes, and in fifteen years of AS2 deployments the practical causes have not changed much.

There is also a warning form. processed/warning: authentication-failed, processing continued means the receiver could not verify you but processed the message anyway. Treat that as a failure that has not happened yet: the partner is being lenient, and the day they tighten their configuration your feed stops.

What causes integrity-check-failed in an AS2 MDN?

An integrity-check-failed means the MIC your side computed over the outbound payload does not match the Received-content-MIC the partner returned. There are three real causes, and only one of them is the scary one.

The first and most common is an algorithm mismatch. You requested a receipt with a specific digest algorithm via the Disposition-notification-options header, and the partner computed the MIC with a different one. SHA-1 against SHA-256 is the classic pairing, usually left over from a half finished migration. Microsoft documents this exact failure for BizTalk: the algorithm in the signed-receipt-micalg header of the original message has to match what the receiving side is configured to use.

The second is a Content-Transfer-Encoding difference. The MIC is computed over the MIME part including its headers, so if one side includes a Content-Transfer-Encoding: 7bit header and the other omits it entirely, or one uses binary where the other uses base64, the digests differ over byte-identical business data. This one is maddening precisely because the payload is fine and the file arrives intact.

The third is that something actually modified the payload. A proxy, a content filter or a gateway that rewrites MIME parts will break the MIC legitimately. If the first two check out and the mismatch is consistent, look at what sits between the two endpoints.

processed/error and failed/failure are not the same thing

This distinction gets flattened by almost every integration dashboard, and it costs troubleshooting time. RFC 4130 is specific: the failed disposition type must be used when a failure prevents the proper generation of an MDN at all. processed/error means the receiver understood the message enough to process it and then hit a problem with it.

The practical difference: a processed/error is usually a certificate or configuration mismatch between two working AS2 systems. A failed/failure means the two sides do not agree on what AS2 even looks like, which is a setup conversation, not a retry.

Why does AS2 return HTTP 200 when the MDN says it failed?

Because they are different layers, and RFC 4130 requires it. The specification states directly that even when the disposition of the data was an error condition at the authentication, decryption or other higher level, the HTTP status code should indicate success at the HTTP level.

This is the single most expensive misreading in AS2 operations. An HTTP 200 means the POST reached the endpoint and the endpoint replied. It carries no information about whether your purchase order was accepted, decrypted, or even readable. Any monitoring that alerts on HTTP status alone will report a perfectly healthy AS2 channel while every message in it fails authentication.

If you have ever seen this pattern in EDI, it is the same shape as a 997 that returns AK901 = A. The acknowledgment confirms syntax, not business acceptance. The EDI 997 error code reference covers that layer, and the two together are how you tell transport problems from document problems.

Does a processed MDN mean my purchase order was accepted?

No. A processed MDN means the receiver decrypted your message, verified your signature and handed the payload to whatever comes next. It is signed proof of receipt, and with a matching MIC it gives you non-repudiation, which is genuinely valuable. It is not proof that anything read the document.

The chain for an outbound purchase order looks like this, and each step can fail independently while the one before it reports success:

Only the last row tells you anything about your order. If you are tracking whether orders are being fulfilled, the 855 is the document that answers it, and the EDI 855 acknowledgment converter lays out the line status codes it carries.

Synchronous and asynchronous MDN, and why the difference matters

The failure signature of asynchronous MDN is worth internalizing: everything on your side looks perfect. The message went out, the HTTP call returned 200, and there is no error anywhere. The MDN is missing because the partner tried to deliver it to a URL that is unreachable, or to an address you changed and did not tell them about. If MDNs stop arriving from one partner and only one, check the return URL before you touch certificates.

Signed and unsigned MDN

A signed MDN is a multipart/signed body with the MDN as the first part and an application/pkcs7-signature as the second. An unsigned MDN is a plain multipart/report. Only a signed MDN gives you non-repudiation of receipt, because only a signed MDN cryptographically ties the returned MIC to the partner identity.

If your trading partner agreement mentions non-repudiation and your MDNs are coming back unsigned, you do not have what the agreement says you have. You request signing through the Disposition-notification-options header, which is also where you state which digest algorithms you will accept.

What does it mean when no MDN arrives at all?

A missing MDN is not a slow MDN, and waiting longer rarely helps. Work through these in order.

Can I resend the same AS2 message?

Yes, and the specification is unusually precise about how. A Message-ID on a POST can be reused if and only if all of the content, including the original Date, is identical. If your client failed to read the server response, you should repeat the POST with identical content and the same Message-ID. Receiving systems are expected to handle this: on a repeated Message-ID they should resend the MIME reply body they sent the first time.

The operational consequence matters. When a partner reports a duplicate purchase order, the first question is whether the retransmission used the same Message-ID or a new one. Same Message-ID is a legitimate retry that their system should have deduplicated. A new Message-ID with the same PO number is a genuine duplicate submission, and that is your side to fix.

A troubleshooting order that actually works

Most AS2 problems are certificate problems wearing a different hat. Checking in this order avoids the usual detour through packet captures.

Step two deserves a calendar entry rather than a troubleshooting session. AS2 certificates expire on a known date and take down a working channel with no warning and no code change, and each trading partner has its own. Teams that run AS2 with more than a handful of partners keep a per partner record of certificate expiry, contact and endpoint, alongside the commercial supplier details, because the technical relationship and the commercial one fail in the same place. If that list is thin because the partner set is small, and the reason it is small is the onboarding effort, it is worth knowing that finding and qualifying new suppliers is now much less of a project than wiring one up.

Where documents fit next to the AS2 channel

AS2 is one channel and it is rarely the only one. The partners big enough to run AS2 are usually a minority of the customer or supplier list, and everyone else emails a PDF. Those orders carry exactly the same fields and none of the transport machinery, which is why they end up being keyed by hand.

Lining the two channels up on the same columns is the cheap win: purchase order number, order date, requested date, ship to, vendor, then one row per item. Our EDI to Excel converter guide covers how the X12 side flattens into those columns, including how the ISA header declares the delimiters, and PurchaseOrders reads the document side into the identical layout. To be clear about scope, PurchaseOrders is not an AS2 client and not an EDI translator, and it will not diagnose an MDN. It handles the orders that never had an MDN in the first place.

Quick reference