The marketplace says it sent 40 leads and your CRM has 31

The missing leads were lost at one of 4 hops: the vendor never sent them, the mail was sent but never landed anywhere a human or parser reads, the parser received the payload and rejected it, or the lead was parsed and deduplication folded it into a record that already existed. From inside the CRM those 4 outcomes are indistinguishable — in every one of them, there is simply no new row. So the first job is not a fix. It is a reconciliation that says which hop.

Do this before you open a ticket with the vendor or change a setting in the CRM. A large share of these investigations end with the counts agreeing and the disagreement turning out to be a timezone offset or a difference in what each side calls a lead.

Prove the gap is real, in one closed window

1. Pick a closed 24-hour window that ended at least 48 hours ago. Live windows guarantee an argument about leads still in flight.
2. Export the vendor's sent log for that window: lead id, request timestamp, customer name, email, phone, and the destination address it was sent to. If the portal only gives you a count, ask for the detail — a count alone cannot be reconciled with anything.
3. Export the mail accept log for that destination mailbox. Google Workspace Email Log Search and the Microsoft 365 message trace both return sender, recipient, subject, timestamp and final disposition.
4. Export CRM leads created in the window with source, created-at, phone and email.
5. Normalise every phone number to its last 10 digits and join the 3 exports on phone plus request timestamp within ±10 minutes. The vendor's lead id almost never survives into the CRM, which makes phone the only key present in all 3 systems.
6. Write down 4 numbers: sent, accepted, parsed, visible. The first pair that disagrees is your hop.

The four hops, and the evidence that confirms each

The order matters. The first three are silent to everyone, the fourth is silent only to the person who would have followed up, and the fifth is not your problem to fix but is the one people assume first.

Quarantine: accepted is not delivered

A vendor's log that says "delivered" usually means the receiving server returned an SMTP 250. That code means the server took responsibility for the message. It says nothing about which folder the message ended up in, and quarantine is a folder.

The mechanism behind most silent quarantining is worth understanding because it decides the fix. Several lead providers put the shopper's own address in the From header so that hitting reply reaches the shopper directly. That message is then sent from the vendor's infrastructure while claiming to be from a consumer mailbox domain, so it fails SPF and DKIM alignment for that domain. Where the domain publishes a DMARC policy of quarantine or reject, a conforming receiver does exactly what it was told. Nothing errors. Your store sees an empty lead queue and the vendor sees a clean delivery report.

• Confirm it. Search the quarantine directly for the window, filtered by recipient rather than sender, and look at the disposition column rather than the delivery column.
• Fix it properly. Ask the vendor to send from their own authenticated domain with the shopper in Reply-To. That is the configuration that both delivers and preserves the reply behaviour.
• Allow-list by authenticated sending domain, never by From address or subject line. A subject-line rule is a rule an unrelated sender can satisfy tomorrow.
• Check bounce handling too. A mailbox over quota or a retired alias produces a 5xx the vendor may still summarise as an attempted send.

The payload arrived and the parser refused it

Here the message is sitting in the parser mailbox and no lead exists. Dealership CRMs ingest lead email as ADF, and the document has to survive the journey intact. Four things break it, in rough order of frequency.

• The XML is not where the parser looks. Some vendors inline the document in the message body, others attach it as a file. A mail rule that converts messages to plain text, or a security product that strips attachments, removes the payload while leaving a message that looks perfectly normal.
• Auto-forwarding. Forwarding re-encodes the MIME structure and can wrap the document in quoted-printable with soft line breaks inserted mid-tag. If the parser mailbox is fed by a forward from a shared inbox, take that hop out of the path before investigating anything else.
• Fields the document must carry are missing or unparseable — a request date that is not ISO 8601 with an offset, a vehicle with no year, make or model, a customer with neither email nor phone. Many parsers reject the whole document rather than the field.
• Encoding. One accented surname or curly apostrophe in a document declared as us-ascii is enough, and it fails for exactly the leads whose names are least common.

Dedupe merged it and told nobody

This is the one hop where the lead is not lost. It was received, parsed and accepted, and the CRM decided it already had this person — so it appended an activity instead of creating a lead. Correct behaviour, wrong outcome, and no notification fired because notifications hang off lead creation.

Marketplaces make the underlying matching harder on purpose. Masked relay addresses mean the email is unique every time, and withheld numbers mean the phone is sometimes absent, which pushes the CRM onto name plus vehicle — the worst available key. The full matching-key policy, and the merge-safety rule that stops you overcorrecting into three salespeople texting the same shopper, belongs on that page rather than this one.

Confirm a merge by pulling record history for the matched customer at the request timestamp, and by comparing the count of activities carrying that lead source against the count of lead records for the same source and window. A large gap between those two numbers is a merge signature. Where the merge lands on a record owned by someone who has left, the lead is now invisible in exactly the way described in the lead assigned in nine seconds to a salesperson on holiday — present, owned, and unread.

A merged lead is not a missing lead. It is a lead sitting in the building with nobody assigned to notice it, which is worse, because the counts eventually agree.

The same shape shows up elsewhere in the store whenever one real thing lives under two identifiers, or two things share one — the parts-counter version, where the system says two in stock and the bin is empty, is the same identity problem with a different consequence.

Fix in this order, then instrument it

1. Restore delivery first. Nothing downstream matters while mail is being quarantined, and a delivery fix is usually a same-day change.
2. Give every vendor its own destination address. A sub-addressed alias per source makes routing provable per source and turns the next count argument into a filter rather than an investigation.
3. Store the raw payload with its received timestamp, and expose a per-source daily count from it rather than from the CRM.
4. Alert on absence, not on errors. A source that normally delivers 6 to 20 leads a day and delivers zero between 09:00 and 15:00 is the signal worth waking someone for; a weekly report finds the same thing 6 days late.
5. Alert separately on leads suppressed by a merge, with the matched record id in the alert, so the merged-but-unread case has an owner.

Two things are deliberately out of scope here. Whether you should be receiving leads as email at all rather than through a CRM API is a separate decision, covered in the integration cluster. And once the counts do agree, the next number that will not is appointments set against customers who arrive, which is a different investigation entirely: the appointment was confirmed twice and the customer still didn't come. The rest of this silo sits under lead response and follow-up, and the wider systems view is in our automotive retail and aftermarket work.

• lead delivery
• CRM integration
• ADF
• email deliverability