Email intake

Send delivery orders to Conterminal by email

Email or forward a delivery order to your workspace document address and Conterminal archives the message, reads the attachment, and puts the document in Document Review. If the sending address is recognized, the document is processed without anyone clearing a warning first, and a carrier workspace can reply to the sender automatically with a live tracking link.

8 minute setup · Updated September 9, 2026

Your workspace has two Conterminal addresses and they are not interchangeable.

Documents go to the delivery-order address. LFD conversations go to the separate address that begins with lfd-. A delivery order attached to a message sent to an lfd- address is never archived as a document and never reaches Document Review: intake decides the route from the recipient before it looks at attachments, and the LFD path stores message text only.

Which address to use

Every Conterminal workspace address ends in @conterminal.com, and each one is registered for exactly one purpose. Open Settings → Email aliases to see what your workspace holds. The table lists Alias, Purpose, Status, Routing, and Last sync.

Delivery-order documents
The address this article is about. Attachments sent here are archived, read, and placed in Document Review.
LFD conversations
Always begins with lfd-. Message text is captured for the Last Free Day digest; attachments are ignored on that path.

An address only routes when its Status is Active and its Routing shows Provisioned or Covered By Catchall. An address still shown as Requested or Provisioning accepts nothing yet. If your workspace has no delivery-order address, a tenant admin requests one from the same panel using the Request alias form; see Request and manage your Conterminal email addresses.

Do not guess at an address. Local parts such as admin, support, noreply, and postmaster are reserved and cannot be assigned to a workspace, and mail addressed to an unregistered @conterminal.com address is recorded with the routing warning intended_recipient_alias_not_registered. An address that exists but is not yet live records intended_recipient_alias_not_active. Neither produces a document you can work.

Sending or forwarding a delivery order

  1. Attach the document. Only attachments are read on this path. Nothing you type in the message body becomes delivery-order data, so pasting a container number into the email does not rescue a missing or unreadable attachment.
  2. Send to the delivery-order address. Put it in To or Cc, or forward the original message to it. Conterminal works out the intended recipient from the delivery headers first and the visible To line only as a fallback, so an address that appears solely in a forwarding rule still resolves correctly.
  3. Send from a recognized address. The From address on the message decides whether the document is processed automatically or held for a person. See what trusted senders unlock below.
  4. Expect one item per attachment. Every supported attachment on the message becomes its own Document Review item. A message carrying three PDFs produces three items, not one.

Forwarding usually breaks DKIM and DMARC alignment, and that is the most common reason a correctly addressed document still lands in the review queue. Conterminal tolerates the mixed signal only when the authentication result still carries a pass aligned to the sender's own domain. Otherwise the document is held and the review page shows “Email authentication has mixed pass/fail signals, commonly caused by forwarding. Review before confirming.” Where you have the choice, have the sender email your address directly rather than forwarding their message.

Resending is not free. Each inbound message is recorded as its own receipt, so mailing the same PDF a second time creates a second Document Review item rather than updating the first one. Chase the original item instead of re-sending, and archive the extra if you have already created one.

Supported attachments

Intake pulls three attachment types off an inbound message and ignores everything else. Both the MIME type and the filename extension are checked, so a correctly named file still works when the sending client sets a vague content type.

PDF
application/pdf, or any filename ending in .pdf. Read directly.
Word
.docx and .doc, or the matching Word MIME types. Converted to PDF before anything reads it, and the converted PDF is the copy you see in review.

A photograph or scan saved as JPEG, PNG, or TIFF is not accepted as a delivery order. If a photo is all you have, convert it to a PDF before sending. Image files are accepted for proof of delivery, interchange receipts, and other documents, but only through the Conterminal Mail Chrome extension or a manual upload — not through this email address.

When a message reaches the address with no PDF, DOC, or DOCX attached, Conterminal replies to the sender automatically and stops there. The reply body reads:

We could not find a supported delivery-order attachment on this email, so nothing was processed. Please resend the email with the delivery order attached as a PDF, DOC, or DOCX file.

That reply keeps the original subject with Re: prefixed, or uses Re: Missing supported delivery-order attachment when the message had no subject. It goes to whoever sent the message, recognized or not, so an outside party who mails your address by mistake will receive it. A Word file that cannot be converted is treated as a permanent failure for that attachment rather than retried forever.

What trusted senders unlock

Conterminal decides ownership from the message's From address. That address is recognized when it matches any one of three things.

  1. A user account in your workspace whose email is that address.
  2. Your organization's own contact email, or its global notifications email.
  3. An active entry on the workspace's delivery-order intake allowlist.

