Externes Reputations-Feedback

Die Seite „Zustellungsgesundheit“ von Owlat vergleicht das eigene Beschwerdesignal mit Reputationsdaten, die von Mailbox-Providern gemeldet werden. Provider-Daten sind verzögert und stichprobenbasiert; nutzen Sie sie als Indiz neben den SMTP-Ergebnissen, nicht als Echtzeit-Zustellgarantie.

Google Postmaster Tools

Die API von Google verlangt eine OAuth-2.0-Autorisierung durch einen Benutzer, der die Authentifizierungsdomain lesen darf. Eine von Owlat durchgeführte DNS-Prüfung gewährt diesem Google-Konto keinen Zugriff. Registrieren und verifizieren Sie die DKIM-d=-Domain oder die SPF-Return-Path-Domain in den Postmaster Tools und legen Sie anschließend einen OAuth-Client mit aktivierter Postmaster-Tools-API an.

Fordern Sie ausschließlich diese Lese-Scopes an:

• https://www.googleapis.com/auth/postmaster.domain
• https://www.googleapis.com/auth/postmaster.traffic.readonly

Erzeugen Sie ein Offline-Refresh-Token für den Google-Benutzer und konfigurieren Sie alle drei MTA-Variablen gemeinsam:

GOOGLE_POSTMASTER_CLIENT_ID=...
GOOGLE_POSTMASTER_CLIENT_SECRET=...
GOOGLE_POSTMASTER_REFRESH_TOKEN=...

Starten Sie die MTA neu. Der Leader fragt die v2-Ressource domainStats stündlich für die vorangegangenen sieben UTC-Tage ab, weil Google Daten üblicherweise mit Verzögerung veröffentlicht. Ein persistierter, begrenzter Domain-Cursor deckt mit der Zeit auch Konten mit mehr Domains ab, ohne dass ein einzelner Lauf unbegrenzt wachsen kann. Der Collector besitzt zudem ein verteiltes Overlap-Lease, ein Wall-Clock-Budget, einen Refresh-Versuch bei 401 sowie begrenzte Retries für Retry-After und transiente Fehler.

Das Refresh-Token bleibt in der MTA-Umgebung, das Access-Token bleibt kürzer als seine vom Provider deklarierte Lebensdauer in Redis, und keines von beiden wird an Convex, an Logs, an Prometheus oder an den Browser gesendet. Bevor die MTA Statistiken abfragt oder einen Cursor bzw. eine Quittung je Domain anlegt, fragt sie den signierten Convex-Endpunkt, ob genau diese Domain in Owlat aktuell verifiziert ist. Die Antwort enthält nur accepted_authorized oder ignored_unowned; sie legt keinen Mandantendatensatz offen. Autorisierungsprüfungen und Beobachtungen umgehen die generische Audit-Speicherung roher Webhooks, und die MTA legt sie niemals in ihre generische Dead-Letter-Queue. Eine fehlgeschlagene Zustellung lässt die Domain-Seite ohne Checkpoint zurück, sodass der nächste begrenzte Durchlauf sie gefahrlos erneut versucht. Nur eine Beobachtung mit accepted_authorized erzeugt eine Quittung. Ein persistenter Generationsindex erlaubt es jedem abgeschlossenen Discovery-Zyklus, Cursor- und Quittungszustand für Domains zu entfernen, die Google nicht mehr auflistet — auch über MTA-Neustarts hinweg; die Bereinigung ist pro Lauf gedeckelt und scannt niemals den Redis-Keyspace. Es wird keine Postmaster-Metrik je Domain exportiert: Das Dashboard konsumiert das strukturierte Convex-Aggregat. Owlat bewahrt dieses Tagesaggregat 90 Tage auf und löscht es, sobald die Versanddomain entfernt wird; ein Replay für eine unverifizierte oder gelöschte Domain wird bestätigt, ohne ihren Namen oder ihre Nutzlast aufzubewahren.

Owlat erhebt je verifizierter Domain und UTC-Tag:

• SPAM_RATE — den Anteil der zugestellten Mails, den Gmail-Nutzer als Spam gemeldet haben.
• SPF_SUCCESS_RATE, DKIM_SUCCESS_RATE, DMARC_SUCCESS_RATE — den Anteil des Traffics, der sich authentifiziert hat, gemessen von Google statt vorhergesagt von unserer eigenen DNS-Prüfung.
• DELIVERY_ERROR_RATE plus eine Best-Effort-Aufschlüsselung nach Kategorien (Rate-Limiting, Spamverdacht, schlechte DMARC-Policy und so weiter).
• Das v2-Verdikt Compliance Status: das Bestehen/Nichtbestehen jeder Prüfung, gespeichert mit dem von Google gemeldeten Prüfungsnamen. Ein Prüfungsname, zu dem Owlat keine Handlungsempfehlung hat, wird beibehalten und generisch dargestellt statt verworfen.

