Protecting cold-email mailboxes with a bounce ladder, and syncing outcomes to the CRM
Two Make scenarios run alongside a cold-email sending platform. Every night one works out each sending mailbox's rolling seven-day bounce rate, moves its daily sending limit up or down a ladder, tags mailboxes at risk and switches warm-up on or off. The other, roughly hourly, writes replies, interest, bounces and unsubscribes back onto the matching CRM leads.
Where this applies
Outbound teams that send cold email from many mailboxes and want deliverability protected, and replies reflected in the CRM, without anyone watching a dashboard.
- rolling bounce window
- 7-day
- nightly ladder runs, no errors
- 33
- outcome-sync runs, no errors
- 648
The problem
Cold email goes out from many mailboxes across several domains, and a mailbox that bounces too much damages the domain behind it. The sending platform reports bounce rates, but someone has to look every day and lower the limits on the mailboxes going wrong before the damage is done.
Meanwhile the outcome of every send lives in the sending platform, and the sales team works from the CRM. A lead who replied, bounced or asked not to be contacted again has to show that in the CRM, or the next campaign writes to them anyway.
What we built
A rolling window, kept by Make
The nightly scenario pages through every sending account and its warm-up detail through the platform's API, reads each mailbox's bounce history from a data store and computes its bounce rate over the last seven days. Tonight's figures are saved back as a new record, so the window rolls forward one night at a time without depending on the platform's own reporting period.
A ladder, not a switch
The bounce rate sets the mailbox's step on a ladder of daily sending limits: a mailbox that bounces steps down and sends less, one that recovers steps back up. Mailboxes at risk are tagged, and warm-up is switched on or off to match. A gradual ladder protects the domain without taking a mailbox out of service for one bad day.
Each write fails soft
Every change pushed to the platform (the limit, the warm-up setting, the tags) has its own Resume handler, so one mailbox the API refuses does not stop the others being adjusted.
Outcomes back to the CRM
Roughly every hour a second scenario reads recent leads and replies from the sending platform and finds each lead in the CRM, and a router with about seven routes writes the right status: replied, interested, bounced, unsubscribed and the rest. Every change is logged in a data store, and a lead the CRM doesn't know is logged as unmatched rather than created.
The outcome
The ladder ran on 33 nights between 18 September and 20 October 2026 without an error. Its sender-history data store held 4,291 records on 21 October.
The outcome sync ran 648 times between 27 September and 21 October, with no errors. It is the sixteenth version of the scenario.
Where it stops
The ladder acts once a night, so a mailbox that starts bouncing in the morning keeps its limit until that night's run. It changes limits, tags and warm-up; it does not pause campaigns or clean lists. The outcome sync covers one brand's sending account, and leads the CRM doesn't know are logged, not added. Copies of the ladder for the other brands and a daily mailbox report are not described.
Built with
- Make.com
- EmailBison
- Salesforce
- HTTP API
- Make data store
Patterns used
- Rolling window in a data store
- Ladder instead of a kill switch
- Resume per write
- Log unmatched, don't create
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Have something shaped like this?
If any part of the above resembles a problem you are living with, a short call is the fastest way to find out whether it is the same problem underneath.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no