📄 E-Mails aus Microsoft 365 kommen bei GMX, web.de oder iCloud nicht an

E-Mails aus Microsoft 365 kommen bei GMX, web.de oder iCloud nicht an

Mails kommen nicht an, aber nur bei bestimmten Empfängern: Nachrichten aus Microsoft 365 werden von GMX, web.de und iCloud abgewiesen, während Gmail sie zustellt. Ursache ist fast immer die Absenderdomain in Verbindung mit fehlender E-Mail-Authentifizierung per SPF, DKIM und DMARC. Dieser Leitfaden zeigt, wie Sie die Ursache eingrenzen und dauerhaft beheben.

Symptombild: Mails kommen bei einzelnen Providern nicht an

Mails an gmx.de, web.de und icloud.com laufen in einen Unzustellbarkeitsbericht, Mails an gmail.com und an regionale Provider gehen durch. Der Bericht trägt die Überschrift „<Empfänger> wurde nicht in <Domain> gefunden, oder das Postfach ist nicht verfügbar“. Die Postfächer der Empfänger sind nachweislich in Ordnung.

Was die Fehlermeldung wirklich bedeutet

Die Überschrift des Berichts ist irreführend. Microsoft bildet jede fremde 550-Antwort auf den Statuscode 5.1.351 ab und formuliert daraus einen Empfängerfehler. Maßgeblich ist allein der Text im Feld Fehler weiter unten im Bericht. Steht dort „Reject due to policy restrictions“, ist die Empfängeradresse korrekt und es liegt eine Richtlinien-Ablehnung des empfangenden Providers vor. Die Suche nach Tippfehlern in der Adresse führt in diesem Fall nirgendwo hin.

Warum ausgerechnet GMX, web.de und iCloud

gmx.de, gmx.net und web.de gehören zum selben Betreiber. Zwei vermeintlich unabhängige Ausfälle sind also ein einziges Regelwerk. iCloud ist das zweite. Beide lehnen unauthentifizierte oder schlecht beleumundete Absender hart ab, während Google pro Nachricht bewertet und deutlich toleranter ist. Fällt genau diese Kombination aus, liegt die Ursache nahezu immer auf Absenderseite.

Prüfschritte: die Ursache eingrenzen

  1. Absenderadresse im Bericht lesen, unter „Details der ursprünglichen Nachricht“. Steht dort eine Adresse der Form @<name>.onmicrosoft.com statt der eigenen Firmendomain, ist das mit hoher Wahrscheinlichkeit die Ursache. Diese Standarddomain vergibt Microsoft beim Anlegen eines Tenants. Sie wird massenhaft für Spam missbraucht und deshalb von strengen Empfängern pauschal abgelehnt.
  2. DNS der Firmendomain prüfen. Der MX-Eintrag muss auf *.mail.protection.outlook.com zeigen, der SPF-Eintrag include:spf.protection.outlook.com enthalten. Dazu gehören die beiden DKIM-Selektoren selector1._domainkey und selector2._domainkey sowie ein DMARC-Eintrag unter _dmarc.<domain>. Fehlende DKIM-Einträge und fehlendes DMARC sind bei älteren Einrichtungen der Normalfall.
  3. Fallcode des Providers auswerten. GMX und web.de hängen an die Ablehnung eine Adresse der Form postmaster.gmx.net/en/case?c=<code>&i=<kriterium>&v=<wert>. Der Code r1102 steht für eine Ablehnung wegen Blockliste oder Richtlinie. Der Parameter i nennt das Kriterium, auf das der Provider gematcht hat: ip für die Sende-IP, domain für die Absenderdomain.
  4. Sende-IP einordnen. Die IP aus dem Bericht gegen die offizielle Microsoft-365-Endpunktliste prüfen. Liegt sie in einem der veröffentlichten Exchange-Online-Bereiche, handelt es sich um einen geteilten Ausgangspool, den sich viele Microsoft-Kunden teilen. Eine solche IP lässt sich nicht einzeln freikaufen – die Reputation muss über saubere Absenderauthentifizierung kommen.
  5. Breite prüfen. Ist nur ein einzelner Tenant betroffen, liegt es an dessen Absenderkonfiguration. Melden mehrere unabhängige Systeme gleichzeitig denselben Fallcode, ist tatsächlich ein Microsoft-Ausgangspool gesperrt.

Eine Spamhaus-Abfrage lässt sich nicht über öffentliche DNS-Resolver durchführen, Spamhaus beantwortet solche Anfragen nicht. Ein leeres Ergebnis darf deshalb nie als „nicht gelistet“ gewertet werden. Die Prüfung gehört auf check.spamhaus.org.

Behebung: SPF, DKIM und DMARC richtig einrichten

  1. Firmendomain als Absender erzwingen. Die Firmendomain als Standarddomain des Tenants setzen und bei jedem Benutzer die primäre SMTP-Adresse sowie möglichst den Anmeldenamen auf die Firmendomain umstellen. Die onmicrosoft-Adresse bleibt als Alias erhalten, damit nichts abreißt. Dieser Schritt löst die meisten Fälle bereits allein.
  2. DKIM einrichten. Im Defender-Portal DKIM für die Domain aktivieren und die beiden von Microsoft vorgegebenen CNAME-Einträge beim DNS-Betreiber der Domain veröffentlichen. Exchange Online signiert danach jede ausgehende Nachricht.
  3. DMARC veröffentlichen. Einstieg mit v=DMARC1; p=none; rua=mailto:…, damit zunächst nur berichtet wird. Nach einigen Wochen Auswertung auf quarantine verschärfen.
  4. Nachtesten an je eine gmx.de-, web.de- und icloud.com-Adresse. DNS-Änderungen brauchen bis zu einigen Stunden, bis sie überall greifen.
  5. Scheitert der Versand danach mit sauber authentifizierter Firmendomain weiter, liegt es an der geteilten Sende-IP. Dann den Postmaster des Providers mit dem vollständigen Bericht kontaktieren und parallel den Tenant auf ein kompromittiertes Postfach prüfen: Ausgangs-Spamberichte, eingeschränkte Benutzer, unbekannte Weiterleitungsregeln, Anmeldeprotokolle. Ein blockierter Ausgangspool geht häufig auf ein gekapertes Postfach zurück.

Häufige Fragen

Warum kommen meine Mails bei GMX nicht an, bei Gmail aber schon?
GMX und web.de prüfen strenger als Google und lehnen Absender ohne saubere Authentifizierung pauschal ab. Gmail bewertet jede Nachricht einzeln.

Muss ich SPF, DKIM und DMARC alle drei einrichten?
Ja. SPF allein genügt heute nicht mehr. Erst das Zusammenspiel aus SPF, DKIM und DMARC weist Ihre Domain gegenüber strengen Empfängern zuverlässig aus.

Wie lange dauert es, bis die Änderung wirkt?
Die Umstellung selbst ist in kurzer Zeit erledigt. DNS-Änderungen brauchen anschließend einige Stunden, bis sie weltweit greifen.

Nützliche Anlaufstellen

Weitere gelöste Fälle finden Sie in unserer Sammlung von Lösungswegen. Wenn Sie die Umstellung nicht selbst durchführen möchten, hilft Ihnen der IT-Support der OIT GmbH weiter.