PowerMTA-Einrichtung und Konfiguration

Der Port 25, vor allem anderen

Es gibt ein Teil, das vor allem anderen besondere Aufmerksamkeit braucht: der Port 25. Es ist der Port, über den die Mailserver untereinander kommunizieren — der Transport zwischen Servern —, während die Einlieferung von einem Client über Port 587 mit Authentifizierung läuft. Viele Zugangsnetze blockieren den ausgehenden Port 25 in Privatanschlüssen, als Anti-Spam-Maßnahme, und die Cloud-Anbieter sind in dieser Hinsicht nicht großzügiger: AWS etwa blockiert ihn standardmäßig auf allen Instanzen und verlangt einen Antrag zur Freigabe. Die direkte Konsequenz für den, der eine MTA betreibt: PowerMTA, das mit den Zielservern genau über Port 25 spricht, kann nicht an einem Privatanschluss leben, sondern in einem Rechenzentrum oder einer Cloud, wo dieser ausgehende Port verfügbar ist. Das zu bestätigen ist der erste Schritt der Bereitstellung, denn eine Engine, die nicht über Port 25 hinauskommt, stellt schlicht nicht zu, so gut sie auch konfiguriert ist.

Wo sollte PowerMTA laufen: Cloud, VPS oder Hardware?

Die erste Bereitstellungsentscheidung ist das Hosting, und PowerMTA verträgt sich mit fast allem: Es läuft auf Ihrer eigenen Hardware, auf einem VPS oder in einer öffentlichen Cloud wie AWS oder Azure und leistet viel mit relativ wenig Eisen, fähig, Millionen Nachrichten pro Stunde von einem einzigen gut konfigurierten Server zu bewegen. Die Wahl hängt weniger von roher Kraft ab und mehr von drei Dingen: der Kontrolle, die Sie über die IPs und ihre Reputation wollen, der Leichtigkeit, horizontal zu skalieren, wenn Sie wachsen, und den Beschränkungen Ihres Anbieters bei Port 25 und ausgehendem Versand. Der letzte Punkt überrascht viele: AWS etwa blockiert standardmäßig den ausgehenden Port 25 auf allen EC2-Instanzen und verlangt das Ausfüllen des Formulars „Request to remove email sending limitations“, mit einem zugehörigen A-Record und rDNS, und einer Antwort, die meist bis zu rund achtundvierzig Stunden dauert. Andere Clouds haben ähnliche Beschränkungen. Deshalb gehört zur Arbeit, vor der Bereitstellung zu bestätigen, dass der gewählte Anbieter den Anwendungsfall erlaubt und den Port freigibt. Wenn das Volumen es verlangt, erlaubt PowerMTA, den Traffic auf mehrere Knoten zu verteilen und die IPs auf einem externen Proxy mit dem HAProxy-Protokoll bereitzustellen, was Lastverteilung und Fehlertoleranz vereinfacht. Diese Architektur wird am Anfang entschieden, denn sie später umzubauen, kostet Reputation.

Die Härtung des Servers und die Sicherheit

Ein Versandserver ist ein begehrtes Ziel, und ein schlecht geschütztes PowerMTA ist ein Geschenk für jeden, der auf Ihre Kosten Spam senden oder Ihre Reputation stehlen will. Die Härtung beginnt beim Betriebssystem: eine unterstützte Linux-Distribution, aktualisiert, mit nur den nötigen Diensten am Laufen. Die Firewall beschränkt den Zugang so, dass Port 25 und die Versandports dort offen sind, wo sie sein müssen, und die Monitoring-Konsole von PowerMTA nur von vertrauenswürdigen Adressen oder hinter einem VPN erreichbar bleibt, nie dem Internet ausgesetzt. Die Authentifizierung der SMTP-Clients, die an die Engine einliefern, wird geschlossen, damit kein Fremder Mail einspeisen kann, und so das klassische offene Relay vermieden, das in Stunden auf jeder Blacklist endet. TLS bei den Verbindungen, gepflegte Schlüssel und Berechtigungen auf den Konfigurations- und DKIM-Schlüsseldateien und ein Zugriffprotokoll, das sehen lässt, wer was anfasst. Diese Schicht taucht selten in den Schnellanleitungen auf und ist genau die, die eine professionelle Installation von einer trennt, die aus Nachlässigkeit gekapert oder gelistet endet.

