How to Verify a Freight Broker

How this comes up in practice

A common pattern in carrier dispatch: an email arrives from a domain that differs by one character from a broker the operation has worked with before. The rate, lane, and shipper name all match what is expected. The carrier's packet goes out before anyone compares the sending domain against a prior rate confirmation. Calling the broker's main number from an older document — not from anything in the new email — is the check that would have surfaced the problem first. The domain difference is one character in a long name; the display name in the email client looks right, but the full sender address does not match. That comparison, run before responding to the new thread, is the step that changes the outcome.

The gap this workflow closes

Broker verification failures tend to occur not because the check wasn't done, but because it was done once, at the wrong point, or with the wrong question. An authority check run when first setting up a broker relationship doesn't cover loads booked six months later. A callback to a number in the current email thread doesn't confirm the sender is from the broker — it confirms whoever answered the phone. For adjacent verification steps, compare this with Broker MC Number Lookup Checklist, Broker Authority Status Explained, and Broker Bond / BMC-84 / BMC-85 Explained.

The check that matters is a comparison of the communicating party against the official FMCSA record, using a contact path that wasn't introduced in the same transaction. That's the gap: a broker name, MC number, and polished rate confirmation can all be exactly right while the person sending them has no connection to the entity they're representing.

Authority status, financial responsibility, and contact verification are separate checks because they catch different problems. A broker with active authority can have a lapsed bond. A real MC number can appear in an email from someone who has no relationship with that company. Running each check separately, close to booking rather than once during setup, is what makes the workflow complete.

What to confirm before accepting the load

Start with the broker identity shown on the load offer, rate confirmation, email signature, and payment terms.

The first decision is whether the communicating party lines up with the official broker record and a known contact path.

Documents to pull before booking

Build the working file from original records — before pickup, before payment, or before escalating a dispute. Keep each revised version separately from the original.

Signals that require a call-back

A red flag should trigger a slower review and a documented call-back. It is not a public accusation or a final finding.

Questions that need a confirmed answer

Ask questions that can be answered with a record, a known contact, or a dated instruction.

Broker verification assumptions to avoid

Avoid filling gaps with memory, old emails, or a search result that may not belong to the current transaction.

Official broker records to compare

Use official records as comparison points and save the lookup date. Official status can change, and legitimate company records can be impersonated.

When to hold the load

Escalation means preserving evidence and moving the question to the right internal, insurance, legal, law enforcement, or official reporting channel. This site does not provide legal, financial, or insurance advice.

Source Notes

FAQ