An AS2 MDN (Message Disposition Notification) is the protocol receipt produced after a receiving AS2 system processes an incoming message. It reports a disposition such as successful processing or an error, identifies the original message and may include a Message Integrity Check (MIC) and digital signature.
An MDN can be synchronous—returned in the original HTTP session—or asynchronous—sent later through a separate AS2 request. The right mode is the one both trading partners configure and test consistently.
What an AS2 MDN proves
An MDN records the receiver’s AS2-level disposition. When it is signed and the returned MIC matches the sender’s calculation, it provides evidence that the receiver processed the same message content the sender transmitted.
An MDN does not prove that:
- an EDI translator accepted every segment;
- the document passed business validation;
- an invoice posted in an ERP;
- a warehouse accepted a shipment;
- a human approved the transaction.
Those later states require an X12 997 or 999, EDIFACT CONTRL, application response or other business event. Treat them as a separate evidence layer.
Synchronous MDN workflow
With a synchronous MDN:
- Sender opens an HTTP or HTTPS connection.
- Sender posts the AS2 message and requests a receipt.
- Receiver decrypts, verifies and processes the AS2 package.
- Receiver returns the MDN in the HTTP response.
- Sender validates the disposition, signature and MIC before closing the exchange state.
This mode is straightforward to correlate because the HTTP response belongs to the original request. It also means the sender must keep the request open long enough for the receiver to generate the receipt.
Asynchronous MDN workflow
With an asynchronous MDN:
- Sender posts the AS2 message and supplies the agreed receipt-delivery option.
- Receiver acknowledges the HTTP request without returning the formal MDN in that response.
- Receiver processes the AS2 package.
- Receiver opens a new connection to the sender’s asynchronous MDN endpoint.
- Sender receives and correlates the MDN using the original Message-ID and validates its evidence.
This decouples receipt generation from the original request, but creates a second network route. The original sender must now operate a reachable inbound endpoint with the correct profile, certificate and security controls.
Synchronous vs asynchronous MDN
| Decision factor | Synchronous MDN | Asynchronous MDN |
|---|---|---|
| HTTP session | Same session as message | New session later |
| Correlation | Direct response plus Message-ID | Message-ID across separate request |
| Inbound route at sender | Not needed solely for receipt | Required |
| Timeout sensitivity | Original request must remain open | Receipt deadline managed separately |
| Network complexity | Lower | Higher |
| Typical reason | Simple immediate receipt | Receiver processes later or partner mandates callback |
Asynchronous is not inherently more reliable, and synchronous is not inherently more secure. Reliability depends on matching configuration, durable queues, correlation, retries and monitoring.
Signed and unsigned MDNs
An unsigned MDN communicates a disposition but lacks a verifiable digital signature from the receiver. A signed MDN adds cryptographic validation and normally includes a MIC derived from the received message.
The sender should validate:
- the MDN signature against the expected partner certificate;
- the original Message-ID reference;
- the disposition value and any modifier;
- the received-content MIC and algorithm;
- the receipt timestamp and connection context.
Store validation results with the original message. Retaining only a green status discards the evidence needed for later investigation.
Understanding the MIC
The Message Integrity Check is a digest calculated over the canonical form of the message content defined by the AS2 processing rules. The receiver returns its calculated MIC in a signed receipt; the sender compares it with the value calculated for the original transmission.
A mismatch can indicate different content, incorrect canonicalization, algorithm disagreement or a packaging defect. Do not “fix” a MIC mismatch by marking the message successful manually. Preserve both calculations and inspect MIME structure, transfer encoding, compression, signature processing and the exact algorithm token.
MDN dispositions
A successful receipt typically communicates processed. Error dispositions can include modifiers indicating authentication, decryption, integrity or unexpected-processing failures. Exact text varies by implementation.
Operational logic should classify the result:
- positive and fully validated MDN;
- negative MDN that requires configuration or payload investigation;
- receipt received but signature invalid;
- receipt received but MIC mismatched;
- HTTP response received without expected MDN;
- MDN not received before the agreed deadline.
These states should not be collapsed into one generic “failed” status because their owners and recovery actions differ.
Timeout and retry behavior
For synchronous receipts, the HTTP timeout must allow the partner enough time to process the package. If the sender times out after the receiver accepted the message but before the MDN arrived, delivery becomes uncertain. A blind resend can create a duplicate.
For asynchronous receipts, define a receipt deadline independent of the original HTTP response. Queue outbound MDNs durably and retry callbacks according to the bilateral agreement.
In either mode, preserve Message-ID and idempotency behavior. Before retransmission, determine whether the partner may already have processed the business document.
Common MDN problems
No synchronous MDN in the HTTP response
Confirm that both profiles expect synchronous mode, that the correct receipt headers were sent and that the partner did not return an HTML proxy or firewall error instead of an AS2 entity.
Asynchronous MDN never arrives
Check callback URL, DNS, TLS, firewall, receiving AS2 ID and the partner’s outbound retry logs. The message route and receipt route are independent.
MDN signature fails
Compare the actual signing certificate fingerprint with the trusted certificate in the partner profile. Check expiry, algorithm support and whether the partner uses a different certificate for receipts.
MIC does not match
Compare algorithms and raw canonical message evidence. MIME or compression handling may differ even when the visible EDI text looks identical.
Positive MDN but partner says the EDI failed
The transport succeeded. Retrieve the 997, 999, CONTRL or application error and route the issue to EDI mapping or business operations. Read AS2 MDN vs EDI acknowledgments for the distinction.
What to retain for audit and support
- original AS2 Message-ID;
- partner and environment identifiers;
- send and receipt timestamps;
- MDN mode;
- HTTP status and relevant headers;
- disposition and modifier;
- MIC value and algorithm;
- signature validation result and certificate fingerprint;
- retry history;
- link to the payload and later business acknowledgment.
Retention should follow legal, contractual and security requirements. Protect message content separately from operational metadata if it contains sensitive business data.
MDN test checklist
- Send a valid signed and encrypted message.
- Confirm the expected synchronous or asynchronous route.
- Verify the MDN signature with the intended certificate.
- Match Message-ID and MIC.
- Trigger a controlled negative case.
- Test timeout and retry handling without duplicating business processing.
- Confirm monitoring alerts on an overdue receipt.
- Confirm a later EDI acknowledgment is tracked independently.
Use the AS2 connection testing guide for the full pre-production plan and AS2 transaction monitoring for operational controls.
AS2Connection exposes message and MDN states through its managed cloud AS2 gateway, so transport evidence can be connected to the rest of the EDI workflow.
Technical references
RFC 4130 defines AS2 receipt behavior, including synchronous and asynchronous return, AS2-specific disposition fields and the received-content MIC. RFC 8098 is the current general MDN standard. Use the AS2 rules together with the exact bilateral settings documented by the trading partner.
