Rate Limiting & Throttling: Waarom providers je e-mail vertragen (en hoe je dat voorkomt)

# Rate Limiting & Throttling: Waarom providers je e-mail vertragen

Je hebt net een belangrijke update verstuurd naar 5.000 klanten. De eerste 500 berichten vliegen eruit, maar dan… stilte. Je SMTP-server retourneert 451 4.7.1 Too many connections. Welkom in de wereld van rate limiting.

Wat is rate limiting precies?

Rate limiting is het mechanisme waarmee ontvangende mailservers het aantal berichten beperken dat ze van één afzender accepteren binnen een bepaalde tijdsperiode. Het is geen bug — het is een bewuste verdedigingslinie tegen spam en serveroverbelasting.

Er zijn drie niveaus waarop rate limiting wordt toegepast:

Throttling vs. Rate Limiting

Hoewel de termen vaak door elkaar worden gebruikt, is er een subtiel verschil:

• Rate limiting: harde grens — je wordt geblokkeerd na X berichten
• Throttling: dynamische vertraging — je verbinding wordt vertraagd op basis van reputatie, volume en gedrag

Denk aan rate limiting als een verkeerslicht (rood = stop) en throttling als een snelheidsdrempel (langzamer, maar je rijdt door).

Hoe de grote providers het doen

Gmail (Google Workspace)

Gmail hanteert een van de meest geavanceerde systemen:

Nieuwe domeinen:     ~50-100 berichten/dag
Opgebouwde reputatie: ~2.000-5.000/dag
Hoog vertrouwen:     ~10.000+/dag

Google kijkt naar meer dan alleen volume:

• Engagement: open- en klikpercentages
• Spamklachten: percentage ontvangers dat je markeert als spam
• Authenticatie: SPF, DKIM en DMARC alignment
• Inhoudskwaliteit: links, bijlagen, HTML-structuur

Bij overschrijding krijg je typisch:

421-4.7.28 Our system has detected an unusual rate of unsolicited mail
originating from your IP address. To protect our users from spam,
mail sent from your IP address has been temporarily rate limited.

Microsoft 365 / Outlook.com

Microsoft hanteert strenge limieten, vooral voor nieuwe afzenders:

• Nieuwe IP's: maximaal ~50 berichten per uur naar @outlook.com
• Gevestigde afzenders: tot 1.500/uur
• Hard bounce threshold: >5% bounces triggert onmiddellijke throttling

Microsoft's SNDS (Smart Network Data Services) biedt inzicht in je reputatie per IP-adres.

Yahoo / AOL

Yahoo gebruikt een feedback-loop systeem:

• CFL (Complaint Feedback Loop) moet actief zijn
• Throttling begint bij >0,3% spamklachten
• Berichten worden vertraagd met toenemende wachttijden (exponential backoff)

De wiskunde achter exponential backoff

Als je een rate limit raakt, is de juiste strategie exponential backoff met jitter. Hier is waarom:

javascript
// Naïeve retry — FOUT
function retryNaive(attempt) {
  return 5000; // Altijd 5 seconden wachten
}

// Exponential backoff — BETER
function retryExponential(attempt) {
  return Math.min(1000 * Math.pow(2, attempt), 300000);
  // 1s, 2s, 4s, 8s, 16s, 32s, 64s, 128s, 256s, max 300s
}

// Exponential backoff met jitter — BEST
function retryWithJitter(attempt) {
  const base = Math.min(1000 * Math.pow(2, attempt), 300000);
  const jitter = Math.random() * base * 0.3;
  return base + jitter;
}

De jitter is cruciaal: zonder jitter proberen alle vertraagde berichten tegelijk opnieuw, waardoor je exact hetzelfde probleem veroorzaakt (het thundering herd-probleem).

IP Warming: de oprijlaan naar volume

Als je een nieuw IP-adres of domein in gebruik neemt, moet je het opwarmen. Dit is geen optioneel advies — het is een harde vereiste.

