E-Mail-Zustellbarkeit 2026 — die Standards, das Warm-up, der Feedback-Loop.

§1 · Grundlagen

Was E-Mail-Zustellbarkeit tatsächlich bedeutet.

Zustellbarkeit ist die Quote, mit der Ihre gesendeten Nachrichten im primären Posteingang des Empfängers ankommen — abzugrenzen von der Auslieferung (die Nachricht wurde vom Empfänger-Mailserver akzeptiert) und vom Versand (Sie haben sie an die Sende-Pipeline übergeben). Eine Nachricht kann erfolgreich versendet, dem Empfänger-Mailserver zugestellt und trotzdem im Spam-Ordner gelandet sein — das ist ein Auslieferungs-Erfolg und ein Zustellbarkeits-Versagen. Die Zahlen, die zählen — Open Rate, Click Rate, Conversion — hängen von der Zustellbarkeit ab, nicht von der Auslieferung.

Mailbox-Provider — Gmail, Outlook, Yahoo, Apple iCloud Mail, Proton, die großen regionalen Anbieter — betreiben jeweils eine mehrstufige Scoring-Pipeline für jede eingehende Nachricht. Die Stufen sind providerübergreifend ähnlich, nur die Gewichtung unterscheidet sich:

1. Prüfungen beim Verbindungsaufbau. Reverse DNS, HELO/EHLO-Plausibilität, TLS-Unterstützung, IP-Listung auf RBLs (Spamhaus, SpamCop usw.).
2. Authentifizierungs-Prüfungen. SPF Pass/Fail (RFC 7208), DKIM-Signatur-Validierung (RFC 6376), DMARC-Alignment (RFC 7489). Alle drei müssen sauber bestehen, damit das nachgelagerte Scoring am mildesten ausfällt.
3. Content-Scoring. Dichte von Spam-Keywords, Link-Reputation, Bild-zu-Text-Verhältnis, Konsistenz zwischen From-Name und From-Adresse.
4. Reputations-Lookup. Die interne Historie des Providers zu Ihrer Versand-IP und Ihrer From-Domain — historische Bounce-Rate, Beschwerdequote, Engagement bei früheren Sendungen.
5. Engagement-Signal. Hat der Empfänger (oder Empfänger seiner Kohorte) zuvor ähnliche Nachrichten von Ihnen geöffnet oder angeklickt? Aktuelles Engagement ist das stärkste positive Einzelsignal.
6. Disposition. Posteingang, Promotions-Tab (Gmail), Spam-Ordner oder Ablehnung. Die Disposition fließt wieder in die Reputation ein.

Die folgenden fünf Abschnitte behandeln die Stufen 2 (Authentifizierung) und 4 (Reputation). Stufe 1 ist im Wesentlichen Sache des Versand-Relays; Stufen 3 und 5 sind Content- und Audience-Entscheidungen außerhalb des Rahmens eines Zustellbarkeits-Leitfadens. Stufe 6 ist das Ergebnis. Für einen typischen kommerziellen Versender hebt eine saubere Umsetzung der Stufen 2 und 4 die Inbox-Quote von 60–80 % auf über 95 %.

Dieser Leitfaden richtet sich an selbstgehostete Betreiber, weil Sie es sind, der an den Stellschrauben dreht. Bei SaaS abstrahiert die Plattform das meiste; selbstgehostet sind Sie Eigentümer des SPF-Records, des DKIM-Schlüsselpaars, der DMARC-Policy und des IP-Warm-up-Plans. Die gute Nachricht: Die Standards sind öffentlich und stabil. Die schlechte: Abkürzungen gibt es keine.

§2 · SPF-Record

SPF — das Sender Policy Framework.

SPF (RFC 7208) ist eine öffentliche Liste der IP-Adressen, die im Namen Ihrer Domain E-Mails versenden dürfen. Sie publizieren sie als einzelnen TXT-Record auf Ihrer Versand-Domain. Wenn ein Mailbox-Provider eine Nachricht erhält, die vorgibt, von @yourcompany.com zu kommen, ruft er den SPF-Record unter yourcompany.com ab und fragt: Kam diese Nachricht von einer der gelisteten IPs? Wenn ja, besteht SPF. Wenn nein, fällt SPF durch.