# Lizenziertes Paket installieren, dann bestätigen, dass der Dienst bindet
$ rpm -ivh PowerMTA-5.0r*.rpm && systemctl enable --now pmta
$ pmta show status | head -1
PowerMTA v5.0 running — 0 messages queued

# Die Prüfung, die einen Launch rettet: passt der PTR zum Sende-Host?
$ dig -x 198.51.100.25 +short
mta1.send.example.com.
$ dig +short mta1.send.example.com
198.51.100.25        # vorwärts und rückwärts stimmen — bereit zu authentifizieren

Warum entscheiden DNS und Authentifizierung über die Ablehnung?

Bevor PowerMTA eine einzige Nachricht versendet, müssen DNS und Authentifizierung tadellos sein, denn dort wird die Zustellung gegenüber Gmail, Yahoo und Microsoft gewonnen oder verloren. Jede versendende IP braucht ihren PTR-Record für Reverse-DNS, der zu einem Namen kohärent mit der Versanddomain auflöst; eine IP ohne PTR ist eine sofortige rote Flagge für die Filter. Die Domain veröffentlicht ein SPF, das die Versandquellen einschließt, ohne das Lookup-Limit zu überschreiten, DKIM mit einem Schlüssel pro Domain, mit dem PowerMTA jede Nachricht signiert, und ein DMARC, das über SPF oder DKIM ausrichtet. Das Alignment ist das Detail, das die meisten korrekten Bereitstellungen zu Fall bringt: Es genügt nicht, dass SPF und DKIM bestehen, die bestehende Domain muss mit der übereinstimmen, die der Empfänger im Absender sieht. Diese Schicht vor dem ersten Versand geschlossen und verifiziert zu hinterlassen, vermeidet das frustrierendste Szenario: eine perfekte Engine, die Mail versendet, die wegen einer halb aufgebauten Authentifizierung zurückkommt.

Die Tracking-Domain, getrennt

Ein Detail, das eilige Installationen übergehen, ist die Tracking-Domain, die die Öffnungs- und Klick-Links signiert. Sie sollte eine Domain oder Subdomain getrennt von der Hauptdomain der Marke sein, aus zwei Gründen. Der erste ist Reputation: Die Tracking- und Redirect-Aktivität darf die Reputation der zentralen Unternehmensdomain nicht verseuchen. Der zweite ist Kontrolle: Das Tracking zu trennen erlaubt, es zu verwalten, zu rotieren oder zu isolieren, ohne die Domain anzufassen, von der Ihre ernsthafte Mail abhängt. PowerMTA verwaltet das Tracking nativ, und es von Anfang an gut zu konfigurieren — mit eigenem DNS, eigenem TLS-Zertifikat und eigenem Alignment — vermeidet, es später entwirren zu müssen, wenn schon Reputation auf dem Spiel steht. Es ist eine dieser kleinen Anfangsentscheidungen, für die man ein Jahr später sehr dankbar ist.

Wie werden VirtualMTAs, Pools und Segmentierung entworfen?

Hier lebt das Herz einer guten Konfiguration. Ein VirtualMTA ist praktisch eine Versandidentität: eine Quell-IP mit ihrem Namen, ihrer Begrüßung und ihrem Verhalten. Indem man VirtualMTAs zu Pools gruppiert, trennt man die Mailströme nach ihrer Natur: Die Transaktionsmail, die der Nutzer erwartet und öffnet, sollte keine IPs mit der Massenwerbung teilen, deren Beschwerdeprofil anders ist; ein wichtiger Kunde kann seinen eigenen isolierten Pool verdienen; und ein neuer oder riskanter Strom bleibt getrennt, damit ein Problem nicht den Rest mitreißt. Diese Segmentierung erlaubt, die Reputation pro Strom zu verwalten und nicht als einen einzigen fragilen Block. Auf dieser Basis werden die Limits pro Provider aufgesetzt — wie viele Verbindungen und wie viele Nachrichten pro Stunde an Gmail, an Outlook, an Yahoo —, die PowerMTA mit seiner MX-Gruppierung anwendet, um die vielen Domains kohärent zu behandeln, die jeder große Provider verbirgt. Die VirtualMTAs und Pools am Anfang gut zu entwerfen, unterscheidet einen Versand, der geordnet skaliert, von einem, der sich verheddert, sobald er wächst.

Limits pro Provider und MX-Gruppierung

