E-Mails von Ihrer eigenen Domain
Ihr Bot kann Ihren Kunden E-Mails schreiben – von einer Adresse auf Ihrer Domain, etwa noreply@example.com. Versendet wird die Nachricht dabei von unserem Server. Deshalb müssen Sie vor dem ersten Versand einmalig drei Einträge im DNS Ihrer Domain anlegen. Nachfolgend: warum das nötig ist, was genau einzutragen ist und was danach passiert.
Warum E-Mails ohne DNS-Einträge nicht ankommen
Betrachten Sie es aus Sicht der Gegenseite – Gmail, Outlook oder der Mailserver Ihres Kunden. Dort trifft eine Nachricht ein, die behauptet, von Ihrer Domain zu stammen, aber von einem Server kommt, der nicht zu Ihrer Domain gehört. Genau so sieht eine Fälschung aus: So funktioniert Phishing.
Unterscheiden kann der Empfänger beides nur auf einem Weg – indem er die Domain selbst fragt: „Handelt dieser Absender wirklich in Ihrem Namen?" Die Antwort veröffentlichen Sie im DNS Ihrer Domain, denn das DNS ist der einzige Ort, über den ausschließlich Sie verfügen – und deshalb der einzige, dem der Empfänger glaubt.
Solange diese Antwort fehlt, muss ein gewissenhafter Mailserver die Nachricht als verdächtig behandeln. Im besten Fall landet sie im Spam, im schlechtesten wird sie abgewiesen und der Empfänger erfährt nie davon.
Die drei Einträge unten sind also keine Formalie und kein Häkchen in einer Oberfläche. Sie sind Ihre Autorisierung.
Die drei Einträge und was jeder bewirkt
DKIM – die Signatur, die Echtheit beweist
DKIM ist eine kryptografische Signatur an jeder ausgehenden Nachricht. Die Plattform erzeugt für Ihre Domain ein Schlüsselpaar: Der private Teil bleibt bei uns und signiert die Nachrichten, den öffentlichen veröffentlichen Sie im DNS. Der Empfänger holt den öffentlichen Schlüssel aus Ihrem DNS und prüft die Signatur. Passt sie, wurde die Nachricht von jemandem mit dem privaten Schlüssel versendet und der Inhalt unterwegs nicht verändert.
Ohne DKIM: Es gibt nichts, woran sich die Signatur prüfen ließe. Die Nachricht wirkt unsigniert und unglaubwürdig, und keine andere Einstellung gleicht das aus. DKIM ist der wichtigste der drei Einträge.
SPF – welche Server in Ihrem Namen senden dürfen
SPF beantwortet eine andere Frage: von welchen Servern überhaupt E-Mails für diese Domain zulässig sind. Es ist eine Liste von Quellen – die Mailserver Ihres Hosters, die Versanddienste, die Sie bereits nutzen, und, damit der Bot senden kann, unsere Sendeserver.
Ohne SPF: Die Nachricht kommt von einem Server, den Ihre Domain nicht kennt. Für einen Filter ist das ein klassisches Fälschungsmerkmal, das sich zu allen anderen Verdachtsmomenten addiert.
DMARC – was der Empfänger tun soll, wenn die Prüfungen scheitern
DKIM und SPF beantworten „ist die Nachricht echt". DMARC beantwortet die Folgefrage: was tun, wenn nicht. Es ist Ihre Anweisung an den Empfänger – nichts tun und nur berichten, in den Spam verschieben oder abweisen. Zugleich ist DMARC die Adresse, an die Empfänger Sammelberichte über Post in Ihrem Namen schicken, einschließlich fremder Fälschungsversuche.
Beginnen Sie mit der mildesten Richtlinie, „nur Berichte". Verschärfen Sie später, wenn Sie sicher sind, dass alle Ihre legitimen Absender (Buchhaltung, CRM, Newsletter, dieser Bot) die Prüfungen bestehen. Eine zu früh aktivierte strenge Richtlinie frisst Ihre eigene Post.
Ohne DMARC: Jeder Empfänger entscheidet für sich, und Sie erfahren nie, was mit Post in Ihrem Namen geschieht.
Welche Einträge anzulegen sind
Legen Sie die Domain zuerst im Dashboard an: Bereich Email → „Sending domains" → Schaltfläche „Add domain". Der Dialog hat drei Felder: die Domain selbst (etwa shop.example.com), den lokalen Teil der Adresse (alles vor dem @, üblicherweise noreply) und den Absendernamen, den der Empfänger statt einer Adresse sieht. Nach dem Speichern erscheinen Ihre DNS-Einträge auf dem Bildschirm.
Alle drei sind TXT-Einträge im DNS Ihrer Domain. Sie legen sie dort an, wo Sie die Domain verwalten: im Panel Ihres Registrars oder bei Ihrem DNS-Anbieter.
Die Werte unten verwenden example.com als Beispiel – setzen Sie Ihre eigene Domain ein. Die genauen Werte für Ihre Domain stehen im Dashboard auf der Domain-Karte; kopieren Sie sie von dort, besonders DKIM: Dessen Wert enthält Ihren eigenen öffentlichen Schlüssel, der für jede Domain anders ist und sich nicht aus der Dokumentation entnehmen lässt.
Auf dem Bildschirm ist jeder Eintrag in zwei getrennte Felder aufgeteilt – „Host" und „Value" –, jedes mit eigener Schaltfläche „Copy". Kopieren Sie sie einzeln in die passenden Felder Ihres DNS-Anbieters: Als ein Block lassen sich die beiden Teile nicht einfügen.
| Typ | Name des Eintrags (Host) | Wert |
|---|---|---|
| TXT | mybot._domainkey.example.com | v=DKIM1; k=rsa; p= gefolgt vom langen Schlüssel aus dem Dashboard |
| TXT | example.com (Wurzel der Domain) | v=spf1 include:esp.getmybot.dev ~all |
| TXT | _dmarc.example.com | v=DMARC1; p=none; rua=mailto:dmarc@example.com |
Zwei Dinge, über die am häufigsten gestolpert wird:
- Viele Panels hängen die Domain selbst an den Namen an. Steht im Namensfeld bereits „.example.com", geben Sie nur
mybot._domainkeyein und nicht den vollständigen Namen – sonst entstehtmybot._domainkey.example.com.example.com. - Der DKIM-Wert ist lang und darf innerhalb des Schlüssels weder Zeilenumbrüche noch Leerzeichen enthalten. Kopieren Sie ihn mit der Schaltfläche, nicht mit der Maus.
Wenn die Domain bereits einen SPF-Eintrag hat
Eine Domain darf nur einen SPF-Eintrag haben. Wenn Sie bereits über Hosting, CRM oder einen anderen Newsletter-Dienst versenden, existiert er schon. Legen Sie keinen zweiten an – ergänzen Sie den vorhandenen um ein weiteres include, vor dem abschließenden ~all:
v=spf1 include:spf.ihranbieter.de include:esp.getmybot.dev ~all
Zwei SPF-Einträge auf einer Domain sind derselbe Fehler wie gar keiner: Die Prüfung scheitert, weil der Empfänger nicht wissen kann, welchem der beiden er glauben soll.
Beachten Sie: „abgedeckt" über einen fremden Eintrag genügt nicht. Selbst wenn Ihr jetziger Anbieter uns in seinem eigenen SPF einbindet, muss unser include direkt in Ihrem Eintrag stehen – warum, steht unten im Abschnitt zur Domainprüfung.
Warum SPF ein include verwendet und keine IP-Adresse
Der häufigste Fehler ist, eine IP-Adresse einzutragen, die man in einem Mail-Header oder in einem Forenbeitrag gesehen hat. Tun Sie das nicht.
include:esp.getmybot.dev ist ein Verweis auf unsere eigene, von uns gepflegte Liste der Sendeserver. Heute steht hinter diesem Namen ein einzelner Server. Morgen können es mehr sein, sie können umziehen oder ersetzt werden. Wenn das geschieht, aktualisieren wir die Liste bei uns – und Ihr Eintrag funktioniert weiter, ohne dass Sie etwas ändern müssen. Genau darum geht es: Die Adresse ändert sich an einer Stelle statt im DNS jedes Kunden.
Eine handgeschriebene IP-Adresse stimmt in diesem Moment schlicht nicht mehr. Nachrichten beginnen ohne jede Vorwarnung, SPF zu verfehlen – keine Fehlermeldung im Dashboard, keine Benachrichtigung. Sie erfahren es von Kunden, die „nie etwas bekommen haben".
Schreiben Sie exakt include:esp.getmybot.dev und fügen Sie nichts hinzu.
Domainprüfung
Domainprüfung heißt: Die Plattform schaut selbst in das DNS Ihrer Domain und bestätigt, dass alle drei Einträge stimmen. Bestehen alle drei, gilt die Domain als geprüft und der Versand ist erlaubt. Solange einer nicht besteht, bleibt sie in Wartestellung.
Geprüft wird mehr als nur „ein Eintrag existiert":
| Eintrag | Was tatsächlich geprüft wird |
|---|---|
| DKIM | Der Eintrag ist veröffentlicht und enthält Ihren eigenen öffentlichen Schlüssel. Ein fremder oder veralteter DKIM-Eintrag besteht die Prüfung nicht. |
| SPF | Der Eintrag existiert und enthält direkt include:esp.getmybot.dev. Ähnlich aussehende Werte wie include:esp.getmybot.dev.fremde-domain.example zählen nicht. |
| DMARC | Ein Eintrag ist veröffentlicht und beginnt mit v=DMARC1. Die Richtlinie selbst (p=, rua=) wird nicht geprüft – das ist Ihre Entscheidung und keine Erlaubnis für uns. |
Warum DMARC lockerer geprüft wird: Es sagt Empfängern, was sie tun sollen, wenn DKIM und SPF ausgewertet sind, gibt uns aber kein Recht, in Ihrem Namen zu senden. Dieses Recht stammt allein aus den ersten beiden Einträgen, und beide werden inhaltlich vollständig geprüft.
Ein fremder include zählt nicht
include:esp.getmybot.dev muss in Ihrem eigenen SPF-Eintrag stehen. Wenn Ihr SPF einen Drittanbieter einbindet, dessen Eintrag wiederum uns einbindet, akzeptiert die Prüfung das nicht: Die Plattform löst Ketten fremder includes nicht auf. Der Grund ist einfach – so bleibt die Antwort auf die Frage „hat genau diese Domain uns autorisiert" eindeutig.
Praktisch heißt das: Auch wenn Sie sicher sind, „über den Anbieter abgedeckt" zu sein, tragen Sie unseren include direkt in Ihren eigenen Eintrag ein. Genau das steht auch auf dem Bildschirm selbst, im Erklärtext zum SPF-Eintrag: Wenn die Domain bereits einen SPF-Eintrag hat, ergänzen Sie darin den Wert include:..., statt den Eintrag komplett zu ersetzen – die Domain versendet womöglich nicht nur über uns. Dieser Hinweis steht dort dauerhaft und erscheint nicht erst nach einer fehlgeschlagenen Prüfung.
DNS aktualisiert sich nicht sofort. Nach dem Speichern beim Registrar müssen sich die Einträge über die Nameserver verteilen: meist Minuten, manchmal Stunden, gelegentlich bis zu einem Tag. Das hängt von Ihrem Anbieter und der TTL ab. Das ist normal und liegt nicht in unserer Hand.
Passiv warten müssen Sie trotzdem nicht. Die Plattform prüft wartende Domains stündlich von selbst, doch auf der Domain-Karte gibt es die Schaltfläche „Verify now" – dieselbe Prüfung, sofort ausgeführt, mit dem Ergebnis direkt auf dem Bildschirm. Nutzen Sie sie gleich nach dem Speichern der Einträge: Bei einem Tippfehler wissen Sie es nach einer Sekunde statt nach einer Stunde. Sie können sie beliebig oft auslösen.
Den Status der Domain zeigt die Karte an: „Pending verification", „Verified" oder „Not verified". Solange sie ungeprüft ist, steht dort außerdem der Hinweis „Sending from this domain is disabled until it is verified."*
Das Ergebnis ist nicht nur „fehlgeschlagen". Jeder der drei Einträge hat auf dem Bildschirm einen eigenen Status – „Passing", „Not passing" oder „Not checked yet" – und eine eigene Zeile mit der Erklärung, was nicht stimmt.
Bei SPF unterscheidet der Bildschirm zwei Fälle, und das ist die wichtigste Unterscheidung im ganzen Ablauf:
- Die Domain hat überhaupt keinen SPF-Eintrag. Veröffentlichen Sie einen – mit dem Wert aus der Tabelle oben.
- Ein SPF-Eintrag existiert, enthält aber unseren include nicht. Ergänzen Sie den include im vorhandenen Eintrag: Legen Sie keinen zweiten an und ersetzen Sie ihn nicht komplett. Dieselbe Meldung behandelt ausdrücklich auch den Kettenfall: Erreicht uns der include nur über den SPF-Eintrag eines anderen Anbieters, zählt das nicht – Ketten werden nicht aufgelöst.
Der zweite Fall ist der verwirrendste Moment des ganzen Ablaufs: Der Eintrag ist bereits da, Sie haben ihn gerade selbst noch einmal gelesen, und die Prüfung verweigert trotzdem. Die Fehlermeldung sagt jetzt genau dasselbe wie der dauerhaft sichtbare Hinweis neben dem Eintrag – ergänzen Sie unseren include in dem, was schon vorhanden ist.
Wenn die Prüfung nicht durchgeht:
- Lesen Sie, welcher der drei Einträge auf „Not passing" steht und was in seiner Erklärung steht – und handeln Sie danach.
- Vergewissern Sie sich, dass die Einträge wirklich veröffentlicht sind – viele Panels verlangen ein zusätzliches „Änderungen übernehmen".
- Prüfen Sie den Namen auf eine verdoppelte Domain (siehe oben).
- Prüfen Sie, dass es nur einen SPF-Eintrag gibt und unser include in genau diesem Eintrag steht.
- Warten Sie kurz und prüfen Sie erneut: Die Änderung ist womöglich noch nicht verteilt.
Bis zur Prüfung verweigert der Versand die Arbeit
Solange eine Domain ungeprüft ist, wird nicht gesendet. Nicht „gesendet und im Spam gelandet" – gar nicht gesendet: Der Versuch scheitert mit einem Fehler zur ungeprüften Domain, sichtbar im Journal.
Das ist Absicht und kein Fehler. Post von einer Domain, die nicht für sich selbst bürgt, wird zu Spam-Beschwerden, und Beschwerden beschädigen den Ruf einer Sendeinfrastruktur, die sich alle Kunden der Plattform teilen. Eine Nachricht nicht zu senden ist billiger, als sie zu senden und sich danach ein halbes Jahr aus Blocklisten herauszuarbeiten. Deshalb eine Verweigerung statt einer Warnung.
Wenn Sie diesen Fehler sehen, prüfen Sie die DNS-Einträge und lösen Sie die Prüfung aus, bevor Sie den Support schreiben. In der überwiegenden Mehrheit der Fälle ist es ein Tippfehler im Namen eines Eintrags.
Abmeldungen, Beschwerden und Zustellfehler
Drei Regeln, die überraschen, wenn man sie nicht vorher kennt.
Jede Werbenachricht trägt eine Ein-Klick-Abmeldung. Die Plattform ergänzt selbst einen Abmeldelink in der Fußzeile und die technischen Header, aus denen Mailprogramme eine Schaltfläche „Abmelden" neben der Absenderadresse zeichnen. Entfernen lässt sich das nicht – weder per Einstellung noch über die Gestaltung der Nachricht. Die Abmeldung greift sofort, ohne die Nachricht zu öffnen und ohne Bestätigungsschritt. Gmail und die anderen großen Anbieter verlangen das von Massenversendern: Eine Nachricht ohne diese Möglichkeit geht garantiert in den Spam.
Eine Abmeldung ist endgültig und lässt sich nicht aus der Oberfläche zurücknehmen. Eine abgemeldete Adresse erhält keine weitere Post dieses Bots. Es gibt keine Schaltfläche „wiederherstellen" und keinen Umweg über einen erneuten Listenimport: Eine Abmeldung wird nie über den Kopf des Menschen hinweg aufgehoben. Zurückkommen kann er nur selbst – indem er sich erneut über Ihr Anmeldeformular einträgt.
Es gibt einen noch härteren Fall: Hat jemand im Mailprogramm „Das ist Spam" gedrückt, ist die Adresse endgültig geschlossen. Selbst eine neue Anmeldung über Ihr Formular öffnet sie nicht wieder – denn wir wissen bereits, wie der vorige Versuch endete, und an solche Adressen zu schreiben zerstört den Ruf einer Domain am schnellsten. Adressen, die auf rechtliche Anforderung manuell gesperrt wurden, verhalten sich genauso.
Ein harter Zustellfehler sperrt die Adresse dauerhaft. Antwortet der Mailserver des Empfängers, dass es dieses Postfach nicht gibt, wird die Adresse als unzustellbar markiert und aus künftigen Sendungen entfernt. Das ist kein vorübergehender Zustand. Weiter gegen ein nicht existierendes Postfach zu hämmern ist der schnellste Weg, mitsamt allen anderen Adressen in Spamfiltern zu landen.
Weiche Zustellfehler (volles Postfach, vorübergehend nicht erreichbarer Server) sperren die Adresse nicht – der Versand geht weiter.
Warum die Öffnungsrate zu niedrig ausfällt
Die E-Mail-Statistik enthält eine Kennzahl für Öffnungen, und sie liegt immer unter der Wirklichkeit. Das ist kein Zählfehler, sondern liegt daran, wie Öffnungen überhaupt gemessen werden.
Eine Öffnung wird erfasst, wenn das Mailprogramm beim Anzeigen der Nachricht ein winziges Zählpixel von einem Server lädt. Moderne Programme laden entfernte Bilder standardmäßig nicht; und die, die es tun (Apple Mail und ähnliche Datenschutzfunktionen), laden sie vorab für alle, auch für Menschen, die die Nachricht nie geöffnet haben. Im ersten Fall geht die Öffnung verloren, im zweiten wird sie jemandem zugeschrieben, der nicht da war. E-Mail-Öffnungen genauer zu zählen ist nicht möglich – weder für uns noch für sonst jemanden.
Deshalb steht in der Oberfläche ein Hinweis neben der Zahl: Sie ist eine Untergrenze, keine exakte Größe. Nutzen Sie sie, um Nachrichten untereinander zu vergleichen, wo alle dieselbe Verzerrung trifft, aber nicht als Antwort auf „wie viele Menschen haben das gelesen".
Brauchen Sie eine belastbare Kennzahl für Interesse, schauen Sie auf „Link clicks". Ein Klick auf einen Link ist eine echte Handlung eines echten Menschen; niemand führt sie vorab für ihn aus. „Delivered", „Unsubscribes", „Complaints" und „Bounces" werden ebenfalls exakt gezählt: Sie werden von Mailservern gemeldet, nicht von einem Bild in einer Nachricht. All das steht im Block „Sending stats" auf demselben Email-Bildschirm.
Wie geht es weiter
- Kanäle – Mehrkanalfähigkeit und Kanalfunktionen.
- Broadcasts – Versand an viele Empfänger gleichzeitig.
- Analytik – wo Sie die Zahlen finden.