Die Syntax

v=spf1 include:amazonses.com ~all

Liest sich als: „SPF Version 1, autorisiere alles, was Amazon SES autorisiert, alles andere Soft-Fail." Das ~all am Ende ist die Catch-all-Klausel. ~all = Soft-Fail (als verdächtig markieren, aber annehmen), -all = Hard-Fail (ablehnen), ?all = neutral (keine Aussage). Verwenden Sie ~all, bis DMARC stabil läuft, und ziehen Sie dann auf -all an.

Mehrere Versender (z. B. Google Workspace für Outbound + SES fürs Marketing + Mailgun fürs Transaktionale) werden mit mehreren include:-Mechanismen verkettet:

v=spf1 include:_spf.google.com include:amazonses.com include:mailgun.org ~all

Das 10-DNS-Lookups-Limit. RFC 7208 §4.6.4 deckelt die SPF-Auflösung bei insgesamt 10 DNS-Lookups. Jedes include: zählt als eines. Häufiger Fehlerfall: 5+ Anbieter verketten und das Limit überschreiten — danach löst SPF zu permerror auf und wird wie ein Fail behandelt. Auditieren Sie mit dig TXT yourcompany.com + einem SPF-Flattener, sobald Sie nahe am Limit sind.

SPF bei AcelleMail

Das SendingDomain-Modell von AcelleMail stellt getSpf() in app/Model/SendingDomain.php:154 bereit — die Methode liest die globale Einstellung spf_record und gibt den Wert des TXT-Records aus. verifySpf(string $ipOrHostname) in Zeile 363 kapselt die Bibliothek Mika56\SPFCheck: Sie fragt zur Laufzeit live das DNS ab und prüft auf RESULT_PASS. Die Verifizierungs-Oberfläche im Admin-UI zeigt grün, wenn der Record existiert und die Versand-IP autorisiert, ansonsten rot.

Praxis-Tipp: SPF authentifiziert ausschließlich den Envelope-Sender (das MAIL FROM auf SMTP-Ebene), nicht den sichtbaren From-Header. Genau diese Lücke schließt das DMARC-Alignment — siehe §4.

§3 · DKIM-Signatur

DKIM — die kryptografische Absender-Signatur.

DKIM (RFC 6376) hängt jeder ausgehenden Nachricht eine kryptografische Signatur an. Der Empfänger-Server holt Ihren öffentlichen Schlüssel aus einem TXT-Record im DNS, verifiziert die Signatur gegen bestimmte Header und den Nachrichten-Body und akzeptiert die Nachricht als authentisch, wenn die Rechnung aufgeht. SPF sagt „diese IP darf für uns versenden"; DKIM sagt „dieser exakte Nachrichten-Body und From-Header wurden seit dem Signieren nicht manipuliert".

Der Mechanismus

1. Sie erzeugen ein RSA-Schlüsselpaar (mindestens 1024 Bit, für neue Setups werden 2048 Bit empfohlen).
2. Der öffentliche Schlüssel kommt als TXT-Record unter {selector}._domainkey.{yourdomain} ins DNS. Der Selektor ist ein beliebiger String (z. B. k1, mail, 20251208), den Sie wählen, um Schlüssel rotieren zu können, ohne in Flight befindliche Nachrichten zu brechen.
3. Der private Schlüssel bleibt auf Ihrem Versand-Server. Der MTA (oder das Versand-Relay) signiert jede ausgehende Nachricht damit und fügt einen DKIM-Signature-Header an.
4. Der Empfänger-Mailserver liest die Werte d= (Domain) und s= (Selektor) aus dem Signatur-Header, schlägt {s}._domainkey.{d} nach, holt den öffentlichen Schlüssel und verifiziert.

DKIM bei AcelleMail

