"Send a daily summary email": the prompt that avoids the spam list

"Send a daily summary email" sounds trivial, and the first version an AI gives you will run. It'll also, quietly, do several wrong things: fire at an unpredictable time, stop if your app restarts, and — if one address bounces — abandon everyone after it. Do this carelessly and you don't just annoy users; you get your sending domain flagged as spam, which is hard to undo.

Here's the request three ways to Claude via Claude Code, with the real code. This one is less about security and more about the difference between "technically sends an email" and "sends the right email, once, on time."

The same request, three ways

send a daily summary email

setInterval(async () => {
  const users = await getUsers();
  for (const u of users) await sendEmail(u.email, summary(u));
}, 24 * 60 * 60 * 1000);

send a daily summary email on a schedule (08:00) using a real email provider, not setInterval

// scheduled function — cron: "0 8 * * *" (08:00 daily)
export async function scheduled() {
  const users = await getUsers();
  for (const u of users) {
    await resend.emails.send({
      from: 'Aliteq <hello@example.com>',
      to: u.email,
      subject: 'Your daily summary',
      html: summary(u),
    });
  }
}

same, but run in the background, only email users who opted in, never send twice for the same day, and don't let one failed send stop the rest

export async function scheduled() {
  const today = new Date().toISOString().slice(0, 10);
  const users = await getUsers({ subscribed: true });   // respect opt-out
  for (const u of users) {
    if (await alreadySent(u.id, today)) continue;        // no double-send
    try {
      await resend.emails.send({
        from: 'Aliteq <hello@example.com>',
        to: u.email,
        subject: 'Your daily summary',
        html: summary(u),
      });
      await markSent(u.id, today);
    } catch (err) {
      await logFailure(u.id, err);                        // one failure ≠ all fail
    }
  }
}

The setInterval version is the tell of a prompt that didn't mention scheduling. It works on your laptop and looks fine in a demo, but on a real host it restarts with every deploy and fires whenever it feels like it. Asking for a cron schedule moves it onto real infrastructure that fires at a real time.

The constrained version's three guards are the whole difference between a feature and an incident. Without the opt-out filter you email people who asked you not to; without the dedupe guard a retry can send the same summary a dozen times; without the try/catch, one bounced address means everyone after it silently gets nothing. None of those show up in a quick test — they show up in production, on a Sunday.

There's also a reputation cost that's easy to underestimate. Inboxes and email providers score your sending domain, and a burst of duplicate or unwanted mail can quietly drop you into spam folders for everyone — including the people who actually wanted your summary. The guards above aren't just good manners; they protect the one thing a summary email depends on, which is landing in the inbox at all.

Before you ship it

Scheduled email is a background job, and background jobs have their own rules. Before you switch it on for real users:

• Run it as a scheduled/background task, never a loop inside a request — see Queues and background jobs.
• A retry loop with no guard can email someone hundreds of times — the exact runaway pattern rate limits exist to contain.
• The email provider's API key is a secret; keep it in an env var on the server — Your API keys are in the browser.
• Always honour opt-out and include an unsubscribe link — it's the law in most places, and the fastest way off a block list is to never get on one.

The pattern generalises to any "do this on a schedule" task: move it off the request, run it on a real cron, and guard for the three things that break at scale — duplicates, failures, and people who opted out. Queues and background jobs has the interactive version.