[{"data":1,"prerenderedAt":2762},["ShallowReactive",2],{"search-de":3,"content-de-developer\u002Fdeliverability-infrastructure":4,"surround-de-\u002Fdeveloper\u002Fdeliverability-infrastructure":2753},[],{"id":5,"title":6,"body":7,"description":2745,"extension":2746,"meta":2747,"navigation":2748,"path":2749,"seo":2750,"stem":2751,"__hash__":2752},"content_de\u002F3.developer\u002F19.deliverability-infrastructure.md","Zustellbarkeits-Infrastruktur",{"type":8,"value":9,"toc":2712},"minimark",[10,14,37,42,57,65,179,211,216,243,323,359,362,389,396,412,422,436,447,469,473,487,532,536,548,595,617,621,651,655,673,749,753,770,834,838,869,883,887,893,950,964,968,971,1047,1050,1109,1112,1116,1204,1207,1248,1258,1262,1265,1363,1377,1381,1388,1420,1436,1443,1460,1469,1473,1484,1528,1535,1578,1589,1593,1597,1600,1667,1671,1690,1758,1781,1785,1796,2120,2124,2161,2223,2227,2258,2336,2340,2358,2375,2382,2385,2494,2498,2515,2690,2694,2698,2702,2707],[11,12,13],"p",{},"Diese Seite bildet die Zustellbarkeits-Maschinerie ab, die im Convex-Backend liegt: wie ein Sendevorgang einen Provider auswählt, wie Provider-Ausfälle in das Failover einfließen, wie sich Zustellereignisse zu einem Reputationswert summieren, der das Deployment automatisch verwarnen oder sperren kann, die zwischengespeicherte Sicht auf den IP-Warming-Zustand, die Adress-Blockliste sowie die täglichen Sendezähler samt der Schwellenwerte für den Content-Scan vor dem Versand.",[11,15,16,17,21,22,27,28,32,33,36],{},"Die Intelligenz auf der ",[18,19,20],"em",{},"Sendeseite"," — Throttling pro ISP, der eigentliche IP-Warming-Fahrplan, Circuit Breaker und DNSBL-Monitoring — liegt im MTA, nicht in Convex. Siehe dazu ",[23,24,26],"a",{"href":25},"\u002Fdeveloper\u002Fmta-system","MTA-System",". Diese Seite behandelt alles, was Convex verantwortet; beide treffen sich am ",[29,30,31],"code",{},"\u002Fip-reputation","-Snapshot des MTA, an der authentifizierten Lease-Grenze ",[29,34,35],{},"\u002Fsend\u002Fdecision"," und an den Webhooks für Zustellung und Routing-Reentry.",[38,39,41],"h2",{"id":40},"provider-routing-und-strategien-pro-organisation","Provider-Routing und -Strategien pro Organisation",[11,43,44,45,48,49,52,53,56],{},"Ein Deployment kann jeden Nachrichtentyp an einen anderen E-Mail-Provider routen oder einen einzelnen Typ auf mehrere aufteilen. Routen liegen in der Tabelle ",[29,46,47],{},"providerRoutes"," (",[29,50,51],{},"apps\u002Fapi\u002Fconvex\u002Fschema\u002Fdelivery.ts",") und werden über ",[29,54,55],{},"apps\u002Fapi\u002Fconvex\u002FproviderRoutes.ts"," verwaltet.",[11,58,59,60,64],{},"Jede Routenzeile ist auf ",[61,62,63],"strong",{},"einen Nachrichtentyp"," geschlüsselt und trägt eine Strategie, eine geordnete Provider-Liste und einen optionalen IP-Pool-Override:",[66,67,68,84],"table",{},[69,70,71],"thead",{},[72,73,74,78,81],"tr",{},[75,76,77],"th",{},"Feld",[75,79,80],{},"Typ",[75,82,83],{},"Bedeutung",[85,86,87,110,137,166],"tbody",{},[72,88,89,95,107],{},[90,91,92],"td",{},[29,93,94],{},"messageType",[90,96,97,100,101,100,104],{},[29,98,99],{},"campaign"," | ",[29,102,103],{},"transactional",[29,105,106],{},"automation",[90,108,109],{},"Eine Route pro Nachrichtentyp",[72,111,112,117,131],{},[90,113,114],{},[29,115,116],{},"strategy",[90,118,119,100,122,100,125,100,128],{},[29,120,121],{},"single",[29,123,124],{},"priority_failover",[29,126,127],{},"workload_split",[29,129,130],{},"adaptive_mix",[90,132,133,134,136],{},"Auswahlalgorithmus (",[29,135,130],{}," gehört dem Controller, nicht vom Betreiber wählbar)",[72,138,139,144,150],{},[90,140,141],{},[29,142,143],{},"providers",[90,145,146,147],{},"Array aus ",[29,148,149],{},"{ providerType, weight?, isEnabled }",[90,151,152,153,156,157,156,160,156,163],{},"Geordnete Kandidatenmenge; eingebaut sind ",[29,154,155],{},"mta"," \u002F ",[29,158,159],{},"ses",[29,161,162],{},"resend",[29,164,165],{},"smtp",[72,167,168,173,176],{},[90,169,170],{},[29,171,172],{},"ipPool",[90,174,175],{},"String (optional)",[90,177,178],{},"Überschreibt den MTA-IP-Pool für Sendevorgänge auf dieser Route",[11,180,181,184,185,188,189,192,193,196,197,200,201,156,204,48,207,210],{},[29,182,183],{},"setRoute"," legt eine Route an bzw. aktualisiert sie, ",[29,186,187],{},"removeRoute"," löscht eine (wodurch dieser Nachrichtentyp auf den globalen Standard zurückfällt). Beide erfordern die Berechtigung ",[29,190,191],{},"organization:manage",". Der öffentliche Leser ist ",[29,194,195],{},"listRoutes"," (eine ",[29,198,199],{},"authedQuery","); Sendepfade lösen Routen über ",[29,202,203],{},"resolveSendRoute",[29,205,206],{},"resolveSendRouteFromDb",[29,208,209],{},"apps\u002Fapi\u002Fconvex\u002Flib\u002FsendProviders\u002Froute.ts",") auf.",[212,213,215],"h3",{"id":214},"die-vier-strategien","Die vier Strategien",[11,217,218,219,48,222,225,226,228,229,232,233,235,236,238,239,242],{},"Die Auswahl ist eine reine Funktion. Der dünne Dispatcher ",[29,220,221],{},"resolveRoute",[29,223,224],{},"apps\u002Fapi\u002Fconvex\u002Flib\u002FsendProviders\u002Frouting.ts",") schlägt anhand von ",[29,227,116],{}," ein Strategie-Modul nach und ruft dessen ",[29,230,231],{},"select(entries, ipPool, healthStatuses, mix)"," mit den aktivierten Providern, dem ",[29,234,172],{}," der Route, dem aktuellen Provider-Health-Snapshot und dem Mix-Kontext pro Empfänger auf. Nur ",[29,237,130],{}," liest dieses vierte Argument; die drei ausgelieferten anderen ignorieren es. Jede Strategie liegt in einem eigenen Ordner unter ",[29,240,241],{},"lib\u002FsendProviders\u002Fstrategies\u002F",":",[66,244,245,255],{},[69,246,247],{},[72,248,249,252],{},[75,250,251],{},"Strategie",[75,253,254],{},"Verhalten",[85,256,257,266,283,302],{},[72,258,259,263],{},[90,260,261],{},[29,262,121],{},[90,264,265],{},"Verwendet immer den ersten aktivierten Provider. Ignoriert die Health.",[72,267,268,272],{},[90,269,270],{},[29,271,124],{},[90,273,274,275,278,279,282],{},"Geht die aktivierten Provider der Reihe nach durch und wählt den ersten, der ",[61,276,277],{},"nicht"," ",[29,280,281],{},"down"," ist. Fällt auf den ersten aktivierten Provider zurück, wenn alle down sind oder keine Health-Daten vorliegen.",[72,284,285,289],{},[90,286,287],{},[29,288,127],{},[90,290,291,292,294,295,298,299,301],{},"Gewichtet zufällige Auswahl über die aktivierten Provider, unter Ausschluss aller, die ",[29,293,281],{}," sind. Gewichte haben den Standardwert ",[29,296,297],{},"100"," (gleichverteilt). Sind alle Provider ",[29,300,281],{},", wird trotzdem einer gewählt, statt den Versand zu blockieren.",[72,303,304,308],{},[90,305,306],{},[29,307,130],{},[90,309,310,311,314,315,318,319,322],{},"Deterministische Aufteilung PRO EMPFÄNGER zwischen dem eigenen MTA und dem Referenztransport, mit dem Anteil, den der Ramp-Controller für die Zelle ",[29,312,313],{},"(stream, destinationProvider)"," hält. Controller-eigen: Sie wird im Strategie-Auswahlfeld nie angeboten. Ein entarteter Anteil löst die GESAMTE Zelle auf einen Arm auf — den Referenztransport bei ",[29,316,317],{},"s = 0"," (das heutige Fallback-aktive Verhalten), den eigenen MTA bei ",[29,320,321],{},"s = 1"," — ausgewählt nach Arm und nicht nach Health; das gesundheitsgetriebene Failover bleibt bei der Fallback-Sequenz und der erneuten Auflösung zum Dispatch-Zeitpunkt.",[11,324,325,326,328,329,332,333,336,337,339,340,343,344,48,347,350,351,354,355,358],{},"Gibt es keine Route, keinen aktivierten Provider oder liefert die Strategie nichts, fällt ",[29,327,221],{}," auf die Umgebungsvariable ",[29,330,331],{},"EMAIL_PROVIDER"," durch und gibt andernfalls ",[29,334,335],{},"null"," zurück (nicht konfiguriert). Die Auflösung ist fail-closed — es gibt keinen impliziten ",[29,338,155],{},"-Standard, sodass ein unkonfiguriertes Deployment niemals still an einen Phantom-MTA dispatcht. Die zurückgegebene ",[29,341,342],{},"ResolvedRoute"," hält ihre ",[29,345,346],{},"source",[29,348,349],{},"org_config",", ",[29,352,353],{},"env_fallback"," oder ",[29,356,357],{},"deliverability_fallback",") für die Observability fest.",[11,360,361],{},"Mandantenbezogene Kampagnen-, Automations-, Agent-Antwort-, transaktionale und Test-Sendevorgänge lösen unmittelbar vor dem Dispatch eine frische Last-Mile-Entscheidung auf. Die kontrollierte MTA-Annahme setzt die resultierende Lease voraus und bindet sie an die Nachricht, die Organisation, den Empfänger, den Absender, den Nachrichtentyp, den Provider bzw. Pool, die Warmup-Overflow-Policy, die gewählte IP und die Breaker-Generationen. Stellt ein eingereihter MTA-Job vor dem Öffnen von SMTP fest, dass sich die Entscheidung geändert hat oder abgelaufen ist, gibt er seine Reservierungen frei und sendet ein authentifiziertes Routing-Reentry-Ergebnis an Convex. Convex reiht denselben Sendevorgang atomar erneut über den begrenzten Workpool mit demselben Idempotenzschlüssel ein, wo eine frische Entscheidung eigene Zustellung, Relay oder Zurückstellung wählen kann. System- und Auth-Mail sowie Postbox verwenden separate MTA-Endpunkte mit fixem Scope, die nur den Master-Key akzeptieren; authentifizierte rohe SMTP-Einlieferung ist ein Pfad über den eigenen MTA und nimmt am Mandanten-Relay-Fallback nicht teil.",[11,363,364,365,368,369,372,373,376,377,380,381,384,385,388],{},"Die Übergabe selbst ist durch eine dauerhafte Re-Entry-Quittung pro Job abgesichert (",[29,366,367],{},"apps\u002Fmta\u002Fsrc\u002Fqueue\u002FroutingReentryHandoff.ts","), weil die Queue den Abschluss erst festhält, nachdem der Worker zurückgekehrt ist. ",[29,370,371],{},"reserved"," bedeutet, dass der Nachfolger möglicherweise noch nicht persistiert ist, sodass ein Replay dieselbe Übergabe idempotent zu Ende führt — die Outbox-Payload ist in der Quittung eingefroren, jeder Neuaufbau ist also byteidentisch. ",[29,374,375],{},"accepted"," bedeutet, dass die geschützte Outbox den Nachfolger bereits besitzt und der wiederholte Job nicht erneut in den Dispatch eintreten darf: Ohne diese Absicherung würde ein Absturz im Abschlussfenster den Job die gesamte Pipeline gegen frische Kapazität erneut durchlaufen lassen und eine Nachricht zustellen, die der Convex-Nachfolger ebenfalls zustellt. Der Re-Entry-Callback trägt den Retry-Zustand, über den der Callback-Digest ausgestellt wurde, einschließlich der Felder ",[29,378,379],{},"workAttemptId"," und ",[29,382,383],{},"acceptanceReconciliation",", die nach einem Dispatch mit unbekanntem Annahmestatus hinzukamen; ließe man eines von beiden weg, würde der Callback zu einem dauerhaften ",[29,386,387],{},"binding_mismatch",".",[11,390,391,392,395],{},"Jeder terminale Pfad, der nie SMTP geöffnet hat — Screening- und Suppression-Drops sowie das Aufgeben nach vier Tagen Ablauffrist —, gibt die Warming-Reservierung der Nachricht und die Half-Open-Probe des Breakers frei. Es wurde nichts übertragen, sie festzuhalten würde also das Tageslimit einer Warming-IP für Mail verbrauchen, die nie gesendet wurde. Die Annahmequittung wird bei jedem Worker-Lauf, der sie noch besitzt, neu scharf gestellt, sodass eine bis zum maximalen Alter zurückgestellte Nachricht ihren terminalen Ablauf-Bounce immer noch emittieren kann, statt im Dead-Letter zu landen, während der Sendevorgang in ",[29,393,394],{},"queued"," feststeckt.",[11,397,398,399,401,402,405,406,408,409,411],{},"Zwei Invarianten verhindern, dass eine mehrdeutige MTA-Annahme zu doppelter oder verlorener Mail wird. Erstens verlässt ein Sendevorgang, solange er eine unbekannte Annahme abgleicht, nie den Pfad über den eigenen MTA — nur dieser Pfad dedupliziert die wiederverwendete ",[29,400,379],{},", und ein Relay trägt überhaupt keinen Idempotenzschlüssel, sodass jeder andere Transport eine zweite Kopie einer Nachricht senden würde, die der MTA möglicherweise bereits zustellt. Jedes nicht-eigene Routing-Ergebnis stellt stattdessen zurück. Zweitens ist ein Routing-Reentry-Nachfolger ein ",[18,403,404],{},"neuer"," Arbeitsversuch: Er prägt seine eigene ",[29,407,379],{}," und verwirft das Reconciliation-Flag, weil die Übergabe vor SMTP stattfindet und damit beweist, dass der vorherige Versuch nicht zugestellt hat. Ein Nachfolger, der die alte Identität erbte, würde gegen die Annahmequittung des Jobs deduplizieren, der die Eigentümerschaft gerade abgegeben hat, und der Sendevorgang würde in ",[29,410,394],{}," auf einen Webhook warten, der nie eintreffen kann.",[11,413,414,415,417,418,421],{},"Vorübergehende Routing-Verweigerungen halten, statt zu terminalisieren. Ein offener organisationsweiter Sicherheits-Circuit oder ein Fallback, dessen Relay-Identität nicht verifiziert ist, wirft aus ",[29,416,221],{}," heraus; unbehandelt würde das als Workpool-Fehler auftauchen und jeden laufenden Sendevorgang als ",[29,419,420],{},"WORKPOOL_FAILED"," markieren, sodass das Auslösen eines Sicherheitssignals genau die Mail zerstören würde, die es pausieren sollte. Die kontrollierten Routen-Queries melden diese stattdessen als typisierte Zurückstellungen, protokolliert mit ihrem Code, weil das der einzige Hinweis für den Betreiber ist, warum Mail pausiert. Ein Sicherheits-Hold verbraucht keinen Routing-Versuch — die Versuchsobergrenze begrenzt Routing-Churn, und acht Versuche à 60 Sekunden würden den Sendevorgang nach etwa sieben Minuten terminalisieren, also innerhalb des eigenen Zehn-Minuten-Frischefensters eines einzelnen Signals. Gehaltene Sendevorgänge prüfen an genau diesem Horizont erneut und sind durch die Vier-Tage-Zustellfrist begrenzt.",[11,423,424,425,428,429,432,433,435],{},"Die Verbuchung von Bounces und Beschwerden bleibt paarweise. Eine Nachricht, die der MTA bei SMTP ablehnt, geht ",[29,426,427],{},"queued → bounced",", ohne ",[29,430,431],{},"sent"," zu durchlaufen, weshalb der terminale Übergang auch die ausgehenden Zähler emittiert, die ",[29,434,431],{}," erzeugt hätte — sonst hätte die Bounce-Rate der Reputation, die die automatische Durchsetzung steuert, einen Zähler ohne Nenner und würde einen zur Hälfte gebouncten Batch als 100 % ausweisen.",[11,437,438,439,442,443,446],{},"Das SMTP-Outcome-Journal deckt ausschließlich das wirklich unumkehrbare Fenster ab. ",[29,440,441],{},"sendToMx"," löst Leases, MX- und Provider-Profile, DKIM-Signierung und den TLS-Mindeststandard auf, bevor es eine Verbindung akquiriert; ein Fehler in diesem Abschnitt hat nichts übertragen, deshalb wird die Reservierung freigegeben und der Job wiederholt normal. Sobald die erste Verbindungsakquise beginnt, bleibt ein unterbrochener Versuch ungewiss und ein Replay löst ihn als ",[29,444,445],{},"ambiguous"," auf, statt die Nachricht ein zweites Mal auf die Leitung zu geben.",[448,449,452],"callout",{"title":450,"type":451},"IP-Pool-Verdrahtung","info",[11,453,454,455,458,459,461,462,465,466,468],{},"Die kontrollierte Dispatch-Grenze (",[29,456,457],{},"apps\u002Fapi\u002Fconvex\u002Fdelivery\u002FgovernedDispatch.ts",") reicht den ",[29,460,172],{}," der frisch aufgelösten Route über ",[29,463,464],{},"MtaExtras"," an den MTA durch; existiert kein Routen- bzw. Eingabepool, verwendet der MTA-Adapter standardmäßig ",[29,467,103],{},". Sie trägt außerdem die stabile Message-ID, den Nachrichtentyp, die Routing-Lease, das Warmup-Overflow-Bit und das begrenzte Convex-Arbeitselement, das für einen Routing-Reentry vor dem Netzwerkzugriff nötig ist. Die Pool-Auswahl für Kampagnen übersteht damit sowohl den initialen Dispatch als auch den Reentry eines angenommenen Jobs; sie wird nicht auf einen Adapteraufruf mit reiner Message-ID reduziert.",[38,470,472],{"id":471},"sende-dispatch-und-gesundheitsbewusstes-provider-failover","Sende-Dispatch und gesundheitsbewusstes Provider-Failover",[11,474,475,476,48,479,482,483,486],{},"Jeder Provider-Versuch läuft durch einen einzigen Helper, ",[29,477,478],{},"sendProviderDispatch",[29,480,481],{},"apps\u002Fapi\u002Fconvex\u002Flib\u002FsendProviders\u002Fdispatch.ts","), beschrieben in ADR-0020 (",[29,484,485],{},"docs\u002Fadr\u002F0020-send-provider-adapter-modules.md","). Der Pfad über den kontrollierten Workpool, Kampagnen-Testsendungen und der System-\u002FAuth-Absender mit fixem Scope erreichen alle diese Grenze; die Produzenten für Automationen und Agent-Antworten laufen zunächst auf demselben Workpool-Worker zusammen, statt direkt einen Transport aufzurufen. Der Dispatcher erledigt einheitlich drei Dinge:",[488,489,490,508,522],"ol",{},[491,492,493,496,497,380,500,503,504,507],"li",{},[61,494,495],{},"Retry-Schleife",", gesteuert von ",[29,498,499],{},"retryDelays",[29,501,502],{},"categorizeError"," des jeweiligen Provider-Moduls. Jeder Versuch ruft das ",[29,505,506],{},"sendEmail"," des Moduls für genau einen Versuch auf.",[491,509,510,513,514,517,518,521],{},[61,511,512],{},"Health-Erfassung"," — nach jedem terminalen Ergebnis (Erfolg oder aufgebrauchte Retries) plant er ",[29,515,516],{},"recordSendResult"," im Modul ",[61,519,520],{},"Send provider health"," ein, sodass auch Bypass-Aufrufer (Testsendungen, Automationsschritte) Health-Daten erfassen.",[491,523,524,527,528,531],{},[61,525,526],{},"Fehlerkategorisierung"," — das Ergebnis trägt einen typisierten ",[29,529,530],{},"EmailErrorCode",", keinen rohen String.",[212,533,535],{"id":534},"provider-health","Provider-Health",[11,537,538,48,540,543,544,547],{},[29,539,516],{},[29,541,542],{},"apps\u002Fapi\u002Fconvex\u002Flib\u002FsendProviders\u002Fhealth.ts",") pflegt eine ",[29,545,546],{},"providerHealth","-Zeile pro Provider-Art und nutzt dafür exponentiell abklingende rollierende Erfolgs-\u002FFehlerzähler, eine EMA-Latenz und einen Zähler für aufeinanderfolgende Fehler. Der Status wird daraus abgeleitet:",[66,549,550,560],{},[69,551,552],{},[72,553,554,557],{},[75,555,556],{},"Status",[75,558,559],{},"Bedingung",[85,561,562,572,582],{},[72,563,564,569],{},[90,565,566],{},[29,567,568],{},"healthy",[90,570,571],{},"Erfolgsrate ≥ 90 %",[72,573,574,579],{},[90,575,576],{},[29,577,578],{},"degraded",[90,580,581],{},"Erfolgsrate ≥ 50 % und \u003C 90 %",[72,583,584,588],{},[90,585,586],{},[29,587,281],{},[90,589,590,591,594],{},"Erfolgsrate \u003C 50 % ",[61,592,593],{},"oder"," ≥ 5 Fehler in Folge",[11,596,597,598,600,601,48,603,605,606,608,609,611,612,156,614,616],{},"Die ",[29,599,546],{},"-Zeilen werden von ",[29,602,206],{},[29,604,209],{},") eingesammelt und vor jedem Dispatch an das reine ",[29,607,221],{}," übergeben, was den Regelkreis schließt: Ein Provider, der zu scheitern beginnt, kippt auf ",[29,610,281],{},", und ",[29,613,124],{},[29,615,127],{}," routen automatisch um ihn herum.",[38,618,620],{"id":619},"versandreputation-organisation-pro-domain-abgeleitetes-risiko-automatische-durchsetzung","Versandreputation (Organisation + pro Domain, abgeleitetes Risiko, automatische Durchsetzung)",[11,622,623,624,627,628,48,631,634,635,638,639,642,643,646,647,650],{},"Zustellergebnisse summieren sich in der Tabelle ",[29,625,626],{},"sendingReputation",", die ausschließlich dem Modul ",[61,629,630],{},"Sending reputation",[29,632,633],{},"apps\u002Fapi\u002Fconvex\u002Fanalytics\u002FsendingReputation.ts",") gehört, gemäß ADR-0042 (",[29,636,637],{},"docs\u002Fadr\u002F0042-sending-reputation-module.md","). Es handelt sich um eine nach Scope diskriminierte Tabelle: Zeilen mit ",[29,640,641],{},"scope: 'org'"," verfolgen das gesamte Deployment, Zeilen mit ",[29,644,645],{},"scope: 'domain'"," eine einzelne Sendedomain. Bounce-Rate, Beschwerderate und Risikostufe werden ",[61,648,649],{},"nie gespeichert"," — sie werden beim Lesen abgeleitet.",[212,652,654],{"id":653},"wie-ereignisse-eintreffen","Wie Ereignisse eintreffen",[11,656,657,658,661,662,665,666,669,670,672],{},"Der Send-Lifecycle (",[29,659,660],{},"apps\u002Fapi\u002Fconvex\u002Fdelivery\u002FsendLifecycle.ts",") emittiert bei jedem Zustellübergang einen ",[29,663,664],{},"reputation_update","-Effekt, der ",[29,667,668],{},"recordEvent"," mit einem Ereignistyp und (sofern bekannt) der Sendedomain einplant. ",[29,671,668],{}," ist der einzige Schreiber: Es erhöht immer den heutigen Tages-Bucket der Organisation und, sofern eine Domain vorliegt, zusätzlich den Tages-Bucket der Domain.",[66,674,675,685],{},[69,676,677],{},[72,678,679,682],{},[75,680,681],{},"Ereignistyp",[75,683,684],{},"Erhöhte Zähler",[85,686,687,699,711,723,737],{},[72,688,689,694],{},[90,690,691],{},[29,692,693],{},"send",[90,695,696],{},[29,697,698],{},"totalSent",[72,700,701,706],{},[90,702,703],{},[29,704,705],{},"deliver",[90,707,708],{},[29,709,710],{},"totalDelivered",[72,712,713,718],{},[90,714,715],{},[29,716,717],{},"bounce",[90,719,720],{},[29,721,722],{},"totalBounced",[72,724,725,730],{},[90,726,727],{},[29,728,729],{},"hard_bounce",[90,731,732,380,734],{},[29,733,722],{},[29,735,736],{},"totalHardBounced",[72,738,739,744],{},[90,740,741],{},[29,742,743],{},"complaint",[90,745,746],{},[29,747,748],{},"totalComplaints",[212,750,752],{"id":751},"abgeleitetes-risiko","Abgeleitetes Risiko",[11,754,755,758,759,762,763,766,767,242],{},[29,756,757],{},"summarize"," (und ",[29,760,761],{},"summarizeDomains"," für die Sicht pro Domain) ist die ",[61,764,765],{},"einzige"," Stelle, an der das rollierende 30-Tage-Risikofenster aufsummiert wird; sie ist lesertypisiert, sodass der Schreiber, die Session-Auth-Queries, die Plattform-Admin-Queries und der Control-Plane-Reporter alle exakt dieselbe Zahl ableiten. Das Risiko wird aus internen Durchsetzungsschwellen berechnet. Die davon getrennte, providerseitige FBL-Spamrate verwendet Beschwerden geteilt durch zugestelltes Volumen: Unter 0,1 % ist das Ziel, 0,3 % ist die harte Grenze. Googles aktuelle Formulierung spricht ab dieser harten Grenze von Auswirkungen auf die Zustellung und fehlender Eignung für Mitigation, nicht von einer universellen Zusage der SMTP-Ablehnung. Absender unterhalb der Mindeststichprobengröße sind stets ",[29,768,769],{},"low",[66,771,772,782],{},[69,773,774],{},[72,775,776,779],{},[75,777,778],{},"Risiko",[75,780,781],{},"Auslöser (bei ≥ 100 Sendevorgängen im Fenster)",[85,783,784,796,808,821],{},[72,785,786,790],{},[90,787,788],{},[29,789,769],{},[90,791,792,793],{},"unterhalb der Schwellen für ",[29,794,795],{},"medium",[72,797,798,802],{},[90,799,800],{},[29,801,795],{},[90,803,804,805,807],{},"Beschwerderate ≥ 0,1 % ",[61,806,593],{}," Bounce-Rate ≥ 2 %",[72,809,810,815],{},[90,811,812],{},[29,813,814],{},"high",[90,816,817,818,820],{},"Beschwerderate ≥ 0,2 % ",[61,819,593],{}," Bounce-Rate ≥ 5 %",[72,822,823,828],{},[90,824,825],{},[29,826,827],{},"critical",[90,829,830,831,833],{},"Beschwerderate ≥ 0,3 % ",[61,832,593],{}," Bounce-Rate ≥ 10 %",[212,835,837],{"id":836},"automatische-durchsetzung","Automatische Durchsetzung",[11,839,840,841,843,844,847,848,354,850,852,853,856,857,859,860,350,863,859,865,868],{},"Die automatische Durchsetzung läuft nicht mehr innerhalb von ",[29,842,668],{}," (das jetzt nur noch die geshardeten Zähler erhöht). Sie läuft stündlich über den Cron ",[29,845,846],{},"evaluateAutoEnforce",", der das Organisationsfenster einmal zusammenfasst und — bei ",[29,849,814],{},[29,851,827],{}," — ",[29,854,855],{},"autoEnforceReputation"," einplant, dabei einen Ziel-Abuse-Status wählt (",[29,858,814],{}," → ",[29,861,862],{},"warned",[29,864,827],{},[29,866,867],{},"suspended",") und den Übergang an das Abuse-Status-Modul (ADR-0011) delegiert, das idempotent dedupliziert und Herabstufungen der Schwere verweigert. Domain-Buckets speisen ausschließlich das Dashboard pro Domain — der Abuse-Status ist ein Zustand auf Deployment-Ebene.",[11,870,871,874,875,878,879,882],{},[29,872,873],{},"recalculateAll"," ist ein ",[61,876,877],{},"reiner Aufräum-Cron",", der stündlich läuft (verdrahtet in ",[29,880,881],{},"apps\u002Fapi\u002Fconvex\u002Fcrons.ts","); er lässt Tages-Buckets, die älter als 60 Tage sind, über beide Scopes hinweg auslaufen. Das Risiko muss nicht mehr periodisch neu berechnet werden, weil es beim Lesen abgeleitet wird.",[212,884,886],{"id":885},"compliance-telemetrie","Compliance-Telemetrie",[11,888,889,892],{},[29,890,891],{},"analytics\u002FcomplianceTelemetry.ts"," verknüpft drei begrenzte Signale für die Seite „Delivery“:",[894,895,896,902,947],"ul",{},[491,897,898,901],{},[29,899,900],{},"summarizeSpamRate"," und die gemeinsame Bucket-Gruppierung pro Domain leiten FBL-Beschwerden über zugestelltem Volumen ab, ohne den bestehenden Circuit Breaker bei 0,2 % \u002F 100 Sendevorgängen zu verändern. Das Domain-Dashboard liest und gruppiert die Reputations-Buckets einmal und leitet dann sowohl Risiko als auch Spamrate aus demselben begrenzten Ergebnis ab. Der interne Sieben-Tage-Nachweiszähler zählt abgeschlossene UTC-Tage mit zugestelltem Verkehr und einer Rate strikt unter 0,3 %; ein Tag ohne Volumen kann keinen sauberen Nachweis beanspruchen. Es ist kein Urteil über Googles Mitigation-Eignung: Betreiber müssen Googles Tagesrate in den Postmaster Tools sowie jede weitere Absenderanforderung selbst prüfen.",[491,903,904,905,908,909,911,912,914,915,918,919,922,923,926,927,922,929,931,932,935,936,939,940,942,943,946],{},"Ein erfolgreiches MTA-",[29,906,907],{},"POST \u002Fsend"," bedeutet nur die Annahme in die Queue und bringt einen Sendevorgang auf ",[29,910,431],{},"; es erhöht nie das zugestellte Volumen. Der spätere authentifizierte MTA-Webhook ",[29,913,431],{}," bedeutet, dass der Ziel-SMTP-Server DATA angenommen hat, deshalb bildet der Adapter dieses wahrheitsgemäße Remote-Annahmesignal auf einen Zustellnachweis ab. Der Send-Lifecycle persistiert die erste Beobachtung von Annahme\u002FÖffnung\u002FKlick\u002FBeschwerde in ",[29,916,917],{},"deliveredAt","; diese eine Idempotenznaht erfasst Kampagnen-, Tages- und Reputationszustell-Effekte genau einmal, ohne einen fortgeschrittenen oder terminalen Anzeigestatus zurückzudrehen. ",[29,920,921],{},"bouncedAt","\u002F",[29,924,925],{},"failedAt"," am Sendevorgang und ",[29,928,921],{},[29,930,925],{}," am Postbox-Empfänger stellen die Ordnung nach Ereigniszeit her, sodass eine frühere Annahme zurechenbar bleibt, selbst wenn ihr Webhook zuletzt eintrifft; ein terminales Ereignis, das wirklich zuerst eintrat, weist sie zurück. Eine wiederholt eingespielte frühere Annahme löscht keinen Kontakt-Wiederherstellungszustand, den das neuere terminale Ereignis erzeugt hat. Postbox persistiert die unabhängige Beobachtung in ",[29,933,934],{},"acceptedAt",". Der ",[29,937,938],{},"DestinationSnapshot.providerKey"," aus Phase 2 reist auf dem Webhook mit. Gmail-Beobachtungen werden nur geschrieben, wenn der Lifecycle ein zurechenbares Send-\u002FPostbox-Ergebnis auflöst, und sind idempotent über die Provider-Message-ID. Der Hot Path shardet die stündlichen Schreibvorgänge jeder PSL-korrekten primären DKIM-Domain deterministisch über acht Dokumente und vermeidet so einen OCC-Engpass auf einem einzelnen Convex-Dokument. Ein stabiler Job pro Domain fasst Bursts zusammen und aktualisiert das materialisierte Rollup fester Breite asynchron; die indizierte Dashboard-Query liefert die Top-100-Domains plus ein explizites Kürzungs-Flag, ohne die Kardinalität Domain × Stunde × Shard zu scannen. Das authentifizierte ",[29,941,934],{}," des MTA bestimmt die Messstunde, während das vertrauenswürdige Convex-",[29,944,945],{},"ingestedAt"," die Aufbewahrung der Quittungen steuert. Ein begrenzter Zeitversatz von fünf Minuten in die Zukunft wird gekappt; Ereignisse jenseits davon oder älter als der 48-Stunden-Telemetriehorizont behalten ihre Idempotenz, erzeugen aber kein Volumen. Das Aufräumen löscht, aktualisiert oder plant pro Transaktion höchstens 128 Zeilen aus jeder indizierten Klasse neu und plant sofort einen weiteren Batch ein, solange Rückstand besteht. Das Dashboard warnt bei 4.000 auf dem Weg zu Googles ungefährem dauerhaftem Klassifikator bei 5.000\u002F24 h. Stundensummen können die exakte nachlaufende Grenze um bis zu 60 Minuten überlappen, was API und UI offenlegen.",[491,948,949],{},"Der RFC-8058-POST-Handler erfasst ein begrenztes tägliches Latenzhistogramm erst, nachdem seine synchrone Abmelde-Mutation abgeschlossen ist. Das Dashboard leitet p95 über 30 Tage ab und alarmiert jenseits des 48-Stunden-Einlösefensters. Ein Telemetriefehler ist für den Endpunkt fail-open; er kann eine angewandte Abmeldung nie in einen für den Provider sichtbaren Fehler verwandeln.",[11,951,952,955,956,959,960,963],{},[29,953,954],{},"delivery\u002FmarketingCompliance.ts"," verantwortet die einzige finale Envelope-Zusicherung für Kampagnen- und Automationsmail. Sie verlangt beide One-Click-Header und liest die von ",[29,957,958],{},"@owlat\u002Fmail-message"," exportierte ",[29,961,962],{},"SIGNED_HEADERS","; in Convex wird keine zweite Liste signierter Header gepflegt.",[212,965,967],{"id":966},"empfänger-policy-abgebildet-auf-owlat-kontrollen","Empfänger-Policy, abgebildet auf Owlat-Kontrollen",[11,969,970],{},"Diese Tabelle trennt die Policy der Mailbox-Provider von Owlats Implementierung. Die\nProvider-Werte sind nicht austauschbar: Google berechnet eine tägliche Spamrate in den\nPostmaster Tools, Yahoo teilt Beschwerden durch die in den Posteingang zugestellte Mail,\nund Owlats FBL-Sicht verwendet zugestelltes Volumen über ihr eigenes rollierendes Fenster.",[66,972,973,986],{},[69,974,975],{},[72,976,977,980,983],{},[75,978,979],{},"Policy-Grenze",[75,981,982],{},"Aktuelle Empfängerregel",[75,984,985],{},"Owlat-Kontrolle",[85,987,988,999,1010,1021,1036],{},[72,989,990,993,996],{},[90,991,992],{},"Gmail-Bulk-Nähe",[90,994,995],{},"Die Klassifizierung liegt bei rund 5.000 Nachrichten in 24 Stunden an private Gmail-Adressen, aggregiert nach primärer Sendedomain",[90,997,998],{},"Warnung bei 4.000 angenommenen, Gmail zugerechneten Nachrichten in der rollierenden Näherung; Anzeige der Klassifikatorgrenze von 5.000",[72,1000,1001,1004,1007],{},[90,1002,1003],{},"Gmail-Spamrate",[90,1005,1006],{},"Postmaster Tools unter 0,10 % halten; 0,30 % oder mehr vermeiden",[90,1008,1009],{},"Ziel und harte Grenze anzeigen; sieben interne saubere Sendetage nur als Untersuchungsnachweis zählen",[72,1011,1012,1015,1018],{},[90,1013,1014],{},"Yahoo-Spamrate",[90,1016,1017],{},"Unter 0,3 % halten; Yahoos Nenner ist die in den Posteingang zugestellte Mail",[90,1019,1020],{},"Dieselbe harte Grenze anzeigen, Owlats Nenner aber nie als Yahoos Rate bezeichnen",[72,1022,1023,1026,1033],{},[90,1024,1025],{},"One-Click-Verarbeitung",[90,1027,1028,1029,1032],{},"Gmail verlangt für Bulk-Marketing-\u002FAbo-Mail RFC 8058; Yahoo verlangt ein funktionierendes ",[29,1030,1031],{},"List-Unsubscribe"," und empfiehlt RFC 8058 dringend; beide erwarten Erledigung binnen 2 Tagen",[90,1034,1035],{},"Kampagnen-\u002FMarketing-Automations-Envelopes ohne signierte RFC-8058-Header ablehnen; Suppression synchron anwenden; alarmieren, wenn p95 48 Stunden überschreitet",[72,1037,1038,1041,1044],{},[90,1039,1040],{},"Kampagnenbeschwerden",[90,1042,1043],{},"Die Platzierung beim Empfänger kann sich verschlechtern, bevor eine ganze Organisation einen Breaker überschreitet",[90,1045,1046],{},"Alarm oberhalb von 0,3 % nach mindestens 100 zurechenbaren Zustellungen",[11,1048,1049],{},"Der Echtzeit-Organisations-Breaker des MTA ist bewusst eine andere, strengere\nKontrolle. Jeder Vergleich ist ein striktes Größer-als:",[66,1051,1052,1065],{},[69,1053,1054],{},[72,1055,1056,1059,1062],{},[75,1057,1058],{},"Signal",[75,1060,1061],{},"Fenster",[75,1063,1064],{},"Öffnet oberhalb von",[85,1066,1067,1078,1089,1099],{},[72,1068,1069,1072,1075],{},[90,1070,1071],{},"Bounce, schnell",[90,1073,1074],{},"Letzte 50 Ergebnisse",[90,1076,1077],{},"15 %",[72,1079,1080,1083,1086],{},[90,1081,1082],{},"Bounce, anhaltend",[90,1084,1085],{},"Letzte 100 Ergebnisse",[90,1087,1088],{},"8 %",[72,1090,1091,1094,1096],{},[90,1092,1093],{},"Beschwerde, schnell",[90,1095,1074],{},[90,1097,1098],{},"4 %",[72,1100,1101,1104,1106],{},[90,1102,1103],{},"Beschwerde, anhaltend",[90,1105,1085],{},[90,1107,1108],{},"0,2 %",[11,1110,1111],{},"Ein geöffneter Breaker kühlt 30 Minuten ab, bevor Half-Open-Proben laufen. Er ist nicht\nGoogles oder Yahoos Messung und darf nicht als Provider-Policy beschrieben werden.",[212,1113,1115],{"id":1114},"aktuelle-anforderungen-für-consumer-mailboxen","Aktuelle Anforderungen für Consumer-Mailboxen",[66,1117,1118,1131],{},[69,1119,1120],{},[72,1121,1122,1125,1128],{},[75,1123,1124],{},"Empfänger-Scope",[75,1126,1127],{},"Mindeststandard Authentifizierung",[75,1129,1130],{},"Weitere aktuelle Anforderungen",[85,1132,1133,1144,1159,1169,1186],{},[72,1134,1135,1138,1141],{},[90,1136,1137],{},"Gmail, alle Absender",[90,1139,1140],{},"SPF oder DKIM",[90,1142,1143],{},"Gültiges Forward-\u002FReverse-DNS, TLS, RFC 5322, Spam unter 0,3 %",[72,1145,1146,1149,1156],{},[90,1147,1148],{},"Gmail, Bulk",[90,1150,1151,1152,1155],{},"SPF und DKIM; DMARC mindestens ",[29,1153,1154],{},"p=none","; From ausgerichtet an SPF oder DKIM",[90,1157,1158],{},"Mindeststandard für alle Absender; RFC 8058 plus sichtbarer Abmeldelink im Text für Marketing-\u002FAbo-Mail; Einlösung binnen 48 Stunden",[72,1160,1161,1164,1166],{},[90,1162,1163],{},"Yahoo, alle Absender",[90,1165,1140],{},[90,1167,1168],{},"Gültiges Forward-\u002FReverse-DNS, RFC 5321\u002F5322, Spam unter 0,3 %",[72,1170,1171,1174,1180],{},[90,1172,1173],{},"Yahoo, Bulk",[90,1175,1176,1177,1179],{},"SPF und DKIM; bestandenes DMARC mindestens ",[29,1178,1154],{},"; From-Ausrichtung",[90,1181,1182,1183,1185],{},"Funktionierendes ",[29,1184,1031],{}," plus sichtbarer Link im Text für Marketing-\u002FAbo-Mail; Einlösung binnen 2 Tagen",[72,1187,1188,1191,1197],{},[90,1189,1190],{},"Outlook.com Consumer, ab 5.000 pro Tag und From-Domain",[90,1192,1193,1194,1196],{},"SPF und DKIM bestehen beide; DMARC mindestens mit ",[29,1195,1154],{}," veröffentlicht; ausgerichtetes SPF oder DKIM lässt DMARC bestehen",[90,1198,1199,1200,1203],{},"Nicht konforme Mail mit hohem Volumen wird mit ",[29,1201,1202],{},"550 5.7.515"," abgelehnt",[11,1205,1206],{},"Die Zeile von Microsoft gilt für Consumer-Adressen von Outlook.com, Hotmail, Live und\nMSN, nicht automatisch für jeden Microsoft-365-Tenant. Die Ablehnung begann am\n5. Mai 2025.",[11,1208,1209,1210,1216,1217,1216,1222,1216,1227,1216,1232,1216,1237,1242,1243,388],{},"Offizielle Quellen zuletzt geprüft am 26. Juli 2026:\n",[23,1211,1215],{"href":1212,"rel":1213},"https:\u002F\u002Fsupport.google.com\u002Fmail\u002Fanswer\u002F81126?hl=en",[1214],"nofollow","Google-Absenderrichtlinien",",\n",[23,1218,1221],{"href":1219,"rel":1220},"https:\u002F\u002Fsupport.google.com\u002Fmail\u002Fanswer\u002F14229414?hl=en",[1214],"Google-Absender-FAQ",[23,1223,1226],{"href":1224,"rel":1225},"https:\u002F\u002Fsenders.yahooinc.com\u002Fbest-practices\u002F",[1214],"Yahoo Sender Requirements & Recommendations",[23,1228,1231],{"href":1229,"rel":1230},"https:\u002F\u002Fsenders.yahooinc.com\u002Ffaqs\u002F",[1214],"Yahoo-Absender-FAQ",[23,1233,1236],{"href":1234,"rel":1235},"https:\u002F\u002Fsupport.microsoft.com\u002Fen-us\u002Foutlook\u002Ffix-ndr-error-550-5-7-515-in-outlook-com",[1214],"Microsoft-Hinweise zu 550 5.7.515",[23,1238,1241],{"href":1239,"rel":1240},"https:\u002F\u002Ftechcommunity.microsoft.com\u002Fblog\u002Fmicrosoftdefenderforoffice365blog\u002Fstrengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders\u002F4399730",[1214],"Microsofts Ankündigung der Durchsetzung",",\nund ",[23,1244,1247],{"href":1245,"rel":1246},"https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc8058",[1214],"RFC 8058",[11,1249,1250,1251,1253,1254,1257],{},"Googles Eskalation vom November 2025 betrifft nicht konformen Absenderverkehr im weiteren\nSinne. Die aktuelle Durchsetzungstabelle führt fehlendes One-Click oder ein verfehltes\n48-Stunden-Einlösefenster als nicht mitigationsfähig auf; die FAQ sagt, dass dieses\nVersäumnis allein eine Nachricht nicht automatisch ablehnt oder in den Spam-Ordner\nbefördert. Yahoo begann die Durchsetzung von ",[29,1252,1031],{}," im Juni 2024 und\nakzeptiert ausdrücklich ",[29,1255,1256],{},"mailto",", empfiehlt jedoch die POST-Methode nach RFC 8058\ndringend.",[212,1259,1261],{"id":1260},"eingecheckte-profile-der-zielprovider","Eingecheckte Profile der Zielprovider",[11,1263,1264],{},"Das sind Startwerte, keine unveränderlichen Provider-Kontingente. Sie werden in Redis\neingesät, ohne Änderungen des Betreibers zu überschreiben, und lassen sich über die\nISP-Profil-API des MTA anpassen. TLS-Mindeststandards setzen sich weiterhin nach dem\nPrinzip „strengste gewinnt“ zusammen.",[66,1266,1267,1286],{},[69,1268,1269],{},[72,1270,1271,1274,1277,1280,1283],{},[75,1272,1273],{},"Provider",[75,1275,1276],{},"Start \u002F Obergrenze \u002F Untergrenze pro Minute",[75,1278,1279],{},"TLS-Mindeststandard",[75,1281,1282],{},"Verbindungen",[75,1284,1285],{},"Zustellungen pro Verbindung",[85,1287,1288,1305,1321,1335,1349],{},[72,1289,1290,1293,1296,1299,1302],{},[90,1291,1292],{},"Gmail",[90,1294,1295],{},"100 \u002F 300 \u002F 5",[90,1297,1298],{},"Erforderlich",[90,1300,1301],{},"5",[90,1303,1304],{},"50",[72,1306,1307,1310,1313,1316,1319],{},[90,1308,1309],{},"Microsoft",[90,1311,1312],{},"80 \u002F 200 \u002F 5",[90,1314,1315],{},"Opportunistisch",[90,1317,1318],{},"3",[90,1320,297],{},[72,1322,1323,1326,1329,1331,1333],{},[90,1324,1325],{},"Yahoo",[90,1327,1328],{},"50 \u002F 150 \u002F 3",[90,1330,1315],{},[90,1332,1318],{},[90,1334,297],{},[72,1336,1337,1340,1343,1345,1347],{},[90,1338,1339],{},"Apple",[90,1341,1342],{},"60 \u002F 150 \u002F 5",[90,1344,1315],{},[90,1346,1318],{},[90,1348,297],{},[72,1350,1351,1354,1357,1359,1361],{},[90,1352,1353],{},"Sonstige",[90,1355,1356],{},"30 \u002F 100 \u002F 2",[90,1358,1315],{},[90,1360,1318],{},[90,1362,297],{},[448,1364,1366],{"title":1365,"type":451},"Wo die Dashboards leben",[11,1367,1368,1369,1372,1373,1376],{},"Das session-bezogene Reputations-Dashboard liest ",[29,1370,1371],{},"getSendingOverview"," in ",[29,1374,1375],{},"apps\u002Fapi\u002Fconvex\u002Fanalytics\u002FreputationQueries.ts",". Die deploymentweite Reputationsoberfläche für Plattform-Admins (Roster, Abuse-Status, Content-Review) ist in diesem OSS-Repository eine Backend-\u002FAPI-Fläche und kein mitgeliefertes Produkt-Dashboard — die umfangreiche Control-Plane-UI wurde in ein separates privates Repository ausgelagert.",[38,1378,1380],{"id":1379},"ip-warming-zustand-convex-gecacht-und-sendeschätzungen","IP-Warming-Zustand (Convex-gecacht) und Sendeschätzungen",[11,1382,1383,1384,1387],{},"Die authentifizierte Antwort von ",[29,1385,1386],{},"GET \u002Fip-reputation"," trägt außerdem einen begrenzten\nRouting-Snapshot, wenn Convex die ID der Singleton-Organisation liefert. Jedes Signal hat\neinen expliziten Scope für den Empfängerprovider, eine feste Taxonomie aus Quelle und\nSchweregrad sowie einen Beobachtungszeitpunkt. Convex weist den gesamten Snapshot zurück,\nwenn er fehlerhaft oder veraltet ist, und materialisiert dann höchstens eine dauerhafte\nHysterese-Zeile pro bekanntem Provider plus den globalen Pool-Scope. Provider-lokaler\nZustand wird nie zu einem globalen Ausfall verallgemeinert.",[11,1389,1390,1391,1394,1395,48,1398,1401,1402,1405,1406,1408,1409,1412,1413,156,1416,1419],{},"Der MTA verantwortet den echten Warming-Fahrplan und den Zustand pro IP in Redis. Convex hält eine ",[61,1392,1393],{},"gecachte, reaktive"," Kopie, damit Queries sie abonnieren können, ohne bei jedem Lesevorgang den MTA anzusprechen. ",[29,1396,1397],{},"syncWarmingState",[29,1399,1400],{},"apps\u002Fapi\u002Fconvex\u002Fdelivery\u002FwarmingSync.ts",") läuft alle 5 Minuten (Cron in ",[29,1403,1404],{},"crons.ts","), holt ",[29,1407,1386],{}," vom MTA, cacht jede transaktionale und jede Kampagnen-IP, aggregiert die Kampagnenkapazität und legt die Singleton-Zeile ",[29,1410,1411],{},"warmingState"," an bzw. aktualisiert sie. Sind ",[29,1414,1415],{},"MTA_INTERNAL_URL",[29,1417,1418],{},"MTA_API_KEY"," nicht gesetzt, überspringt sie den Lauf still.",[11,1421,1422,1423,48,1426,156,1429,156,1432,1435],{},"Die gecachte Zeile trägt eine Gesamt-",[29,1424,1425],{},"phase",[29,1427,1428],{},"ramp",[29,1430,1431],{},"plateau",[29,1433,1434],{},"graduated","), das aufsummierte tägliche Kampagnenlimit, die heutige Zahl der Kampagnensendungen, eine IP-Anzahl und eine Aufschlüsselung pro IP (Phase, Warming-Tag, Tageslimit, heute gesendet, Bounce-\u002FDeferral-Rate, Pool, Aktiv-\u002FBlockgründe, DNSBL-Status und die FCrDNS-Checkliste).",[11,1437,1438,1439,1442],{},"Zwei clientseitige Queries lesen sie (",[29,1440,1441],{},"reputationQueries.ts","):",[894,1444,1445,1452],{},[491,1446,1447,1451],{},[61,1448,1449],{},[29,1450,1371],{}," — kombiniert Warming-Zustand, tägliches Sendevolumen, die rollierende 30-Tage-Reputationszusammenfassung der Organisation und den aktuellen Abuse-Status in einer Karte.",[491,1453,1454,1459],{},[61,1455,1456],{},[29,1457,1458],{},"getCampaignSendEstimate"," — schätzt bei gegebener Empfängerzahl, wie viele Tage eine Kampagne dauern wird, ausgehend von der verbleibenden Tageskapazität, und projiziert konservativ nach vorn (~1,5-faches Kapazitätswachstum pro Tag), solange IPs noch aufgewärmt werden. Vollständig aufgewärmte Deployments melden eine Schätzung von einem Tag.",[448,1461,1464],{"title":1462,"type":1463},"Die Schätzung ist eine Projektion","warning",[11,1465,1466,1468],{},[29,1467,1458],{}," ist eine Projektion für die Oberfläche, kein Scheduler. Das tatsächliche Pacing erzwingt die Warming-Drossel des MTA zum Zustellzeitpunkt; diese Query setzt lediglich die Erwartungen der Nutzer.",[38,1470,1472],{"id":1471},"suppression-liste-und-blockliste","Suppression-Liste und Blockliste",[11,1474,1475,1476,1479,1480,1483],{},"Die Tabelle ",[29,1477,1478],{},"blockedEmails"," ist die Suppression-Liste auf Adressebene — die letzte Verteidigungslinie für die Absenderreputation. Verwaltet wird sie in ",[29,1481,1482],{},"apps\u002Fapi\u002Fconvex\u002FblockedEmails.ts",". Jede Zeile speichert eine normalisierte (kleingeschriebene, getrimmte) Adresse und einen Grund:",[66,1485,1486,1496],{},[69,1487,1488],{},[72,1489,1490,1493],{},[75,1491,1492],{},"Grund",[75,1494,1495],{},"Quelle",[85,1497,1498,1508,1518],{},[72,1499,1500,1505],{},[90,1501,1502],{},[29,1503,1504],{},"bounced",[90,1506,1507],{},"Hard Bounce — die Adresse existiert nicht",[72,1509,1510,1515],{},[90,1511,1512],{},[29,1513,1514],{},"complained",[90,1516,1517],{},"Empfänger hat die E-Mail als Spam markiert",[72,1519,1520,1525],{},[90,1521,1522],{},[29,1523,1524],{},"manual",[90,1526,1527],{},"Betreiber hat sie von Hand hinzugefügt",[11,1529,1530,1531,1534],{},"Blockierte Adressen werden als Teil des Eignungsprädikats für die Kampagnen-Zielgruppe vom Versand ausgeschlossen (Soft-Delete + E-Mail vorhanden + Suppression + DOI-falls-Thema). Das automatische Blockieren geschieht über ",[29,1532,1533],{},"addFromEvent",", den internen Schreiber, den die Bounce- und Beschwerde-Handler aufrufen; es ist idempotent (das erneute Blockieren einer bestehenden Adresse gibt den vorhandenen Datensatz zurück). Betreiberseitige Fläche:",[894,1536,1537,1552,1568],{},[491,1538,1539,156,1542,156,1545,1548,1549,388],{},[29,1540,1541],{},"add",[29,1543,1544],{},"bulkAdd",[29,1546,1547],{},"remove"," — erfordern die Berechtigung ",[29,1550,1551],{},"contacts:manage",[491,1553,1554,1557,1558,350,1561,350,1564,1567],{},[29,1555,1556],{},"listByTeam"," (optional nach Grund gefiltert), ",[29,1559,1560],{},"get",[29,1562,1563],{},"getByEmail",[29,1565,1566],{},"getCountsByReason"," — Lesevorgänge.",[491,1569,1570,1573,1574,1577],{},[29,1571,1572],{},"isBlocked"," (Session) und ",[29,1575,1576],{},"isBlockedInternal"," (von anderen Convex-Funktionen genutzt, ohne Zugriffsprüfung) — Punktabfragen.",[11,1579,1580,1581,1584,1585,1588],{},"Alle Abfragen laufen über den Index ",[29,1582,1583],{},"by_email"," auf der normalisierten Adresse; ",[29,1586,1587],{},"by_reason"," unterlegt die gefilterte Liste und die Zählungen.",[38,1590,1592],{"id":1591},"tägliche-sendestatistiken-und-schwellenwerte-des-content-scan-gates","Tägliche Sendestatistiken und Schwellenwerte des Content-Scan-Gates",[212,1594,1596],{"id":1595},"tageszähler","Tageszähler",[11,1598,1599],{},"Es existieren zwei getrennte Tageszähler für unterschiedliche Zwecke:",[894,1601,1602,1636],{},[491,1603,1604,1609,1610,48,1613,1616,1617,1620,1621,1372,1624,1627,1628,1631,1632,1635],{},[61,1605,1606],{},[29,1607,1608],{},"instanceSettings.dailySendCount"," — ein einzelner laufender Zähler für den aktuellen UTC-Tag, erhöht über ",[29,1611,1612],{},"nextDailySendCount",[29,1614,1615],{},"apps\u002Fapi\u002Fconvex\u002Flib\u002FsendingLimits.ts","), das das Inkrement in den ",[29,1618,1619],{},"instanceSettings","-Patch einfaltet (der Schreiber für Massenversand ist ",[29,1622,1623],{},"incrementDailySendCountInternal",[29,1625,1626],{},"campaigns\u002FsendQueries.ts","). Er dient ",[61,1629,1630],{},"nur der Anzeige","; tarifbasierte Limits wurden entfernt, und das Pacing ist Aufgabe des MTA. ",[29,1633,1634],{},"getDailySendVolume"," setzt ihn beim ersten Lesevorgang eines neuen UTC-Tags träge zurück.",[491,1637,1638,1643,1644,156,1646,156,1649,156,1652,1655,1656,1659,1660,48,1663,1666],{},[61,1639,1640],{},[29,1641,1642],{},"sendDailyStats"," — eine Zeile pro UTC-Tag mit den Zählern ",[29,1645,431],{},[29,1647,1648],{},"delivered",[29,1650,1651],{},"opened",[29,1653,1654],{},"clicked",", geschrieben vom ",[29,1657,1658],{},"daily_stats_bump","-Effekt des Send-Lifecycle über ",[29,1661,1662],{},"bumpSendDailyStat",[29,1664,1665],{},"apps\u002Fapi\u002Fconvex\u002Flib\u002FsendDailyStats.ts","). Die Zusammenfassungskarte des Dashboards liest die letzten 30 Zeilen dieser Tabelle, statt jeden einzelnen Sendevorgang zu scannen.",[212,1668,1670],{"id":1669},"das-content-scan-gate","Das Content-Scan-Gate",[11,1672,1673,1674,1677,1678,1681,1682,1685,1686,1689],{},"Bevor eine Kampagne ausgefächert wird, lässt der Orchestrator (",[29,1675,1676],{},"apps\u002Fapi\u002Fconvex\u002Fcampaigns\u002Fsend.ts",") die Adresse durch den E-Mail-Scanner laufen. Er kombiniert den lokalen Content-Score (",[29,1679,1680],{},"scanContent"," aus ",[29,1683,1684],{},"@owlat\u002Femail-scanner",") mit einem optionalen URL-Reputationsdurchlauf über Google Safe Browsing (nur wenn ",[29,1687,1688],{},"GOOGLE_SAFE_BROWSING_API_KEY"," gesetzt ist; fehlgeschlagene URL-Prüfungen blockieren einen Versand nie). Der kombinierte Score von 0–100 wird auf drei Stufen abgebildet:",[66,1691,1692,1705],{},[69,1693,1694],{},[72,1695,1696,1699,1702],{},[75,1697,1698],{},"Score",[75,1700,1701],{},"Stufe",[75,1703,1704],{},"Ergebnis",[85,1706,1707,1728,1745],{},[72,1708,1709,1712,1717],{},[90,1710,1711],{},"≥ 40",[90,1713,1714],{},[29,1715,1716],{},"blocked",[90,1718,1719,1720,1723,1724,1727],{},"Kampagne fällt mit einem ",[29,1721,1722],{},"contentBlockReason"," auf ",[29,1725,1726],{},"draft"," zurück; Versand bricht ab",[72,1729,1730,1733,1738],{},[90,1731,1732],{},"15–39",[90,1734,1735],{},[29,1736,1737],{},"suspicious",[90,1739,1740,1741,1744],{},"Kampagne wechselt zu ",[29,1742,1743],{},"pending_review"," für die Prüfung durch Plattform-Admins",[72,1746,1747,1750,1755],{},[90,1748,1749],{},"\u003C 15",[90,1751,1752],{},[29,1753,1754],{},"clean",[90,1756,1757],{},"Versand läuft weiter",[11,1759,1760,1761,1764,1765,1768,1769,1772,1773,1776,1777,388],{},"Nicht saubere Ergebnisse werden als Prüfpfad in ",[29,1762,1763],{},"contentScanResults"," persistiert (geschlüsselt über ",[29,1766,1767],{},"resourceType"," + ",[29,1770,1771],{},"resourceId","). Derselbe Scanner unterlegt an anderer Stelle die Validierung von Anhängen und Medien-Uploads; URL-Urteile werden in ",[29,1774,1775],{},"urlReputationCache"," gecacht (24 h für sauber, 1 h für auffällig). Zu den Interna des Sicherheits-Scannings siehe ",[23,1778,1780],{"href":1779},"\u002Fdeveloper\u002Femail-security","E-Mail-Sicherheit",[38,1782,1784],{"id":1783},"yahoo-complaint-feedback-loop-geführte-anmeldung-über-die-dkim-domain","Yahoo Complaint Feedback Loop (geführte Anmeldung über die DKIM-Domain)",[11,1786,1787,1788,1791,1792,1795],{},"Yahoos CFL basiert auf der ",[61,1789,1790],{},"DKIM-Domain",": Es gibt keine API und keine zu speichernden Zugangsdaten, nur eine beidseitige Anmeldung, die ein Betreiber auf Yahoos Absenderseite für eine Domain vornimmt, die wir bereits signieren. Die Integration ist deshalb ein ",[61,1793,1794],{},"geführter Ablauf plus ein festgehaltener Zustand",", kein Client.",[894,1797,1798,1816,1833,1879,1920,1940,1963,2034,2047,2059],{},[491,1799,1800,1803,1804,1807,1808,1811,1812,1815],{},[61,1801,1802],{},"Kein zweiter Parser."," Ein Yahoo-CFL-Report ist eine gewöhnliche ARF-Nachricht nach RFC 5965 und läuft durch den ausgelieferten Prozessor in ",[29,1805,1806],{},"apps\u002Fmta\u002Fsrc\u002Fbounce\u002FfblProcessor.ts",", dessen ISP-Map ",[29,1809,1810],{},"yahoo"," bereits auflöst, sowie durch die ausgelieferte Zurechnung über signierte VERP plus persistierte Provenienz in ",[29,1813,1814],{},"feedbackProvenance.ts",". Eine Beschwerde-Pipeline, drei Quellen (Yahoo CFL, der CFBL-Address-Feed nach RFC 9477 und der Abmelderaten-Proxy).",[491,1817,1818,1821,1822,1824,1825,1828,1829,1832],{},[61,1819,1820],{},"Was der MTA jetzt weiterreicht."," Das reduzierte Webhook-Ereignis ",[29,1823,1514],{}," trägt die ",[29,1826,1827],{},"Reported-Domain"," nach RFC 5965 (unsere Sende- bzw. DKIM-Domain) und den aufgelösten Quell-ISP. Beide werden an der Emissionsstelle in ",[29,1830,1831],{},"outcome.ts"," begrenzt: Die gemeldete Domain ist vom Internet kontrollierter Reporttext, und ein übergroßer Wert, der den Validator für Webhook-Ereignisse nicht besteht, würde die gesamte Beschwerde verwerfen — und die muss immer die Blockliste erreichen.",[491,1834,1835,1838,1839,1842,1843,1846,1847,1850,1851,1854,1855,1858,1859,1862,1863,1866,1867,1870,1871,1874,1875,1878],{},[61,1836,1837],{},"Die Zustandsmaschine"," liegt in ",[29,1840,1841],{},"packages\u002Fshared\u002Fsrc\u002FyahooCfl.ts"," und ist rein — ",[29,1844,1845],{},"not_started → awaiting_yahoo → enrolled",", plus ",[29,1848,1849],{},"lapsed",", wenn eine angemeldete Domain 90 Tage lang keine Yahoo-Beschwerde gesehen hat. Ein Report darf eine Anmeldung ",[61,1852,1853],{},"bestätigen und auffrischen",", sie aber nie herbeiführen: Alles, woran der Beobachtungspfad ansetzen könnte, stammt aus dem Report (das Quell-ISP-Token kommt aus dessen eigenem ",[29,1856,1857],{},"User-Agent",", die gemeldete Domain aus dessen eigenem RFC-5965-Feld), und die einzige vorgelagerte Authentifizierung ist eine VERP-zugerechnete Message-ID, die jeder Empfänger eines Sendevorgangs ohnehin besitzt. Ein Report gegen eine ",[29,1860,1861],{},"not_started","-Domain wird deshalb mit dem Grund ",[29,1864,1865],{},"not_submitted"," abgelehnt und schreibt überhaupt keine Zeile. Ab ",[29,1868,1869],{},"awaiting_yahoo"," befördert und belebt ein Report die Anmeldung unabhängig davon, was der Betreiber festgehalten hat, und ein Replay in falscher Reihenfolge dreht ",[29,1872,1873],{},"lastReportAt"," nie zurück. Die Convex-Hülle (",[29,1876,1877],{},"apps\u002Fapi\u002Fconvex\u002Fdomains\u002FyahooCfl.ts",") lädt, ruft auf und schreibt.",[491,1880,1881,1884,1885,1888,1889,1681,1891,1893,1894,1897,1898,48,1901,1904,1905,1908,1909,922,1912,1915,1916,1919],{},[61,1882,1883],{},"Die erneute Prüfung wird beim Lesen abgeleitet, nicht eingeplant."," Es gibt keinen Cron und keinen Schreibvorgang für die erneute Prüfung: ",[29,1886,1887],{},"getGuide"," berechnet ",[29,1890,1849],{},[29,1892,1873],{}," (ersatzweise ",[29,1895,1896],{},"enrolledAt",") gegen die Uhr zum Lesezeitpunkt, sodass das Urteil immer aktuell ist und zwischen zwei Durchläufen nie veralten kann. Die Beobachtung eines Reports ist der einzige Schreibvorgang und wird auf höchstens einen Zeilen-Patch pro Stunde ",[61,1899,1900],{},"zusammengefasst",[29,1902,1903],{},"YAHOO_CFL_REPORT_COALESCE_MS",") — Beschwerden treffen in Schüben ein und alle Reports einer Domain landen auf einer Zeile, sodass ein Patch pro Report genau jene Einzeldokument-Contention wäre, wegen der ADR-0042 geschrieben wurde. Die Beobachtung läuft außerdem ",[18,1906,1907],{},"nach"," der Suppression und innerhalb eines ",[29,1910,1911],{},"try",[29,1913,1914],{},"catch",", und nur für Verkehr über Zustelldomains in ",[29,1917,1918],{},"production",": Eine Beschwerde muss unabhängig von der Buchführung immer die Blockliste erreichen, und Mail aus der Mitglieder-Vorschau darf eine Anmeldung nie als live markieren.",[491,1921,1922,1925,1926,350,1929,1932,1933,1936,1937,1939],{},[61,1923,1924],{},"Die Betreiberoberfläche"," ist ein Panel pro Domain in der aufgeklappten Domainzeile (",[61,1927,1928],{},"Delivery → Domains",[29,1930,1931],{},"apps\u002Fweb\u002Fapp\u002Fcomponents\u002Fdomains\u002FYahooCflPanel.vue","): die vier geführten Schritte samt „woran Sie erkennen, dass es geklappt hat“, die Steuerelemente Absenden \u002F Bestätigen \u002F Neu beginnen für Owner und Admins (mit dem Grund für ein deaktiviertes Absenden als sichtbarer, per ",[29,1934,1935],{},"aria-describedby"," verknüpfter Text und einer Bestätigung bei „Neu beginnen“, die die Konsequenz benennt) sowie der Vertrauenssatz, den der reine Kern immer mitliefert. ",[29,1938,1861],{}," wird als ruhige, noch nicht begonnene Option dargestellt — nie als Warnbadge und nie als „Einrichtung unvollständig“-Ermahnung.",[491,1941,1942,278,1945,156,1948,156,1951,1954,1955,1958,1959,1962],{},[61,1943,1944],{},"Jedes Betreiberereignis wird auditiert.",[29,1946,1947],{},"submitEnrollment",[29,1949,1950],{},"confirmEnrollment",[29,1952,1953],{},"resetEnrollment"," schreiben jeweils eine Audit-Log-Zeile ",[29,1956,1957],{},"sending_domain.yahoo_cfl_changed"," — auch bei Ablehnungen —, die das Ereignis trägt, ob sich die Zeile geändert hat, den resultierenden Zustand samt Grund und ",[61,1960,1961],{},"auf welcher Beschwerdequelle die Yahoo-Zelle danach läuft",". „Neu beginnen“ ist der scharfe Fall: Es ist destruktiv und stuft diese Quelle von Yahoos eigenem Feed auf den Abmelderaten-Proxy herab, sodass die Herabstufung immer einen Akteur benennt.",[491,1964,1965,278,1968,1971,1972,1975,1976,1979,1980,1983,1984,1681,1987,1990,1991,1994,1995,1998,1999,1983,2002,2005,2006,2009,2010,1372,2013,1372,2016,2019,2020,2023,2024,156,2027,156,2030,2033],{},[61,1966,1967],{},"Der Auslösepunkt von Gate 3 hat genau ein Zuhause, und er ist eine Vereinigung aus zweien.",[29,1969,1970],{},"apps\u002Fapi\u002Fconvex\u002Fdelivery\u002Fsignals\u002FyahooCfl.ts"," wählt die aktive Quelle und veröffentlicht einen ",[29,1973,1974],{},"YahooComplaintTrip"," — dieselbe Regel, die ",[29,1977,1978],{},"evaluateStandaloneComplaintGate"," ausführt, nie eine zweite Deklaration davon. Die beiden Feed-Quellen (Yahoo CFL, CFBL-Address) liefern einen ",[29,1981,1982],{},"absolute_rate","-Auslöser bei ",[29,1985,1986],{},"RAMP_GATE_THRESHOLDS.complaintMax",[29,1988,1989],{},"delivery\u002Framp\u002FgateConfig.ts"," — dieselbe gebrandete ",[29,1992,1993],{},"RateFraction",", gegen die das eigene Beschwerde-Gate der Rampe vergleicht — und er ist auf der Fehlerseite ",[61,1996,1997],{},"strikt",": Genau der Schwellenwert besteht noch. Die Proxy-Quelle liefert einen ",[29,2000,2001],{},"trailing_multiple",[29,2003,2004],{},"RAMP_GATE_THRESHOLDS.unsubscribeProxyMultiple"," gegen die eigene nachlaufende 30-Tage-Abmelderate der Zelle, und dieser ist auf der Fehlerseite ",[61,2007,2008],{},"einschließend",": Genau das 3-Fache fällt durch, passend zu ",[29,2011,2012],{},"boundary: 'inclusive_fail'",[29,2014,2015],{},"UNSUBSCRIBE_PROXY_SPEC",[29,2017,2018],{},"trailingBaselineGates.ts",", wo die Regel des Proxys liegt. Zwei Arten von Auslösepunkt, zwei Grenzen, ein Komparator: ",[29,2021,2022],{},"compareYahooComplaintRate"," ist dreiwertig — ",[29,2025,2026],{},"breach",[29,2028,2029],{},"no_breach",[29,2031,2032],{},"not_comparable"," —, sodass eine Rate, die die Zähler nicht ausdrücken konnten, oder eine nachlaufende Baseline, die kein Nenner sein kann, als das gelesen wird, was sie ist: ein Halt, und nicht als gesunde Zelle.",[491,2035,2036,2039,2040,2042,2043,2046],{},[61,2037,2038],{},"Die DKIM-Vorbedingung"," kontrolliert nur unseren eigenen Assistenten: Yahoo akzeptiert keine Anmeldung für eine Domain, auf der es unsere Signatur nicht sehen kann, deshalb bleibt Schritt 2 ",[29,2041,1716],{},", bis die Domain ",[29,2044,2045],{},"verified"," ist und einen MTA-DKIM-Selektor trägt. Den Versand kontrolliert sie nie.",[491,2048,2049,2052,2053,2055,2056,2058],{},[61,2050,2051],{},"Abwesenheit ist eine unterstützte Konfiguration."," Eine Domain ohne Anmeldung ist schlicht ",[29,2054,1861],{},". Das Beschwerde-Gate der Yahoo-Zelle ersetzt die direkte Beschwerdeobergrenze von 0,1 % durch den CFBL-Feed (mittlere Konfidenz) oder den Abmelderaten-Proxy beim 3-Fachen der eigenen nachlaufenden 30-Tage-Abmelderate der Zelle (mittlere Konfidenz — ein Proxy, als solcher gekennzeichnet, mit dem Vertrauenssatz und dem Verbesserungsvorschlag an der Zelle). Der Assistent veröffentlicht exakt die Regel, die der Controller anwendet: Es gibt eine Definition dieses Auslösepunkts, nicht eine für den Bildschirm und eine für das Gate. ",[29,2057,1849],{}," ist eine Aufforderung, bei Yahoo erneut nachzusehen, kein Alarm: Nichts stoppt, nichts läuft auf einen Fehler, und es gibt keine „Einrichtung unvollständig“-Ermahnung.",[491,2060,2061,2064,2065,2068,2069,2072,2073,2076,2077,2080,2081,2084,2085,2087,2088,2090,2091,2093,2094,2097,2098,2101,2102,2105,2106,2109,2110,2112,2113,2116,2117,2119],{},[61,2062,2063],{},"Das erneute Prüfen einer abgelaufenen Anmeldung ist ein echter Übergang."," Der ",[18,2066,2067],{},"gespeicherte"," Zustand einer abgelaufenen Domain ist weiterhin ",[29,2070,2071],{},"enrolled",", deshalb setzen sowohl die Bedienmöglichkeit als auch die Zustandsmaschine am ",[61,2074,2075],{},"abgeleiteten"," Zustand an: ",[29,2078,2079],{},"yahooCflAvailableActions"," bietet „Absenden“ erneut an, der Absendeschritt öffnet sich wieder als To-do, und ein erneutes Absenden bringt den Datensatz mit einem frischen ",[29,2082,2083],{},"submittedAt"," zurück nach ",[29,2086,1869],{},", behält ",[29,2089,1873],{}," (beobachtete Historie) und verwirft das nun veraltete ",[29,2092,1896],{},". Eine aktive Anmeldung verweigert das Absenden weiterhin mit ",[29,2095,2096],{},"already_enrolled"," — geprüft ",[18,2099,2100],{},"vor"," der DKIM-Vorbedingung, sodass einer angemeldeten Domain, die später ihre DKIM-Bereitschaft verloren hat, nie gesagt wird, sie solle einen Eintrag für eine Domain veröffentlichen, die Yahoo bereits akzeptiert hat. Der vierte Schritt öffnet sich mit: „Beschwerden eintreffen sehen“ fragt, ob ein Report ",[61,2103,2104],{},"seit der aktuellen Einreichung"," gesehen wurde (",[29,2107,2108],{},"lastReportAt >= submittedAt","), nicht ob jemals einer gesehen wurde — so kann das beibehaltene ",[29,2111,1873],{}," den Schritt nicht als ",[29,2114,2115],{},"done"," stehen lassen (und behaupten, es flössen Beschwerden) für eine Anmeldung, die wir gerade nicht mehr für live halten. Er schließt sich wieder beim ersten Report, der das neue ",[29,2118,2083],{}," übertrifft. Das Panel rendert diese Bedienmöglichkeiten wortgetreu, statt eigene abzuleiten, sodass ein angebotenes Steuerelement immer eines ist, das die Zustandsmaschine auch bedient.",[38,2121,2123],{"id":2122},"eigene-tracking-domains","Eigene Tracking-Domains",[11,2125,2126,2127,380,2130,2133,2134,2137,2138,2141,2142,2145,2146,2149,2150,2153,2154,48,2157,2160],{},"Öffnungs- und Klicklinks zeigen auf den eigenen Tracking-Host des Deployments — die HTTP-Actions ",[29,2128,2129],{},"\u002Ft\u002Fo",[29,2131,2132],{},"\u002Ft\u002Fc",", ausgeliefert unter ",[29,2135,2136],{},"CONVEX_SITE_URL",". Ein Deployment kann eine gebrandete Subdomain ",[61,2139,2140],{},"registrieren und per DNS verifizieren",", sodass getrackte Links irgendwann seine eigene Domain statt eines gemeinsamen Hosts tragen. Registrierung, admin-geschützte DNS-Verifizierung und die Einstellungsoberfläche sind vorhanden; das Umschreiben der Links zum Sendezeitpunkt ist ",[61,2143,2144],{},"noch nicht verdrahtet"," (siehe den zweiten Punkt). Die Tabelle ",[29,2147,2148],{},"trackingDomains"," wird in ",[29,2151,2152],{},"apps\u002Fapi\u002Fconvex\u002Fdomains\u002FtrackingDomains.ts"," verwaltet und unter ",[61,2155,2156],{},"Einstellungen → Domains",[29,2158,2159],{},"TrackingDomainsSection.vue",") angezeigt:",[894,2162,2163,2187],{},[491,2164,2165,2168,2169,2172,2173,2175,2176,2179,2180,2183,2184,388],{},[29,2166,2167],{},"addTrackingDomain"," erfasst die Subdomain mit einem ",[29,2170,2171],{},"cnameTarget",", das aus dem Hostnamen von ",[29,2174,2136],{}," abgeleitet wird — dem Host, der die Tracking-Handler tatsächlich ausliefert, nie einem externen SaaS-Host. ",[29,2177,2178],{},"verifyTrackingDomain"," plant eine CNAME-Prüfung per DNS-over-HTTPS (Cloudflare) ein (",[29,2181,2182],{},"verifyTrackingDomainDns","), die die Zeile nur dann auf verifiziert umstellt, wenn der CNAME auf dieses Ziel auflöst. Alle drei Mutations erfordern ",[29,2185,2186],{},"requireAdminContext",[491,2188,2189,2190,48,2193,2196,2197,2200,2201,2204,2205,2208,2209,2212,2213,2215,2216,2219,2220,2222],{},"Die interne Query ",[29,2191,2192],{},"getActiveTrackingDomain",[29,2194,2195],{},"trackingDomains.ts",") stellt der Sende-Pipeline die erste verifizierte Zeile bereit, ",[61,2198,2199],{},"aber noch konsumiert sie kein Produzent",". ",[29,2202,2203],{},"delivery\u002Fworker.ts"," leitet ",[29,2206,2207],{},"trackingBaseUrl"," als ",[29,2210,2211],{},"envelopeInput.trackingBaseUrl ?? convexSiteUrl"," ab, und nichts auf dem Kampagnen-Sendepfad befüllt ",[29,2214,2207],{}," aus einer Tracking-Domain (",[29,2217,2218],{},"apps\u002Fapi\u002Fconvex\u002Fcampaigns\u002F"," enthält keinerlei Referenzen darauf). Getrackte Links fallen also unabhängig von jeder verifizierten Domain weiterhin auf ",[29,2221,2136],{}," zurück — die Branding-Hälfte dieser Funktion ist registriert und verifiziert, aber noch nicht in Links gerendert.",[38,2224,2226],{"id":2225},"pre-flight-für-die-ausrichtung-zweier-transporte","Pre-Flight für die Ausrichtung zweier Transporte",[11,2228,2229,2230,2233,2234,2237,2238,2241,2242,2245,2246,2249,2250,2253,2254,2257],{},"Wenn eine Sendedomain ",[61,2231,2232],{},"zwei"," konfigurierte Arme hat — den eigenen MTA und eine Referenz-Relay-Identität —, müssen die beiden für den Empfänger in allem außer der Sendeinfrastruktur ununterscheidbar sein. Sonst misst eine Anteilsrampe zwischen ihnen die DMARC-Ausrichtung und nicht die Zustellbarkeit. ",[29,2235,2236],{},"apps\u002Fapi\u002Fconvex\u002Fdelivery\u002FalignmentPreflight.ts"," (Zustand) und ",[29,2239,2240],{},"alignmentPreflightGather.ts"," (Live-DNS, Node-Runtime) verifizieren vier Prüfungen erneut und speichern das Urteil in ",[29,2243,2244],{},"deliverabilityAlignmentStates","; der reine Entscheidungskern ist ",[29,2247,2248],{},"packages\u002Fshared\u002Fsrc\u002FdeliverabilityAlignment.ts",". Der Sweep-Cron läuft ",[61,2251,2252],{},"stündlich",", und jede Domain trägt ihr eigenes ",[29,2255,2256],{},"nextCheckDueAt"," — 24 h nach einem aufgelösten Urteil, ~1 h nach einer nicht aufgelösten Abfrage —, sodass die kürzere Wiederholungsfrequenz tatsächlich eingehalten wird; eine Domain, die nicht fällig ist, kostet einen indizierten Lesevorgang. Jeder Lauf durchläuft eine begrenzte Zahl von Seiten verifizierter Domains und reicht den Cursor an eine eingeplante Fortsetzung weiter, sodass ein Deployment mit vielen Domains sie alle erneut prüft statt nur die erste Seite.",[894,2259,2260,2280,2301,2319],{},[491,2261,2262,2265,2266,2269,2270,48,2273,350,2276,2279],{},[61,2263,2264],{},"From-Domain"," — auf beiden Armen identisch. Blockierend. Eine Subdomain pro ",[18,2267,2268],{},"Transport"," spaltet die Domainreputation auf und macht die Arme unvergleichbar; Subdomains pro ",[18,2271,2272],{},"Stream",[29,2274,2275],{},"news.",[29,2277,2278],{},"bounces.",") sind die legitime, davon getrennte Sache und bestehen, wenn beide Arme sie teilen.",[491,2281,2282,2285,2286,2289,2290,2293,2294,2297,2298,388],{},[61,2283,2284],{},"SPF"," — ein ",[29,2287,2288],{},"v=spf1","-Eintrag, der beide Arme autorisiert, innerhalb des 10-Lookup-Limits von RFC 7208. Zählung und Merge liegen in ",[29,2291,2292],{},"packages\u002Fshared\u002Fsrc\u002FspfCoexistence.ts"," (eine Implementierung, aufbauend auf den ausgelieferten Merge-Primitiven in ",[29,2295,2296],{},"spf.ts","); ein Eintrag über dem Limit benennt das zu flachende ",[29,2299,2300],{},"include:",[491,2302,2303,2306,2307,2310,2311,2314,2315,2318],{},[61,2304,2305],{},"DKIM"," — beide Arme signieren dasselbe ",[29,2308,2309],{},"d="," mit ",[61,2312,2313],{},"unterschiedlichen"," Selektoren, nachgewiesen per Live-TXT-Abfrage. Ein leeres ",[29,2316,2317],{},"p="," (widerrufen) fällt durch.",[491,2320,2321,2324,2325,2328,2329,2332,2333,2335],{},[61,2322,2323],{},"DMARC"," — ein einzelner ",[29,2326,2327],{},"_dmarc","-Eintrag existiert und beide Arme richten sich unter dessen Modus aus (",[29,2330,2331],{},"adkim=s"," verlangt, dass ",[29,2334,2309],{}," exakt der From-Domain entspricht).",[212,2337,2339],{"id":2338},"der-referenzarm-und-warum-er-singulär-sein-muss","Der Referenzarm, und warum er singulär sein muss",[11,2341,2342,2343,48,2346,2349,2350,2353,2354,2357],{},"Der Adaptive Mix hat genau zwei Arme: den ",[61,2344,2345],{},"eigenen Arm",[29,2347,2348],{},"OWN_ARM_TRANSPORT_KIND = 'mta'",") und einen ",[61,2351,2352],{},"Referenzarm"," — dasjenige Relay, über das dieses Deployment den anderen Anteil versendet. Jede andere Art ist automatisch der Referenzarm; es gibt keinen Controller-Code pro Provider, weshalb Mailchimp Transactional zu einem erstklassigen Migrationsarm wurde, ohne dass der Controller irgendetwas darüber lernen musste. Die Identität, die einen Arm beschreibt, stammt aus der Provider-Registry der Sendedomain (",[29,2355,2356],{},"domains\u002Fproviders\u002F\u003Ckind>\u002FdescribeReferenceArm","), sodass ein Provider seinen eigenen Arm genauso mitbringt wie seinen eigenen Relay-Nachweis.",[11,2359,2360,2363,2364,2367,2368,2370,2371,2374],{},[61,2361,2362],{},"Halten Sie während einer Migration genau ein Relay aktiviert."," Bei zweien gibt es keinen eindeutigen zweiten Arm, mit dem eine Domain verglichen werden könnte: Der Pre-Flight schreibt ",[29,2365,2366],{},"unknown"," (ein Halt, nie ein Bestehen), das Urteil verschlechtert die Messkonfidenz, und jede Zelle bleibt bei ihrem aktuellen Anteil. Das ist kein Fehlerzustand, den man durch Verifizieren von irgendetwas behebt — es ist eine Konfigurationsfrage mit genau einer Antwort, deshalb nennt das ",[29,2369,2366],{},"-Detail, welche Relays aktiviert sind, und das Dashboard zeigt es unter Delivery → Provider und Delivery → Cells als eigene Warnung an statt als vierten DNS-Befund. Ein Team, das von Mailchimp kommt, läuft genau in dem Moment hinein, in dem es einen alten SES- oder Resend-Key neben ",[29,2372,2373],{},"MANDRILL_API_KEY"," stehen lässt.",[11,2376,2377,2378,2381],{},"Relays, deren Nachweis altert, werden genauso gehalten. Eine Mandrill-Sendedomain-Identität wird von einem stündlichen Sweep neu bestätigt und läuft nach 7 Tagen ab (",[29,2379,2380],{},"MANDRILL_RELAY_PROOF_MAX_AGE_MS","); eine abgelaufene liest sich als „wird erneut geprüft“ und hält den Anteil, statt ein verifiziertes Relay zu melden, dem das Routing bereits nicht mehr vertraut.",[11,2383,2384],{},"Semantik, die stärker zählt als die Prüfungen selbst:",[894,2386,2387,2399,2405,2426,2450,2467,2476,2488],{},[491,2388,2389,2395,2396,2398],{},[61,2390,2391,2392,2394],{},"Eine Abfrage, die nicht beantwortet werden konnte, ist ",[29,2393,2366],{},", kein Fehlschlag und kein Bestehen."," Timeout \u002F SERVFAIL \u002F REFUSED halten die Zelle bei ihrem aktuellen Anteil und werden in einer Stunde wiederholt; NXDOMAIN und eine leere Antwort sind autoritative Abwesenheiten und fallen durch. Das ist der eine DNS-Lesevorgang im Backend, der bewusst ",[18,2397,277],{}," weich auf „nicht gefunden“ zurückfällt.",[491,2400,2401,2404],{},[61,2402,2403],{},"Kein Referenztransport bedeutet nichts auszurichten — und nichts zu speichern."," Der Sweep überspringt die Domain vollständig: keine zu vergleichenden Arme, keine DNS-Abfragen, keine Urteilszeile. Das Bereitschaftspanel rendert deshalb für ein Deployment ohne jegliche Drittanbieter-Konten keine Ausrichtungswarnung; nirgendwo erscheint ein Fehler- oder „Einrichtung unvollständig“-Zustand.",[491,2406,2407,2417,2418,2421,2422,2425],{},[61,2408,2409,2410,278,2413,2416],{},"Ein ",[18,2411,2412],{},"gespeichertes",[29,2414,2415],{},"single_arm","-Urteil hört in dem Moment auf, Beweis zu sein, in dem ein Relay konfiguriert wird."," Es wurde erfasst, als es keinen zweiten Arm gab, und es ist das eine Urteil, das eine Domain ohne Auffrischung ewig halten könnte, deshalb honoriert das Gate es nicht: Sobald ein Referenzarm im Spiel ist, fällt die Zeile auf ",[29,2419,2420],{},"not_yet_checked"," durch und hält, bis der Sweep ein echtes Zwei-Arm-Urteil erzeugt. ",[29,2423,2424],{},"referenceArm === 'none'"," ist der einzige Ein-Arm-Grund zum Öffnen. (Solche Zeilen existieren nur aus der Zeit, bevor der Sweep aufhörte, sie zu schreiben; das Spiegelbild der Regel „eine reine Relay-Domain wird übersprungen“ weiter unten.)",[491,2427,2428,2433,2434,922,2436,922,2438,922,2440,2442,2443,2446,2447,2449],{},[61,2429,2430,2431,388],{},"Ein Relay, das wir nicht beschreiben können, hält, und heißt nie ",[29,2432,2415],{}," Die ausgelieferte Transportmenge ist breiter als SES (",[29,2435,155],{},[29,2437,159],{},[29,2439,162],{},[29,2441,165],{}," plus ",[29,2444,2445],{},"plugin.*","). Ist ein Relay aktiviert, die Domain hat aber keine signierende Identität, gegen die wir vergleichen können, lautet das Urteil ",[29,2448,2366],{}," — ein Halt —, denn mit „kein zweiter Arm“ für einen Transport zu antworten, den wir bloß nicht beschreiben konnten, ließe zwei tatsächlich nicht ausgerichtete Arme hochrampen.",[491,2451,2452,2459,2460,2463,2464,2466],{},[61,2453,2454,2455,2458],{},"Die SPF-Mechanismen des eigenen Arms stammen aus ",[29,2456,2457],{},"MTA_IP_POOLS",","," nicht aus dem gespeicherten SPF-Wert der Domain (der für eine bei SES registrierte Domain ",[18,2461,2462],{},"das"," Include des Relays ist). Ohne konfigurierten Pool ist die SPF-Prüfung ",[29,2465,2366],{},", nie ein Bestehen auf einem reinen Relay-Eintrag.",[491,2468,2469,2472,2473,2475],{},[61,2470,2471],{},"Eine reine Relay-Domain wird übersprungen, nicht blockiert."," Eine verifizierte Domain ohne eigene MTA-Identität hat keinen Arm zum Vergleichen, deshalb wird keine Urteilszeile geschrieben — ein nicht handhabbares dauerhaftes ",[29,2474,1716],{}," wäre ein für eine unterstützte Konfiguration herbeigeführter Fehlerzustand.",[491,2477,2478,48,2481,859,2484,2487],{},[61,2479,2480],{},"Die Bereitschaftsoberfläche",[29,2482,2483],{},"getAlignmentReadiness",[29,2485,2486],{},"apps\u002Fweb\u002Fapp\u002Futils\u002FdeliveryReadiness.ts"," → das Delivery-Bereitschaftspanel) rendert ein Gate nur dann, wenn wirklich ein Referenztransport im Spiel ist, und dieses Gate ändert nie das Urteil des Sendepfads: Was es hält, ist die Rampe, nicht der Versand.",[491,2489,2490,2493],{},[61,2491,2492],{},"Der Return-Path wird erfasst, blockiert aber nie."," Ein Relay, das den eigenen VERP-Return-Path nicht tragen kann, markiert lediglich die Messung der Domain als verschlechtert.",[38,2495,2497],{"id":2496},"bildschirm-zur-zustellmessung-nur-lesend","Bildschirm zur Zustellmessung (nur lesend)",[11,2499,2500,2503,2504,2507,2508,2510,2511,2514],{},[29,2501,2502],{},"\u002Fdashboard\u002Fadmin\u002Fdelivery\u002Fadvanced\u002Fmeasurement"," rendert das, was die Ramp-Gates sehen, bevor irgendetwas darauf reagiert. Eine organisationsbezogene Query — ",[29,2505,2506],{},"apps\u002Fapi\u002Fconvex\u002Fdelivery\u002FdeliverabilityDashboard.ts"," — liest für jede Zelle ",[29,2509,313],{}," die Transportergebnisse beider Arme und liefert pro Zelle: die Zähler und Raten beider Arme, das Urteil jedes Gates ",[61,2512,2513],{},"samt der Zahlen, die es erzeugt haben",", die Messkonfidenz und einen Trendpunkt pro Tag des Fensters. Hinter diesem Bildschirm liegen keine Steuerelemente und keine Schreibvorgänge.",[894,2516,2517,2531,2545,2551,2654],{},[491,2518,2519,2522,2523,2526,2527,2530],{},[61,2520,2521],{},"Das Fenster ist fest verankert, nicht gewählt."," Die Query nimmt keine Argumente entgegen: ",[29,2524,2525],{},"dashboardWindow()"," leitet das 7-Tage-Auswertungsfenster ab, die nachlaufende Baseline, gegen die Gate 4b vergleicht, und die weiteste Grenze, die der einzelne Index-Lesevorgang abdecken muss. Die Baseline ",[61,2528,2529],{},"endet dort, wo das Auswertungsfenster beginnt"," — eine Baseline, die das jüngste Fenster überlappte, trüge bereits den Zerfall in sich, den der Slow-Poison-Boden aufdecken soll, und der Bildschirm würde ein Urteil rendern, das der Controller nie erreichen würde.",[491,2532,2533,2536,2537,2540,2541,2544],{},[61,2534,2535],{},"Jede Rate ist die des Summierers."," Die Query führt ",[29,2538,2539],{},"summarizeTransportOutcomeBuckets"," über den gelesenen Zeilen erneut aus — ein Lesevorgang pro (Zelle, Arm), daraus abgeleitet mehrere disjunkte Teilfenster — und die Vue-Komponenten formatieren, was ihnen übergeben wurde. Nichts in ",[29,2542,2543],{},"apps\u002Fweb\u002Fapp\u002Futils\u002FdeliverabilityMeasurement.ts"," dividiert, sodass der Bildschirm und der Ramp-Controller für denselben Verkehr keine unterschiedlichen Zahlen melden können (ADR-0042).",[491,2546,2547,2550],{},[61,2548,2549],{},"Dünne Daten sind ein Zustand, kein Fehler."," Ein Gate unterhalb seiner Stichprobenuntergrenze wird neutral als „noch nicht genug Daten — N von 400 Sendevorgängen in diesem Fenster“ gerendert. Eine Zelle, durch die niemand gesendet hat, wird leer und ruhig dargestellt.",[491,2552,2553,2556,2557,48,2560,2563,2564,2567,2568,2571,2572,2575,2576,2579,2580,2583,2584,2587,2588,2591,2592,2595,2596,2598,2599,2602,2603,2606,2607,2610,2611,350,2614,380,2616,2619,2620,2623,2624,2627,2628,2631,2632,2635,2636,350,2639,380,2641,1372,2644,2646,2647,1372,2650,2653],{},[61,2554,2555],{},"Kein Referenztransport ist eine unterstützte Konfiguration — gemessen von einer anderen Gate-Implementierung."," Ohne Relay im Spiel wählt die Query ",[29,2558,2559],{},"trailingBaselineGateEvaluator",[29,2561,2562],{},"apps\u002Fapi\u002Fconvex\u002Fdelivery\u002Framp\u002FgateEvaluation.ts",", einmal pro Organisation statt pro Zelle gewählt), sodass die Gate-Zeilen, die ein eigenständiger Betreiber liest, die ",[61,2565,2566],{},"Substitutionen über die nachlaufende Baseline"," sind — die eigene 30-Tage-Historie einer Zelle steht für den zweiten Arm — und nicht die Zwei-Arm-Vergleiche, die der Rest dieses Abschnitts beschreibt: Hard Bounce ist absolut ",[61,2569,2570],{},"plus"," ≤ 1,5× die nachlaufende Rate der Zelle, Deferral wird zum primären schnellen Signal befördert — die Deferral-",[61,2573,2574],{},"Rate",", wobei der harte Stopp über Blockmeldungen pro ISP (",[29,2577,2578],{},"evaluateSmtpBlockMessages",") sie ",[61,2581,2582],{},"überstimmt",": Der MTA klassifiziert jedes empfangene 4xx\u002F5xx in das gemeinsame Vokabular ",[29,2585,2586],{},"@owlat\u002Fshared\u002FsmtpBlockCategories"," und meldet das Urteil als typisiertes Feld auf einem ",[29,2589,2590],{},"smtp.classified","-Webhook, ",[29,2593,2594],{},"analytics\u002FsmtpResponseCategories.ts"," zählt es pro Zelle ",[29,2597,313],{},", Arm und UTC-Tag, und ein Fenster, dessen klassifizierte Antworten zu mindestens 0,5 % Verweigerungen sind, hält die Zelle rundheraus an, statt sie bloß durchfallen zu lassen (Issue #501). Verweigerung heißt, dass der Empfänger unseren Inhalt, unsere Absenderidentität oder unsere IP ablehnt — Throttling und Greylisting sind Ratendruck, sie werden im selben Fenster als Nenner gezählt und tragen nie zu diesem Zähler bei. Eine Zelle, deren Fenster überhaupt keine klassifizierte Antwort enthält, ist ABWESEND und nicht sauber: Die Klausel liefert kein Urteil und die Deferral-Rate entscheidet allein — One-Click-Abmeldung bei ≥ 3× der nachlaufenden Rate steht dort für Beschwerden, wo es keinen Feedback-Loop gibt, Engagement vergleicht gegen die eigene EWMA der Zelle (≥ 0,85, 7-Tage-Fenster, Untergrenze 2000 Sendevorgänge) und darf immer nur eine ",[18,2600,2601],{},"Verringerung"," rechtfertigen, und die Platzierung liest die selbst gehosteten Seeds absolut. Was ",[29,2604,2605],{},"apps\u002Fapi\u002Fconvex\u002Fdelivery\u002Framp\u002FtrailingBaselineGates.ts"," verantwortet, ist die ",[61,2608,2609],{},"Form"," jeder Substitution, nicht ihre Zahlen: ",[29,2612,2613],{},"TRAILING_HARD_BOUNCE_SPEC",[29,2615,2015],{},[29,2617,2618],{},"TRAILING_ENGAGEMENT_SPEC"," legen fest, welche Reihe gegen welche verglichen wird (das jüngste Fenster gegen die eigene nachlaufende Baseline der Zelle statt gegen einen zweiten Arm), dass die Bounce- und Abmeldevergleiche ",[29,2621,2622],{},"kind: 'multiple'"," sind — ein Verhältnis, weil ein anderer Monat mit einer anderen Liste nur relativ beurteilt werden kann — und auf welcher Seite der Grenze jeder von ihnen liegt: ",[29,2625,2626],{},"inclusive_pass"," für die 1,5×-Bounce-Toleranz (genau 1,5× besteht noch) und ",[29,2629,2630],{},"inclusive_fail"," für den 3×-Abmelde-Proxy (genau 3× fällt durch). Die ",[61,2633,2634],{},"Werte"," liegen dort, wo jeder andere Ramp-Schwellenwert liegt: ",[29,2637,2638],{},"RAMP_GATE_THRESHOLDS.hardBounceTrailingMultiple",[29,2640,2004],{},[29,2642,2643],{},"RAMP_GATE_SAMPLE_FLOORS.engagementTrailing",[29,2645,1989],{}," sowie ",[29,2648,2649],{},"ENGAGEMENT_GATE_THRESHOLDS.trailingBaselineRatio",[29,2651,2652],{},"delivery\u002Framp\u002FengagementConfig.ts",". Das 7-Tage-Fenster ist bewusst nirgends eine Konstante — die Gates nehmen ihre Fenster als Parameter entgegen, sodass derjenige Aufrufer, der das Fenster gewählt hat, es auch benennt.",[491,2655,2656,278,2659,2662,2663,2666,2667,2672,2673,2676,2677,2681,2682,2686,2687,2689],{},[61,2657,2658],{},"Die Konfidenz einer einarmigen Zelle hat drei Fälle, nicht einen.",[29,2660,2661],{},"dashboardConfidence"," nimmt das Schwächste aus dem, was die Gates tatsächlich gemessen haben, und einer ",[18,2664,2665],{},"Obergrenze",", die sich daraus ergibt, welche Instrumente existieren: ",[61,2668,2669],{},[29,2670,2671],{},"none"," für eine Zelle, durch die niemand gesendet hat (",[29,2674,2675],{},"ownSent \u003C= 0",", kurzgeschlossen, bevor irgendeine Note gelesen wird), ",[61,2678,2679],{},[29,2680,769],{},", wenn weder ein Relay noch Seed-Postfächer verbunden sind, und ",[61,2683,2684],{},[29,2685,795],{},", wenn Seed-Postfächer ohne Relay existieren — eine ausgelieferte Konfiguration, seit die selbst gehosteten Seeds gelandet sind, keine hypothetische. ",[29,2688,814],{}," ist nur mit einem Referenzarm erreichbar. Neben der Stufe benennt die Karte als Einladung, was sie anheben würde — ein Relay verbinden, Seed-Postfächer hinzufügen, mehr Volumen senden. Die Überschrift lautet „Aufwärm-Autopilot“ statt eines abwertenden „Sendeunabhängigkeit“. Nichts läuft auf einen Fehler, warnt oder ermahnt.",[38,2691,2693],{"id":2692},"verwandte-themen","Verwandte Themen",[2695,2696],"link-card",{"description":2697,"title":26,"to":25},"Zustellung auf der Sendeseite: Throttling pro ISP, der IP-Warming-Fahrplan, Circuit Breaker, DNSBL-Monitoring.",[2695,2699],{"description":2700,"title":1273,"to":2701},"Die austauschbaren Provider-Abstraktionen (LLM, E-Mail, Benachrichtigungen) und wie Sie einen neuen Sende-Provider hinzufügen.","\u002Fdeveloper\u002Fproviders",[2695,2703],{"description":2704,"title":2705,"to":2706},"Die nutzerseitige Sicht auf Reputation, Warming und Posteingangsplatzierung.","Zustellbarkeit (Leitfaden)","\u002Fguide\u002Fdeliverability",[2695,2708],{"description":2709,"title":2710,"to":2711},"Provider-Beschränkungen, Bereitschaft der ausgehenden IP, der eingecheckte Aufwärmplan und Relay-Abwägungen.","Versand von einem VPS","\u002Fguide\u002Fsending-from-a-vps",{"title":2713,"searchDepth":2714,"depth":2714,"links":2715},"",2,[2716,2720,2723,2732,2733,2734,2738,2739,2740,2743,2744],{"id":40,"depth":2714,"text":41,"children":2717},[2718],{"id":214,"depth":2719,"text":215},3,{"id":471,"depth":2714,"text":472,"children":2721},[2722],{"id":534,"depth":2719,"text":535},{"id":619,"depth":2714,"text":620,"children":2724},[2725,2726,2727,2728,2729,2730,2731],{"id":653,"depth":2719,"text":654},{"id":751,"depth":2719,"text":752},{"id":836,"depth":2719,"text":837},{"id":885,"depth":2719,"text":886},{"id":966,"depth":2719,"text":967},{"id":1114,"depth":2719,"text":1115},{"id":1260,"depth":2719,"text":1261},{"id":1379,"depth":2714,"text":1380},{"id":1471,"depth":2714,"text":1472},{"id":1591,"depth":2714,"text":1592,"children":2735},[2736,2737],{"id":1595,"depth":2719,"text":1596},{"id":1669,"depth":2719,"text":1670},{"id":1783,"depth":2714,"text":1784},{"id":2122,"depth":2714,"text":2123},{"id":2225,"depth":2714,"text":2226,"children":2741},[2742],{"id":2338,"depth":2719,"text":2339},{"id":2496,"depth":2714,"text":2497},{"id":2692,"depth":2714,"text":2693},"Das Zustellbarkeits-Backend auf Convex-Seite: Provider-Routing, gesundheitsbewusstes Failover, Versandreputation mit automatischer Durchsetzung, Cache für IP-Warming, die Blockliste und das Content-Scan-Gate.","md",{},true,"\u002Fdeveloper\u002Fdeliverability-infrastructure",{"title":6,"description":2745},"3.developer\u002F19.deliverability-infrastructure","ntETBwhdSHwngU3wfTrkjqqbYf_IVXOnTFcjI8Rw8Iw",[2754,2758],{"title":2755,"path":2756,"stem":2757,"children":-1},"Automationen im Detail","\u002Fdeveloper\u002Fautomation-internals","3.developer\u002F18.automation-internals",{"title":2759,"path":2760,"stem":2761,"children":-1},"Architekturüberblick","\u002Fdeveloper\u002Farchitecture","3.developer\u002F2.architecture",1786915108669]