Exactly one workspace has to match. Zero matches records sender_not_authorized. If the same address is recognized by more than one Conterminal workspace, the document is held with sender_maps_to_multiple_organizations instead of a guess about who owns it.

The recipient address and the sender's organization are separate facts. A delivery order sent by one Conterminal company to another company's document address can be legitimate without changing who owns the sender address. The receiving workspace can accept the current document, and a tenant admin can separately trust that sender for future authenticated documents routed to that workspace.

Email authentication is assessed before the allowlist and overrides it: a message whose SPF, DKIM, or DMARC result is failing, missing, or contradictory is held even when the sender is on your allowlist. The only authentication result that counts is the one Conterminal's own mail edge computed. Authentication headers carried inside a forwarded message are kept as audit evidence and never used to make the decision, because a sender can write lookalike headers into the raw message.

Adding a sender to the allowlist

You add senders from the document they sent, not from a settings screen. In a carrier workspace, open an eligible sender warning and choose Review sender. Any authorized reviewer can use Accept this document without changing future email behavior. Tenant admins also see Accept & trust future documents. In the express review table the equivalent controls read Trust sender for future documents and Trust sender & apply tracking. Trusting a sender clears the warning on the document in front of you as well as allowing the next one.

Only the future-trust choice is limited to tenant admins. Accepting one eligible document does not trust the address. Email authentication and parser warnings cannot use either action; they must be corrected or reviewed through their existing recovery path.

What recognition actually buys

Recognized sender
The document is assigned to your workspace and staged for review or automatic tracking without anyone clearing a warning first.
Unrecognized sender
The document is held. If it reached your workspace address it is still yours and still visible in your queue, with the reason attached, but a person has to accept it.

Recognition is also the gate on the automatic reply described next. An unrecognized sender never receives one.

Configuring the automatic reply

A carrier workspace can answer the sender automatically once a trusted delivery order has been read, so the dispatcher who sent it knows it landed. The reply carries a live tracking link for the shipment, which the sender can open without a Conterminal account — one fewer status call for your team to field. Open Settings → Instant received confirmation. The panel appears only in carrier workspaces, and only a tenant admin can change it — everyone else sees the current mode and both templates as read-only text. An attempt to save without the role returns “Only trucker tenant admins can change this setting.”

  1. Set Automation Mode. Choose Disabled or Trusted single-container send. Disabled is the default for every workspace, so nothing goes out until someone turns this on.
  2. Choose Email Framing. Received — review in progress tells the sender the document arrived and is being validated. Confirmed — corrections only if something changes tells the sender the order is confirmed and that they will hear from you again only if something changes. Switching framing rewrites the stock templates but leaves templates you have hand-edited alone.
  3. Edit the templates. Subject Template accepts up to 200 characters and Body Template up to 4,000. Neither can be empty. The supported tokens are {containerNumber}, {tenantName}, {replySubject}, {originalSubject}, and {senderEmail}. Anything else in braces fails the save with “The template contains an unsupported token.”
  4. Check Sample Preview, then save. The preview renders both templates against a sample container and sender. Reset to defaults restores the stock copy for the framing you selected; Save Automation commits the change.

The panel says the reply fires “when exactly one container number is safely parsed,” and the mode is still labelled Trusted single-container send. That copy is out of date. A multi-container delivery order is eligible, and the reply enumerates every container it read rather than going silent. Read the mode as trusted-sender automation, not as a one-container restriction.

When the reply is suppressed

The send is deliberately conservative. Nothing goes out when the sender is not recognized for your workspace, when the workspace is not a carrier workspace, when the mode is disabled, when no container number was read at all, when a container reading is marked ambiguous or illegible, when the document carried field evidence but never marked a container as present, when the reply recipients could not be established with confidence from the original thread, or when a working tracking link cannot be issued for the shipment. At most one such reply is ever sent per attachment.

The reply is never sent with a dead or missing tracking link. If a live link cannot be issued at send time, the whole reply is held back rather than going out with a link that would fail in the sender's hands. A sender who receives one of these can trust the link in it.

The reply is queued at intake and held rather than sent instantly. It goes out when tracking enrichment finishes and the document is ready for review, or at a ten-minute ceiling, whichever comes first. A sender who replies within the first minute has not missed it.

Where the document appears next

Before anything is treated as a delivery order, the attachment is checked against two other paths. A proof-of-delivery document is recognized and routed to the proof-of-delivery flow, and an attachment that links straight to networked tracking is handled there. Only what is left is read for delivery-order fields. An interchange receipt is recognized later, from the document title and subject, and leaves the delivery-order flow before assignment, tracking, or the automatic reply can run.