Im richtigen Tempo an jeden Provider zu senden, trennt die Zustellung von der Wand aus Ablehnungen, und hier gibt PowerMTA eine feine Kontrolle, die man mit Augenmaß nutzen muss. Für jedes Ziel werden die Zahl der gleichzeitigen Verbindungen, die Nachrichten pro Verbindung und die Rate pro Stunde justiert, Werte, die Gmail, Outlook und Yahoo unterschiedlich tolerieren und die sich zudem mit Ihrer Reputation ändern. Die Engine gruppiert die vielen Domains, die jeder große Provider verbirgt, über die MX-Gruppierung — die die jüngeren Versionen automatisch machen können —, sodass die Dutzenden Domains, die in Wahrheit auf die Google-Infrastruktur zeigen, mit einer kohärenten Richtlinie behandelt werden und nicht Domain für Domain. Ebenso wichtig ist die Antwort auf die Bremse: Beginnt ein Provider zu defer-en oder mit Verlangsamungscodes zu antworten, muss die Konfiguration das Tempo senken und mit Kopf wiederholen, statt stärker gegen eine sich schließende Tür zu drücken. Diese Limits zu stimmen, ist keine einmalige Justierung; es ist eine lebendige Arbeit, die dem Puls der Reputation folgt, und ein guter Teil dessen, was der erfahrene Betrieb der Engine einbringt. Im DACH-Raum lohnt zudem die Erinnerung, dass neben den großen globalen Providern lokale wie GMX, Web.de und T-Online mit eigener Nutzerbasis existieren, und sie mit eigenen Regeln statt einer generischen Richtlinie zu behandeln, ist es, was einen für das deutschsprachige Publikum gestimmten Versand auszeichnet.

Der Aufwärmplan

Eine neue IP hat keine Reputation, und die Provider misstrauen standardmäßig dem, der aus dem Nichts auftaucht und mit Volumen sendet. Das Aufwärmen ist der Prozess, den Versand über mehrere Wochen in Stufen zu steigern, niedrig beginnend und in einem Tempo zunehmend, das die Provider akzeptieren, anfangs die engagiertesten Empfänger priorisierend, um positive Signale anzusammeln. PowerMTA wärmt nicht von allein auf: Der Plan wird entworfen und überwacht, das Tempo danach justiert, wie die Provider antworten, gebremst, wenn Deferrals auftauchen, und vorangegangen, wenn die Signale mitziehen. Das Aufwärmen zu überspringen oder zu schnell zu erzwingen, ist die häufigste Ursache dafür, dass eine technisch perfekte Bereitstellung die ersten Wochen schlecht zustellt und monatelang eine geschädigte Reputation mitschleppt. Deshalb behandeln wir es als untrennbaren Teil der Installation und nicht als nachträglichen Zusatz: An dem Tag, an dem die Engine bereit ist, ist der Aufwärmplan schon geschrieben. In der Praxis startet dieser Plan mit bescheidenen Zahlen pro IP und Provider und vervielfacht sie in Stufen über vier bis acht Wochen, mit dem Tempo regiert von der Antwort der Provider und nicht von einem starren Kalender. Die ersten Versände richten sich an das engagierteste Segment — wer öffnet und klickt —, denn ihre positiven Signale lehren den Provider, dass Ihre Mail erwünscht ist, und erst danach wird auf kältere Empfänger ausgeweitet. Tauchen auf irgendeiner Stufe Deferrals auf oder steigt die Beschwerderate, hält der Plan an oder geht zurück, bevor er voranschreitet. Diese Staffelung zu dokumentieren und sie während des Starts täglich zu überwachen, verwandelt ein Aufwärmen in einen geordneten Reputationsaufstieg statt in eine Wette.

Bounces, Feedback-Loops und Monitoring vom ersten Tag

Einen gesunden Versand erkennt man daran, wie er das Zurückkommende verwaltet, und das wird vor der ersten Nachricht konfiguriert, nicht nach dem ersten Schreck. PowerMTA klassifiziert die Bounces, und es lohnt, sie an einen Prozessor anzubinden, der den Hard Bounce — nicht existierende Adresse, sofort zu unterdrücken — vom Soft Bounce unterscheidet — temporäres Problem, mit Augenmaß zu wiederholen —, denn weiter an tote Adressen zu senden, ist eines der Signale, die die Reputation am schnellsten versenken. Zugleich werden die Feedback-Loops der Provider abonniert, die sie anbieten, um den zu empfangen und zu unterdrücken, der Ihre Mail als Spam markiert. Und das Monitoring wird aufgestellt: die PowerMTA-Konsole, die Metriken pro Domain und pro VirtualMTA und Alarme über Deferrals, Ablehnungen und Spam-Traps. All das vom ersten Tag an aufzusetzen, verwandelt die Probleme in Signale, die Sie kommen sehen, statt in Überraschungen, die Sie entdecken, wenn sie schon Zustellung gekostet haben.

