Re-verification triggered after engagement inactivity

Email addresses decay at roughly 22–30% per year: people change jobs, abandon mailboxes, and forward to new addresses. Without a periodic re-verification workflow, your list accumulates stale contacts that hard-bounce, soft-bounce repeatedly, or go to spam traps — all of which damage sender reputation. CAN-SPAM § 5 does not prescribe a specific re-verification cadence, but it does require honoring suppression and maintaining deliverability good faith. Sending to addresses that have not engaged in 12+ months is a recognized bad practice that ESPs use as a criterion for account review. A weekly scheduled process that routes contacts through a re-engagement or re-verification pipeline is the industry baseline.

Add a scheduled job that identifies contacts inactive beyond a configurable threshold and queues them for re-verification or re-engagement:

// vercel.json cron entry or equivalent:
// { "path": "/api/cron/reverify-stale", "schedule": "0 2 * * 1" }

export async function GET() {
  const STALE_DAYS = parseInt(process.env.REVERIFY_AFTER_DAYS ?? '120')
  const stale = await db.$queryRaw`
    SELECT id, email FROM contacts
    WHERE last_engaged_at < now() - interval '${STALE_DAYS} days'
      AND status = 'active'
      AND verification_queued_at IS NULL
    LIMIT 500
  `
  for (const c of stale) {
    await verificationQueue.add('reverify', { contactId: c.id })
    await db.contact.update({ where: { id: c.id }, data: { verification_queued_at: new Date() } })
  }
  return Response.json({ queued: stale.length })
}

Run this at minimum once per 7 days. Batch in groups of 500 or fewer to avoid memory pressure and external API rate limits.