SendingDomain::generateDkimKeys() in app/Model/SendingDomain.php:221 erzeugt über die OpenSSL-Bindings von PHP ein 1024-Bit-RSA-Schlüsselpaar, speichert den privaten Teil in dkim_private und den öffentlichen in dkim_public. Der Selektor wird aus dkim_selector am Modell gelesen, mit Fallback auf die globale Einstellung dkim_selector. Der DNS-Record-Wert wird über $this->getDomain()->getDkimDnsRecord() (Zeile 270) gerendert und dem Betreiber mit einem Copy-Button neben „der zu publizierende Wert" angezeigt.

Das Muster für die Schlüsselerzeugung (aus generateDkimKeys()):

$config = [
    'digest_alg' => 'sha256',
    'private_key_bits' => 1024,
    'private_key_type' => OPENSSL_KEYTYPE_RSA,
];
$res = openssl_pkey_new($config);
openssl_pkey_export($res, $privKey);
$pubKey = openssl_pkey_get_details($res)['key'];

Verifizierung: $this->getDomain()->verifyDkim() fragt das DNS unter {selector}._domainkey.{domain} ab und vergleicht den publizierten öffentlichen Schlüssel mit dem lokal hinterlegten Wert. Die vollständige verify()-Methode am Modell orchestriert Identitäts- + DKIM- + SPF- + DMARC-Checks in einem einzigen Aufruf (Zeile 300).

Vom Anbieter verwaltetes DKIM

Wenn Sie über Amazon SES, SendGrid, Mailgun oder einen anderen Anbieter versenden, der serverseitig signiert, publizieren Sie statt eines selbst erzeugten Schlüssels den Selektor und den öffentlichen Schlüssel des Anbieters. Die Driver-Capability SignsDkimOnServer in AcelleMail (siehe app/SendingServers/Capabilities/SignsDkimOnServer.php) markiert Driver, die DKIM remote abwickeln; die UI zeigt dann die CNAME-Records des Anbieters zur Publikation an, statt ein lokales Schlüsselpaar zu erzeugen. SES nutzt drei CNAMEs, die _domainkey an amazonses.com delegieren — einmal einrichten, und SES rotiert den darunterliegenden Schlüssel automatisch.

§4 · DMARC-Policy

DMARC — Alignment, Policy und Reporting.

DMARC (RFC 7489) setzt auf SPF und DKIM auf. Es leistet drei Dinge, die SPF und DKIM einzeln nicht können:

1. Alignment. Verlangt, dass die SPF-validierte Envelope-Domain oder die DKIM-signierende Domain mit der sichtbaren From-Header-Domain übereinstimmt. Ohne Alignment können SPF und DKIM für eine andere Domain bestehen als die, die der Empfänger sieht — genau diese Lücke nutzt Phishing aus.
2. Policy. Sagt empfangenden Servern, was sie tun sollen, wenn das Alignment fehlschlägt: none (nichts tun, nur reporten), quarantine (in den Spam liefern), reject (die Nachricht bereits per SMTP ablehnen).
3. Reporting. Aggregierte Reports (RUA — tägliche XML-Berichte über alle Sendungen von Ihrer Domain) und forensische Reports (RUF — Einzelberichte pro Fehlerfall) gehen an die Adressen, die Sie angeben. Die Reports geben Ihnen Sichtbarkeit darüber, wer in Ihrem Namen Mails versendet.

Die Syntax

_dmarc.yourcompany.com.    TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.com; pct=100; aspf=s; adkim=s"

Liest sich als: „DMARC Version 1, Nachrichten ohne Alignment in Quarantäne, aggregierte Reports an dmarc@yourcompany.com, Policy auf 100 % der fehlschlagenden Nachrichten anwenden, striktes Alignment für SPF und DKIM verlangen."

Der Standard-Rollout