Integration mit Ihrer Anwendung: SMTP, HTTP und Webhooks

PowerMTA ist die Infrastrukturschicht und verbindet sich mit der Kampagnen- oder Anwendungsschicht, die Sie bereits haben. Der klassische Weg ist, die Mail per SMTP von Ihrer Plattform an die Engine zu liefern, die sie annimmt, routet und nach den konfigurierten Richtlinien versendet. Die modernen Versionen fügen einen HTTP-Weg hinzu: Mail lässt sich über eine API einspeisen, im Stil der Cloud-Dienste, was die Integration für Anwendungen vereinfacht, die lieber HTTP als SMTP sprechen. In umgekehrter Richtung gibt PowerMTA Accounting-Webhooks aus, die Ihr System empfangen kann, um nahezu in Echtzeit zu wissen, was zugestellt wurde, was zurückkam und was deferred wurde, und so Ihre Berichte und Suppression-Listen zu speisen, ohne Logdateien lesen zu müssen. Diese Integration sorgfältig zu entwerfen — was wohin hineingeht, welche Ereignisse empfangen und wie verarbeitet werden — verwandelt die Engine in ein geordnetes Stück Ihres Stacks und nicht in eine Blackbox, die sendet, ohne dass der Rest des Systems davon erfährt.

Logging, Accounting und Datenaufbewahrung

Alles, was durch die Engine läuft, hinterlässt eine Spur, und diese Spur ist zugleich eine Diagnose-Goldgrube und eine Verantwortung. PowerMTA schreibt Accounting-Aufzeichnungen, die jede Zustellung, jeden Bounce und jedes Deferral detaillieren, mit dem Detailgrad, den Sie konfigurieren. Gut verwaltet, sind sie das erste Werkzeug, um zu verstehen, warum ein Provider bremst oder warum die Bounce-Rate steigt; schlecht verwaltet, füllen sie die Festplatte und werden zu einem Betriebs- oder Datenschutzproblem. Die Konfiguration kümmert sich um drei Dinge: welche Felder protokolliert werden, in welchem Takt die Dateien rotieren, um den Speicher nicht zu erschöpfen, und wie lange sie aufbewahrt werden, bevor sie gelöscht oder anonymisiert werden, im Einklang mit dem Datenschutzrecht, das für Sie gilt. Im DACH-Raum heißt das die DSGVO und, in Deutschland, das BDSG, beide mit Fristen und Minimierungsgrundsätzen, die man besser von vornherein respektiert. Eine gute Bereitstellung hinterlässt die Aufbewahrung von Anfang an durchdacht, mit automatisierter Rotation und einem klaren Kriterium, was wie lange aufbewahrt wird, statt das Problem an dem Tag zu entdecken, an dem die Festplatte voll ist oder eine Datenanfrage eintrifft.

Compliance im DACH-Raum: UWG, DSGVO und CSA

Eine für das deutschsprachige Publikum gedachte Bereitstellung berücksichtigt Regeln, die der englischsprachige Markt nicht kennt. In Deutschland verlangt das UWG für werbliche E-Mail eine vorherige ausdrückliche Einwilligung, die sich in der Praxis nur per Double-Opt-in rechtssicher belegen lässt: Der Empfänger trägt sich ein und bestätigt die Anmeldung über einen Link, bevor die erste Werbenachricht kommt. Die DSGVO regelt darüber hinaus die Verarbeitung der zugrunde liegenden Daten, mit Nachweispflichten und Auskunftsrechten, die eine Versandinfrastruktur von Anfang an bedienen können sollte. Und es gibt eine Besonderheit, die im DACH-Raum zum Vorteil werden kann: die Certified Senders Alliance (CSA), eine in Deutschland verwurzelte Whitelist, deren Aufnahmekriterien — saubere Einwilligung, funktionierende Abmeldung, niedrige Beschwerderaten, korrekte Authentifizierung — anspruchsvoll sind, deren Zertifizierung aber die Annahme bei den beteiligten Providern spürbar erleichtert. Die Bereitstellung so zu konfigurieren, dass sie diese Anforderungen erfüllt — und nicht nur die technischen Header der großen Provider —, gehört dazu, einen Versand aufzusetzen, der im DACH-Raum zustellt und sich hält. Diese Compliance-Schicht von Anfang an mitzudenken, spart Nacharbeit und schützt die Reputation, die alles Übrige aufzubauen versucht.