Google kann eine Metrik auslassen, wenn das Aufkommen zu gering ist. No data ist keine Spam-Rate von null, und ein unvollständiger Tag ist normal — eine fehlende Metrik ist in der gespeicherten Zeile schlicht nicht vorhanden. Der aktuelle v2-Vertrag StandardMetric stellt die v1-Felder zu Domain-Reputation, IP-Reputation, Beispiel-IP und Konfidenzgrenzen der Spam-Rate nicht bereit. Owlat markiert diese Reputationsdetails als nicht verfügbar; es ruft weder v1 mit inkompatiblen v2-Scopes auf noch leitet es Bewertungen aus einer anderen Metrik ab. Sollte Google Reputationsmetriken zu v2 hinzufügen, kann Owlat sie gegen diesen veröffentlichten Vertrag ergänzen.

Postmaster Tools ist rein additiv. Ein Deployment ohne verbundenes Google-Konto versendet exakt dieselbe Post: Der Collector kehrt frühzeitig zurück, es wird nichts geschrieben, nichts schlägt fehl, und die Zustellungsseite zeigt einen Hinweis „nicht verbunden“, der erklärt, dass eine Verbindung die Messkonfidenz erhöht. Nicht bestandene Compliance-Prüfungen erscheinen als handlungsleitende Karten auf der Zustellungsseite, die Prüfung und Abhilfe benennen — niemals als rohes API-Feld.

Quellen: Google-API-Einrichtung und OAuth-Scopes, Einrichtung der Authentifizierungsdomain, der Migrationsleitfaden von v1 zu v2, v2-Abfrage der Domain-Statistiken und v2-Standardmetriken.

Microsoft SNDS und JMRP

Microsofts Smart Network Data Services sind IP-orientiert. Melden Sie sich mit einem Microsoft-Konto an, beantragen Sie Zugriff auf jede öffentliche ausgehende IP, die Sie kontrollieren, und durchlaufen Sie den Autorisierungsprozess des Portals. Nutzen Sie anschließend View Data und View IP Status, um auffälliges Verhalten und die Reputation zu beobachten.

Melden Sie dieselben IPs im selben Portal für das Junk Mail Reporting Program an und lassen Sie die Berichte an ein überwachtes Abuse-Postfach senden. JMRP-Berichte sind Beschwerdebelege: Verarbeiten Sie sie zügig über den bestehenden Feedback-/Suppression-Ablauf und mailen Sie einen sich beschwerenden Empfänger nie erneut an. Owlat braucht dafür keine neue Infrastruktur — JMRP-Berichte sind ARF nach RFC 5965 und landen daher im selben Feedback-Prozessor wie die Beschwerden jedes anderen ISPs, dem ursprünglichen Versand über dessen signierten VERP-Return-Path zugeordnet. Microsoft lässt die Standard-Empfängerfelder häufig weg und führt die sich beschwerende Adresse nur in X-HmXmrOriginalRecipient an der wieder angehängten Originalnachricht mit; der Prozessor liest dieses Feld als letzten Ausweg.

Den SNDS-Datenfeed importieren

Microsofts Portal-Ankündigung vom Juli 2026 hat die alten Links sendersupport.olc.protection.outlook.com/snds/ durch kontospezifische Automated Data Access-URLs ersetzt. Erzeugen Sie eine URL je registriertem IP-Bereich und setzen Sie sie als SNDS_DATA_FEED_URLS (durch Komma oder Leerraum getrennt, ausschließlich https). Behandeln Sie sie als geheim: Jede URL ist eine Bearer-Berechtigung für Ihre SNDS-Daten.

Owlat fragt diese Feeds alle sechs Stunden ab und speichert eine Zeile je Versand-IP und UTC-Tag — das Band der Beschwerderate, das Filterergebnis, Treffer in Spam-Traps und die Volumenzähler des Tages — mit 90 Tagen Aufbewahrung. Der Feed meldet Aktivität in Zeitfenstern unterhalb eines Tages; ein Tag faltet sie zusammen, summiert die Zähler und behält das schlechteste Band und Filterergebnis des Tages. Registrierte Bereiche überlappen sich, deshalb faltet sich ein Tag, den zwei Ihrer Feeds melden, in genau dieselbe eine Zeile statt in zwei konkurrierende.