1. Tag 0: p=none mit rua= auf eine überwachte Mailbox publizieren. 7–14 Tage Reports annehmen. Reiner Observation-Modus — keine Nachricht wird abgelehnt.
2. Tag 14: Reports auswerten. Legitime Versender (eigenes SES, die CRM-Versand-IPs, Transaktions-Anbieter) identifizieren und durchgehend in SPF + DKIM-Alignment bringen.
3. Tag 30: auf p=quarantine; pct=10 anziehen. Nicht alignte Mail geht für 10 % der Empfänger in den Spam. Zwei Wochen lang die Reports beobachten.
4. Tag 45: über 2–4 Wochen auf pct=50 und dann pct=100 hochziehen.
5. Tag 60–90: auf p=reject verschärfen. Nicht alignte Mail wird jetzt bei SMTP gebounct — Phisher, die Ihre Domain missbrauchen, sehen Hard Rejects.

Den Rollout nicht überspringen. Der Sprung von kein DMARC direkt auf p=reject ist die häufigste Ursache für selbst verschuldete Zustellbarkeits-Katastrophen: Ein vergessener Transaktions-Versender (Ihr CRM, Ihr Support-Tool, Ihr Billing-System) fängt in dem Moment an Hard-Bounces zu produzieren, in dem p=reject propagiert.

Vorgaben der Mailbox-Provider

Seit Februar 2024 verlangen Gmail und Yahoo DMARC von jedem Versender, der mehr als 5.000 Nachrichten pro Tag an ihre Domains schickt, zusätzlich zu aligntem SPF oder DKIM und One-Click-List-Unsubscribe (RFC 8058). Microsoft 365 hat sich zum Redaktionsschluss demselben Standard angeschlossen. Die Schwelle für „kommerziellen Versand" ist dauerhaft verschoben — DMARC ist für keine Liste über ~1.000 Kontakten mehr optional. Richten Sie es früh ein, auch wenn Ihre Liste noch klein ist.

§5 · BIMI-Logo

BIMI — der Marken-Logo-Bonus.

BIMI (Brand Indicators for Message Identification) zeigt Ihr Markenlogo neben Ihren Nachrichten im Posteingang des Empfängers an. Gmail, Yahoo, Apple Mail und Fastmail unterstützen es seit 2025. Es ist ein zustellbarkeitsnahes Feature — keine Authentifizierung im engeren Sinne — setzt aber DMARC auf p=quarantine oder p=reject als Voraussetzung voraus, weshalb es in diesem Leitfaden steht.

Einrichtungs-Schritte (sobald DMARC auf quarantine oder strenger steht):

1. Eine SVG-Version Ihres Logos nach der BIMI-SVG-Tiny-PS-Spezifikation erstellen — quadratisch, kein Text außerhalb der Marke, einfache Pfade.
2. Die SVG-Datei unter einer öffentlich erreichbaren HTTPS-URL hosten.
3. Optional ein Verified Mark Certificate (VMC) bei einer CA beziehen — von Gmail zwingend, um das Logo mit blauem Häkchen anzuzeigen, ca. 1.500 $/Jahr. Common Mark Certificates (CMC) sind die günstigere Alternative für nicht eingetragene Marken.
4. Den BIMI-Record publizieren: default._bimi.yourcompany.com TXT "v=BIMI1; l=https://yourcdn/logo.svg; a=https://yourcdn/vmc.pem"

Der Zustellbarkeits-Effekt von BIMI ist indirekt, aber messbar: Markenlogos im Posteingang heben die Open Rate laut publizierten Case Studies um 5–20 % (Pilot-Daten von Yahoo Mail, BIMI-Report von Mailchimp). BIMI wirkt zugleich als wirksame Forcing-Function — ohne saubere DMARC-Konfiguration geht es nicht — weshalb Teams es als Belohnung für ein Authentifizierungs-Aufräumprojekt einsetzen.

§6 · Absender-Reputation

Reputation — was Mailbox-Provider tatsächlich bewerten.

Authentifizierung ist binär — ein Record löst auf und alignt, oder eben nicht. Reputation ist kontinuierlich: ein Score von 0 bis 100, den jeder Mailbox-Provider getrennt für Ihre Versand-IP und Ihre From-Domain pflegt. Beide Scores fließen zusammen in die Routing-Entscheidung (Posteingang vs. Promotions vs. Spam vs. Reject).

