DSV Tracking

DSV or Schenker: choose the tracking lane before the number

The current relationship is easy to misunderstand:

DSV owns the acquired Schenker business, but that does not currently make “Schenker” a DSV tracking alias.

DSV's global self-service page still exposes:

• Track DSV shipment
• Track Schenker shipment
• myDSV for users who previously used myDSV
• myDSV (formerly DB Schenker Connect) for users coming from the Schenker system

DSV's current migration guidance says Schenker customers should continue to access Schenker systems until they are told that their migration to DSV systems is taking place. That means a number can be perfectly legitimate in a Schenker workflow while being the wrong input for the DSV lane.

Use the provenance of the shipment record rather than the corporate logo alone:

Do not assume that every historic DB Schenker, Schenker, STT or Connect reference has already migrated to the DSV public tracker. The current first-party interface says otherwise.

How to track a DSV shipment

For a shipment that is clearly in the DSV lane:

1. Open DSV Self-services.
2. Choose Track DSV shipment.
3. Enter the ID number supplied for that DSV tracking lane.
4. Compare the returned identity and events with the shipment record you received from the sender, booking party or customer account.
5. If the result exposes another carrier or another tracking identity, use that as a possible bridge to the carrier operating the relevant leg—but do not treat assignment alone as proof that the second carrier has physically accepted the freight.

The current global DSV field is deliberately broad: Enter ID number. It does not publish one exhaustive worldwide grammar beside the input. That is why the source and service context of the identifier matter more than a guessed pattern.

If you are a DSV customer, myDSV can provide richer customer visibility than the public high-level view. DSV describes customer capabilities that can include detailed shipment information, scan logs, notifications and proof-of-delivery access in the relevant workflow. Those are authenticated/customer features; they should not be assumed to be present for every anonymous public lookup.

Which DSV ID should you use?

There is no single answer that is safe for every DSV system.

The current evidence shows several identifier classes, but they belong to different contexts:

The important ceiling is this:

DSV documents multiple identifiers across public, localized and authenticated systems. That proves identifier plurality. It does not prove that every documented identifier is accepted by the global unauthenticated DSV tracker.

If the number came from a booking confirmation, customer portal, API integration, invoice, sender message or downstream carrier, keep that provenance. It often tells you which system should recognize the value.

For the generic job of identifying an uncertain number, use How to Find and Verify a Tracking Number.

Why there is no safe universal DSV tracking-number format

Do not reject a DSV identifier merely because it does not match a third-party list of lengths or prefixes.

Current first-party DSV material shows:

• different identifier classes in different systems;
• different official example shapes for DSV Shipment IDs;
• separate DSV, Schenker and XPress contexts;
• country-localized terminology that is not identical to the global public interface.

That is evidence against one universal DSV regular expression.

A safe rule is:

Use the exact system and document that issued the identifier. Do not promote one example, prefix or length into a global DSV format rule.

The following are not established by the current official evidence:

• one universal DSV digit length;
• one universal DSV prefix family;
• one global STT rule for DSV tracking;
• a single regex that separates every valid DSV number from every invalid one;
• global anonymous-tracker support for every identifier available in an authenticated API.

A format can help you transcribe a number correctly. It cannot, by itself, prove that DSV physically has the shipment, that the number belongs to your order, or that the correct tracking lane has been selected.

A booking or reference does not mean DSV physically has the freight

This is one of the most important evidence boundaries on a DSV shipment.

DSV's authenticated booking documentation distinguishes stages that can exist before final physical handling. In the XPress workflow, DSV documents a draft booking state that is not sent to the carrier; confirmation is the step that sends the booking instruction to the final carrier.

For a normal tracking user, the practical model is:

reference or booking exists → booking may be validated or prepared → instruction may be confirmed → carrier acceptance or pickup can occur → physical movement can be recorded

Not every service exposes those exact steps publicly, and this is not a universal DSV event sequence. The point is the evidence ceiling:

• A booking number proves a booking/reference object exists in the relevant system.
• It does not by itself prove that a carrier accepted the freight.
• It does not by itself prove pickup.
• It does not by itself prove movement.

If your real question is “who physically has the shipment?”, look for a later item-level acceptance, pickup, carrier-receipt or movement record from the system that controls the transport leg.

This same distinction is useful when a sender gives you a valid DSV reference but tracking has not yet shown a physical event. Do not convert the absence of a later event into proof of fraud or loss; identify the strongest state that is actually recorded.

DSV visibility can coexist with a final carrier's record

DSV is a global transport and logistics organization, not simply one consumer last-mile delivery driver.

Its current solution portfolio spans multiple transport and logistics contexts, including air, sea, road, rail and parcel services. That breadth is another reason a DSV tracking record should be interpreted by service/system context rather than by one consumer-parcel number rule.

