SMTP „421 Too many connections“ oder Ratenbegrenzung: so behebst du es

Was das bedeutet

Eine 421-Antwort heißt „jetzt nicht, versuch es später“. Der empfangende Server schließt die Verbindung, weil du zu viele gleichzeitig geöffnet oder zu schnell gesendet hast. Es ist ein vorübergehender Fehler: Ein normaler Mailserver behält die Nachricht und versucht es erneut. Auf Postfix-Servern sieht die Meldung meist so aus:

421 4.7.0 mx.example.com Error: too many connections from 203.0.113.10

Andere Server formulieren es anders („Too many concurrent SMTP connections“, „Try again later, closing connection“, „rate limited“). Eine verwandte Postfix-Meldung ist 450 4.7.1 Error: too much mail from 203.0.113.10 (Nachrichtenratenlimit).

Manche große Anbieter haben eigene Codes mit eigenen Anleitungen: Gmail 421 4.7.28 und Microsoft 451 4.7.500; Yahoo hat eigene TSS-Codes.

Warum das passiert

• Zu viele parallele Verbindungen. Deine App oder dein Server öffnet viele Verbindungen auf einmal (ein Newsletter oder ein Skript, das jede E-Mail über eine eigene Verbindung sendet).
• Zu viele Nachrichten pro Minute von einer IP oder einem Konto.
• Niedrige oder neue Reputation. Empfänger nehmen von unbekannten IPs weniger an, sodass ein Volumen, das für eine alte IP kein Problem ist, bei einer neuen Limits auslöst.
• Geteilte IP. Andere Kunden auf derselben IP verbrauchen einen Teil des Kontingents.
• Limits deines eigenen Servers, wenn es dein Server ist, der deinen Apps oder einem Partner mit 421 antwortet.
• Limits des Versandkontos. Postfach-Anbieter begrenzen SMTP-Sitzungen und Nachrichten pro Konto; ein 421 oder 4.7.0 bei einem großen Versand aus einem normalen Postfach ist häufig.

So prüfst du es

1. Finde heraus, wer antwortet. Der Hostname in der 421-Zeile zeigt, ob es der Server des Empfängers, das Relay deines Anbieters oder dein eigener Server ist.
2. Auf deinem sendenden Postfix sieh dir die Zurückstellungen an:

   postqueue -p | grep -i "too many" | sort | uniq -c
   grep "421" /var/log/mail.log | tail

3. Auf deinem empfangenden Postfix protokolliert der Dienst anvil die Spitzen:

   grep "anvil" /var/log/mail.log | tail
   postconf smtpd_client_connection_count_limit smtpd_client_connection_rate_limit smtpd_client_message_rate_limit anvil_rate_time_unit

4. Prüfe die Reputation: Schau deine sendende IP auf Blacklists nach und schick einen Test an die einmalige Adresse auf der Startseite von Delivmail. Ein sauberer Bericht heißt, dass es beim Limit um Volumen geht, nicht um eine Sperre.

So behebst du es

Wenn du der Absender bist: langsamer senden

Nutze in einer App mit nodemailer einige wenige Verbindungen mehrfach, statt pro Nachricht eine zu öffnen:

const transporter = nodemailer.createTransport({
  host: 'smtp.example.com',
  port: 587,
  pool: true,          // reuse connections
  maxConnections: 2,   // parallel connections
  maxMessages: 100,    // messages per connection
  rateDelta: 1000,     // time window in ms
  rateLimit: 5,        // messages per window
  auth: { user: 'you@yourdomain.com', pass: process.env.SMTP_PASS }
});

Bremse bei Postfix nur das Ziel, das sich beschwert, mit einem eigenen Transport. In master.cf:

slow      unix  -       -       n       -       2       smtp

In main.cf:

transport_maps = hash:/etc/postfix/transport
slow_destination_concurrency_limit = 2
slow_destination_rate_delay = 1s

Und in /etc/postfix/transport, danach postmap /etc/postfix/transport und systemctl reload postfix:

example.com    slow:

Verteile große Kampagnen über die Zeit, und wenn deine IP oder Domain neu ist, steigere das Volumen Schritt für Schritt (siehe Eine neue Domain oder IP aufwärmen). Wechsle nicht IPs oder Konten, um Limits zu umgehen: Empfänger merken das, und es schadet deiner Reputation.

Wenn dein eigener Server mit 421 antwortet

Die Standardwerte (smtpd_client_connection_count_limit = 50 pro Client, Ratenlimits deaktiviert) passen für die meisten Server. Hast du strengere Limits gesetzt, erhöhe sie oder nimm vertrauenswürdige Absender wie deine eigenen Apps aus:

smtpd_client_event_limit_exceptions = $mynetworks, 203.0.113.10

Für Apps ist es besser, über den Submission-Port mit einem Pool aus wenigen Verbindungen zu senden, wie oben gezeigt.

Prüfe, ob es behoben ist

Beobachte das Log beim nächsten Versand: Zurückgestellte Nachrichten sollten die Warteschlange mit status=sent verlassen, und neue 421-Zeilen sollten ausbleiben. Mach einen neuen Delivmail-Test, um zu bestätigen, dass Authentifizierung und Reputation sauber sind, und sende erneut an die zurückgestellte Adresse, falls sie am Ende doch einen Bounce erzeugt hat.