Everything that survives lands in Document Review. The static tabs in every workspace split the queue into Delivery Orders, Proof of Delivery, Interchange Receipts, and Unknown. Forwarder delivery orders use Express Review; the other document types use the standard assignment table.

Delivery Orders
A recognized sender and a clean read. The document is waiting for you to resolve its assignments and confirm it.
Interchange Receipts
The attachment was identified as an interchange receipt and left the delivery-order flow early.
Unknown
Held for a person: an unrecognized sender, an authentication problem, or an attachment that could not be read.

An interchange receipt attaches itself to a delivery order only when its container number matches exactly one open delivery order in your workspace. No container number, no open match, or more than one match all leave it in the interchange-receipt queue to be assigned by hand. For the review work itself, see Work the Document Review queue and Review and confirm a delivery order.

Forwarded proofs of delivery use the delivery day

A forwarded POD uses the actual delivery date shown on the document, not the day the email arrived. A barcode identifies the shipment; it does not supply that date. If the date is missing, unreadable, conflicting, or in the future, the document stays in Document Review without replacing the shipment's existing proof. Review the original document before confirming a date. Retrying the same email attachment does not overwrite a reviewed correction.

What Conterminal keeps

Stored from the message
The complete original message, each original attachment exactly as sent, the converted PDF for Word files, a preview image, and the routing and authentication metadata used to decide ownership. Conterminal verifies the stored attachment before processing it; held documents are stored separately from clean ones but are not discarded.
Not used as evidence
Authentication headers carried inside a forwarded message. They are retained as part of the archived original, but only the result computed by Conterminal's own mail edge decides whether a sender is recognized.

Only the attachment is read for delivery-order fields. The message body is not, which is why an attachment that scans badly cannot be rescued by describing it in the email. The subject line is used, but only as a hint when classifying what kind of document the attachment is. The LFD conversation address is the mirror image: it stores message text and ignores attachments.

Troubleshooting

The document landed in Unknown or shows a warning

Open it. The queue row carries a short label such as “Sender is not authorized for this workspace”, “Missing From sender header”, or “Parser quarantine: …”; the review page spells the same reason out in full. An eligible, parsed sender-identity warning offers Review sender so you can accept this document once; tenant admins may also trust future authenticated documents. Authentication problems are fixed by having the sender mail you directly instead of forwarding, and parser problems by sending a cleaner PDF.

The sender is not trusted and I cannot trust them

Future sender trust is limited to tenant admins. If Review sender is available, another authorized reviewer can still use Accept this document for the PDF in front of them. Ask a tenant admin to approve future documents, or send support the workspace name and exact sender address when the warning is not eligible for self-service acceptance.

A reason mentions multiple organizations

sender_maps_to_multiple_organizations means that From address is recognized by more than one Conterminal workspace, so ownership is ambiguous and will not resolve itself. Send support the sender address and the workspace that should own the document.

The document was routed to us but is still held

Reasons beginning with alias_routed mean the message reached your address correctly but the sender did not clear the automatic-processing bar. The document is yours and is visible in your queue; it just needs a person to accept it.

An interchange receipt did not attach itself

Interchange receipts leave the delivery-order flow before assignment runs and match on container number alone. If that container has no open delivery order, or has more than one, the receipt waits in Interchange Receipts to be assigned by hand.

Nothing arrived at all

Check the sender's mailbox for the automatic “We could not find a supported delivery-order attachment” reply, which means the attachment was not a PDF, DOC, or DOCX. If there is no reply either, confirm the message went to the delivery-order address and not an lfd- address, and confirm in Settings → Email aliases that the address is Active with routing provisioned or covered by catchall.

Document Review says processing is taking longer

That message appears after the current processing run passes ten minutes; it is not calculated from the email's received time and does not mean the document failed. If all queue retries are exhausted, the live row clears and the document remains in its review bucket with Retry processing.

No automatic reply reached the sender

Confirm the workspace is a carrier workspace, that Automation Mode is set to Trusted single-container send, and that the sender is recognized. Beyond that the send is suppressed when no container was read, when a container reading is ambiguous or illegible, when the reply recipients could not be established from the original thread, or when a working tracking link cannot be issued — the reply is held rather than sent with a link that would not open. It is also held for up to ten minutes by design, so check again before assuming it failed. If replies stopped for every sender at once, ask support to confirm tracking links are enabled for your workspace.

The same document appears twice

Each inbound message is its own receipt, so a resend creates a second item. Archive the duplicate and work the original. Two items from a single message mean the message genuinely carried two supported attachments.