Die Signale

Wo Sie Ihren Reputations-Score nachlesen

• Google Postmaster Tools (postmaster.google.com) — IP- und Domain-Reputation aus Gmail-Sicht, plus Authentifizierungs-Konformität, Verschlüsselungsrate, Spam-Rate. Kostenlos.
• Microsoft SNDS (postmaster.live.com/snds/) — IP-Daten von Outlook.com, Klassifizierung der Absender-Reputation. Kostenlos, Registrierung erforderlich.
• Yahoo Sender Hub — neuer, Anmeldung über die Yahoo-Postmaster-Seite. Aggregierte Statistiken pro Domain.
• Provider-Dashboards — das Amazon SES Reputation Dashboard zeigt Bounce- und Beschwerdequoten mit Schwellenwerten. SparkPost, Mailgun, SendGrid haben Vergleichbares.

Prüfen Sie mindestens eines davon wöchentlich. Die Frühindikatoren (Trend der Spam-Rate, Einbruch der IP-Reputation) tauchen Tage vor den nachgelagerten Effekten auf (sinkende Open Rate) — sobald Sie ein unterperformendes Kampagnen-Ergebnis bemerken, ist das Reputations-Problem bereits zwei Wochen alt.

§7 · IP-Warm-up

IP-Warm-up — der 6-Wochen-Plan.

Eine frische Versand-IP startet bei Reputation null. Mailbox-Provider drosseln hohe Volumina von neuen IPs systematisch — es ist die primäre Verteidigung gegen Snowshoe-Spammer, die Cloud-Instanzen hochfahren und blasten. Warm-up ist die Praxis, das Versand-Volumen über 4–6 Wochen schrittweise zu erhöhen und dabei unter den Tages- und Stunden-Throttle-Limits zu bleiben, sodass Reputation organisch aufgebaut wird.

Das machen Sie pro IP nur einmal. Die meisten Teams machen es nie, weil die Shared IPs von Amazon SES, SendGrid und Mailgun vorgewärmt sind. Wann Warm-up wirklich relevant wird: dedizierte IP auf SES (in der Regel ab > 1 Mio. Sends/Monat sinnvoll), selbstgehostete Postal-MTA auf einer frischen Cloud-Instanz, Migration von einem ESP zum nächsten mit Domain-Wechsel.

Der Plan

Der Plan konsolidiert die publizierten Warm-up-Empfehlungen von SparkPost, Postmark und SES zu einer einzigen Wochen-für-Wochen-Tabelle. Rampen Sie langsamer hoch, wenn die Beschwerdequote nach oben dreht; schneller nur dann, wenn jeder Schritt durch ein vom Provider bestätigtes Reputations-Grün gedeckt ist.

Warm-up-Tracking in AcelleMail

Das SendingServer-Modell von AcelleMail führt Warm-up-State erstklassig. warmup_enabled, warmup_strategy_id und warmup_started_at liegen auf der Tabelle sending_servers; isWarmupEnabled() in app/Model/SendingServer.php:333 gattet die Entscheidung zur Versandzeit. Die ergänzende Tabelle SendingServerWarmupLog protokolliert jeden Versand innerhalb des Warm-up-Fensters mit Datum, Status und einer serialisierten Meta-Payload — siehe app/Model/SendingServerWarmupLog.php.

Das Muster: einem Sending-Server eine WarmupStrategy (eine Zeile, die die Volumen-Kurve pro Tag definiert) zuweisen, warmup_enabled = true setzen, warmup_started_at = now(). SendingServerWarmupUsage in der Sende-Pipeline zählt die heutige Anzahl mit und verweigert die Dispatch, sobald die Tages-Decke der Strategie überschritten würde. Sobald die Tages-N-Decke das volle Tagesvolumen übersteigt, graduiert der Server und der Warm-up-Modus deaktiviert sich automatisch.

Die Klassen DynamicRateTracker und InMemoryRateTracker (app/Library/) übernehmen das Rate-Limiting pro Minute und pro Stunde auf SMTP-Ebene — auch außerhalb des Warm-ups setzt AcelleMail die publizierten Rate-Caps des Relays durch, damit ein Queue-Spike kein providerseitiges Throttling auslöst.

