# Microsoft-Deferrals mit 451 4.7.500: ein Playbook für Absender

Kanonische URL: https://brew.new/de/blog/microsoft-451-4-7-500-deferrals-playbook
Autor: Thomas Park
Veröffentlicht: 2026-10-05
Aktualisiert: 2026-10-05

Ein Deferral von Microsoft ist eine vorübergehende Ablehnung per SMTP, also eine Antwort, die mit 4 beginnt. Outlook.com oder ein Server von Microsoft 365 sendet sie, wenn er deine Nachricht gerade nicht annehmen will. Dein Server sollte die Nachricht behalten und es später erneut versuchen. Am bekanntesten ist `451 4.7.500 Server busy. Please try again later`, und derselbe Code kann „dein Versand wirkt verdächtig“ bedeuten oder „Microsoft hat einen schlechten Tag“.

Am 4. September 2026 bedeutete er das Zweite, und mindestens ein erfahrener Betreiber suchte den ganzen Vormittag nach dem Ersten. So unterscheidest du die beiden.

## Das Wichtigste in Kürze

- Lies zuerst den Host. `*.olc.protection.outlook.com` steht für die privaten Postfächer von Outlook.com, `*.mail.protection.outlook.com` für einen Tenant von Microsoft 365. Andere Dokumentation, anderer Eskalationsweg.
- Ein 4xx heißt: in die Warteschlange und erneut versuchen, laut RFC 5321 im Abstand von mindestens 30 Minuten und mindestens 4 bis 5 Tage lang. Ein 5xx heißt: aufhören. Microsofts Richtlinien verbieten, es erneut zu versuchen.
- Wenn jede IP in derselben Minute denselben Code von Microsoft bekommt, während bei Gmail und Yahoo alles normal läuft, liegt der Verdacht bei Microsoft. Sieh auf mailop nach, bevor du irgendetwas änderst.
- Seit dem 5. Mai 2025 setzt Outlook.com SPF, DKIM und DMARC für Domains durch, die mehr als 5.000 Nachrichten pro Tag senden. Ein `550 5.7.515` musst immer du beheben.
- Registriere deine Versand-IPs jetzt bei SNDS und JMRP. Der Zugang zu SNDS läuft nach 10 Monaten ab, wenn du ihn nicht erneut bestätigst.
- Versuch es nicht aggressiver erneut, wechsle nicht auf frische IPs und setz zurückgestellte Kontakte nicht auf die Sperrliste.

## Finde zuerst heraus, mit welchem Microsoft du es zu tun hast

Microsoft betreibt zwei Empfangssysteme.

