Die meiste Zeit ging in Dinge, die richtig aussahen und falsch waren, oder falsch aussahen und richtig waren.
Ein Diagnosewerkzeug, das beim PTR-Eintrag log
Eine Abfrage des PTR-Eintrags des Servers lieferte einen völlig anderen Test-Hostnamen, was nach einem schweren Widerspruch zum HELO-Namen aussah. Die Ursache war der lokale Resolver auf der Diagnosestation: Er beantwortete PTR-Anfragen aus der Hosts-Datei des Rechners. Im öffentlichen DNS war der Eintrag die ganze Zeit korrekt. Von da an ging jede DNS-Prüfung direkt an die autoritativen Server und an einen öffentlichen Resolver.
Microsoft sagte, die Adresse sei nicht gesperrt, und wies Post trotzdem ab
So sah die Unzustellbarkeitsmeldung aus, die ein Nutzer bekam; Adressen und Zeitstempel sind anonymisiert:
<**************@hotmail.com>: host hotmail-com.olc.protection.outlook.com[x.x.x.x]
said: 550 5.7.1 Unfortunately, messages from [x.x.x.x] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3150). You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors.
[Name=Protocol Filter Agent][AGT=PFA][MxId=**************] [**************.eurprd04.prod.outlook.com 2026-03-17T08:14:52.316Z **************] (in reply to MAIL FROM command)
Die Abweisungen trugen den Code S3150, während das Selbstbedienungsportal von Microsoft beteuerte, die IP-Adresse sei nicht gesperrt. S3150 bedeutet eine Sperre eines Adressbereichs beim Hosting-Anbieter, nicht einer einzelnen Adresse, und das Portal kennt nur einzelne Adressen. Der Weg führte über ein Ticket beim Microsoft-Support, eskaliert mit Fakten: SPF, DKIM und DMARC in allen Domains, saubere öffentliche Blacklists, geringes Volumen, nur authentifizierte Absender. Die Bestätigung, dass die Sperre aufgehoben ist, kam 1 Stunde 18 Minuten nach der ersten Nachricht an den Support. DKIM und DMARC heben eine solche Sperre nicht auf, weil Microsoft die Verbindung abweist, bevor es die Nachricht sieht; vollständige Authentifizierung macht die Eskalation aber deutlich stärker.
Der Server hätte eingehenden Spam signieren können
Mit global aktiviertem Signier-Milter, wie es die meisten Anleitungen vorsehen, wäre von amavis geprüfte Post auf dem Rückweg in Postfix ein zweites Mal durch ihn gelaufen. Eingehender Spam mit gefälschtem Absender aus einer der vier Domains hätte so eine gültige DKIM-Signatur dieser Domain erhalten. Die Milter sind deshalb auf dem Port, über den amavis die Post zurückgibt, und auf dem öffentlichen Port 25 abgeschaltet.
Ein Tag in einem DKIM-Eintrag, und die TTL
Der Schlüsseltest scheiterte mit „unknown hash“: Das Tag h= in einem DKIM-Eintrag nimmt Hash-Namen wie sha256 an, nicht den Namen des Signaturalgorithmus. Empfänger, die sich an die Spezifikation halten, hätten jede Signatur abgelehnt. Der Eintrag wurde korrigiert, bevor die Domain etwas signierte, und der Schlüsseltest wurde zur Bedingung für das Einschalten. Weil der Eintrag eine TTL von einem Tag hatte, hätten Resolver die falsche Fassung 24 Stunden im Cache halten können; für den Rollout wurde die TTL auf eine Stunde gesenkt.
Unzustellbarkeitsmeldungen brauchen SPF für den eigenen Servernamen
Eine Unzustellbarkeitsmeldung hat einen leeren Umschlagabsender, SPF prüft dann stattdessen den HELO-Namen des Servers. Ohne SPF-Eintrag für diesen Namen würden solche Meldungen an DMARC scheitern, sobald die Hauptdomain auf reject wechselt, und externe Absender würden nie erfahren, dass ihre Mail nicht angekommen ist. Ein Eintrag hat das behoben.
