Validation results cached with TTL

DNS MX lookups and external validation API calls have measurable latency — typically 50–500ms per call — and most providers impose rate limits (e.g., 100 calls/minute on free tiers). Without caching, every signup and every re-validation check triggers a live network round-trip for the same domain. At 1,000 signups/hour from domains like gmail.com or company.com, redundant lookups waste budget, add latency to the user-facing signup flow, and risk triggering rate-limit errors that silently degrade validation coverage when the lookup fails open.

Cache MX and disposable-check results at the domain level using Redis with a TTL of at least 1 hour:

import { redis } from '@/lib/redis'

async function getCachedMxResult(domain: string): Promise<boolean | null> {
  const cached = await redis.get(`mx:${domain}`)
  return cached === null ? null : cached === '1'
}

async function setCachedMxResult(domain: string, valid: boolean): Promise<void> {
  await redis.setex(`mx:${domain}`, 6 * 60 * 60, valid ? '1' : '0')
}

// In the ingest handler:
const domain = email.split('@')[1]
let valid = await getCachedMxResult(domain)
if (valid === null) {
  valid = await hasValidMx(email)
  await setCachedMxResult(domain, valid)
}

If Redis is not available, a DB table with an expires_at column works as a fallback. A TTL of 1–24 hours is standard — MX records change infrequently.