The Problem
Sending one DM through an automation is easy. Sending three hundred of them at once is where things start breaking, not technically, but on Instagram’s side. Fire off a broadcast too fast and the pattern looks identical to spam, same message, same timing, sent to a pile of accounts back to back. I learned this the hard way testing a broadcast that went out to everyone who’d opted in through a giveaway, and the volume alone was enough to get some messages held back.
The actual challenge isn’t building the broadcast, it’s building it so it doesn’t look automated at the exact moment it matters most.
The Solution
Instead of blasting every message the second a scenario runs, spread the send out over time, vary the message slightly between batches, and only send to people who’ve genuinely opted in, not a scraped or purchased list. Make.com handles this well once you understand the pieces, an iterator to loop through your contact list, a delay between each send, and a bit of logic so you’re not sending the exact same string of text three hundred times in a row.
Prerequisites
- Instagram account set to Business or Creator, connected to a Facebook Page
- A Make.com account with your Instagram connection already authorized
- A genuine opt in list, meaning people who commented a keyword or messaged you first, not a bought or scraped contact list
- A Google Sheet or database holding your recipient list, since looping through hundreds of contacts directly inside Make gets messy fast without one
Step By Step Scenario Breakdown
- Pull your recipient list into the scenario using a Google Sheets or database module, filtered to only include people who’ve actually opted in.
- Add an Iterator module right after, this is what lets Make step through your list one contact at a time instead of trying to process everyone simultaneously.
- Inside the loop, add your Instagram send message module, mapping in the recipient ID from your list.
- This next part matters more than anything else in this scenario. Add a Sleep module directly after the send, spacing each message out by a meaningful gap, several seconds at minimum, longer if your list is large. Sending to three hundred people over twenty minutes looks nothing like sending to three hundred people in twenty seconds, and Instagram’s detection cares about exactly that difference.
- Vary your message slightly if you can, two or three variations rotated through the list rather than one identical string sent to everyone. This alone makes a broadcast look meaningfully less automated.
- Log each send back to your sheet, marking who’s been messaged. This protects you if the scenario stops partway through, so a re run doesn’t double message anyone who already went through successfully.
- Run this against a small test batch first, ten or twenty contacts, before pointing it at your full list.
A Detail Most People Get Wrong
The pacing is not optional, and it is not just about avoiding a spam flag on one broadcast. Repeated large sends with no variation in timing or content build a pattern on your account over time, and Instagram’s detection is looking at that pattern, not just a single message. Slow, staggered, slightly varied sends protect the broadcast you’re running today and every one you plan to run after it.
Testing It Properly
- Send to a small test group first and confirm timing and message variation both look right
- Check your logging sheet updates correctly as the loop runs, not just at the end
- Deliberately stop the scenario partway through and re run it, confirming it skips already messaged contacts rather than starting over
- Watch for any accounts with DM restrictions blocking delivery, since that’s expected behavior, not a broadcast failure
Visual Proof
Screenshot your full scenario showing the iterator, the send module and the sleep module in sequence, along with your logging sheet showing sends being marked off one by one as the scenario runs. A short screen recording of the loop actually progressing through a handful of contacts, with the delay visible between each one, makes this a lot more convincing than static screenshots alone.
Where InstantDM Fits In
Building the pacing logic yourself in Make gives you full control over timing and message variation, which is worth understanding even if you don’t run it this way long term. I’ve since moved my own broadcast sends over to InstantDM, since it handles this pacing natively without me needing to tune sleep intervals or manage a logging sheet by hand, still built on Meta’s official API underneath, just less for me to maintain manually.
Over to You
Has anyone else hit delivery issues sending broadcasts at real scale, even with pacing built in? Curious what gap you’re all using between sends and whether that’s held up as your lists have grown.