**Outlook.com** ist der E-Mail-Dienst für Privatnutzer: `outlook.com`, `hotmail.com`, `live.com` und `msn.com`, mit MX-Hosts wie `hotmail-com.olc.protection.outlook.com`. Dazu gehören die [Postmaster-Seite von Outlook.com](https://substrate.office.com/ip-domain-management-snds/Postmaster/Troubleshooting), SNDS für die Reputation und ein eigenes Supportformular für Absender.

**Microsoft 365** (Exchange Online) hostet geschäftliche Postfächer. E-Mails für `acme.com` gehen an `acme-com.mail.protection.outlook.com`. Die Fehler sind auf [Microsoft Learn](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online) dokumentiert, Sperren laufen über `sender.office.com`, und die Admins des Empfängers bestimmen, wie ihr Tenant dich behandelt.

Am Domainnamen erkennst du nicht, bei welchem der beiden du landest. An der Antwort schon. In dieser Logzeile, die am 4. September [auf mailop gepostet wurde](https://www.mail-archive.com/mailop@mailop.org/msg27209.html), ist der Host bei `relay=` ein Tenant von Microsoft 365:

```text
relay=xxxx-com.mail.protection.outlook.com[52.101.10.16]:25, dsn=4.7.500,
status=deferred (host xxx-com.mail.protection.outlook.com[52.101.10.16] said:
451 4.7.500 Server busy. Please try again later from [199.89.3.6]. (S77714)
[BN2PEPF000055E1.namprd21.prod.outlook.com 2026-09-04T10:28:53.346Z ...]
(in reply to end of DATA command))
```

## Entschlüssle die Antwort

Lies den Basiscode (`451`), den erweiterten Code (`4.7.500`) und den Subcode in Klammern wie `(S77714)`. Microsoft veröffentlicht keine S-Subcodes, aber wenn viele Absender gleichzeitig denselben melden, ist das ein Signal.

| Antwort | Wo | Was Microsofts Dokumentation sagt | Erster Schritt |
|---|---|---|---|
| `451 4.7.500 Server busy. Please try again later from [IP]. (S77714)` | Microsoft 365 | Learn führt 4.7.500-699 als „Access denied, please try again later“: verdächtige Aktivität, Versand vorübergehend eingeschränkt. | Die Warteschlange erneut versuchen lassen. Zuerst das Ausmaß prüfen. |
| `451 4.7.500-699 (ASxxx)` | Microsoft 365 | Drosselung der IP, wenn die verbindende IP „ihr bisheriges Versandmuster geändert hat, indem sie ein deutlich höheres Volumen sendet“. | Das Hochfahren verlangsamen. Die Drosselung löst sich „im Laufe einiger Tage“. |
| `451 4.7.650 ... temporarily rate limited due to IP reputation (S775)` | Outlook.com | Nicht in Microsofts veröffentlichter Tabelle. | Volumen und parallele Verbindungen reduzieren, dann SNDS prüfen. |
| `451 4.7.652 ... exceeded the maximum number of connections (S3115)` | Outlook.com | Nicht in der Tabelle. Der Text nennt die Ursache. | Weniger Verbindungen öffnen. |
| `421 RP-001`, `RP-002`, `RP-003` | Outlook.com | Limits für die Rate, die Rate pro Verbindung und die Zahl der Verbindungen überschritten, „im Zusammenhang mit der IP-/Domain-Reputation“. | Drosseln, dann SNDS prüfen. |
| `550 5.7.515 Access denied, sending domain [domain] does not meet the required authentication level.` | Outlook.com | Die Domain sendet mehr als 5.000 pro Tag und erfüllt die Anforderungen an SPF, DKIM und DMARC nicht. | Authentifizierung und Alignment korrigieren. |
| `550 5.7.1 ... part of their network is on our block list (S3150)` | Outlook.com | Sperre für deine IP oder deinen IP-Bereich. | Von dieser IP nicht mehr senden und ein Ticket eröffnen. |
| `550 SC-001`, `SC-004`, `OU-002` und ähnliche | Outlook.com | Ablehnungen aufgrund von Richtlinien, wegen Inhalt, Reputation oder Beschwerden. SC-004 verweist auf JMRP. | Die Ursache finden, bevor du wieder sendest. |
| `550 5.7.606-649 Access denied, banned sending IP [IP]` | Microsoft 365 | Die IP steht auf der Liste blockierter Absender. | Die Entfernung über `sender.office.com` beantragen. |
| `550 5.7.511 Access denied, banned sender` | Microsoft 365 | Erfordert eine manuelle Prüfung. | Den Unzustellbarkeitsbericht (NDR) an `delist@microsoft.com` weiterleiten. |

Quellen: Microsofts [NDR-Referenz für Exchange Online](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online), der [Artikel zu ASxxx](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/fix-error-code-451-4-7-500-699-asxxx-in-exchange-online), die Codetabelle auf der Postmaster-Seite und der [Artikel zu 550 5.7.515](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com); Al Iverson zu [S775](https://www.spamresource.com/2026/02/microsoft-rate-limiting-issues.html) und [S3115](https://www.spamresource.com/2025/07/microsoft-says-too-many-connections.html); Twilio SendGrid zu [Sperren mit S3140/S3150](https://support.sendgrid.com/hc/en-us/articles/38465017420955-Troubleshooting-Microsoft-Delivery-Issues-With-Error-550-5-7-1-S3140-S3150-Blocks).

### Die 4 oder die 5 sagt dir, was zu tun ist

Die [Sender Best Common Practices von M3AAWG](https://www.m3aawg.org/sites/default/files/document/M3AAWG_Senders_BCP_Ver3-2015-02.pdf) besagen, dass nach einem vorübergehenden Fehler „der Absender die Verbindung schließen und später eine neue Verbindung öffnen sollte“ und dass Absender einen Tempfail nie als dauerhaft behandeln dürfen. Microsofts [Richtlinien für Absender](https://substrate.office.com/ip-domain-management-snds/Postmaster/Policies) zu 5xx: „Der Absender darf nicht versuchen, diese Nachricht erneut an diesen Empfänger zu übermitteln.“

Ein 451 ist kein Bounce. Wenn deine Plattform oder ein Skript ihn als Bounce behandelt, behebe das zuerst.

## Störung bei Microsoft oder deine Reputation?

Microsofts Hinweise zu 4.7.500 verweisen dich auf deinen eigenen Versand. Meist stimmt das, aber nicht immer.

### So sah der 4. September 2026 aus

Qboxmail [schrieb auf mailop](https://www.mail-archive.com/mailop@mailop.org/msg27208.html), das Problem habe „um 9:47 Uhr MESZ auf allen unseren IPs gleichzeitig begonnen“, mit den Subcodes S77714, S77717 und S77719. Die [Statusseite](https://poppulo1.statuspage.io/incidents/w0671ycn23fw) von Poppulo nannte die ID der Störung bei Microsoft, EX1467029, mit Beginn um 11:19 Uhr BST.

Laut der [Zusammenfassung von emailexpert vom 10. September](https://emailexpert.com/microsofts-ten-days-three-exchange-online-incidents-three-causes/) machte ein Betreiber zunächst durchtrennte Glasfaserkabel verantwortlich, bis One.com, Qboxmail, Mailjet und Poppulo dieselben Codes über alle Versand-IPs und Regionen hinweg meldeten. Microsoft machte erst ein Anti-Spam-Modell verantwortlich, dann eine Drosselungsregel, die während der Wiederherstellung weiter griff. Einen öffentlichen Abschlussbericht zur Störung fand emailexpert nicht. Ein separater Authentifizierungsfehler, MO1465074, dauerte etwa 67 Stunden, vom 31. August bis zum 3. September. Unser [Bericht für September](/de/blog/state-of-email-september-2026) behandelt diese zehn Tage.

### Fünf Prüfungen, bevor du handelst

1. **Das Ausmaß bei dir.** Probleme der Plattform treffen jede IP, jede Domain und jeden Versandstrom innerhalb von Minuten. Reputationsprobleme beginnen meist bei einem davon.
2. **Andere Provider.** Wenn Gmail, Yahoo und Apple normal annehmen und andere Absender denselben Code von Microsoft melden, liegt die Ursache wahrscheinlich bei Microsoft.
3. **Deine letzten 72 Stunden.** Eine Volumenspitze, eine neue IP, eine importierte Liste, eine DNS-Änderung oder einen Reaktivierungsversand musst du so oder so angehen.
4. **Hör dich um.** Sieh im Archiv von mailop und auf Statusseiten nach. Ein Admin von Microsoft 365 kann **Health > Service health** öffnen (in der deutschen Oberfläche **Integrität > Dienstintegrität**). Der dortige [Problemverlauf](https://learn.microsoft.com/en-us/microsoft-365/enterprise/view-service-health) umfasst die Störungen der letzten 7 oder 30 Tage, die für deinen Tenant veröffentlicht wurden. Dort hat Poppulo EX1467029 gefunden.
5. **SNDS.** Steht dort Grün ohne Sperren, während sich die Deferrals häufen, spricht das gegen eine Ursache bei dir.

| Signal | Deutet auf Microsoft | Deutet auf dich |
|---|---|---|
| Zeitpunkt | Jede IP ist ab derselben Minute betroffen | Eine IP oder Domain oder ein allmählicher Anstieg |
| Andere Provider | Normal | Ebenfalls schlechter, oder die Beschwerden steigen |
| Andere Absender | Derselbe Code auf mailop und Statusseiten | Niemand sonst spricht darüber |
| Deine jüngsten Änderungen | Keine | Volumensprung, neue IP, neue Liste |
| SNDS | Grün, keine Sperre | Gelb oder Rot, Beschwerden, „Blocked“ |
| Code | 4.7.500 mit einem Subcode, den auch andere melden | RP-00x, 4.7.650, 5.7.515, S3150 |

![Ein Entscheidungsdiagramm für Antworten von Microsoft: 5xx-Codes führen zur Korrektur der Authentifizierung, zum Delisting-Portal oder zu einem Supportticket; 4xx-Codes führen zu einer Prüfung auf eine Störung und dann entweder zum Abwarten oder zum Drosseln und Prüfen von SNDS.](/images/blog/microsoft-451-4-7-500-deferrals-playbook-flowchart.png)

*Wie du eine Antwort von Microsoft einordnest, nach Microsofts Dokumentation und den Berichten zur Störung im September 2026.*

## SNDS und JMRP: einrichten, bevor du sie brauchst

[Smart Network Data Services](https://substrate.office.com/ip-domain-management-snds/snds) (SNDS) ist Microsofts kostenloses Reputationsportal für Outlook.com, aufgeschlüsselt nach IP. Die [SNDS-FAQ](https://substrate.office.com/ip-domain-management-snds/SNDS/FAQ) nennt, was für jede autorisierte IP angezeigt wird:

- **Filterergebnis.** Grün steht für weniger als 10 % als Spam eingestufte Nachrichten, Gelb für 10 % bis 90 %, Rot für mehr als 90 %.
- **Beschwerderate**, also Beschwerden geteilt durch Empfänger. Mehr als 30 % der IPs bleiben unter 0,3 %, laut FAQ „eine gute Messlatte“.
- **RCPT-Befehle im Vergleich zu Nachrichtenempfängern.** Eine große Lücke deutet auf veraltete Listen hin.
- **IP-Status**: Blocked, Bot oder Junked.

Daten sind laut FAQ „für IPs, die am betreffenden Tag weniger als 100 Nachrichten gesendet haben, möglicherweise nicht vorhanden“. Für den Zugang beantragst du eine IP, einen IP-Bereich oder eine ASN, und SNDS schickt einen Link an Adressen, die es über Reverse DNS (`postmaster@`, `abuse@`) oder RDAP findet. Manuelle Anfragen gibt es nicht.

SNDS ist im Juni 2026 neu gestartet. Al Iverson [wies am 19. Juni darauf hin](https://www.spamresource.com/2026/06/snds-and-jmrp-in-transition.html), dass sich Kampagne und Empfänger über die Return-Paths in JMRP nicht mehr zuverlässig erkennen lassen. Kodiere diese Angaben also an anderer Stelle. Laut der Startseite von SNDS (aktualisiert am 22. September) läuft der Zugang 10 Monate nach Freigabe oder Migration ab, mit drei Erinnerungen vorher. Trag dir das in den Kalender ein.

Das [Junk Mail Reporting Program](https://substrate.office.com/ip-domain-management-snds/Postmaster/Services) (JMRP), für das du dich innerhalb von SNDS anmeldest, schickt dir jede Nachricht zurück, die ein Nutzer von Outlook.com als Junk markiert, oft schon „innerhalb von nur 72 Stunden“ nach der Anmeldung. Entferne alle, die sich beschwert haben, aus jeder Liste und melde neue IPs an, sobald du sie hinzufügst. Bei geteilten IPs, die du nicht registrieren kannst, frag deinen Anbieter, was er überwacht.

## Support für Absender und Delisting

**Outlook.com.** Das Supportformular auf der [Seite zur Fehlerbehebung für Postmaster](https://substrate.office.com/ip-domain-management-snds/Postmaster/Troubleshooting) setzt ein Microsoft-Konto voraus, gilt nur für die vier privaten Domains und übernimmt „keine Garantie“ für die Zustellung. Twilio SendGrid (der Rat eines Anbieters) empfiehlt, Domain, IPs, eine Beschreibung des Versandstroms, den Bounce-Text und Screenshots aus SNDS mitzuschicken, die erste, automatische Antwort mit der Bitte um Eskalation zu beantworten und nach deinem Volumenkontingent sowie einer Prüfung des Volume-Based Limit zu fragen.

**Microsoft 365.** Bei `5.7.606-649` nutzt du das [Delisting-Portal](https://learn.microsoft.com/en-us/defender-office-365/external-senders-use-the-delist-portal-to-unblock-yourself) unter `sender.office.com`: eine Adresse und eine IP pro Besuch, bestätigt per E-Mail. Die Entfernung „kann bis zu 24 Stunden oder länger dauern“. Bei `5.7.511` schickst du den NDR per E-Mail an `delist@microsoft.com` und kannst innerhalb von 48 Stunden mit einer Antwort rechnen.

Für eine ASxxx-Drosselung gibt es kein Delisting. Filtert das empfangende Unternehmen eingehende E-Mails über einen Drittanbieter, bevor sie Microsoft 365 erreichen, hebt laut dem Artikel auf Learn ein Connector, den sein Admin einrichtet, die Drosselung auf. Andernfalls löst sie sich, während du eine Versandhistorie aufbaust.

## Wiederholen, drosseln, hochfahren

**Nach Zeitplan wiederholen.** Laut [RFC 5321, Abschnitt 4.5.4.1](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.5.4.1) soll („SHOULD“) das Intervall zwischen Wiederholungen mindestens 30 Minuten betragen, und bis zum Aufgeben müssen „in der Regel mindestens 4 bis 5 Tage“ vergehen, mit zwei Versuchen in der ersten Stunde und danach einem alle zwei bis drei Stunden. Verkürze das nicht für einen dringenden Versand.

**Pro Ziel drosseln.** Laut M3AAWG erwarten Empfänger, dass Anpassungen „pauschal für alle E-Mails erfolgen, die ihnen von derselben IP-Adresse gesendet werden“. Wenn Microsoft zurückstellt, verlangsame alles, was an diese MX-Familie geht (Outlook.com oder Microsoft 365).

**Verbindungen im Blick behalten.** Laut den Richtlinien von Outlook.com dürfen Absender ohne vorherige Absprache „nicht mehr als 500 gleichzeitige Verbindungen öffnen“. Das ist eine Obergrenze, und ein `4.7.652 (S3115)` bedeutet, dass du über deiner liegst.

**Neue IPs und Domains hochfahren.** Laut Microsoft kann eine neue IP „damit rechnen, innerhalb von ein paar Wochen oder früher vollständig hochgefahren zu sein“, abhängig von Volumen, Genauigkeit der Liste und Beschwerden. Neue IPs, die ein bestehender SPF-Eintrag abdeckt, erben einen Teil der Domain-Reputation. Fang mit Kontakten an, die zuletzt aktiv waren.

## Was du lassen solltest

- **Aggressiver wiederholen.** Stößt du die Warteschlange alle paar Minuten neu an, häufst du Verbindungen auf einer IP an, die Microsoft verlangsamen will, und kassierst ein 4.7.652.
- **Die IP wechseln, um auszuweichen.** Neue IPs haben keine Reputation und bekommen eher Probleme, und E-Mails auf frische IPs zu verteilen, ist genau das, was Snowshoe-Spammer tun.
- **Einen 5xx erneut versuchen.** Microsoft verbietet das, und nach „mehreren Unzustellbarkeitsantworten“ musst du aufhören, an diesen Empfänger zu senden.
- **Zurückgestellte Kontakte auf die Sperrliste setzen.** Die Adresse ist weiterhin gültig.
- **Erneut an zurückgestellte Empfänger senden.** Ihre Nachrichten stehen noch in der Warteschlange. Du würdest Duplikate verschicken.
- **In Panik DNS ändern.** Änderst du mitten in einer Störung SPF oder DKIM, schaffst du ein zweites Problem, es sei denn, du hast ein `5.7.515` bekommen.

Zu DMARC-Alignment und dem Weg von `p=none` zur Durchsetzung lies unseren [Leitfaden zur Zustellbarkeit](/de/blog/email-deliverability). Damit Passwort-Resets und Belege weiter ankommen, erklärt unser [Leitfaden zu Transaktions-E-Mails](/de/blog/transactional-emails), wie du sie auf eine eigene Domain legst.

## So sieht das in Brew aus

Brew betreibt die Versandinfrastruktur und wiederholt vorübergehende Fehler, du musst also nie an Warteschlangen oder Verbindungslimits drehen. Das siehst du:

- **Verzögerte Events.** Ein Deferral erzeugt ein Event „Verzögert“ (`delivery_delayed`), und der Status des Empfängers wechselt von „angenommen“ zu „verzögert“ und dann zu „zugestellt“ oder „Bounce“. Such unter **Events** nach „verzögert“ und tipp dann `@hotmail.com` oder `@outlook.com` ein, um auf Outlook.com einzugrenzen (Domain-Filter werden mit ODER verknüpft; Empfänger bei Microsoft 365 nutzen ihre eigenen Domains). Das Event sagt dir, dass die Nachricht wartet, aber nicht, warum.
- **Details zu Bounces.** Unter „Metadaten“ eines Bounce-Events stehen der Bounce-Typ und die Meldung des Providers.
- **Zahlen über die API.** Die [Übersicht der Analysen](https://docs.brew.new/api-reference/public-v1/analytics/brand-overview-totals-rates-timeseries) liefert `deliveryDelayed` und `pending` neben den Werten für Zustellungen und Bounces. `get_email_analytics` macht dasselbe über MCP.
- **Sperrlisten, die 4xx respektieren.** Hard Bounces und Beschwerden führen sofort zur Sperre, Soft Bounces erst nach dreien innerhalb von 30 Tagen.
- **Hochfahren.** Der [schrittweise Versand](https://docs.brew.new/create-emails/send-options#gradual-send) teilt einen großen Versand in stündliche oder tägliche prozentuale Batches auf, die du pausieren kannst, wenn Outlook.com anfängt zurückzustellen.
- **Domain-Zustand.** Die Karte „Zustellbarkeit“ jeder Domain vergibt 0 bis 100 Punkte über Inbox-Placement, Reputation, Authentifizierung, Inhalt und Versand-Setup hinweg, auch abrufbar über das MCP-Tool `get_domain_health`. Ein Inbox-Placement-Test (10 Credits) erreicht Seed-Postfächer bei Gmail, Outlook, Yahoo, Apple und weiteren Anbietern.

Webhooks für Zustellungen und Daten aus SNDS oder JMRP gibt es in Brew noch nicht (Zahlen pro Provider liefert die Events-API mit `groupBy=recipientDomain`). Nutze für die Reputation also Microsofts Portale. Bei einer vermuteten Störung bei Microsoft würden wir den Versand in Ruhe lassen und zusehen, wie aus „Verzögert“ „Zugestellt“ wird.

## Häufig gestellte Fragen

### Was bedeutet 451 4.7.500 Server busy bei Outlook oder Microsoft 365?

Es ist eine vorübergehende Ablehnung durch Microsoft 365 (Exchange Online), die Microsoft nach verdächtiger Aktivität als „Access denied, please try again later“ führt. Meist hat sich dein Versandmuster geändert, aber am 4. September 2026 war es eine Störung bei Microsoft (EX1467029). Lass deinen Server es erneut versuchen und prüfe, ob andere Absender es auch sehen.

### Wie lange stellt Microsoft meine E-Mails noch zurück?

Laut Microsoft löst sich eine Drosselung aufgrund des Versandmusters „im Laufe einiger Tage“, während du eine Historie aufbaust, und ein Delisting kann bis zu 24 Stunden oder länger dauern. Versuch es mindestens 4 bis 5 Tage lang weiter, wie RFC 5321 es empfiehlt, dann wird der Großteil der zurückgestellten E-Mails doch noch zugestellt.

### Was ist 550 5.7.515, und wie behebe ich es?

Outlook.com lehnt E-Mails von Domains ab, die mehr als 5.000 pro Tag senden und seine Authentifizierungsregeln nicht erfüllen; durchgesetzt wird das seit dem 5. Mai 2025. SPF und DKIM müssen bestehen, die Domain muss DMARC veröffentlichen (`p=none` reicht), und SPF oder DKIM muss Alignment mit der From-Domain haben.

### Sollte ich mir eine neue IP-Adresse besorgen, wenn Microsoft meine sperrt?

Nein. Laut Microsoft haben neue IPs keine Reputation und bekommen eher Probleme. Behebe die Ursache, beantrage das Delisting und fahr das Volumen auf deiner bestehenden IP wieder hoch.

### Zählen Deferrals von Microsoft als Bounces?

Nein. Laut M3AAWG dürfen Absender einen 4xx nicht als dauerhaft behandeln. Zum Bounce wird er erst, wenn die Wiederholungen ausgeschöpft sind oder der Server einen 5xx zurückgibt. In Brew erscheint ein Deferral als Event „Verzögert“, und Kontakte kommen erst nach wiederholten Soft Bounces auf die Sperrliste.