Lizenz und Version: was Sie mitbringen

Es lohnt, beim Teil explizit zu sein, das am meisten Verwirrung stiftet. PowerMTA ist kommerzielle Software, einst von Port25 entwickelt und heute Teil des Bird-Portfolios, mit einem Preis auf Anfrage je nach Volumen, Umgebungen und Instanzen. Die Lizenz bringen Sie mit: Sie schließen sie bei Bird oder einem Partner ab, sind ihr Inhaber, und wir stellen bereit und konfigurieren obendrauf. Wir verkaufen die Engine nicht weiter und arbeiten nicht mit raubkopierten Kopien, einer in den trüben Ecken dieser Branche verbreiteten Praxis, die neben der Illegalität oft Hintertüren mitbringt und Ihren Versand ohne Sicherheitsupdates und Support zurücklässt. Auf der sauberen Spur zu arbeiten heißt legitime, aktualisierte Software unter Ihrer Inhaberschaft; alles andere heißt, Ihre Mail-Infrastruktur auf Sand zu bauen. Die konkrete Version — innerhalb der unterstützten Linien 5.x und 6.x — zählt weniger, als sie aktuell zu halten, denn eine aktualisierte Installation schließt bekannte Lücken und hält die Kompatibilität mit den Änderungen der großen Provider.

Suppression-Listen und Einwilligung

Keine Konfiguration rettet einen Versender, der an den sendet, der ihn nicht empfangen will, also beginnt die saubere Spur vor der Engine, darin, wie die Listen aufgebaut und gepflegt werden. Eine ernsthafte Installation stellt Suppression-Listen auf, die automatisch den aussortieren, der hart gebounct hat, der sich abgemeldet hat und der die Mail als Spam markiert hat, und die die Engine konsultiert, um ihnen nicht erneut zu schreiben. PowerMTA respektiert diese Suppressionen beim Versand, doch die Disziplin, sie zu pflegen und entfernte Adressen nicht wieder einzuführen, liegt beim Versender. Wir arbeiten ausschließlich mit Einwilligungs-Versand — legitimem Opt-in — und setzen keine Infrastruktur für gekaufte Listen oder Spam auf, denn keine Engine-Kraft gleicht eine Liste aus, die Beschwerden erzeugt: Die Linie von 0,30 % Beschwerden, die das Handeln der Provider auslöst, wird mit schlechten Listen weit eher gekreuzt als mit schlechten Konfigurationen. Suppression und Einwilligung gut zu planen, schützt die Reputation, die alles Übrige aufzubauen versucht, und verbindet sich direkt mit den Einwilligungsanforderungen des UWG und der DSGVO, die wir oben gesehen haben.

Horizontale Skalierung und Hochverfügbarkeit

Ein einziges, gut konfiguriertes PowerMTA bewegt ein enormes Volumen, doch Wachstum und Fehlertoleranz verlangen, an mehr als einen Knoten zu denken. Die Engine erlaubt, den Traffic auf mehrere Server zu verteilen und die Quell-IPs auf einem externen Proxy über das HAProxy-Protokoll bereitzustellen, sodass die IPs auf dem Proxy leben und nicht an einen konkreten Knoten gebunden sind. Das bringt zwei Vorteile: Die Lastverteilung des ausgehenden Traffics zwischen Knoten vereinfacht sich, und fällt ein Knoten aus, bleiben seine IPs über den Proxy verfügbar, statt mit eingefrorener Reputation aus dem Spiel zu sein. Diese Skalierung von Anfang an zu entwerfen — auch wenn Sie mit einem einzigen Knoten starten — vermeidet, die Architektur später umzubauen, was genau dann geschieht, wenn angesammelte Reputation da ist, die man nicht beliebig bewegen sollte. Für den, der zu wachsen plant, ist die offene Tür zur horizontalen Skalierung eine am Anfang billige und später teuer hinzuzufügende Entscheidung.

Wie „fertig“ aussieht