DSV's own freight-forwarding explanation describes the forwarder as an intermediary that can arrange transport through carriers and partners. Current first-party product evidence also gives concrete examples of a separate transport-carrier layer:

• DSV XPress documentation refers to a final carrier and a Carrier tracking ID.
• DSV's U.S. LTL material describes selecting national or regional carriers while DSV/myTMS provides centralized management and visibility.

That supports a multi-record model:

DSV shipment or booking identity + DSV visibility + an underlying or final carrier for a leg + possibly a separate carrier tracking identity

This does not mean every DSV shipment has another carrier. It also does not mean DSV never physically handles freight. It means you should not assume that the DSV record must be the only operational record in a multi-leg shipment.

When another carrier appears, ask two separate questions:

1. Has that carrier been assigned or named?
2. Has that carrier itself recorded item-level acceptance or movement?

The second is stronger evidence for that carrier's custody or handling than a mere transfer field or assignment.

For a destination-carrier problem, see Handed to Local Carrier and How to Find the Last-Mile Carrier and Local Tracking Number.

Public tracking, myDSV and API visibility are different evidence surfaces

DSV's systems expose different levels of information to different users.

The current myDSV material distinguishes a public high-level shipment view from richer authenticated customer visibility. In the customer workflow, DSV describes features such as shipment details, scan-log access, notifications and proof-of-delivery visibility after the relevant completion state.

The Developer Portal goes further by documenting authenticated API objects and search keys.

These surfaces should not be collapsed:

11Tracking does not log in to private myDSV accounts, myTMS, customs tools, eClaims or DSV APIs. If a decisive record is private, the relevant account holder or authorized customer may need to check it in the official DSV system.

Customs status and physical movement are separate evidence axes

A customs record answers a different question from a transport scan.

DSV's U.S. self-service material makes this distinction concrete by listing Webtracker as a customs release status tool, separately from ordinary shipment Track & Trace and Road/myTMS functions.

That is a U.S.-scoped example, not a global promise that every DSV shipment has Webtracker access.

The safe evidence rule is broader:

customs status or release record = administrative evidence about the customs process

It does not by itself mean:

• the freight moved at the same moment;
• a destination carrier has accepted it;
• the next transport event has already been recorded;
• delivery is imminent.

A shipment can have a customs milestone and a separate physical movement timeline. myDSV notifications can also surface customs-clearance milestones alongside transport information, reinforcing that these are related but distinct state dimensions.

If the actual issue is customs processing or an action-required customs problem, use Customs Processing or Package Stuck in Customs instead of turning this DSV page into a general customs guide.

What a DSV “not found” or no-result lookup proves

A no-result in a DSV lookup is a result about that queried system and identifier at that time.

It is not, by itself, proof that:

• the shipment is fake;
• the booking never existed;
• the shipment was cancelled;
• no carrier has ever handled the freight;
• the sender committed fraud;
• the parcel is lost.

Before making a stronger conclusion, check the classification:

1. Was the shipment supposed to be in the DSV lane or the Schenker lane?
2. Did you enter the identifier that belongs to that lane?
3. Is the value a shipment number, booking/reference object, or a downstream carrier number?
4. Is the decisive information available only in an authenticated customer system?
5. Has a final carrier been named, and does that carrier have its own record?
6. Is the number copied exactly from the authoritative shipment document rather than a marketplace message or manually retyped source?

There is no verified DSV-wide rule in the accepted evidence saying that every newly created number becomes publicly visible after a fixed number of hours. Do not invent an activation SLA.

If the DSV-specific route and identifier checks are complete and the lookup still fails, continue with Tracking Number Not Found. If a valid active record exists but stops changing, use Tracking Not Updating instead.

Who should act: DSV, Schenker, the sender, the account holder, the final carrier or customs?

Tracking visibility and action authority are not always held by the same actor.

A recipient may be able to see a DSV event but still lack authority to change the booking. A DSV customer may have account-level options that a public recipient does not. A final carrier may control the current delivery leg. A customs authority or broker may control an administrative dependency. A merchant or marketplace may own a commercial remedy even though DSV owns transport evidence.

Use the requested action to select the actor:

DSV's Sweden operation provides a useful scoped example of why role matters: a 2026 notice tells recipients who want shipment changes to contact the sender. That is evidence for that Swedish context; it is not a global rule that recipients can never ask DSV about changes.

Likewise, DSV's eClaims service is a separate claim workflow for eligible users. Its existence does not establish that every recipient worldwide is the claimant, that every service has the same filing deadline, or that filing guarantees compensation.

For generic responsibility routing, use Who Should I Contact About a Package? or the Official Carrier Support Directory.

The next decisive evidence depends on the state you already have

The most useful tracking question is often not “where is it?” but what stronger evidence would change the current conclusion?

This keeps weak evidence from silently becoming a stronger physical conclusion.

