Deliverability is the infrastructure problem that kills more outbound programmes than bad copy or wrong targeting. A business can have a well-defined ICP, compelling sequences, and a good product to sell — and still get near-zero results because the emails are landing in spam.
The frustrating thing about deliverability problems is that they’re mostly avoidable with proper setup, and mostly invisible until significant damage has already been done. By the time reply rates are inexplicably low and open rates have collapsed, the domain reputation has already been eroded. Recovery takes weeks.
This is what you need to get right before sending a single cold email through Apollo.
Why deliverability matters more than you think
Email service providers (Gmail, Outlook, and others) use a combination of technical signals and engagement data to decide whether a message goes to the inbox, spam, or is rejected outright. The main factors:
Domain reputation. Your sending domain has a reputation score with email providers, built from the behaviour of emails sent from it. High bounce rates, spam complaints, low engagement — all damage reputation. Good reputation is built slowly. Bad reputation can be built quickly.
IP reputation. The server IPs used to send email also have reputation scores. Apollo manages the sending infrastructure, but your domain reputation is your own and follows you regardless of which tool you use.
Engagement signals. Providers use inbox engagement (opens, replies, moves out of spam) as a positive signal. Low engagement from a sending domain signals that the emails aren’t welcome — which accelerates the drift toward spam.
Technical authentication. SPF, DKIM, and DMARC records tell receiving servers that you’re authorised to send email from your domain and that the email hasn’t been tampered with. Missing or misconfigured authentication records are both a spam signal and a deliverability failure.
The implication: everything you do with your sending setup either builds or erodes your ability to reach the inbox. Getting the foundation wrong means the sequences you spend time building will never be seen.
Sending domains: don’t use your primary domain
The first and most important decision: never run cold outbound from your primary domain (yourcompany.com).
Your primary domain is used for all your regular business email — internal communications, client-facing emails, support, billing. Its reputation is tied to everything your business does online. Running high-volume cold outreach from it puts that reputation at risk. If a cold email campaign triggers spam complaints or bounces, the damage extends to all the other email your business sends.
What to do instead: Register one or two sending domains specifically for outbound. These should be close variations of your main domain:
- outbound.yourcompany.com
- mail.yourcompany.com
- yourcompanymail.com
- yourcompanyhq.com
Set up these domains to redirect to your main website (a simple 301 redirect) so they don’t look like throwaway domains to recipients who check. Use these for all cold outbound, nothing else.
If a sending domain gets flagged or damaged, you can retire it and create a new one. Your main domain remains clean.
DNS configuration: SPF, DKIM, and DMARC
Every sending domain needs three DNS records properly configured before any email is sent. Skipping this isn’t an option — missing records mean your emails either bounce or go directly to spam at major providers.
SPF (Sender Policy Framework). An SPF record tells receiving servers which services are authorised to send email on behalf of your domain. Add a TXT record to your domain DNS that includes Apollo’s sending servers. Apollo provides the exact record value in their deliverability settings.
Example format: v=spf1 include:sendgrid.net include:[apollo-servers] ~all
DKIM (DomainKeys Identified Mail). DKIM adds a cryptographic signature to your outgoing emails, allowing receiving servers to verify that the message wasn’t tampered with in transit. Apollo provides a DKIM record to add to your DNS. It’s a CNAME or TXT record pointing to Apollo’s DKIM infrastructure.
DMARC (Domain-based Message Authentication, Reporting, and Conformance). DMARC tells receiving servers what to do with emails that fail SPF or DKIM checks, and gives you reporting on authentication failures. Start with a lenient policy and tighten it once you’ve confirmed authentication is working.
Example starting policy: v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com
After setup, use an authentication checking tool (MXToolbox or similar) to verify all three records are configured correctly before warming up.
Mailbox setup and limits
How many mailboxes per domain: limit to two to three mailboxes per sending domain. With one sending domain and three mailboxes, you have capacity for 240–300 emails per day post-warmup — enough for most small team outbound programmes. Spread risk across two or three sending domains.
Separate mailboxes from real people: in most cases, your cold outbound mailboxes should not be the same mailboxes your team uses for personal email. The sending patterns of a cold email mailbox (consistent volume, same-format messages) are different from a personal email mailbox. Some businesses use alias mailboxes (firstname@domain.com pointing to a real inbox) while the outbound volume goes through separate sending mailboxes.
Naming conventions: use realistic first-name-last-name format. ben@outbound.yourcompany.com reads more credibly than sales@outbound.yourcompany.com. Cold email recipients will check who sent them an email.
Mailbox warm-up: what it is and why it’s non-negotiable
A new mailbox has no reputation. Receiving servers treat new mailboxes sending high volumes of email immediately as suspicious — because that’s a pattern associated with spam.
Warm-up is the process of building sending reputation on a new mailbox before using it for cold outbound. Specialised warm-up tools (Instantly, Warmup Inbox, Lemwarm) do this by simulating inbox engagement: sending emails between warmed mailboxes in their network, and responding to them, building a pattern of legitimate activity.
Warm-up duration: minimum four to six weeks. Some operators warm up for eight weeks for higher confidence.
Warm-up volume: warm-up tools start with very low daily volumes (5–10 emails per day) and ramp gradually.
What to avoid during warm-up: don’t send any cold outbound sequences from a mailbox that’s still warming up. The warm-up signals and the cold email signals cancel each other out.
Continue warming after launch: keep the warm-up running even after you start sending sequences. A small ongoing warm-up volume (10–20 emails per day) maintains mailbox health alongside your cold sending.
Sending limits in Apollo
Apollo allows you to set per-mailbox daily sending limits. These defaults are often set too high. Recommended limits:
- During warm-up: 30–50 emails per day per mailbox
- Post-warmup, first 30 days of sequences: 60–80 per day
- Established mailbox, six months+: up to 100 per day maximum
Going above 100 emails per day per mailbox significantly increases risk. The volume signal matters to spam filters regardless of your content.
Sequence step intervals: configure step intervals of at least two days, preferably three. Daily follow-ups look like spam cadences — because by volume standards, they are.
Randomise sending times: Apollo can send emails across a defined window (e.g., 9am–5pm) rather than batching them. Sending 100 emails at exactly 9:00am is a spam pattern. Distributing them throughout the day is a human pattern.
Monitoring and warning signs
Once you’re sending, watch these metrics as early warning signals:
Bounce rate. Above 3% is worth investigating. Above 5% requires immediate attention — pause sending and check list quality and DNS records.
Spam complaint rate. Apollo surfaces this for some providers. Above 0.3% is a warning. Above 0.5% requires action.
Open rate collapse. If your open rate drops significantly over two to four weeks with no messaging changes, deliverability is likely degrading. Check placement by sending test emails to Gmail and Outlook accounts and verifying they hit the inbox.
Reply rates below 0.5%. Not always a deliverability signal (sometimes it’s the copy), but worth investigating placement if combined with low open rates.
Tools like GlockApps or Mail-Tester allow you to test inbox placement before a sequence goes live — worth using when launching a new mailbox or a new sequence.
The deliverability foundation isn’t glamorous work, but it determines whether everything else has any chance of succeeding. Sequences with bad copy can be fixed. Sequences that never reach the inbox can’t produce anything.
For the full Apollo implementation picture beyond deliverability — ICP targeting, sequence design, and CRM integration — the Apollo partner page and the Apollo setup guide cover the complete setup. And for the data layer that feeds Apollo with verified, signal-triggered contacts, the Clay partner page covers how the two tools work together.
Free resources
Four phases for removing yourself from day-to-day sales without revenue dipping.
Free download22-point pre-raise checklist and a 90-day post-raise build plan.
Free downloadScore your revenue function across 5 areas. Find the gaps before you hire.
Free download