An outbound stack is a list of jobs with one owner each, not a list of tools. Every stack that has to be untangled later failed the same way: two systems ended up owning the same job, and nobody could say which one was right. This page is the opinionated version of the stack question. Six jobs, who should own each, what the official documentation actually commits to, and what to leave out in 2026.
Buy the sending domain first, one sequencer second, and one enrichment writer third. Give every job exactly one owner, and give the write into the CRM exactly one writer. Most of what people call a stack problem is two tools with permission to change the same field.
The tools in this category have converged on features and diverged on governance, which is where the decision actually lives. Who may create a record, who may send from your domain, who holds the activity history, and who throttles the volume are four different questions, and the answers are set in permission scopes and sequence settings rather than on pricing pages.
What does an outbound sales engagement stack actually have to do?
Six jobs, and they are easier to separate than to combine.
The reason to write these down before shopping is that vendors sell across the boundaries. A data platform will sequence. A sequencer will enrich. A dialer will score. Every one of those crossings is defensible on its own and expensive in combination, because the second owner of a job is the one that corrupts the first one's record.
Which tool should own data and enrichment?
One tool, and specifically the one whose write into the CRM you can read, scope and reverse.
The useful comparison here is not feature lists but write behaviour, and the documentation is explicit about it. Clay's HubSpot integration documentation sets out which permissions it asks for and which it asks for by default. Seven read scopes cannot be disabled, including contacts, companies, leads, owners and list reads. A second group is requested by default but can be turned off, and that group is where the risk sits: it includes write access to companies, contacts, leads and deals, list creation and editing, and bulk CRM export. A third group is available but not requested at all by default, among them custom object writes and sequence enrolment.
Two defaults in that integration are worth knowing before the first run rather than after. On the update action, Ignore blank values is on by default, so an empty value coming out of an enrichment leaves the existing field alone rather than erasing it. And Keep subdomains in Company domain is off by default, so a domain written to a company record is reduced to its root, which is usually right and occasionally destroys the distinction you were enriching for. Adding records to a list only works against static lists, because HubSpot recalculates an active list's membership from its own filters, and a row can come back with Added to list set to false when the record was already there.
Apollo sits in the same layer from the other side, as a database with engagement attached. Its outbound overview, updated on 16 October 2026, describes the suite as scores, workflows, sequences, a dialer, email tracking, meetings and analytics, and states plainly that the features support different stages and can be used independently rather than forming one required workflow. That is an unusually honest framing from a vendor, and it is also the answer to a common stack mistake: buying the suite does not oblige you to let it own all six jobs.
In practice the pattern that holds up is a staging step. Enrichment writes to properties that nothing downstream reads yet, a dedupe and a review decide what gets promoted into the fields the team works from, and only then does a record become eligible for a sequence. The enrichment waterfall build covers the mechanics of the layer itself, and account hierarchies covers the one data shape that breaks routing most often.
Which tool should own sequencing, and what does each one commit to?
Whichever one you are willing to make the single activity record. The real difference between the candidates is governance of volume, not step types.
Outreach's sequence documentation lists five step types: automatic email, manual email, phone call, generic task and LinkedIn task. Three details in that page matter more than the list. A sequence's type, steps by day interval or steps by exact date and time, cannot be changed once chosen, so a cadence built as a one-time event cannot later become a rolling campaign. The delivery schedule distinguishes calendar days from schedule days, which is why a cadence that reads as day one, two, three in the builder can land across a weekend or skip it depending on a setting most people never open. And if an email fails to send because the email provider's sending limit was reached, the sequence retries after 24 hours rather than dropping the step.
Volume control is where a dedicated engagement platform earns its seat. Outreach's sequence throttle documentation describes throttling as enabled by default, with two settings that work together: the maximum number of prospects active in a sequence at once, and the maximum number added to the first step in any 24 hour period. Prospects beyond those limits sit in a pending state and activate as room appears. The part to read before scaling is the guardrail at the end: when a very large number of prospects are stuck pending, they are eventually moved to a failed state to prevent a backlog, and recovering them means raising the limits, removing the prospects and adding them back.
HubSpot answers the same question as a CRM rather than as a platform. Its sequences documentation, last updated on 20 October 2026, requires Sales Hub or Service Hub at Professional or Enterprise and an assigned Sales or Service seat, and it states the constraint that decides most architectures: sequence emails send through a connected individual work email address, not through HubSpot's marketing email servers, and a team address connected to the conversations inbox cannot be used. Steps cover automated email, manual email task, call task, general task, and, with the LinkedIn Sales Navigator integration, InMail and connection request tasks. Tasks are assigned to whoever enrolled the contact, and there is an account level cap on how many sequences can exist at all.
Read those three together and the choice resolves itself. If the CRM is already HubSpot, the motion runs from individual mailboxes and nobody needs sequence-level throttling, a second engagement platform buys a second activity record and a reconciliation problem. If you need per-user activation ceilings, enforced daily add limits and sequence states as a governance surface, that is what the dedicated platforms are for. The pairwise questions people actually ask are answered elsewhere on this site: Outreach against Salesloft and Apollo against Outreach.
Should cold email send from the engagement platform or from separate infrastructure?
Neither, in the sense people mean. It sends from your domain and your mailboxes, and the platform is only the thing scheduling it.
Apollo states this about its own product in its email deliverability documentation, updated 26 August 2026: Apollo does not operate its own email servers, messages are sent directly through your connected email provider, and authentication is handled at the domain level rather than in the product. The same page carries three operating rules that are worth more than most stack advice. Never send cold email from your primary domain, because a sending subdomain carries its own reputation and keeps billing, support and customer mail out of the blast radius. Apollo suggests no more than 50 emails per day per mailbox, with volume distributed across multiple mailboxes or domains rather than pushed through one. And set up a tracking subdomain before sending, or turn open and click tracking off entirely.
That last one is a real fork, not a nicety. Tracking pixels and rewritten links that resolve to a shared vendor domain are a reputation input you do not control. If nobody is going to configure a tracking subdomain, the honest configuration is tracking off, and the reporting conversation moves to replies and meetings booked, which is where it belongs anyway.
Separate sending infrastructure is a volume and domain decision rather than a philosophy. The documentation for the dedicated cold email platforms that come up in this category, Instantly and Smartlead among them, was not read for this guide, so this page makes no claim about what either one does. The decision rule stands without them: if the motion needs more mailboxes and domains than your engagement platform's per-mailbox guidance supports, the sending layer separates from the sequencing layer, and the sequencer's job narrows to steps, tasks and replies. Our own deliverability build covers the domain side in detail.
What do the mailbox providers require of any sender now?
A set of things no purchase satisfies for you. These are obligations on the domain, and they apply the same way whichever platform schedules the send.
Google's email sender guidelines set two tiers for mail to personal Gmail accounts. Every sender must set up SPF or DKIM for sending domains, have valid forward and reverse DNS records for sending domains or IP addresses, use a TLS connection for transmission, keep spam rates in Postmaster Tools below 0.30%, format messages to RFC 5322, and not impersonate Gmail addresses in the From header. Senders of more than 5,000 messages a day to Gmail accounts must additionally publish SPF, DKIM and DMARC, align the From header domain with either the SPF or the DKIM domain to pass DMARC alignment, and support one-click unsubscribe with a visible unsubscribe link in marketing and subscribed messages. The same page notes that sending to personal Gmail accounts requires a DKIM key of at least 1024 bits, with 2048 recommended where the domain provider supports it.
The practical consequence for a stack decision is small and decisive. Authentication is the first purchase, and it is not a purchase. When setting up a new outbound motion the first step is the DNS records and the mailbox plan, because every tool choice downstream is reversible and a burned root domain is not.
Where do intent signals and a dialer belong?
Signals belong to job two, selection, and they are worth buying when the sequence already works and the open question is who to put in it. Buying a signal layer to rescue a cadence that nobody answers moves the problem rather than solving it, because a better-chosen recipient still receives the same email.
The dialer question usually resolves by checking what you already own. Apollo's outbound overview lists a dialer inside the suite, with individual and parallel calling, voicemail drops, call recording and transcription, and live coaching, with access depending on plan. A separate dialer is therefore a deliberate second purchase with a specific justification, usually connect rate on parallel dialling, rather than a default line item. The same logic applies to conversation intelligence: it is a coaching and analysis tool that gets bought once there are enough conversations to analyse.
What the fan-out data shows people asking about, and what the stack lists sold to them contain, are two different sets. The questions cluster on enrichment, sequencing, deliverability and dialling. The lists add signals, conversation intelligence, scheduling, and an AI agent layer. Those four are not wrong, they are later, and buying them in the wrong order is how a stack reaches eight tools before it reaches a reply rate anyone is proud of. The consolidation case is the other end of that same story.
Who owns the write into the CRM?
One system per field, decided deliberately, written down.
This is the single rule that separates a stack that survives a quarter from one that gets audited. The Clay integration documentation makes the mechanism concrete: write scopes for companies, contacts, leads, deals and lists are requested by default when you connect, and sequence enrolment scopes are off unless you reconnect and switch them on. That is a choice point, not a formality. An enrichment tool with contact write and sequence enrolment permission can create a record and start emailing it without anything in the CRM having decided that the record is real.
The pattern that holds: enrichment writes to its own properties, the CRM's own automation promotes values into the fields reps and reports read, and sequence enrolment is triggered by CRM state rather than by the enrichment tool. It costs one extra step at build time and removes the entire class of question that starts with asking which system last touched this field.
What should you leave out of the 2026 stack?
Four things, each for a stated reason.
A second sequencer. The cost is not licence spend, it is a split activity history and two reply-handling paths, which means neither system can be trusted to say whether a person was already contacted this quarter.
Open and click tracking you cannot host properly. Apollo's own guidance is to set up a tracking subdomain first or turn tracking off, and the second option is a legitimate configuration rather than a failure.
Any tool whose compliance posture you have not configured. Apollo's GDPR settings documentation, updated 6 October 2026, offers three workspace-wide toggles: forbid prospecting of EU residents, forbid email sending to them, and forbid tracking on emails sent to them, the last of which still sends the mail but omits pixels and tracking links. The same page states the limit that matters: those settings only apply when the prospect's location can be determined, and if the location cannot be resolved the controls cannot be applied. It also documents that when someone asks Apollo for removal they are deleted from Apollo's database, but records you had already saved to your workspace are not deleted automatically. Do Not Call screening covers supported national registries including the United Kingdom and Germany. Those are controls to switch on and verify, not reasons to feel covered, and the legal basis question is upstream of all of them.
A dialer before a cadence. Calls into a list that has had no email touch and no signal behind it is the most expensive way to discover that the targeting is wrong.
In what order should a team buy this?
The order is the argument of this whole page, so here it is as a sequence. Domain and mailbox plan with authentication records first, because it gates everything and cannot be undone cheaply. One sequencer second, and the default answer is the CRM you already pay for if it can hold the motion, since that keeps one activity record. One enrichment writer third, scoped to its own properties with a promotion step. Then selection, whether that is scoring you build or signals you buy. Then voice. Then analysis.
Across more than 30 engagements over the last seven years, the tool that gets ripped out is almost never the one that failed. It is the one that quietly became the second owner of a job something else already owned. The question to ask of any addition is not whether it is good. It is which of the six jobs it takes, and what you are taking that job away from.
Where this fits in the rest of the stack
If the question is which minimum set of systems a RevOps function needs rather than which outbound tools, start with the minimal RevOps stack. If the cadence itself is the weak part, the sequence design matters more than any purchase on this page. And if the enrichment layer is where the build actually starts, that is the Clay work itself.
FAQ
What is the best modern sales engagement stack for outbound GTM teams?
There is no single stack, but there is a single structure: six jobs with one owner each, which are data, selection, engagement, delivery, voice and record. Fill the engagement job with one system and give the CRM the record, then add owners for the other jobs in the order that each becomes the actual bottleneck. A stack described as a list of logos rather than a list of owned jobs is the shape that gets consolidated eighteen months later.
Do you need a dedicated sales engagement platform if you already have HubSpot?
Not automatically. HubSpot's sequences require Sales Hub or Service Hub at Professional or Enterprise with an assigned seat, and they send from a connected individual work mailbox rather than marketing email servers, which fits a small team sending from real inboxes. The case for a dedicated platform is governance of volume: per-user limits on active prospects, enforced caps on daily additions, and sequence states you can manage, which Outreach documents as throttle settings that are on by default.
How many cold emails can you send per mailbox per day?
Apollo's own deliverability guidance suggests no more than 50 per day per mailbox, with volume spread across multiple mailboxes or domains instead of concentrated in one. That is vendor guidance rather than a provider rule, but it points at the right variable. Mailbox providers set requirements rather than ceilings: Google's sender guidelines require SPF or DKIM of every sender and additionally DMARC, From header alignment and one-click unsubscribe above 5,000 messages a day to Gmail accounts, and expect spam rates below 0.30%.
Should cold email go out from your main domain?
No. Apollo's documentation is direct about using a separate outreach subdomain so that reputation damage does not reach billing, support and customer mail, while noting that a subdomain is still connected to the parent domain and so does not license bad sending. Pair that with authentication on every sending domain or subdomain and a tracking subdomain, or with tracking switched off if nobody will configure one.
What is the most common mistake in an outbound stack?
Two systems owning one job. It usually appears as two tools with write access to the same CRM fields, or as a second sequencer bought for one team, and it surfaces as an argument about whose number is right. The fix is unglamorous: decide the owner of each job and each field, scope the integrations to match, and give enrichment its own properties with a promotion step rather than direct access to what the team reads.