Aanbevolen warming schema

Gouden regel: verhoog nooit meer dan 2x per dag, en monitor bounces en klachten bij elke stap.

Wat kan misgaan bij te snel opwarmen

Connection pooling en parallellisme

Een veelgemaakte fout is het openen van te veel gelijktijdige SMTP-verbindingen:

# Slecht: 100 gelijktijdige verbindingen naar Gmail
# Resultaat: IP-blokkade

# Goed: maximaal 3-5 verbindingen per ontvangend domein
# Met connection pooling en hergebruik

Optimale configuratie per provider

Bij MailBelly beheren we connection pools automatisch. Per ontvangend domein houden we het aantal actieve verbindingen bij en verdelen we berichten slim:

javascript
class SmtpConnectionPool {
  constructor(domain, maxConnections = 3) {
    this.domain = domain;
    this.maxConnections = maxConnections;
    this.activeConnections = 0;
    this.queue = [];
  }

  async send(message) {
    if (this.activeConnections >= this.maxConnections) {
      await this.waitForSlot();
    }
    this.activeConnections++;
    try {
      await this.deliverMessage(message);
    } finally {
      this.activeConnections--;
      this.processQueue();
    }
  }
}

SMTP Response Codes: wat ze écht betekenen

Niet alle 4xx-fouten zijn gelijk. Hier is een vertaalgids:

Kritiek: 4xx-codes zijn tijdelijk — altijd retrien. 5xx-codes zijn permanent — direct stoppen en de bounce registreren.

De beruchte 550-varianten

550 5.1.1 Gebruiker onbekend        → Hard bounce, verwijder adres
550 5.7.1 Geweigerd door beleid     → Check je reputatie
550 5.7.26 SPF/DKIM-fout            → Fix je authenticatie
553 5.1.3 Ongeldig adres            → Verwijder uit lijst

Monitoring en alerting

Je kunt niet managen wat je niet meet. Essentiële metrics:

Real-time dashboard metrics

1. Sending rate (berichten/minuut per domein)
2. Bounce rate (hard + soft, per ontvangend domein)
3. Queue depth (aantal wachtende berichten)
4. Connection utilization (actieve vs. max verbindingen)
5. Response time (gemiddelde SMTP-transactietijd)

Alerting drempels

Praktische tips voor MailBelly-gebruikers

1. Segmenteer je verzendingen

Stuur niet alles tegelijk. Verdeel grote mailings over meerdere uren:

• Ochtend (9:00-10:00): Batch 1 — meest engaged ontvangers
• Middag (13:00-14:00): Batch 2 — actieve ontvangers
• Avond (17:00-18:00): Batch 3 — minder actieve ontvangers

2. Respecteer feedback loops

Verwerk spamklachten onmiddellijk. Elke klacht die je negeert, schaadt je reputatie exponentieel.

3. Houd je lijsten schoon

• Verwijder hard bounces na 1 poging
• Verwijder soft bounces na 3 pogingen over 72 uur
• Verwijder inactieve adressen (geen opens in 6+ maanden)

4. Gebruik dedicated IP's voor transactioneel vs. marketing

Meng nooit transactionele e-mail (wachtwoord resets, bevestigingen) met marketing op hetzelfde IP. Als je marketingcampagne een rate limit triggert, wil je niet dat je transactionele mail ook stopt.

Conclusie

Rate limiting is geen obstakel — het is een kwaliteitsindicator. Providers die je throttlen, vertellen je eigenlijk: "We kennen je nog niet goed genoeg." De oplossing is niet harder duwen, maar slimmer verzenden.

Bouw reputatie op met geduld, gebruik exponential backoff voor retries, warm je IP's langzaam op, en monitor alles. Bij MailBelly automatiseren we dit hele proces, zodat jij je kunt focussen op het schrijven van goede e-mails in plaats van het managen van SMTP-verbindingen.