mail.dat. The manifest that
moves the drop from press to dock.
Every commercial drop above the eDoc threshold submits to USPS PostalOne! as a mail.dat or Mail.XML file set — the structured manifest that documents every piece, every container, every pallet, every IMb, and every entry facility before the truck rolls. The manifest is load-bearing: bad data in produces validation failures at PostalOne! and discrepancies at the dock; good data in produces an authorized Job ID, a printable placard, and live IMb scan tracking through Informed Visibility. DirectMail.io generates the mail.dat file set from actual production data, manages the IMb pool to prevent serial collisions, submits to PostalOne!, handles validation, and links the Job ID to scan reporting end-to-end.
Five steps. From press output to PostalOne! authorization.
- 01
Hygienized list and press run feed the mail.dat generator
Once the list clears NCOA, CASS, DPV, and DSF2 and the press produces the actual pieces with their IMbs, the platform compiles the mail.dat file set from the real production data — not from a pre-press estimate. The manifest matches what physically shipped, not what was planned.
- 02
IMb pool prevents serial collisions across active windows
Intelligent Mail Barcode serials are assigned from a managed pool that tracks active windows per Service Type Identifier. The platform never reuses a serial within the USPS scan-tracking window, so Informed Visibility scans always resolve to the right drop.
- 03
Container, pallet, and entry-facility builds reflect actual production
The .csm (container summary), .cqt (container quantity), and entry-point fields populate from the production manifest. Pre-sort local entry drops route to one facility code; pre-sort dropship drops route to the correct NDC/SCF/DDU code per pallet — automatically, no manual lookup.
- 04
Submission to PostalOne! via Business Customer Gateway
The complete mail.dat or Mail.XML file set submits to PostalOne!, validates, returns a Job ID and a payment-authorization status. Validation failures surface with the specific field-level error so the team can correct and re-submit without guessing what the eDoc engine objected to.
- 05
Placard, manifest, and IMb tracking activate
Once authorized, the platform produces the placard for the pallet, the drop ships, USPS scans at acceptance, and the same Job ID surfaces in Informed Visibility scan reporting for every IMb in the drop. The submission, the dock acceptance, and the scan tracking all reference the same Job ID end to end.
Why mail.dat is a binding declaration, not a generated invoice.
The mail.dat file is not an after-the-fact summary of what happened; it's a binding declaration USPS uses to authorize the drop, price the postage, and track every piece. The IMbs in the .pdr file have to match what's physically printed on the mail. The container counts have to match what arrives on the truck. The entry-facility codes have to match where the truck actually shows up. USPS reconciles the submission against the physical drop on acceptance, and discrepancies trigger postage adjustments, manifest rejections, or full drop holds at the dock.
That binding quality makes mail.dat generation the load-bearing step that ties the entire production pipeline together. Bad address hygiene upstream produces a manifest that bounces validation. IMb serial collisions across drops break per-piece scan tracking. Mismatched entry-facility codes route pallets to the wrong dock and forfeit the destination discount. Spec-version drift against IDEAlliance releases breaks submissions silently — the file passes locally but fails at PostalOne! on rules the platform hasn't adopted. The work of a production-grade mail.dat engine isn't generating the file; it's preventing every one of those failure modes from reaching the dock.
And the same manifest is what powers everything downstream. Informed Visibility scan reporting resolves IMbs to Job IDs that came from mail.dat. USPS Scan Trigger workflows fire on scan events linked to the same Job ID. Per-piece response attribution joins the campaign data to the IMb. The mail.dat submission is the linchpin: it gets the drop onto USPS infrastructure, and it's the reference key that everything else in the drop's life cycle hangs off of.
Where mail.dat submission shows up.
-
Every commercial drop above the eDoc threshold
USPS requires electronic documentation through mail.dat or Mail.XML on any automation-rated commercial mailing at the volume threshold and above. Effectively, every real production drop submits this way.
-
IMb-tracked campaigns and USPS Scan Trigger workflows
If the campaign depends on Informed Visibility scan data — for delivery dashboards, response attribution, or scan-triggered marketing actions — the mail.dat submission is what registers the IMbs with USPS in the first place.
-
Pre-sort drop-ship campaigns to multiple destinations
Drop-ship campaigns file mail.dat with destination-entry facility codes per pallet. The manifest authorizes the destination discount at each entry dock the truck reaches.
-
Co-mingle pools and walk-sequence presort
Specialty sortation tiers (commingle, walk-sequence) submit through mail.dat with the tier-specific fields populated. The manifest documents the qualifying sortation so the discount applies at acceptance.
Questions teams ask before deploying.
Short answers. For implementation specifics on IMb pool management, validation error workflows, or PostalOne! account configuration, book a demo.
-
What is mail.dat and what is the difference from Mail.XML?
mail.dat is the structured file format USPS commercial mailers submit to PostalOne! to electronically document a drop — every mailpiece, every container, every pallet, every sortation tier, every IMb. Mail.XML is the same data in an XML wrapper rather than the legacy flat-file format. Functionally they're equivalent; PostalOne! accepts both. Modern platforms tend to generate Mail.XML for API-driven submission flows, but the data model and the validation rules are the same. The platform generates whichever PostalOne! expects for the submission type.
-
Why does USPS require electronic documentation in the first place?
PostalOne! launched in 2002 to replace the paper-and-pallet acceptance model with a structured digital submission. Before eDoc, every commercial drop was hand-counted at the dock by a USPS clerk against paper Form 3602/3605 paperwork — slow, error-prone, and impossible to reconcile after the fact. eDoc lets PostalOne! validate the drop, price it, and authorize payment before the truck rolls; the dock just scans a placard. The system is what makes per-piece IMb tracking, accurate postage calculation, and Informed Visibility scan reporting possible. Any commercial mailing above the eDoc volume threshold is required to submit electronically.
-
What happens when a mail.dat submission fails PostalOne! validation?
PostalOne! returns the specific field-level error code and the file that failed validation. Common causes are IMb serial collisions with another active drop, container counts that don't match between .csm and .cqt files, entry-facility codes that don't resolve to a current USPS facility, postage statements that don't reconcile against the per-piece sortation tiers, or spec-version mismatches against the current IDEAlliance release. The platform surfaces the error in the dashboard, identifies the underlying production-data issue, and resubmits once corrected. The team doesn't parse raw eDoc XML errors.
-
How are IMb serials managed across multiple drops?
IMb serials are 9 digits per piece per Service Type Identifier (STI), and USPS uses them as the unique identifier for scan tracking. Reusing a serial inside an active scan window collides with the prior drop and breaks the per-piece tracking on both. The platform manages an IMb pool that tracks active windows per STI and never reissues a serial inside the window — typically 45 days for First-Class STIs, longer for Marketing Mail. Operators don't allocate IMbs manually; the pool assigns them.
-
Does mail.dat handle pre-sort drop-ship drops differently from local-entry drops?
The file format is the same, but the entry-facility codes change per pallet to reflect the destination dock. For a pre-sort local-entry drop, the entry facility is the local NDC or SCF. For a pre-sort drop-ship drop, each pallet on the truck carries the facility code for its destination — different SCFs or DDUs across the same shipment. The platform assigns the correct codes based on the freight plan and the destination ZIP groupings, and PostalOne! prices each pallet at the entry-discount tier the destination earns.
-
How does mail.dat connect to Informed Visibility scan reporting?
The IMbs in the mail.dat .pdr file are what USPS scan infrastructure tracks. When the drop submits and is authorized, the IMbs are registered against the Job ID. As USPS scans the pieces at sortation points, the scan events flow into Informed Visibility under the same Job ID. The platform consumes the IV feed and surfaces per-piece scan status in the dashboard — and the same scan events drive USPS Scan Trigger workflows for campaigns that fire marketing actions on physical-mail delivery.
-
Does the platform handle mail.dat spec updates automatically?
Yes. IDEAlliance releases mail.dat spec updates on a regular cadence as USPS adds new mail products or modifies sortation rules, and the spec version submitted has to match what PostalOne! currently accepts. The platform's mail.dat generator rolls to the current spec on every release, so operators never have to chase a version-mismatch validation error. The drop submitted today validates against today's rules.
Submit your next drop through automated mail.dat.
30-minute demo. We’ll walk a sample drop through mail.dat generation, show the IMb pool allocation, surface where validation errors would have come from on a typical eDoc submission, and demonstrate the Job ID linkage to Informed Visibility scan reporting.