550 5.7.708 “Access denied, traffic not accepted from this IP”: entschlüsselt

Sehen Sie diesen Bounce von einem Empfänger bei Microsoft 365, haben Sie es mit etwas anderem zu tun als dem klassischen S3140 von Outlook.com:

550 5.7.708 Service unavailable. Access denied, traffic not accepted from this IP.
For more information please go to http://go.microsoft.com/fwlink/?LinkID=526654

5.7.708 kommt von Exchange Online Protection (EOP), dem Filter vor jedem Microsoft-365-Tenant. Es ist eine Ablehnung auf IP-Ebene, aber das Reputationssignal wird getrennt von den SNDS-Daten von Outlook.com berechnet.

Was 5.7.708 auslöst

EOP gibt 5.7.708 zurück, wenn die sendende IP auf seiner eigenen internen Sperrliste für Reputation steht. Häufige Ursachen:

• Geteilter Versandpool mit einem schlechten Nachbarn. Ihr ESP hat Sie auf eine IP gesetzt, die ein anderer Kunde missbraucht hat. Für Absender auf geteilter Infrastruktur ist das die Ursache Nr. 1.
• Plötzliche Volumenspitze von einer IP, die bisher wenig gesendet hat.
• Dauerhaft fehlschlagende Authentifizierung: Abweichungen bei SPF / DKIM in großem Umfang.
• Listung auf einer großen DNSBL, die Microsoft nutzt (Spamhaus SBL/PBL).
• Bestätigte Spam-Meldungen von Admins bei Microsoft 365 (das Add-in „Report message“).

Anders als bei S3140 gibt es für 5.7.708 kein öffentliches Delisting-Formular. Der Weg zur Behebung ist ein anderer: Die eigene Lösungsseite von Microsoft zu 5.7.708 verweist Sie an den Microsoft-Support.

So bestätigen Sie, dass es eine echte Sperre ist (kein Throttling)

Microsoft 365 gibt manchmal 4.7.500 / 4.7.501 zurück (vorübergehende Zurückstellung), was ähnlich aussieht, sich aber von selbst erholt. 5.7.708 ist dauerhaft, und Ihre Wiederholungswarteschlange löst es nicht.

Prüfen Sie:

1. Bounce-Klasse: 550 dauerhaft gegenüber 421/450 vorübergehend.
2. Umfang: Bouncen alle Empfänger bei Microsoft 365 oder nur ein Tenant? Ist es nur einer, ist es eine Sperre auf Tenant-Ebene, keine IP-Sperre.
3. Andere Provider: Nehmen Gmail, Yahoo usw. noch an? Wenn ja, betrifft das Problem nur Microsoft (was bei 5.7.708 immer der Fall ist).

Schritt 1: Stellen Sie einen Delisting-Antrag über das Microsoft-Portal

Es gibt kein automatisches Formular. Sie eröffnen einen Support-Fall über:

• Absender auf eigener Infrastruktur: Wenden Sie sich an den Microsoft-365-Admin eines betroffenen Empfänger-Tenants und bitten Sie ihn, eine interne Eskalation einzureichen. Er hat einen anderen Kanal als öffentliche Absender.
• Absender über einen ESP: Ihr ESP muss den Fall einreichen. Wenden Sie sich an dessen Zustellbarkeitsteam und geben Sie den Bounce-Text wörtlich sowie einen Beispiel-Header einer Nachricht an.

In beiden Fällen verlangt der Antrag:

• Die gesperrte(n) IP(s).
• Eine Beschreibung Ihrer Versandpraxis.
• Die Einrichtung der Authentifizierung (SPF/DKIM/DMARC).
• Volumen und die Art, wie Empfänger gewonnen werden.

Bearbeitungszeit: typischerweise 3 bis 7 Werktage.

Schritt 2: Beheben Sie den eigentlichen Grund

Während der Fall offen ist:

• Führen Sie Domain Health für jede Versanddomain aus. SPF, DKIM und DMARC alle grün und im Alignment.
• Prüfen Sie mit dem Blacklist-Checker, ob die IP bei Spamhaus oder anderen DNSBLs gelistet ist. Wenn ja, beantragen Sie dort zuerst das Delisting, denn 5.7.708 verschwindet oft automatisch, sobald die vorgelagerten Listungen entfallen.
• Sind Sie in einem geteilten Pool, fragen Sie Ihren ESP nach der Reputationshistorie der IP. War sie wochenlang belastet, verlangen Sie einen anderen Pool oder wechseln Sie auf eine dedizierte IP.
• Drosseln Sie aggressives Volumen. Throttling bei Microsoft 365 zeigt sich zuerst als 4.7.500 und eskaliert zu 5.7.708, wenn Sie weiter drücken.

Schritt 3: Nach der Entsperrung

Nehmen Sie den Versand langsam wieder auf. EOP bewertet die Reputation in einem gleitenden Zeitfenster neu. Wer am ersten Tag nach der Entsperrung sein früheres Volumen sendet, landet am schnellsten in der zweiten Sperre.

Empfohlene Steigerung:

Tag	% des normalen Volumens
1 bis 2	10 %
3 bis 4	25 %
5 bis 7	50 %
8 bis 10	75 %
11+	100 %

5.7.708 vs. S3140: Kurzübersicht

Symptom	5.7.708	S3140
Filter	EOP (Microsoft 365)	Filter von Outlook.com
Betroffene Empfänger	M365-Tenants	Outlook.com / Hotmail / Live
Öffentliches Delisting-Formular?	Nein	Ja (Formular des Outlook.com-Absendersupports)
Weg zur Lösung	Support-Fall über Tenant oder ESP	Delisting-Formular von Outlook.com
Typische Bearbeitungszeit	3 bis 7 Werktage	24 bis 48 Stunden

Häufige Fragen

Kann ein Absender bei EOP gesperrt sein, aber nicht bei Outlook.com? Ja. Die beiden Systeme teilen Signale, bewerten aber unabhängig. Es kommt häufig vor, dass man bei S3140 sauber ist, aber von 5.7.708 gesperrt, besonders in einem geteilten IP-Pool.

Löst ein IP-Wechsel 5.7.708? Ja, sofort, wenn die neue IP eine saubere EOP-Reputation hat. Beheben Sie aber nicht die eigentliche Ursache, bekommt auch die neue IP innerhalb von Wochen ein 5.7.708.

Hilft eine durchgesetzte DMARC-Richtlinie? Erheblich. EOP bewertet E-Mails mit DMARC-Alignment deutlich günstiger als p=none. Stehen Sie auf p=none, wechseln Sie mit dem DMARC-Generator zu p=quarantine.

Verwandte Beiträge

• 550 5.7.1 bei Microsoft beheben
• 421 4.7.500: das Throttling von Microsoft entschlüsselt
• Die Filterung von Exchange Online Protection erklärt

Quellen

• Fix NDR error codes 550 5.7.703, 5.7.705, 5.7.708 and 5.7.750 (Microsoft Learn), Microsoft führt 5.7.708 „traffic not accepted from this IP“ auf eine IP mit niedriger Reputation zurück und verweist an den Microsoft-Support.
• Email nondelivery reports and SMTP errors in Exchange Online (Microsoft Learn), die vorübergehende Einschränkung 4.7.500-699 neben den Tenant- und IP-Sperren 5.7.705/5.7.708.
• Use the delist portal to remove yourself from the blocked senders list (Microsoft Learn), sender.office.com behandelt Sperren von Microsoft 365 (5.7.606-649), mit einem eigenen Formular für Outlook.com.
• Built-in security features for all cloud mailboxes (Microsoft Learn), wonach Exchange Online Protection für jedes Cloud-Postfach filtert.