§8 · Bounces + Beschwerden

Bounces, Beschwerden und der Feedback-Loop.

Hard Bounce vs. Soft Bounce

Ein Hard Bounce ist ein dauerhafter Fehler — typischerweise ein 5xx-SMTP-Code: Die Adresse existiert nicht, die Domain löst nicht auf, das Postfach des Empfängers ist dauerhaft deaktiviert. Das BounceLog-Modell von AcelleMail definiert die Konstanten HARD und SOFT in app/Model/BounceLog.php:33; ein Hard Bounce sperrt die Adresse sofort. Ein Soft Bounce ist temporär — ein 4xx-Code: Mailbox voll, Server vorübergehend nicht erreichbar, Nachricht zu groß. Soft Bounces werden mit Backoff wiederholt; Adressen, die über mehrere Sendungen hinweg wiederholt Soft-bouncen, werden schließlich zu Hard heruntergestuft.

Die Klassifizierungs-Map für die AWS-SES-Bounce-Notifications (die Quelle, auf die AcelleMail in BounceLog.php:32 in der Dokumentation verweist): Bounce-Typen sind Permanent (hard) mit den Sub-Typen General / NoEmail / Suppressed / OnAccountSuppressionList; Transient (soft) mit den Sub-Typen General / MailboxFull / MessageTooLarge / ContentRejected / AttachmentRejected; sowie Undetermined (als soft behandeln, wiederholen).

Beschwerden

Eine Beschwerde ist ein Empfänger, der im Mail-Client „als Spam melden" klickt. Beschwerden erreichen Sie über Feedback-Loops (FBLs) — einen providerspezifischen Notification-Kanal, über den ISPs Ihnen die als Missbrauch gemeldeten Nachrichten weiterleiten. Der FeedbackLoopHandler von AcelleMail in app/Model/FeedbackLoopHandler.php verarbeitet eingehende FBL-Nachrichten über IMAP/POP und parst die Abuse-Reporting-Format-(ARF, RFC 5965)-Header, um die ursprüngliche Message-ID und den Feedback-Typ zu extrahieren.

ARF-Feedback-Typen, die AcelleMail verarbeitet (gemäß FeedbackLoopHandler::FEEDBACK_TYPES in Zeile 35):

• abuse — der Empfänger hat explizit als Spam markiert. Sofort sperren.
• fraud — der Empfänger hat als Phishing markiert. Sperren + Security-Review loggen.
• virus — der Virenschutz des Empfängers hat einen Payload gemeldet. Sperren + Content auditieren.
• other — generische Beschwerde. Sperren.
• not-spam — explizite „das ist kein Spam"-Rückmeldung (selten). Von der Sperrung ausgenommen — siehe EXCLUDED_FEEDBACK_TYPES.

Große Mailbox-Provider, die an FBLs teilnehmen: AOL, Yahoo, Microsoft (über JMRP), Comcast, BlueTie. Gmail betreibt keine öffentliche FBL — „als Spam markiert"-Feedback liefert Gmail über das Postmaster-Tools-Dashboard und über aggregierte DMARC-Reports.

Sperr-Regeln

1. Hard Bounce → dauerhaft sperren. Nie erneut versuchen; die Adresse ist tot.
2. Beschwerde → dauerhaft sperren. Der Empfänger hat aktiv um Stopp gebeten. Erneuter Versand ist in den meisten Jurisdiktionen illegal und verbrennt die Reputation.
3. Soft Bounce ×3 in 30 Tagen → auf hard herabstufen, sperren. Anhaltende Soft Bounces bedeuten dauerhaft volle Mailbox oder Konnektivitätsprobleme — als tot behandeln.
4. Abmeldung → für Marketing sperren, nicht fürs Transaktionale. Bestellbestätigungen und Passwort-Resets laufen weiter; Kampagnen stoppen.
5. Spam-Trap-Treffer → in die Untersuchung eskalieren. Die gesamte Acquisition-Quelle dieses Subscribers herausziehen. Die Liste war wahrscheinlich mit gekauften oder gescrapten Adressen kontaminiert.