If a shipment has a long unexplained gap after the correct system and carrier are established, the problem has left DSV-specific identity classification. Use Is Your Package Lost or Just Delayed? or the more specific tracking-status/problem guide that matches the latest evidence.

DSV tracking FAQ

Is Schenker tracking the same as DSV tracking now?

No—not as a current tracking instruction. DSV acquired Schenker, but DSV still presents separate Track DSV shipment and Track Schenker shipment routes and tells Schenker customers to keep using Schenker systems until migration notification. This is a high-volatility 2026 boundary and should be rechecked as integration progresses.

Can I enter a DB Schenker or STT number in DSV tracking?

Do not assume that you can. Current Spain guidance documents STT in the Schenker/Connect transition lane, while the global DSV public tracker uses the generic label Enter ID number and does not publish a global STT compatibility rule. Use the lane that issued the identifier.

What is a DSV tracking number?

DSV uses several identifier classes across different systems. Current first-party documentation includes shipment IDs, booking IDs/numbers, references and service-specific identifiers. The right question is which identifier the current DSV service or system expects, not whether the value matches a third-party “DSV format.”

Does DSV have one tracking-number length or prefix?

No universal first-party rule has been established for the global DSV tracking job. Official DSV materials show multiple identifier classes and different example shapes. Do not use one prefix or length as a worldwide validity test.

Does a DSV booking number mean DSV has received my freight?

No. A booking/reference can exist before physical carrier acceptance. DSV's own authenticated workflows document pre-carrier/draft and confirmation distinctions. Look for item-level acceptance, pickup or movement evidence if physical possession is the question.

Why does my DSV shipment show another carrier?

That can be legitimate in a DSV-managed transport flow. DSV XPress documents a final-carrier layer and Carrier tracking ID, while U.S. LTL material describes underlying carrier selection with centralized DSV/myTMS visibility. Do not assume this architecture applies to every DSV shipment; use it when the actual record names another carrier.

If another carrier number appears, does that carrier already have the shipment?

Not necessarily. A carrier assignment or tracking identity can exist before the carrier records physical receipt. The downstream carrier's own acceptance or movement event is stronger evidence for its current handling.

Why can I see more in myDSV than in public tracking?

DSV distinguishes public high-level visibility from richer authenticated customer features. Depending on the workflow, myDSV can expose more detailed shipment information, scan logs, notifications and POD access. Those private/customer capabilities are not evidence that the anonymous public tracker exposes the same fields.

Does customs release mean the shipment is moving?

Not by itself. Customs release is an administrative state. A later transport, acceptance or carrier event is separate evidence of physical movement.

What does it mean if DSV says the number is not found?

It means the queried DSV system did not return the expected record for that lookup. That alone does not prove fake shipping, cancellation, loss or absence of physical handling. Recheck DSV versus Schenker, the identifier's source, authenticated visibility and any final-carrier record before drawing a stronger conclusion.

Can a recipient change a DSV shipment?

It depends on the service, country, booking authority and requested change. Do not infer control from visibility. For example, current DSV Sweden guidance tells recipients seeking shipment changes to contact the sender; that is a scoped Swedish rule, not a universal worldwide rule.

Can I get proof of delivery from DSV?

DSV describes POD visibility within relevant myDSV customer workflows, but that does not mean every public lookup or every recipient has the same access. If delivery evidence is the main issue, use How to Get Proof of Delivery, a Delivery Photo, or a Signature.

The DSV record says delivered, but I do not have the shipment. What now?

The dominant job is no longer DSV identifier classification. Use Package Says Delivered but I Did Not Receive It to reconstruct delivery evidence and the next responsible actor.

Can I file a claim through DSV tracking?

Tracking and claims are separate workflows. DSV provides eClaims for eligible claim users/customers, but the public tracking record does not by itself establish who has claim standing, which deadline applies, or whether compensation will be approved. Use How to File a Package Claim for the generic claim decision model or the relevant official DSV claim route for the actual shipment.

What 11Tracking can and cannot do

11Tracking can help you interpret the tracking information available to you, distinguish DSV from Schenker and other carrier records, and point you toward the relevant official system or Package Help guide.

11Tracking cannot:

• access your private myDSV, Schenker, myTMS, Webtracker or eClaims account;
• access or provision DSV APIs;
• create, backfill or force a DSV, Schenker or final-carrier scan;
• confirm physical possession when the available evidence does not;
• change a booking, address, consignee or delivery instruction;
• contact DSV, Schenker, a final carrier, sender, broker or customs authority on your behalf;
• clear customs;
• retrieve private POD that you are not authorized to access;
• file, decide or guarantee a claim;
• force a merchant refund or replacement;
• guarantee pickup, movement, tracking updates or delivery.

Keep shipment references, account credentials, identity documents, customs documents, one-time codes and payment data in the official systems that require them. Do not send private shipment or account credentials to 11Tracking.