SNDS meldet ein Band der Beschwerderate, keine Rate, deshalb speichert Owlat das Band und argumentiert damit. 0.1% - < 0.2% wird nie in 0.0015 umgerechnet: Das würde eine Präzision erfinden, die Microsoft nie veröffentlicht hat, und jede nachgelagerte Entscheidung würde anschließend eine erfundene Zahl vergleichen. Eine Bandschreibweise, die Owlat nicht erkennt, wird als unknown gespeichert, was den Ramp hält statt ihn zu bewegen. Der Parser gleicht die Spalte als Ganzes gegen Microsofts dokumentierte Schreibweisen ab — < 0.1%, > 0.9% und Bereiche mit einer Bandbreite wie 0.3% - < 0.4% — und liest nie eine Zahl aus Text heraus, den er nicht ansonsten erkennt. Eine Grenze, die keine Bandkante ist (< 0.5% umfasst fünf Bänder), ein verbreiterter Bereich (0% - < 0.9% umfasst neun), ein lokalisiertes Dezimaltrennzeichen und eine sprachliche Umformulierung sind daher allesamt unknown statt geraten. Der Feed kommt aus dem Internet, < 0.1% ist das einzige Band, das eine Beschleunigung des Ramps rechtfertigen kann, und die eine Richtung, in die der Parser niemals fehlgehen darf, ist „sauberer als gemessen“.

Das Gate wird ab 0.1% - < 0.2% aufwärts verletzt — passend zum Beschwerde-Gate, neben dem es steht — und ebenso bei jedem roten Filterergebnis und jedem Spam-Trap-Treffer. Jede Abfrage und jeder Gate-Lesevorgang ist begrenzt: Der Feed-Body wird bereits beim Streamen gedeckelt, die Anzahl der (IP, Tag)-Beobachtungen je Abfrage ist gedeckelt, und sowohl der Ingest als auch das Gate arbeiten neueste Tage zuerst, damit eine Verletzung desselben Tages niemals hinten aus einem Limit herausfallen kann — ein Tag, der nie gespeichert wurde, läse sich später sonst als ein Tag, an dem nichts falsch war. Ein Lesevorgang, der sein Limit erreicht, wird als Lesevorgang mit geringer Konfidenz markiert, sodass ein unvollständiges Fenster den Ramp zwar verlangsamen, seine Beschleunigung aber nie rechtfertigen kann.

Die Anmeldung ist optional, und ihr Fehlen ist eine unterstützte Konfiguration und kein unvollständiges Setup. Ist kein Feed konfiguriert, kehrt der Poller sofort zurück — keine Anfrage, keine Zeile, kein Fehler — und der Microsoft-Ramp stützt sich stattdessen auf die Ergebnisse der eigenen Sendungen (Bounce-, Deferral- und Beschwerderaten sowie die Seed-Platzierung bei Outlook), verweilt doppelt so lange, bevor er weitergeht, und deckelt eine Phase niedriger. Wenn Sie Ihre Versandadressen in MTA_IP_POOLS deklarieren, werden Feed-Zeilen für jede andere Adresse verworfen, da ein SNDS-Schlüssel einen ganzen registrierten Bereich abdecken kann.

MTA_IP_POOLS begrenzt auch den Lesevorgang des Gates, nicht nur den Ingest. Mit deklariertem Pool liest das Gate nur die Tage, die gegen diese Adressen erfasst wurden. Ohne deklarierten Pool liest es das Fenster als Ganzes, markiert es aber als nicht zugeordnet: Ein sauberes Band in einem gemeinsam genutzten registrierten Bereich kann einem anderen Versender gehören, deshalb bleibt es zum Verlangsamen des Ramps nutzbar und kann ihn niemals beschleunigen. Konkret: Ein sauberes, nicht zugeordnetes Fenster hält den Ramp, statt ihn zu bestehen, denn ein Bestehen ist das, was die saubere Serie wachsen lässt, aus der eine Erhöhung bezahlt wird — und ein Spam-Trap-Treffer, der in einem solchen Fenster der einzige verletzende Beleg ist, hält ebenfalls. Belege, die einem Nachbarn gehören könnten, bewegen den Ramp in keine Richtung. Verletzungen bleiben unverändert: Ein rotes Filterergebnis oder ein Band auf oder über dem Verletzungsband lässt das Gate weiterhin scheitern, ob das Fenster zugeordnet ist oder nicht, denn ein Problem innerhalb unseres eigenen registrierten Bereichs müssen wir trotzdem verantworten. Jedes aus einem nicht zugeordneten Fenster abgeleitete Verdikt sagt das in seiner Begründung und benennt die Abhilfe. Ihren Pool zu deklarieren ist deshalb der günstigste Weg, die Messkonfidenz der Microsoft-Zelle zu erhöhen — und, wie bei jedem anderen externen Signal hier, ihn nicht zu deklarieren verlangsamt den Ramp und tut sonst nichts.

Microsoft-Quellen: SNDS-Portal und Anmeldung und Outlook.com-Fehlerbehebung für Versender.