Apollo.io is the fastest way to go from "I need a list" to "first email out the door". Data, enrichment and sending are all in one tool. The price of that convenience is a shared sending infrastructure where your deliverability is partly someone else's problem — and partly yours.
If Apollo campaigns that used to work are suddenly landing in Spam, this article is the 20-minute diagnostic and fix.
The usual cause: Apollo's shared IP pool took a Spamhaus SBL hit, or your connected Google/Microsoft domain is not properly aligned for DMARC. Both are fixable. Neither is visible in Apollo's Deliverability Grade.
How Apollo's shared pool works
When you send "through Apollo", there are two modes:
- Connected Gmail / Outlook mailbox: Apollo sends via OAuth through your provider. Your domain and IP are yours. Apollo adds tracking, rotation and throttling.
- Apollo-hosted sending (mail server mode): Apollo's infrastructure sends on your behalf. The sending IP is shared with every other Apollo customer on that pool.
Most spam issues concentrate in the second mode, but the first mode has its own trap — DMARC misalignment when Apollo rewrites envelope senders for rotation.
Detecting a Spamhaus hit
A sudden drop in reply rate with no copy change is the canonical symptom. Here is the 5-minute test:
- Send a normal message through your Apollo campaign to a Gmail seed mailbox you control.
- Open the message, show original (or raw source), find the
Received:chain. - Grab the first public IP — that is your outbound relay.
- Check it against Spamhaus SBL (
spamhaus.org/ipcheck), SORBS, SpamCop and Barracuda. - Do the same for your sending domain against Spamhaus DBL and URIBL.
Any listing on Spamhaus SBL or DBL explains a large, sudden placement drop. Smaller lists (SORBS, Barracuda) matter less on their own but are worth noting.
Three settings that pull Inbox rate back up
Setting 1: custom sending domain
If you are using Apollo-hosted sending on the default shared pool, move to a custom sending domain as soon as volume justifies it. This is the single biggest lever. Your DKIM signature now ties messages to a domain you control, not the shared pool.
Practical setup:
- Register a dedicated cold-outreach domain (not your main corporate domain).
- Point MX at a mailbox provider (Google Workspace, Zoho, Outlook).
- Publish SPF, DKIM and DMARC records. Start DMARC at
p=nonewithruareporting. - Warm the domain for 3–4 weeks before running Apollo at full volume.
Setting 2: custom tracking domain
Apollo's default tracking domain is shared across customers. One bad actor can drag it onto Spamhaus DBL. Configure a dedicated CNAME (track.yourdomain.com) pointed at Apollo's tracker. Keep that subdomain at least 30 days old before running campaigns through it.
Check the tracking domain against Spamhaus DBL and URIBL monthly. Swap if listed.
Setting 3: rotation cadence
Apollo's default daily cap on a connected Gmail is 50. That is usually fine, but the cadence matters as much as the total. Spread sends across the working day, randomise the interval, and avoid the 09:00 Monday burst that every cold-outreach tool tries to schedule by default.
- Working-hours window: 9am–6pm in the recipient's timezone.
- Interval: 60–180 seconds random jitter between sends per mailbox.
- Ramp: start at 10–20/day on a new mailbox, double every 3 days up to your target.
Apollo Deliverability Grade vs real placement
Apollo surfaces a "Deliverability Grade" (A–F) per mailbox. It is a useful hygiene check — SPF/DKIM alignment, bounce rate, reputation signals. It is not a placement number. A mailbox can have a Grade A while landing 60% of its mail in Spam at Outlook.
The Grade looks at your authentication and list health. It cannot look at what Gmail's filter or Microsoft's SmartScreen actually decide at delivery time. Only a placement test can do that.
Send one of your live Apollo sequence emails to a 20+ provider seed list. You will get per-provider Inbox/Spam/Promotions breakdown, plus authentication and DNSBL status for your sending and tracking domains. No signup. Unlimited tests.
When to leave Apollo for Smartlead or Instantly
Apollo is a good fit for teams that want data and sending in one tool and are sending under ~2,000 emails/week per domain. It becomes a weaker fit when:
- You need per-inbox placement visibility (neither Apollo nor its competitors expose this — you have to test externally).
- You run 5+ sending mailboxes per campaign and need deep rotation logic. Smartlead and Instantly have more mature rotation.
- You send over ~10k emails/week. Dedicated-IP / dedicated-pool setups at larger platforms become worth the price.
- Your audience is heavily in Europe or the CIS and you need provider coverage Apollo's shared pool does not optimise for.
20-minute recovery checklist
- Test send to a Gmail seed, read full headers.
- Check outbound IP against Spamhaus SBL.
- Check sending domain against Spamhaus DBL.
- Check tracking domain against URIBL/SURBL.
- Run a 20+ provider placement test on your current sequence's first email.
- Verify DMARC alignment in received headers —
dmarc=passis the only acceptable result. - If any of the above fail: switch to custom sending domain + tracking domain, rebuild cadence, warm up for 3–4 weeks.