§9 · Listen-Hygiene

Listen-Hygiene — die Disziplin, die Reputation hochhält.

Authentifizierung ist eine einmalige Einrichtung. Reputation ist operative Disziplin. Die sieben Gewohnheiten, die die Nadel bewegen:

1. Double-Opt-in für jede Marketing-Anmeldung. Ein Bestätigungs-Klick, bevor die Adresse auf der aktiven Liste landet. Beseitigt Tippfehler, Rollen-Adressen (info@, sales@) und gescrapte Adressen. Fügt der Anmeldung 10–20 % Reibung hinzu; reduziert das Bounce- und Beschwerderisiko um 50–80 %.
2. One-Click-Unsubscribe (RFC 8058). List-Unsubscribe-Header, der auf eine One-Click-URL zeigt. Pflicht für Gmail und Yahoo für Versender mit > 5K/Tag an deren Domains seit Februar 2024. Machen Sie das Abmelden einfacher als das Beschweren — wer sonst „Spam" klicken würde, klickt stattdessen „Abmelden".
3. Reaktivierung vor Sperrung. Abonnenten, die seit 90 Tagen nicht geöffnet haben, bekommen eine „Wir wollen relevant bleiben"-Kampagne. Geöffnet → behalten. Nicht geöffnet → in eine Sunset-Queue. Nach 180 Tagen ohne Öffnung → sperren.
4. Automatische Bounce-Sperrung. Den Bounce-Webhook innerhalb von Minuten verarbeiten; die Adresse vor der nächsten Kampagne aus der aktiven Sendeliste nehmen. BounceLog::record() von AcelleMail und vergleichbare vbrandsync-artige Bounce-Webhook-Handler erledigen das automatisch.
5. Keine gekauften Listen importieren. Niemals. Gekaufte Listen sind mit Spam-Traps gespickt. Ein Trap-Treffer und Ihre Domain steht 30+ Tage auf Spamhaus. Die Rechnung geht nie auf — gekaufte Listen sind ein dauerhaftes Reputations-Loch.
6. Nach Engagement segmentieren. Senden Sie Kampagnen an die engagierten 50 % doppelt so oft, an die kalten 50 % halb so oft. Das hebt die Gesamt-Open-Rate, drückt die Beschwerdequote und sendet Mailbox-Providern ein starkes „dieser Absender ist relevant"-Signal.
7. Automation-Frequenz deckeln. Eine Welcome-Serie + Abandoned Cart + Post-Purchase + Geburtstag + Reaktivierung können acht Nachrichten in einer einzigen Woche produzieren. Deckeln Sie die Automation-Nachrichten auf eine pro 48 Stunden pro Empfänger, mit harten Ausnahmen für Transaktionales (Belege, Passwort-Resets).

§10 · AcelleMail-Tooling

Das Zustellbarkeits-Tooling von AcelleMail — was der Source-Tree mitbringt.

Direkt aus dem Source-Tree unter app/Model/ und app/Library/ herausgezogen. Jeder Eintrag ist ein echtes Modell, eine Capability-Schnittstelle oder eine Library-Klasse — kein Marketing.

§11 · Fehlerbehebung

Häufige Zustellbarkeits-Probleme und ihre Lösungen.

§12 · Häufige Fragen

FAQ zur E-Mail-Zustellbarkeit.

Cluster-Übersicht

Wie es weitergeht.

Authentifizierte Domains. Getrackte Bounces. Posteingangs-taugliche Reputation.

AcelleMail bringt SPF/DKIM/DMARC-Verifizierung, ARF-Feedback-Loop-Verarbeitung, eine State Machine für IP-Warm-up und Rate-Limiting pro Server von Haus aus mit. Jede Aussage in diesem Leitfaden lässt sich auf eine Klasse in app/Model/ oder app/Library/ im Source-Tree von AcelleMail zurückführen.