Eine Bereitstellung ist fertig, wenn sie sich allein trägt und ohne uns verstanden wird. Das heißt mehrere konkrete Dinge: Die IPs wärmen nach einem geschriebenen Plan und in gutem Tempo auf; DNS und Authentifizierung bestehen und richten für alle Ströme aus; die VirtualMTAs und Pools trennen die Mail nach Natur und wenden vernünftige Limits pro Provider an; die Bounces werden verarbeitet und die toten Adressen unterdrücken sich von selbst; die Feedback-Loops sind angebunden; und das Monitoring warnt vor den Problemen, bevor sie die Zustellung treffen. Und, nicht weniger wichtig, alles bleibt dokumentiert: wie es aufgebaut ist, warum so entschieden wurde und was anzufassen ist, wenn sich etwas ändert. Eine Bereitstellung, die nur funktioniert, solange der verfügbar ist, der sie aufgesetzt hat, ist nicht fertig; ihr steht eine Übergabe aus, die noch nicht stattgefunden hat.

Sollte ein Neuaufbau überhaupt PowerMTA verwenden?

Die ehrliche Frage vor der Bereitstellung ist, ob PowerMTA die passende Engine für Sie ist, und die Antwort lautet nicht immer ja. PowerMTA passt am besten zu Hochvolumen-Versendern, die feine Kontrolle pro IP und Provider brauchen, mit einem Team, das es betreiben kann, oder einem Partner, der es tut. Für kleinere Volumen, oder für den, der die Infrastruktur lieber delegiert, deckt ein gut gestimmtes Postfix oder eine Cloud wie Amazon SES den Fall mit weniger Kosten, weniger Wartung und weniger Fehlerfläche. Da wir PowerMTA nicht weiterverkaufen und an seiner Lizenz nichts verdienen, haben wir keinen Grund, es aufzusetzen, wenn es nicht passt; wir sagen es lieber vorher und leiten Sie gegebenenfalls zu der Option, die Ihnen tatsächlich passt. Dieses Gespräch gehört zum Service und erspart einem Kunden oft eine Bereitstellung, die er nicht brauchte. Wenn die Frage lautet, welche Engine zu wählen ist, gehen wir sie in Ruhe in der MTA-Auswahl an.

Wie läuft eine Bereitstellung ab?

Wir beginnen mit dem kostenlosen 25-Punkte-Audit, das die Eignung von PowerMTA bestätigt und den Ausgangspunkt von DNS, IPs und Authentifizierung klärt. Von da an folgt die Arbeit der Abfolge, die diese Seite beschreibt: die Verfügbarkeit des ausgehenden Ports 25 bestätigen und Server und Hosting vorbereiten; DNS, Authentifizierung und Tracking-Domain schließen; die unterstützte Version Ihrer Lizenz installieren; die VirtualMTAs, Pools und Limits pro Provider entwerfen; den Aufwärmplan schreiben; die Bounce-Verarbeitung, die Feedback-Loops und das Monitoring anbinden; und das Aufwärmen unter Aufsicht starten. Zum Abschluss übergeben wir Ihnen die dokumentierte Installation, damit Ihr Team sie übernimmt, oder wir betreiben sie als gemanagten Service, wie Sie es vorziehen. Infrastruktur und Lizenz sind jederzeit Ihre, und die Beziehung wird nach der Arbeit berechnet, ohne eine Engine, die auf der anderen Seite des Tisches zu verkaufen wäre. Was Fristen angeht, brauchen Vorbereitung und Konfiguration je nach Komplexität Ihrer Umgebung einige Tage bis ein paar Wochen, mit der Zeit für die Port-25-Freigabe in der Cloud obendrauf, und das Aufwärmen fügt danach vier bis acht Wochen hinzu, bis das Zielvolumen mit guter Reputation erreicht ist. Wir versprechen keinen Versand mit voller Leistung von einem Tag auf den anderen, denn das würde verlangen, das Aufwärmen zu überspringen und es in Zustellung zu bezahlen; wir ziehen einen etwas langsameren Start und eine Reputation vor, die hält. Das ist der ehrliche Tausch, und es ist, was wir jedem empfehlen, der von seiner Mail abhängen wird.

Wenn Sie überlegen, ein PowerMTA aufzusetzen oder neu zu bauen, kostet der Ausgangspunkt nichts: Das 25-Punkte-Audit bestätigt die Eignung der Engine und den Zustand Ihres DNS, Ihrer IPs und Ihrer Authentifizierung vor der Bereitstellung. Steht die Bereitstellung, hält der gemanagte Betrieb sie in Form.