Outbound System Architecture: The Seven Layers

This is the builder's view of the work described in what GTM engineering is. If you are looking for the Clay-specific build, see the Clay outbound workflow.

In short

• Layers, not tools. The same seven layers exist whether you use Clay and n8n or a spreadsheet and a VA.
• Every handoff is a contract: what data must be present, in what shape, for the next layer to work.
• Suppression is a layer-four decision, not a sending-tool setting.
• Layer five is now compliance. Google and Yahoo publish explicit authentication, unsubscribe and spam-rate requirements.
• Feedback closes the loop back into the definition layer, or the system just repeats itself louder.

The seven layers

Layer 1: Definition

Everything downstream inherits this layer's mistakes. It holds four artefacts:

• The ICP, written as filters a machine can apply: industry, size proxy, geography, technology, structure. "Companies that value quality" is not a filter. "Lending businesses with 8 or more branches in the US Southeast" is.
• Why now — the trigger that makes this month different from last month: a hire, a funding event, a new location, a job posting, a renewal window.
• The offer, in one sentence tied to a number the buyer already tracks.
• The never list: existing customers, open opportunities, past opt-outs, competitors, active partners, anyone a colleague is already working.

Write the never list first. It is easier to add than to apologise for.

Layer 2: Sourcing

Sourcing produces candidate records. The only architectural requirement is that every record carries where it came from and when, because six weeks later you will need to know whether a bad batch came from one source or all of them.

Three patterns, in increasing order of quality: static list purchase (fast, degrades immediately, no refresh path); query-based sourcing (filters you re-run, so the list regenerates); and signal-based sourcing, where records enter when an event fires — a posting appears, a location opens, a technology changes. Only the third stays alive by design.

Layer 3: Enrichment

Enrichment answers two questions: is this record real, and what do I need in order to route and to write. The discipline is restraint — every call costs money and adds a field someone must maintain.

The rule that keeps costs sane: filter, then enrich, then filter again. Qualify on the data you already own, enrich only survivors, and stack providers cheapest-first so the expensive one only runs when the cheap one missed. That is the idea behind waterfall enrichment.

Insist on two properties for every enriched field:

• Provenance — which provider said this, and when.
• Confidence — verified, probable or guessed. A phone number with no confidence flag gets dialled as if it were certain.

Layer 4: Decisioning

This is where a list becomes a plan. Four decisions happen here, in this order:

1. Suppress. Apply the never list. This runs before scoring, because a suppressed account should not consume scoring or enrichment budget.
2. Score. Fit and timing, kept separate. A perfect-fit account with no trigger is a nurture; a mediocre-fit account with a strong trigger is a call today. Mixing them into one number hides the reason. More on the mechanics in lead scoring explained.
3. Route. Owner, territory, channel, and the queue it lands in.
4. Prioritise. How many records per rep per day, and in what order.

Suppression belongs here, at the system level, not inside a sending tool. A suppression list that lives in one sequencer protects that sequencer's campaigns and nothing else. Read it from the CRM, which should be the system of record — see CRM architecture.

Layer 5: Infrastructure

This layer used to be a preference. It is now a published requirement, and the rules are specific enough to build a checklist from.

Google's email sender guidelines state that all senders must set up SPF or DKIM for their sending domains, use TLS for transmission, keep valid forward and reverse DNS (PTR) records for sending domains or IPs, format messages to RFC 5322, and keep spam rates reported in Postmaster Tools "below 0.10%", while avoiding "ever reaching a spam rate of 0.30% or higher" (Google).

For senders of 5,000 or more messages a day to personal Gmail accounts, the same guidelines add: SPF and DKIM, a DMARC policy for the sending domain (enforcement may be set to none), alignment of the From: header domain with either the SPF domain or the DKIM domain, and one-click unsubscribe for marketing and subscribed messages using the List-Unsubscribe-Post: List-Unsubscribe=One-Click and List-Unsubscribe: <URL> headers, plus a clearly visible unsubscribe link (Google).

Yahoo's sender best practices align closely: SPF or DKIM at minimum for all senders; both SPF and DKIM for bulk senders; a DMARC policy of at least p=none that passes; From: alignment with the SPF or DKIM domain; a DKIM key of at least 1024 bits; a functioning list-unsubscribe header supporting one-click, with RFC 8058's POST method "highly recommended"; a visible unsubscribe link; unsubscribes honoured within two days; and spam rate kept below 0.3% (Yahoo).

