Ihre Kampagne startet, ein Teil der Empfänger bleibt in der Warteschlange und das Protokoll zeigt „452 4.5.3 Your message has too many recipients„, während Ihr E-Mail-Tool meldet, alles sei in Ordnung. Der Server lehnt in dieser SMTP-Transaktion einen Teil der Liste ab, ohne die Verbindung zu beenden. Teilen Sie den Versand in Blöcke von maximal 100 Empfängern auf (die Untergrenze, die jeder Server laut RFC 5321 akzeptieren muss) und senden Sie nur die abgelehnten Adressen erneut.
Was ein 452 4.5.3 bedeutet
Die Ziffer 4 stuft den Fehler als temporär ein. Die RFC 5321 erschien im Oktober 2008 als Nachfolgerin der RFC 2821 und korrigiert die RFC 821 von 1982, die für diesen Fall fälschlicherweise den Code 552 vorsah. Die RFC 5321 (Abschnitt 4.5.3.1.10) schreibt den Code 452 vor, wenn ein Server sein Limit an RCPT-Befehlen erreicht. Eine Ablehnung unterhalb von 100 RCPT-Befehlen verstößt gegen die Spezifikation.
Ein 452 ist also ein soft bounce. Den Unterschied zur endgültigen Ablehnung erklärt der Artikel zu Hard Bounce und Soft Bounce. Dieselbe Überschreitung der Empfängerzahl führt zu einem 550 5.5.3 (RESOLVER.ADR.RecipLimit bei Exchange), wenn die Ablehnung endgültig ist und kein weiterer Zustellversuch folgt.
Die allgemeine Liste der Codes finden Sie unter SMTP-Antwortcodes, die Sie kennen sollten. Ein volles Postfach, ein weiterer Fehlerfall bei einer existierenden Adresse, behandelt der Artikel zum Fehler 552 mailbox full.
Empfängerlimits nach E-Mail-Anbieter
Die Tabelle vergleicht die von den Anbietern veröffentlichten Obergrenzen für einen einzelnen Versand. Welche Zahl blockiert, hängt vom Weg ab: Dasselbe Gmail-Konto akzeptiert über die Weboberfläche 2.000 Empfänger, aber nur 100, wenn ein Tool sich per SMTP verbindet. Die Werte stammen vom Oktober 2026. Prüfen Sie sie vor jeder Versandplanung erneut, denn Google und Microsoft ändern sie regelmäßig.
| E-Mail-Anbieter oder Kontext | Empfänger pro Nachricht | Tageslimit | Beobachteter Fehlertext |
|---|---|---|---|
| Gmail und Google Workspace (Weboberfläche) | 2.000 insgesamt, davon maximal 500 extern | 2.000 Nachrichten und 10.000 Empfänger pro Nutzer; 3.000 externe Empfänger | Your message has too many recipients |
| Gmail per SMTP (POP- oder IMAP-Nutzer) | 100 | gleiche Tageslimits | Your message has too many recipients |
| Gmail API | 500 | gleiche Tageslimits | Your message has too many recipients |
| Relay smtp-relay.gmail.com | 100 pro SMTP-Transaktion | siehe Seite zum Relay | Your message has too many recipients |
| Exchange Online | einstellbar bis 1.000 | 10.000 Empfänger pro Postfach und Tag; Tenant-Limit (TERRL) je nach Lizenzen | Recipients belong to multiple regions (ATTR38) |
| Postfix | standardmäßig 1.000 (smtpd_recipient_limit) | keines | Error: too many recipients |
| Von RFC 5321 vorgeschriebenes Minimum | mindestens 100 zu akzeptieren | nicht zutreffend | 452 4.5.3 |
Für die Diagnose zählt vor allem die Spalte „Fehlertext“. Zwei Server können denselben Code 452 4.5.3 aus entgegengesetzten Gründen zurückgeben: Beim einen steckt eine Obergrenze für die Empfängerzahl dahinter, beim anderen eine Domainregel. Lesen Sie deshalb immer den Satz, der auf den Code folgt.
Gmail und Google Workspace: zwei Meldungen für denselben Code
Der Code 452 4.5.3 erscheint auf der Seite zu den SMTP-Fehlern von Gmail in zwei Formulierungen: „Your message has too many recipients“ und „Domain policy size per transaction exceeded, please try this recipient in a separate transaction“.
Die erste verweist auf die Seite mit den Sendelimits von Google. Laut der Google-Workspace-Dokumentation zu den Sendelimits akzeptiert eine Nachricht 2.000 Empfänger insgesamt, davon 500 extern. Für Nutzer, die per SMTP über einen POP- oder IMAP-Client senden, nennt dieselbe Seite 100 Empfänger pro Nachricht. Ein per SMTP an ein Gmail-Konto angebundenes Tool bleibt also bei 100.
Die zweite Formulierung hängt mit einer Domainregel zusammen: Der Server verlangt, den genannten Empfänger in einer separaten Transaktion zu übermitteln. Einen konkreten Schwellenwert veröffentlicht Google für diese Regel nicht. Nehmen Sie die in der Fehlermeldung genannte Adresse heraus und senden Sie sie einzeln erneut.
Zu den Limits pro Nachricht kommen die Tageslimits. Google erlaubt 2.000 Nachrichten pro Tag und Nutzer, mit insgesamt 10.000 Empfängern, davon 3.000 extern. 30 Blöcke zu je 100 von einem einzigen Konto reichen, um die 3.000 externen Empfänger zu erreichen. Verteilen Sie größere Kampagnen deshalb auf mehrere Tage. Das Relay smtp-relay.gmail.com wendet seinerseits 100 Empfänger pro SMTP-Transaktion an (Seite zu den Fehlern des SMTP-Relays von Google Workspace).
Microsoft 365 und Exchange Online
Exchange Online (Microsoft 365) begrenzt jede Nachricht auf eine Empfängerzahl, die sich bis auf 1.000 in den Feldern An, Cc und Bcc einstellen lässt. Dazu kommt ein eigenes Limit von 10.000 Empfängern pro Postfach und 24-Stunden-Zeitraum (Microsoft-Learn-Dokumentation, Exchange-Online-Limits, Stand September 2026). Beide Werte stehen auf der Seite zu den Exchange-Online-Limits, ebenso ein weiteres Limit auf Tenant-Ebene, das von der Zahl der Lizenzen abhängt.
Die Variante ATTR38 führt eher in die Irre. Der vollständige Text lautet „452 4.5.3 Recipients belong to multiple regions ATTR38″. Hier entsteht die Ablehnung, weil sich die Adressen auf mehrere Regionen oder Tenants von Microsoft verteilen, ganz unabhängig von ihrer Anzahl. Ein Administrator mit einer Liste von rund 100 Adressen bekam sie bei jedem Versand wegen 5 Hotmail-Adressen (Thread in Microsoft Q&A). Den Code ATTR38 definiert Microsoft auf der Seite zu den Limits nicht.
Um den tatsächlichen Wert eines Postfachs auszulesen, öffnen Sie PowerShell mit dem Modul ExchangeOnlineManagement (Connect-ExchangeOnline) und führen Sie Get-Mailbox vorname.nachname@domain.de | Format-List RecipientLimits aus. Das TERRL-Limit Ihres Tenants zeigt der Bericht Tenant Outbound External Recipients im Exchange Admin Center > Reports > Mail flow. Unter Mail flow > Message trace enthält die Fehlerdetailansicht den vollständigen Text des 452.
Nehmen Sie die Adressen von outlook.com und hotmail.com aus dem Hauptblock und senden Sie sie in kleinen Gruppen. Ein Thread in Microsoft Q&A von 2018 zitiert Michael Wise von Microsoft: Ein 452 fordere den sendenden Server auf, die abgelehnten Empfänger sofort erneut zu übermitteln. Der Verfasser der Antwort sieht darin einen Fehler auf Seiten von Outlook.com. Bleibt die Ablehnung bestehen, wechseln Sie auf einen Empfänger pro Transaktion. Die SPF- und DKIM-Einträge der Domain spielen dabei keine Rolle. Im Nachrichtentext steht mitunter „retry timeout exceeded“: Der Server hat die Warteschlange bis zum Ablauf erneut abgearbeitet und die Nachricht dann verworfen.
Postfix
Auf einem Postfix-3.x-Server, der E-Mails empfängt, heißt das Limit smtpd_recipient_limit und liegt standardmäßig bei 1.000 (Postfix-Dokumentation, postconf). Darüber antwortet der Server mit „452 4.5.3 Error: too many recipients“. Unter Debian und Ubuntu liegen die Protokolle in /var/log/mail.log, und grep "too many recipients" /var/log/mail.log listet die abgelehnten Sitzungen auf. Wenn Sie diesen Server verwalten, lesen Sie den Wert mit postconf smtpd_recipient_limit aus und erhöhen ihn mit postconf -e "smtpd_recipient_limit = 2000" (die Direktive steht in /etc/postfix/main.cf). Danach laden Sie mit postfix reload neu.
Der Parameter smtpd_recipient_overshoot_limit (standardmäßig 1.000) lässt zusätzlich 1.000 überzählige Empfänger durch, bevor Postfix einen Sitzungsfehler zählt. Auf der Senderseite teilt Postfix seine Sendungen selbst pro Ziel mit default_destination_recipient_limit (standardmäßig 50) auf und legt abgelehnte Empfänger in die zurückgestellte Warteschlange (deferrals).
Freenet, IONOS und T-Online
Freenet (freenet.de), IONOS (ionos.de) und T-Online (t-online.de) tauchen in den Google-Ergebnissen zu diesem Code auf. In der offiziellen Dokumentation dieser drei Anbieter steht kein Schwellenwert pro Nachricht, deshalb nennen wir hier keine Zahl.
Das Limit finden Sie im Datenblatt Ihres Tarifs, oder Sie fragen den Support.
Den Versand Schritt für Schritt freigeben
- Notieren Sie den exakten Text, der im NDR oder im SMTP-Protokoll auf den Code folgt: „too many recipients“ (Obergrenze für die Anzahl), „Domain policy size per transaction exceeded“ (Domainregel von Google) oder „Recipients belong to multiple regions“ (ATTR38 bei Microsoft). Dieser Text bestimmt die Korrektur.
- Zählen Sie die Empfänger des Umschlags. An, Cc und Bcc zählen alle (Microsoft-Dokumentation), Adressen ins Bcc zu verschieben verringert die Gesamtzahl also nicht.
- Teilen Sie die Liste in Blöcke von maximal 100 Empfängern pro Transaktion auf. Eine Datenbank mit 25.000 Adressen ergibt 250 Blöcke, also mindestens 3 Versandtage von einem Google-Workspace-Konto aus, das auf 10.000 Empfänger pro Tag begrenzt ist.
- Lassen Sie zuerst den sendenden Server die Warteschlange erneut abarbeiten. Ein 4xx wird von selbst wiederholt, und ein manueller Neuversand erzeugt in der Zwischenzeit Duplikate.
- Bleiben Adressen abgelehnt, senden Sie nur diese erneut. Die in derselben Transaktion akzeptierten Empfänger haben ihre Nachricht bereits, ein vollständiger Neuversand würde sie doppelt zustellen.
- Prüfen Sie nach dem ersten Block die Reputation: Öffnen Sie Google Postmaster Tools (postmaster.google.com) und sehen Sie sich die von Nutzern gemeldete Spam-Rate (complaint rate) an, bevor die weiteren Blöcke rausgehen.
- Kontrollieren Sie das Tageslimit, bevor Sie die Blöcke erneut starten, bei Exchange Online etwa die 10.000 Empfänger pro Tag und Postfach.
Der vollständige Neuversand nach einem teilweisen 452 ist der typische Fehler. Die RFC 5321 sieht vor, dass der Client nur die abgelehnten Empfänger erneut übermittelt, nicht die gesamte Transaktion. Nehmen wir einen Versand an 150 Adressen über Gmail per SMTP: Die ersten 100 RCPT-TO-Befehle gehen durch, der 101. erhält „452 4.5.3 Your message has too many recipients“. Die ersten 100 Empfänger haben ihre Nachricht. Nur die übrigen 50 warten auf den nächsten Versuch. Würden Sie erneut an alle 150 senden, bekämen 100 Personen ein Duplikat.
Warum Sie die Liste bereinigen sollten, bevor Sie die Blöcke erneut senden
Man hört oft den Einwand, ein 452 sei ja temporär, die Liste müsse also nicht geprüft werden. Nur vervielfacht das Aufteilen eines Versands die Transaktionen. Jeder erneut gesendete Block setzt ungültige Adressen einer weiteren Ablehnung aus. Diese endgültigen Ablehnungen kommen per NDR zurück, treiben die Hard-Bounce-Rate hoch und belasten damit die sender reputation. Eine saubere Liste (list hygiene) senkt dieses Risiko. Ob es eintritt, sehen Sie in den NDRs jedes Blocks: Steigt die Hard-Bounce-Rate von einem Block zum nächsten, war die Ausgangsliste ungeprüft.
Testen Sie vor dem erneuten Versand der Blöcke die Verifizierung von CaptainVerify an einer Stichprobe Ihrer Liste. So kennen Sie den Anteil ungültiger Adressen, bevor die NDRs ihn für Sie messen.
Der erste Test, den Sie starten sollten
Öffnen Sie das Protokoll Ihres letzten Versands, suchen Sie den Text nach „452 4.5.3″ und senden Sie dann nur die abgelehnten Adressen in Blöcken zu je 100 erneut.
