How WarmySender verifies InMail delivery (and what to do if your daily cap shows the wrong number)
If your dashboard says an InMail was sent but you can't find it in your LinkedIn Sent folder — or if your campaign shows 'Daily limit reached' when you know you haven't actually sent that many — this guide explains how WarmySender verifies InMail delivery, why InMails sometimes show as queued but don't deliver, and what's happening when your cap counter shows the wrong number.
Why InMails sometimes show as queued but don't deliver
A LinkedIn InMail can fail to deliver for reasons that look identical to success at first glance:
- Recipient eligibility — InMail can only be sent to recipients who allow InMails (most Premium / Sales Navigator / Recruiter members do; Free members can opt in via Open Profile). If a recipient has tightened their settings, the send is rejected.
- Sales Navigator credits — Each InMail consumes one Sales Nav credit. If your account is out of credits, the send is rejected even though every other check passes.
- Open Profile fallback — If you're sending via the 'classic' InMail API and the recipient has Open Profile enabled, the send goes through without consuming a credit. If their Open Profile is off, the send needs a credit and falls back to standard InMail rules.
- Rate limits and ramp — LinkedIn's per-account InMail limits change with your account type and how long you've been sending. Sales Nav veteran accounts can typically send up to 50 InMails per day; new accounts ramp gradually from much lower numbers.
- Connectivity gaps — A recipient on an account in transit, or a temporary LinkedIn-side issue, can return a soft failure that looks like 'sent' from our side.
In every case above, LinkedIn can accept the send request and still never create the conversation on the recipient's side. WarmySender's job is to tell those apart.
How we verify delivery
When WarmySender sends an InMail through our LinkedIn integration partner, a genuinely successful send comes back with a conversation identifier — the new InMail thread on LinkedIn's side. That conversation is the proof a real thread now exists for the recipient. No conversation, no delivery.
The delivery gate works like this:
1. WarmySender sends the InMail.
2. LinkedIn responds, and we look for the new conversation in that response.
3. If a real conversation comes back, we treat the send as successful: the send is recorded, the dashboard counter advances, your prospect is marked as messaged, and the thread is linked into your unified inbox.
4. If no conversation comes back — the silent-drop signature — we treat the send as failed: nothing is recorded, no counter advances, and the prospect is NOT marked as messaged. The send is classified as a phantom and your daily cap is preserved.
This is our proof-of-delivery contract. It guarantees that every number on your dashboard reflects a real conversation that exists on LinkedIn, not a request that succeeded on paper and quietly bounced.
A practical example: 18 days of phantom InMails caught by the delivery gate
On May 2, 2026 we found a bug where we were reading the wrong part of LinkedIn's response, which made every InMail look like a silent drop — 1,104 InMail sends across the platform over 18 days had no conversation attached. The new delivery gate (deployed earlier that morning) correctly refused to count any of them. We deployed a follow-up fix the same day so real conversations are recognised again and real InMails count.
The key takeaway: the gate did its job. Even while the underlying read was broken, the platform refused to inflate your dashboard numbers with phantom sends. That's the design — your dashboard tells you what reached LinkedIn, not what we hoped reached LinkedIn.
What happens if your daily cap shows the wrong number
The daily cap on each LinkedIn campaign counts how many sends have happened today. If the counter is inflated by historical phantom sends (recorded before the delivery gate landed), it can read 40/40 even though zero real InMails have actually been sent today.
We shipped a companion fix on May 2, 2026 to handle this exact case:
- Every historical phantom InMail (1,104 across the platform, going back to mid-April) is flagged as a phantom. Nothing is deleted; the records are kept for audit, refund eligibility checks, and accurate support answers.
- The daily-cap calculation now subtracts flagged phantoms from your per-campaign cap. Before the fix, today's count was simply every InMail recorded today; after the fix, it is that total minus the phantoms. On a clean campaign with no phantoms, the number is identical.
If your campaign was reading 40/40 before the fix because of 40 phantom rows, post-fix it reads 0/40 immediately. Real ramp budget is intact: phantoms cost no LinkedIn-side capacity, so freeing the cap mathematically restores the actual day's budget without raising LinkedIn risk.
Monitoring and what's coming
Every InMail send is now recorded together with whether a real conversation came back, and every daily-cap calculation records how the phantom exclusion affected your specific campaign. That gives support an exact answer whenever a number looks off.
If your counter still looks wrong and you'd like it reset to the true value, reply to your support thread and we'll reconcile it by hand. We only do that after confirming real InMails are being recognised again, because lowering a cap counter is otherwise something we deliberately never do automatically.
Frequently asked questions
Q: Why didn't I see a failed-delivery alert before today?
A: Before May 2 we recorded a successful send whenever the request itself came back without an error, whether or not a conversation was actually created. The delivery gate is new — it landed on the morning of May 2, 2026, and the follow-up fix that afternoon corrected which part of LinkedIn's response we read.
Q: Are my refunds for the phantom period automatic?
A: Refund eligibility is reviewed manually for the 18-day phantom-affected period. If you sent InMails between mid-April 2026 and May 2, 2026 and consumed Sales Nav credits without messages reaching recipients, contact support with your account email and we'll review.
Q: Will this happen again?
A: We added two automated guards alongside the fix: a test that pins the correct reading of LinkedIn's response, and a build-time check that fails if any future code path forgets to look for the new conversation. The same approach already caught two earlier families of regression — defense in depth is now standard wherever we depend on a specific piece of LinkedIn's response.
Q: What's the long-term plan for verifying delivery?
A: We're extending the same delivery gate to connection invites and follow-up messages in the next release. Same verification, same proof-of-delivery contract. The eventual invariant: zero events on the dashboard that don't correspond to a real LinkedIn-side conversation or relationship change.