RFC 8058 is the underlying standard. Titled Signaling One-Click Functionality for List Email Headers, it specifies that the List-Unsubscribe-Post header "MUST contain the single key/value pair 'List-Unsubscribe=One-Click'", so a receiving system can perform an HTTPS POST to the unsubscribe URI and complete the request without further interaction (RFC 8058).

Two more operational points from Google's guidance: increase sending volume slowly, starting low with engaged users and raising it over time, and if you send from multiple IP addresses, use a different IP address for each message type (Google).

The deliverability floor checklist

Not a growth tactic. The floor you must be standing on before volume is even a conversation.

• [ ] SPF and DKIM published for every sending domain
• [ ] DMARC record present (p=none is enough to satisfy the published requirements)
• [ ] From: domain aligned with the SPF or DKIM domain
• [ ] Valid forward and reverse DNS for sending domains or IPs
• [ ] TLS on transmission
• [ ] List-Unsubscribe + List-Unsubscribe-Post one-click headers, plus a visible unsubscribe link
• [ ] Unsubscribes processed within two days
• [ ] Postmaster Tools connected and spam rate watched against the 0.10% / 0.30% lines
• [ ] Volume ramped gradually; message types separated by IP where multiple IPs are used

If you also run phone or SMS channels, the equivalent registration and consent rules for those channels are separate and must be cleared before any sending, not after.

Layer 6: Execution

Now, and only now, copy and cadence. Architecturally, three things matter more than the words:

• Channel assignment is a decision, not a habit. Email, phone, LinkedIn and voice each have different cost, latency and consent profiles. MitHub's pioneers have built AI voice campaigns that ran across 28 live branches of a multi-location lending business, including a 10-branch pilot with 13,159 AI calls — voice at that scale is an architecture problem (routing, transfer, recording, compliance) long before it is a script problem.
• Personalisation should read from fields, not from vibes. If the message needs a fact, that fact is a required field in the handoff contract from layer three. If it is missing, the record does not send — it goes to an exception queue.
• Cadence is a budget. Contacts per account per quarter is a finite resource shared across marketing, sales and partners. Without a shared cap, three teams "personalise" the same person into unsubscribing.

Layer 7: Feedback

An outbound system without a feedback layer is a broadcast. This layer does four things:

1. Classify every reply (interested, not now, wrong person, unsubscribe, hostile) and write it back to the record.
2. Write outcomes to the CRM as structured fields, not free-text notes.
3. Report by cohort: accounts sourced in March, their contact rate, reply rate, meeting rate, and what closed.
4. Return the learning to layer one. Which ICP filter predicted a meeting? Which trigger was noise?

Clay's guide makes the same point about GTM work in general: measure success by outcomes such as meetings booked and hours saved, not by tasks completed (Clay). In outbound, "emails sent" is the easiest number to move and the least informative.

Handoff contracts

The part most teams skip. A contract states what must be true for a record to cross a layer boundary. Write them down once and silent failures become loud.

A record that fails a contract does not silently disappear. It lands in an exception queue a human reviews. Exception volume is itself a metric: if 30% of records fail a contract, the problem is upstream.

Three gates before you increase volume

Volume multiplies whatever the system already is. Before turning it up, pass all three:

1. Quality gate. Pull 25 records at random from the last batch and check them by hand. Right company, right person, right claim in the message, suppression respected. If more than a couple are wrong, volume will multiply the error.
2. Infrastructure gate. Every box in the deliverability floor checklist ticked, and spam rate trending under the published thresholds, not just under them once.
3. Capacity gate. Somebody can handle the replies, fast. Outbound that generates responses nobody answers destroys more pipeline than it creates — the same logic as speed to lead on the inbound side.

The four failure signatures

Diagnose by symptom, then look at the layer that owns it.

That last row is the expensive one, and it is invisible unless layer seven reports by cohort all the way to closed-won. It is also why MitHub teaches following the money backwards before building anything: start at the payment, trace the decision, the conversations and the first contact, and only then design the machine that produces more of them.

Build it in this order

Not layer one to seven. Build the spine first, then widen it.

1. Definition on one page, including the never list.
2. Infrastructure to the floor checklist — before a single send.
3. A 50-record slice through sourcing, enrichment and decisioning, inspected by hand.
4. Execution for that slice only, one channel.
5. Feedback, even if it is a spreadsheet, before you scale.
6. Then widen sourcing, add channels, and automate the exception queue.

A 50-record system that reports its own results beats a 50,000-record system that cannot tell you which cohort produced the one deal. To turn this into proof of work, the six free chapters of the Faculty of Revenue Reverse Engineering walk from diagnosis to a published case study.