mail.dat

mail.dat is the file format USPS commercial mailers use to electronically document a drop — every mailpiece, every container, every pallet, every sortation tier, every barcode — before it physically enters the postal network. It is maintained by IDEAlliance (an industry consortium that codifies the spec on behalf of USPS) and submitted through USPS’s Business Customer Gateway portal, where the PostalOne! system ingests the file, validates it, prices the drop, and authorizes the postal acceptance. Mail.XML is the same data in an XML wrapper rather than the flat-file format — functionally equivalent, used in modern API-driven submissions instead of the legacy fixed-width files.

Why this exists at all

Before electronic documentation existed, USPS commercial acceptance was a paper-and-pallet exercise: a mailer rolled a truck into a postal facility with a stack of physical paperwork (Form 3602, 3605, others), and a USPS clerk hand-counted pieces, validated the presort, and stamped the postage. The error rate was significant, the throughput was low, and the entire system depended on the mailer and clerk agreeing on a count nobody could verify after the fact. PostalOne! launched in 2002 to digitize the entire workflow: the mailer submits a structured file describing the drop, PostalOne! validates it against USPS rules, the drop arrives at the dock with a barcoded placard, and the clerk scans the placard rather than hand-counting. mail.dat is that structured file format. Today, any commercial mailing claiming automation postage discounts above a certain volume threshold is required to submit through mail.dat or Mail.XML.

How it actually works

The mail.dat spec defines a set of related files — each describing a different facet of the drop. The Header (.hdr), Mail Piece Unit (.mpu), Container Summary (.csm), Container Quantity (.cqt), Mail Piece IMb (.pdr), Postage Statement (.pqt), and several supporting files together describe every piece in the drop, what container it’s in, what pallet that container is on, what entry facility the pallet is going to, what sortation tier each piece qualifies for, and what IMb (Intelligent Mail Barcode) is on each piece. The files cross-reference each other through structured keys, and the whole set submits as a single .zip to PostalOne!. PostalOne! validates the cross-references, prices the drop, and returns a payment authorization that the mailer needs at the dock when the trucks arrive. The version of the spec changes annually as USPS adds new mail products or sortation rules.

Two important details. First, mail.dat is not just an invoice — it’s a binding declaration. The IMbs in the .pdr file must match what’s physically printed on the mail, the container counts must match what arrives on the truck, and the entry facility must match where the truck actually shows up. USPS reconciles the submitted file against the physical drop, and discrepancies trigger postage adjustments or rejection. Second, mail.dat and Mail.XML are functionally interchangeable for most submission types — Mail.XML is more API-friendly and what most modern platforms generate, but PostalOne! accepts both, and the underlying data model is the same.

What goes in, what comes out

Input: the full set of structured files describing the drop, packaged as a single submission. The platform that generates the files needs accurate per-piece IMbs, accurate container manifests, accurate pallet builds, accurate entry-facility codes, and accurate postage calculations — any of which can fail validation and bounce the submission. Output: a PostalOne! confirmation with a Job ID and a payment-authorization status. Once authorized, the drop has a placard that prints with the pallet, the trucks roll, and USPS scans the placard at acceptance. The same Job ID then surfaces in Informed Visibility scan reporting so the mailer can follow every piece through the postal network on the IMb-by-IMb level.

Common pitfalls

The biggest pitfall is treating mail.dat as a generated output rather than a load-bearing dataset. Bad address hygiene upstream produces a clean-looking mail.dat that bounces at PostalOne! validation because IMbs reference pieces with invalid addresses, or pieces that DPV-failed and shouldn’t have shipped. The mail.dat is only as good as the data feeding it. The second pitfall is version drift — the IDEAlliance spec updates yearly, and a submission file generated against last year’s version may parse but fail current USPS validation rules. Production platforms have to update their mail.dat generators on every spec release. The third pitfall is reusing IMb serial numbers across drops. The 9-digit serial inside the IMb is supposed to uniquely identify the piece for a long window (often 45 days for First-Class, longer for Marketing Mail). Reusing a serial inside the window collides with the older drop in USPS scan reporting and breaks the per-piece tracking the mailer is presumably paying for.

How DirectMail.io runs it

DirectMail.io generates mail.dat (or Mail.XML, depending on the destination) on every drop automatically. The IMbs are assigned from a managed pool that prevents serial collisions across active windows, the container and pallet builds reflect the actual production output, the entry facility codes route to the correct USPS dock for pre-sort or drop-ship entry, and the submission files against PostalOne! with the Job ID returned to the dashboard. Spec updates from IDEAlliance roll into the platform’s mail.dat generator on every USPS release so submissions stay current without operator action. Details on the mail.dat submission feature page.

When to use this

• Every commercial drop above the eDoc threshold. USPS requires electronic documentation through mail.dat or Mail.XML on any automation-rated commercial mailing at or above the volume threshold — effectively, every real production drop.
• Any drop using Intelligent Mail Barcodes. If the campaign needs IMb tracking through Informed Visibility (and it does, if scan triggers, delivery dashboards, or response attribution matter), mail.dat is what registers the IMb-to-piece mapping with USPS.
• Pre-sort drop-ship campaigns. Destination-entry drops file mail.dat with facility codes for each NDC/SCF/DDU entry point. The manifest is what authorizes the discount at each destination dock.

For the IMb format mail.dat tracks, see the Intelligent Mail Barcode entry.