MDNs: Your AS2 Receipt System

An MDN (Message Disposition Notification) is how your trading partner's system tells you three things: they got your message, they processed it, and they can prove both with a cryptographic signature.

When MDNs work, you forget they exist. When they break, you're blind. No delivery confirmation. No proof of receipt for compliance. No idea whether your partner could even decrypt what you sent. And the error messages? Practically useless.

You've probably stared at "MDN verification failed" wondering what exactly failed. Let's break it down.

Sync vs. Async: Pick One. Agree on It.

Two MDN delivery modes exist. Getting them wrong wastes hours.

Synchronous MDN

Your system sends the AS2 message. The partner processes it. The MDN comes back on the same HTTP connection. One request, one response, done.

Upside: Simple to debug. Everything happens in a single transaction. No extra infrastructure needed.

Downside: Your HTTP connection stays open during processing. Large messages or slow systems can hit the 30–60 second timeout wall.

Asynchronous MDN

The partner returns an immediate 200 OK, then processes the message in the background. When they're done, they POST the MDN to a receipt URL you specified in your original message headers.

Upside: No timeout problems. Your connection closes immediately.

Downside: You need a publicly accessible receipt URL. You need to correlate the async MDN back to the original message via Message-ID. If that receipt URL is unreachable, your MDN disappears into the void.

The Sync/Async Mixup

You configure sync. Your partner configures async. You send a message. Their system processes it and fires the MDN to a receipt URL. Meanwhile, your system is waiting on the original HTTP connection. You get a timeout. They think they responded. You think they didn't.

Confirm sync vs. async with your partner before the first test message. Thirty seconds of coordination prevents hours of finger-pointing.

What "Verification Failed" Actually Means

Your system received an MDN but couldn't validate the signature. Four causes cover nearly every case.

Algorithm Mismatch (60% of Failures)

Your system expects SHA-256. Your partner signs with SHA-1. The MDN is perfectly valid. The signature checks out. But your system tries to verify with the wrong algorithm and rejects it.

This is the most frustrating kind of failure — everything worked, but a config mismatch makes it look broken.

Fix: Check your "requested MIC algorithm" setting. This tells your partner which algorithm to use for the MDN signature. Set it to sha-256, sha-384, or sha-512. Then confirm your partner's system actually honors the request. Some older platforms ignore it entirely and sign with whatever they want.

Wrong Verification Certificate (25% of Failures)

You verify the MDN signature using your partner's public certificate. If you have an expired cert, a rotated cert, or a cert that belongs to a different partner — verification fails. The signature is fine. Your certificate is stale.

Fix: Confirm the certificate in your AS2 config matches what your partner currently uses to sign MDNs. Watch out: partners sometimes use separate certificates for encryption and signing. Ask specifically for the signing cert.

Content-Type Corruption

MDNs are multipart/report messages with a human-readable part and a machine-readable disposition. If the Content-Type header gets mangled, your AS2 system can't parse the MDN structure and reports a verification failure.

Custom AS2 implementations cause this most often. But load balancers and security appliances can also silently rewrite headers in transit.

Fix: Capture the raw MDN response — all HTTP headers included. The Content-Type must be multipart/report; report-type=disposition-notification. Anything else means something modified the MDN between your partner's system and yours.

MIC Mismatch

The MDN contains a MIC (Message Integrity Check) — a hash of your original message content. Your system computes its own hash and compares. If they don't match, either the message was altered in transit or each side hashed different content.

Common culprits: line-ending normalization differences, trailing whitespace stripping, headers included on one side but excluded on the other, or different hash algorithms.

Fix: Pull the MIC algorithm and value from the MDN's Received-Content-MIC header. Compare against your system's computed value. If the algorithms match but values differ, something between you and your partner is modifying the message body. Look at proxies, middleware, and content transformation layers.

The 6-Step MDN Diagnosis

Work through these in order. Most problems resolve by step 4.

Did your partner receive the message? Ask them. Check their logs. If the message never arrived, you have a network or TLS problem — not an MDN problem.
Did they send an MDN? For sync: inspect your HTTP response body. For async: check their outbound logs and your receipt endpoint access logs.
Is the MDN well-formed? Capture the raw MDN. Look for the multipart/report Content-Type and the disposition-notification part. Malformed MIME structure = parsing failure before verification even starts.
Does the signing algorithm match? Check the MDN's micalg parameter in the Content-Type. Compare it to your configured expected algorithm. This is your answer 60% of the time.
Is the certificate current? Verify your system has the partner's active signing certificate. Not last year's. Not the encryption cert. The current signing cert.
Does the MIC match? Compare the Received-Content-MIC value against your computed MIC. A mismatch here means content was modified in transit.

Algorithm mismatch at step 4 resolves about 60% of cases. Wrong certificate at step 5 catches another 25%. Steps 3 and 6 handle the rest.

Stop MDN Failures Before Production

Every MDN failure we've described is a configuration mismatch. Every single one could be caught before your first production message hits the wire.

Agree on MDN mode (sync/async) before you exchange certificates
Agree on signing algorithm — SHA-256 is the safe default
For async MDNs, verify the receipt URL is reachable from your partner's network before testing
Test the full MDN exchange against a known-good AS2 endpoint before connecting with the actual partner
Track each partner's signing certificate and when it was last updated

AS2 Certify tests the complete MDN exchange on every connection test. It verifies signing algorithm, certificate validity, MIC computation, and MIME structure — for both sending and receiving. If a config mismatch exists, the test report flags it before production traffic does.