E-Mail-Zustellbarkeit für Erwachsenenanzeigen: warum der Bestätigungscode nie ankommt
Der Ausfall, für den niemand eine Warnung bekommt
Ein neuer Nutzer meldet sich an, gibt eine E-Mail-Adresse ein und wartet auf den sechsstelligen Code, mit dem er die Altersverifizierung abschließen kann. Er kommt nicht innerhalb der Minute an, in der er ankommen sollte. Vielleicht landet er zehn Minuten später im Spam-Ordner, lange nachdem der Nutzer aufgegeben und den Tab geschlossen hat. Vielleicht weist der empfangende Mailserver ihn direkt beim Versand ab, mit einer Bounce-Nachricht, die in einem Protokoll vorbeiläuft, das niemand beobachtet. So oder so sagt nichts an dieser Erfahrung dem Betreiber, dass etwas schiefgelaufen ist. Der Anmeldetrichter zeigt einfach einen weiteren Besucher, der eine E-Mail-Adresse eingegeben hat und nie zurückkam, nicht zu unterscheiden von jemandem, der es sich einfach anders überlegt hat.
Diese Unschärfe ist das eigentliche Problem, mehr als jede einzelne technische Ursache. Die meisten Seiten überwachen, ob eine E-Mail gesendet wurde, ein grünes Häkchen in einem Dashboard, nicht ob sie tatsächlich vor einem Menschen gelandet ist. Das sind zwei verschiedene Ereignisse, und genau in der Lücke dazwischen versteckt sich ein Zustellbarkeitsproblem monatelang. Ein Betreiber, der noch nie einen Hosting-Ausfall oder eine eingefrorene Zahlungsabwicklung erlebt hat, kann trotzdem einen echten Anteil neuer Anmeldungen an ein Mail-Problem verlieren, das er gar nicht bemerken kann, weil es keinen Vorfall gibt, kein Support-Ticket, kein rot werdendes Dashboard.
Das ist eine andere Art von Anbieterrisiko als jenes, das ein Hosting-Konto mit einer Mitteilung schließt, die eine Klausel zitiert, die niemand seit der Unterschrift noch einmal gelesen hat. Ein gesperrter Host ist laut: Die Seite geht offline, und der Betreiber erfährt es innerhalb von Minuten, weil Kunden es melden und das Dashboard es auch anzeigt. Ein Zustellbarkeitsproblem ist von Natur aus leise. Das Versandkonto bleibt geöffnet, die monatliche Rechnung kommt weiterhin, und das einzige sichtbare Symptom ist ein Anmeldetrichter, der beim letzten Schritt Leute verliert, aus Gründen, die von der Seite des Betreibers aus wie gewöhnliche Abbrüche aussehen und nicht wie ein behebbarer technischer Fehler.
Die zugrunde liegende Ursache ist trotzdem dieselbe Art von kategoriebedingter Reibung, die auch bei Hostern, Banken und Zahlungsabwicklern auftaucht. Postfach-Anbieter und E-Mail-Versanddienste bewerten diese Kategorie als riskanter als die meisten, manche ausdrücklich und namentlich, und eine neue Domain ohne Versandhistorie startet jede Nachricht mit einem Nachteil, der nichts damit zu tun hat, was die Nachricht tatsächlich sagt.
Warum diese Kategorie härter gefiltert wird als die meisten
Spamfilter und E-Mail-Dienstanbieter behandeln nicht jede Branche gleich, und es lohnt sich, die Unterschiede vor der Anmeldung zu lesen statt danach, wenn ein Konto bereits gemeldet wurde. Die von SendGrid veröffentlichte Richtlinie zu verbotenen Inhalten listet als getrennte Punkte „Pornografie oder sexuell explizite Inhalte" und, davon unterschieden, „Escort-Dienste, Suche nach Bräuten oder Ehepartnern per Korrespondenz, internationale Heiratsvermittlungen und ähnliche Dienste". Diese zweite Kategorie betrifft nicht, was die E-Mail enthält. Sie nennt das Geschäft selbst als Ausschlussgrund, was bedeutet, dass ein reiner Textverifizierungscode eines Escort-Verzeichnisses allein wegen der Kategorie außerhalb der Richtlinie liegen kann, egal wie zurückhaltend die Nachricht formuliert ist.
Die Richtlinie zur akzeptablen Nutzung von Mailgun zieht die Grenze an einer ganz anderen Stelle. Ihr Abschnitt zu verbotenen Inhalten beschränkt sich auf Material, das Ausbeutung von Kindern, Sodomie oder nicht-einvernehmliche Handlungen darstellt oder fördert, ohne eine gesonderte Klausel, die Erwachsenengeschäfte oder Escort-Dienste als Kategorie nennt. Das ist eine deutlich engere Einschränkung als die von SendGrid, gerichtet auf das, was illegal ist, statt auf die Branche, die versendet. Zwei große, breit aufgestellte Anbieter, erreichbar über dieselbe Art von Anmeldeformular, ziehen die Grenze an wirklich verschiedenen Stellen, und ein Betreiber, der einen davon wählt, ohne über die Preisseite hinauszulesen, hat keine Möglichkeit zu wissen, auf welcher Seite dieser Grenze sein Konto liegt, bis eine Überprüfung es aufdeckt.
Das ist dieselbe Sorgfaltslücke, die Betreiber schon bei einer Hosting- oder CDN-Kündigungsklausel überrascht hat, die sie nie gelesen haben, nur eine Ebene tiefer im Stack. Die Frage, die vor der Wahl eines E-Mail-Anbieters zu stellen ist, lautet nicht, ob er technisch erlaubt, für diese Art von Geschäft im Allgemeinen E-Mails zu versenden. Sie lautet, ob die schriftliche Richtlinie des Anbieters die Geschäftskategorie ausdrücklich nennt, schriftlich, bevor der erste Verifizierungscode hinausgeht, nicht erst nachdem eine Missbrauchsprüfung es findet.
Eine neue Versanddomain verschärft das zusätzlich zu allem, was der Anbieter erlaubt. Filter gewichten Historie und Volumenmuster einer Domain stark, und eine Domain, die kürzlich aufgetaucht ist und sofort im großen Umfang automatische Codes versendet, sieht für einen Filter ohne anderes Signal wie das Muster eines Kontos aus, das für einen engen Zweck erstellt und nach der Markierung aufgegeben wurde. Das ist kein Urteil über das Geschäft; es ist ein Musterabgleich, den jede brandneue Domain auslöst, Erwachsenenanzeigen hin oder her, und der nur mit der Zeit und konstantem Versandverhalten verblasst.
Der technische Mindeststandard, den jeder Postfach-Anbieter inzwischen durchsetzt
Selbst ein Anbieter, dessen Richtlinie das Konto vorbehaltlos begrüßt, kann eine E-Mail nicht allein ins Postfach bringen. Seit dem 1. Februar 2024 verlangt Google von jedem Absender, der E-Mails an Gmail-Adressen sendet, unabhängig vom Volumen, eine dokumentierte Grundlage zu erfüllen: mindestens SPF oder DKIM korrekt auf der Versanddomain eingerichtet. SPF listet auf, welche Server im Namen der Domain senden dürfen; DKIM signiert jede Nachricht, damit der empfangende Server bestätigen kann, dass sie unterwegs nicht verändert wurde. Absender, die speziell 5.000 Nachrichten pro Tag an Gmail-Adressen erreichen, stehen vor einer höheren Hürde: SPF und DKIM zusammen, plus DMARC, veröffentlicht auf der Domain, mindestens im Überwachungsmodus. Eine Anzeigenseite, die Altersverifizierungscodes, Passwort-Rücksetzungen und Zahlungsbelege in echtem Umfang versendet, überschreitet diese Schwelle von 5.000 Nachrichten schnell, da jede davon dazu zählt.
Googles eigene veröffentlichte Richtlinien setzen eine feste Zahl oberhalb der Authentifizierung: Absender jeder Größe müssen die über Googles Postmaster Tools gemeldete Beschwerderate unter 0,30 Prozent halten, und dieselben Richtlinien empfehlen, unter 0,10 Prozent zu bleiben, als echten Sicherheitspuffer, statt 0,30 Prozent als bequemes Ziel zu behandeln, dem man sich annähern kann. Nichteinhaltung zeigt sich in zwei getrennten, jeweils gesondert dokumentierten Ausfallarten statt in einer vagen Strafe. Post, die SPF, DKIM oder DMARC nicht besteht, kann als Spam markiert oder direkt mit dem SMTP-Fehler 5.7.26 abgewiesen werden. Absender, die das von Google erlaubte Versandkontingent überschreiten, stoßen auf eine andere Wand, einen Ratenbegrenzungsfehler 4.7.28. Keiner der beiden verkündet „diese Branche ist hier nicht willkommen". Beide sehen vom Dashboard eines Entwicklers aus wie ein gewöhnlicher technischer Fehler, und genau deshalb werden sie eher Wochen später bemerkt als am Tag ihres Auftretens behoben.
Yahoo, dessen Infrastruktur auch AOL-Adressen bedient, veröffentlicht unabhängig dieselbe Art von Anforderung: SPF und DKIM zusammen, eine DMARC-Richtlinie von mindestens p=none, die bestehen muss, und dieselbe 0,30-Prozent-Obergrenze bei der Beschwerderate, seit Februar 2024 nach demselben Zeitplan in Kraft. Ein Betreiber, der dies für Gmail löst und annimmt, dass Yahoo und AOL mitziehen, liegt in der Mechanik meist richtig, da die beiden Anbieter sich auf nahezu identische Zahlen zubewegt haben, aber die beiden Systeme messen und setzen die Regeln weiterhin getrennt durch, sodass eine Domain, die bei einem in gutem Stand ist, es beim anderen nicht automatisch auch ist.
Eine Anforderung in diesem Regelwerk ist absichtlich eng gefasst. Ein-Klick-Abmeldung, über den List-Unsubscribe-Header, gilt in Googles eigenem Wortlaut ausdrücklich für Marketingnachrichten und abonnierte Nachrichten. Ein Verifizierungscode oder ein Zahlungsbeleg ist keines von beidem, also zielt genau diese Zeile nicht darauf ab. Die Authentifizierungs- und Reputationsanforderungen darüber, SPF, DKIM, DMARC und die Beschwerdeobergrenze, sind nicht so begrenzt: Sie gelten für jede Nachricht, die eine Domain versendet, transaktionale eingeschlossen.
Der Fehler, der auch die wichtige Post mit nach unten reißt
Der häufigste Weg, wie ein Betreiber seine eigenen Verifizierungs-E-Mails beschädigt, ist der Versand von Marketingpost von derselben Domain, die auch Verifizierungscodes und Zahlungsbelege versendet. Reputation wird vor allem auf Ebene der Versanddomain und -subdomain erfasst, weshalb das Trennen der Ströme hilft, aber die Isolation zwischen Subdomains ist nicht absolut: Ein Beschwerdeausschlag auf einer Subdomain kann sich immer noch auf die übergeordnete Domain auswirken, besonders wenn beide Ströme im Hintergrund dieselbe DKIM-Signaturidentität teilen. Eine Werbe-E-Mail, die eine neue Funktion oder ein saisonales Angebot ankündigt und an eine veraltete Liste geschickt wird, erzeugt genau die Art von Beschwerdeausschlag, die die Reputation einer geteilten Domain nach unten drücken kann, und ein Teil dieses Schadens erreicht den Verifizierungscode, auf den ein gerade neu angemeldeter Nutzer genau jetzt wartet, eine Nachricht, die nichts mit dem Marketingversand zu tun hat, der das Problem verursacht hat.
Genau hier verschränkt sich auch die operative Disziplin rund um die Altersverifizierung mit einem rein technischen Zustellungsproblem, auf eine leicht zu übersehende Weise. Ein Verifizierungsablauf, der davon abhängt, dass ein Code in einem Postfach ankommt, ist nur so zuverlässig wie die Reputation der Versanddomain an dem Tag, an dem dieser Code hinausgeht, und Reputation ist eine Ressource, die zwischen allen Nachrichtenarten geteilt wird, die verwandte Infrastruktur nutzen, es sei denn, der Betreiber hält sie absichtlich getrennt.
Die Lösung ist strukturell, keine Einstellung, die man umlegt, nachdem ein Beschwerdeausschlag bereits passiert ist. Versenden Sie transaktionale Post, Verifizierungscodes, Zahlungsbestätigungen, Passwort-Rücksetzungen, von einer eigenen Subdomain, die für nichts anderes verwendet wird, zum Beispiel mail.beispiel.com statt der nackten Domain oder einer geteilten Marketing-Subdomain, und signieren Sie sie mit einem eigenen DKIM-Schlüssel statt einem, der über alle Ströme hinweg wiederverwendet wird. Versenden Sie Marketinginhalte oder Newsletter von einer vollständig getrennten Subdomain, etwa news.beispiel.com, mit eigenen Authentifizierungseinträgen und eigener Reputation, die eine schlechte Beschwerdewoche abfedern kann, ohne die Post mit nach unten zu ziehen, die unbedingt ankommen muss. Beide Ströme können über dasselbe Konto beim Anbieter laufen, müssen aber aus Sicht des empfangenden Mailservers wie erkennbar unterschiedliche Absender aussehen und signiert sein.
Was diese Woche wirklich zu prüfen ist
Beginnen Sie damit, die Richtlinie zur akzeptablen Nutzung des Dienstes hervorzuholen, der gerade die transaktionale Post der Seite versendet, und finden Sie schriftlich heraus, ob sie die Geschäftskategorie ausdrücklich nennt, genauso wie die frühere Prüfung von Hosting- und CDN-Verträgen bei Infrastrukturanbietern funktioniert hat. Ein Anbieter, dessen Richtlinie die Kategorie bereits namentlich ausschließt, ist kein Anbieter, auf dem man einen Verifizierungsablauf aufbauen sollte, egal wie zuverlässig er bisher war, denn eine Kontoprüfung kann diese Zuverlässigkeit ohne jede Vorwarnung beenden.
Prüfen Sie, ob SPF, DKIM und DMARC auf der Domain, die gerade jetzt Verifizierungs- und Belegs-E-Mails versendet, tatsächlich veröffentlicht sind und bestanden werden, statt es als korrekt vorauszusetzen, weil jemand sie vor Jahren einmal eingerichtet hat. Ein DNS-Eintrag, der richtig war, als er geschrieben wurde, kann nach einer Anbietermigration veralten, und eine Domain ohne Authentifizierung startet jede Nachricht mit einer echten Ablehnungschance nach den Regeln, die Google und Yahoo seit Februar 2024 durchsetzen, unabhängig davon, was die Nachricht sagt.
Trennen Sie transaktionale und Marketingpost auf getrennte Subdomains mit getrennten Signaturschlüsseln, falls sie es noch nicht sind, und behandeln Sie das als Infrastrukturarbeit statt als Entscheidung des Marketingteams, denn ein Fehler hier kostet eine gescheiterte Identitätsprüfung, keinen entgangenen Verkauf.
Beobachten Sie die tatsächliche Beschwerderate über die eigenen Berichte des Anbieters oder über Googles Postmaster Tools nach einem festen Zeitplan, und behandeln Sie jede Annäherung an 0,10 Prozent als den Punkt, an dem zu untersuchen ist, nicht 0,30 Prozent, denn 0,30 Prozent liegt näher an dem Punkt, an dem Post zurückgewiesen wird, als an dem Punkt, an dem ein Problem beginnt. Und schicken Sie gelegentlich eine echte Test-Anmeldung an eine persönliche Gmail- und eine persönliche Yahoo-Adresse, und stoppen Sie, wie lange der Code braucht, um anzukommen, und wo er landet, denn ein Dashboard, das einen erfolgreichen Versand meldet, meldet, was den Server verlassen hat, nicht, was ein Nutzer tatsächlich gesehen hat.
