SPF, DKIM & DMARC für GetResponse.
GetResponse authentifiziert Ihre Versanddomain über Profil → E-Mails und Domains, und zwar anders als ESPs, die auf CNAME-Delegation setzen: Sie erzeugen innerhalb von GetResponse einen DKIM-Schlüssel und veröffentlichen ihn als TXT-Record, fügen optional den gemeinsam genutzten SPF-include von GetResponse hinzu (include:_spf.getresponse.com) und legen selbst einen DMARC-Policy-Record an. Sie können alle drei Records von GetResponse über dessen automatische (Entri) Integration mit über 45 DNS-Hostern für sich schreiben lassen oder sie von Hand hinzufügen. Sobald der DKIM-TXT auflöst und GetResponse ihn bestätigt, werden Ihre Newsletter und Automationen als Ihre eigene Domain signiert, DMARC besteht über die DKIM-Ausrichtung, und die \"sent on behalf of\" / via-getresponse-Zuordnung, die Empfänger bei nicht authentifizierter Post sehen, verschwindet.
Warum GetResponse authentifizieren?
Ob Sie Ihre GetResponse-Domain authentifizieren, entscheidet darüber, ob Ihre Kampagnen im Posteingang oder im Spam-Ordner landen. Seit Februar 2024 verlangen Gmail und Yahoo von jedem Massenversender (grob ab 5.000 Nachrichten pro Tag), dass SPF, DKIM und DMARC mit Ausrichtung bestanden werden, und Microsoft hat 2025 dieselben Erwartungen auf die Verbraucher-Postfächer Outlook.com/Hotmail/Live ausgeweitet — genau die Zielgruppen, auf die die meisten Newsletter abzielen. GetResponse empfiehlt inzwischen jedem Versender dringend, als Absenderadresse eine Adresse auf der eigenen privaten Domain zu verwenden (nicht gmail.com oder yahoo.com, die blockiert oder herabgestuft werden) und sowohl DKIM als auch DMARC zu konfigurieren. Solange Sie nicht authentifizieren, versendet GetResponse unter seiner eigenen Signaturdomain: Empfänger sehen, dass die Post nicht wirklich von Ihnen stammt, Ihre Absenderadresse richtet sich nicht aus, DMARC kann nicht bestehen, und Ihre Reputation wird mit der aller anderen nicht authentifizierten Versender auf der Plattform in einen Topf geworfen. Es gibt einen GetResponse-spezifischen Kniff, der DKIM unverzichtbar macht: GetResponse behält bei ausgehender Post seinen eigenen Return-Path (Bounce-Domain), sodass SPF gegen die Domain von GetResponse ausgewertet wird und sich nie an Ihrer Absenderdomain ausrichtet — DKIM, signiert als d=yourdomain.com, ist der einzige Mechanismus, der Ihr DMARC-Bestehen trägt. Lassen Sie den DKIM-Schlüssel weg, haben Sie überhaupt keine ausgerichtete Authentifizierung, ganz gleich, wie die SPF-Prüfung aussieht.
Die SPF-Realität bei GetResponse
GetResponse ist ein echter \"include\"-Anbieter — der gemeinsam genutzte Mechanismus ist include:_spf.getresponse.com — doch hier ist SPF die optionale Seite der Einrichtung, nicht der tragende Teil. Die eigene Dokumentation von GetResponse sagt, ein SPF-Record sei \"empfohlen, aber zum Versand nicht erforderlich,\" und begründet auch warum: \"die Versanddomain ist GetResponse und bereits SPF-signiert.\" Da GetResponse den Envelope-Sender / Return-Path auf seiner eigenen Bounce-Domain behält (GetResponse verarbeitet die Bounces, nicht Sie), wird SPF stets gegen die Domain von GetResponse geprüft, liefert für sich genommen ein reines PASS und richtet sich nie an Ihrer Absenderdomain aus — und DMARC zählt SPF nur, wenn es ausgerichtet ist. Deshalb dreht sich der Authentifizierungsablauf von GetResponse um einen DKIM-TXT-Schlüssel und einen DMARC-Record: DKIM, signiert als d=yourdomain.com, ist es, was sich ausrichtet und DMARC erfüllt. Behandeln Sie den Root-include daher als hilfreichen \"GetResponse-IPs autorisieren\"-Mechanismus, von dem manche Eingangsfilter gern ein sauberes Bestehen sehen — nicht als das, was DMARC funktionieren lässt, und nicht als etwas, das Sie zwingend hinzufügen müssen. Falls Sie ihn doch hinzufügen, die gute Nachricht: Er ist günstig. include:_spf.getresponse.com löst zu einem einzigen flachen Record aus ip4:-Bereichen ohne verschachtelte includes auf und kostet daher genau EINE Ihrer 10 SPF-DNS-Abfragen. Führen Sie ihn in den einen v=spf1-Record auf Ihrer Root-Domain zusammen — vor dem abschließenden ~all — statt einen zweiten SPF-TXT zu veröffentlichen (zwei SPF-Records sind ein PermError), und lassen Sie DKIM die eigentliche DMARC-Arbeit erledigen.
Zwei Wege zur Einrichtung
Automatische Authentifizierung (Entri)
- GetResponse erkennt Ihren DNS-Hoster und schreibt den DKIM-Schlüssel, einen SPF-Record und einen p=none-DMARC-Record für Sie, nachdem Sie sich beim Hoster angemeldet haben
- Unterstützt über 45 Anbieter, darunter Cloudflare, GoDaddy, Namecheap, AWS Route 53 und SiteGround
- Beseitigt die beiden häufigsten Fehlerquellen: die Verdopplung des Host-Felds und abgeschnittene DKIM-Schlüssel
- Am besten, wenn Sie über den DNS-Hoster-Login verfügen und den schnellsten, fehlerärmsten Weg wollen
Manuell — "Ich mache es selbst"
- GetResponse zeigt Ihnen den DKIM-Identifier + Schlüssel, den SPF-Wert und den DMARC-Record zum Kopieren
- Sie fügen sie selbst bei Ihrem Registrar ein — nötig, wenn das DNS von jemand anderem verwaltet wird oder der Hoster von Entri nicht unterstützt wird
- Sie müssen den DKIM-TXT exakt hinzufügen (selector und den vollständigen 2048-Bit-Schlüssel), sonst bestätigt GetResponse ihn nicht
- Dieselben Endrecords wie beim automatischen Weg — nur von Hand hinzugefügt
Schritt für Schritt
- 1
E-Mails und Domains öffnen
Melden Sie sich an und gehen Sie zu Profil → E-Mails und Domains (in der neueren Oberfläche heißt es Tools → E-Mails und Domains). Dieser eine Bildschirm verwaltet sowohl Ihre verifizierten Absenderadressen als auch die vollständige Domain-Authentifizierung. Fügen Sie zuerst die Absenderadresse auf Ihrer eigenen Domain hinzu und bestätigen Sie sie — GetResponse lässt Sie nicht von unverifizierten oder kostenlosen öffentlichen Domains wie gmail.com/yahoo.com senden.
- 2
Authentifizierung für die Domain starten
Suchen Sie im Reiter E-Mail-Adressen Ihre Domain in der Liste, klicken Sie auf das Aktionsmenü (die 3 Punkte) daneben und wählen Sie Authentifizieren (bei älteren Konten heißt es TXT-Records anzeigen → Ihre Domain mit DKIM authentifizieren). Damit öffnet sich das Authentifizierungspanel, in dem GetResponse Ihre Schlüssel erzeugt.
- 3
Automatisch oder manuell wählen
Wählen Sie "Automatisch authentifizieren", damit die Entri-Integration von GetResponse sich bei Ihrem DNS-Hoster anmeldet und den DKIM-, SPF- und (falls keiner existiert) einen p=none-DMARC-Record für Sie veröffentlicht. Oder wählen Sie "Ich mache es selbst", um die Records anzuzeigen und sie bei Ihrem Registrar einzufügen. Beide Wege erzeugen dieselben DNS-Einträge.
- 4
DKIM-Schlüssel erzeugen und kopieren
Auf dem manuellen Weg zeigt GetResponse einen DKIM-Identifier und einen DKIM-Schlüssel. Der Identifier ist ein eindeutiger, domainspezifischer selector (eine kurze Hex-Zeichenkette), der zu Ihrem Record-Host wird, und der Schlüssel ist der lange Public-Key-Wert. Schieben Sie den Regler auf "Einen 2048-Bit-DKIM-Schlüssel für stärkeren Schutz erzeugen" (die Empfehlung von GetResponse) und kopieren Sie BEIDE Felder exakt — ein einziges fehlendes Zeichen im Identifier ist eine häufige Fehlerquelle.
- 5
Den DKIM-TXT-Record veröffentlichen
Fügen Sie bei Ihrem DNS-Hoster einen TXT-Record hinzu: Host = <your-identifier>._domainkey (z. B. 1a2b3c4d._domainkey), Wert = der DKIM-Schlüssel von GetResponse (er beginnt mit k=rsa; p=… / v=DKIM1; k=rsa; p=…). Belassen Sie ihn als TXT — GetResponse-DKIM ist ein selbst veröffentlichter Schlüssel, keine CNAME-Delegation. Begrenzt Ihr Hoster TXT-Zeichenketten auf 255 Zeichen, stellen Sie sicher, dass der vollständige 2048-Bit-Schlüssel gespeichert wird (bei Bedarf in Anführungszeichen gesetzte Teilstücke aufgeteilt), sonst wird nur ein Teil davon veröffentlicht.
- 6
Den SPF-include hinzufügen oder zusammenführen (optional)
SPF ist bei GetResponse empfohlen, aber nicht erforderlich. Falls Sie ihn hinzufügen, setzen Sie include:_spf.getresponse.com in den einen v=spf1-TXT-Record auf Ihrer Root-Domain, vor das abschließende ~all — z. B. v=spf1 include:_spf.getresponse.com ~all. Falls Sie bereits einen SPF-Record haben (Google Workspace, Microsoft 365 usw.), führen Sie den include in diese eine Zeile zusammen; veröffentlichen Sie niemals einen zweiten SPF-TXT. Er kostet nur eine DNS-Abfrage.
- 7
Den DMARC-Record hinzufügen
GetResponse legt DMARC auf dem manuellen Weg nicht für Sie an. Fügen Sie einen TXT-Record beim Host _dmarc mit v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com hinzu. p=none ist reine Überwachung, ändert also nichts an der Zustellung, während Sie die Ausrichtung bestätigen. Halten Sie genau einen _dmarc-Record für die gesamte Domain.
- 8
GetResponse die Domain bestätigen lassen
DNS-Änderungen können bis zu 24–48 Stunden zur Verbreitung brauchen. GetResponse prüft automatisch erneut und schaltet die Domain auf Authentifiziert, sobald es den DKIM-Record erkennt — Sie müssen nichts anklicken, können aber das Aktionsmenü erneut öffnen, um nachzuprüfen. GetResponse schlägt außerdem vor, sich zur schnellen Verbreitungsprüfung selbst einen Newsletter zu senden.
- 9
Die Header an einer echten Nachricht prüfen
Senden Sie eine Testkampagne an eine Gmail-Adresse, öffnen Sie sie und nutzen Sie ⋮ → Original anzeigen. Sie wollen DKIM: PASS mit d=yourdomain.com (über Ihren GetResponse-selector) und DMARC: PASS. SPF zeigt ein Bestehen gegen die Return-Path-Domain von GetResponse, was zu erwarten ist — die DKIM-Ausrichtung ist es, die DMARC hier trägt.
- 10
Von der authentifizierten Absenderadresse senden
Stellen Sie in Ihren Nachrichten- und Listeneinstellungen sicher, dass die Absenderadresse die auf der authentifizierten Domain ist, damit die Post tatsächlich als Ihre Domain DKIM-signiert wird. Das Authentifizieren des DNS bringt nichts für eine Kampagne, die weiterhin auf Versand von einer anderen oder unverifizierten Adresse eingestellt ist.
Einzutragende Einträge
GetResponse erzeugt die genauen Werte in seinem Einrichtungsassistenten — diese zeigen die Struktur dessen, was Sie bei Ihrem DNS-Anbieter hinzufügen werden.
| Typ | Host | Wert |
|---|---|---|
| TXT | 1a2b3c4d._domainkey | k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…(2048-bit public key from GetResponse)DKIM — Beispielwert. Das Host-Label (selector) ist ein eindeutiger Identifier, den GetResponse pro Domain erzeugt; kopieren Sie den exakten Identifier und Schlüssel aus dem Authentifizieren-Panel. Dies ist ein selbst veröffentlichter TXT, kein CNAME. GetResponse zeigt den Wert möglicherweise beginnend mit k=rsa; p= (gleichbedeutend mit v=DKIM1; k=rsa; p=). |
| TXT | @ | v=spf1 include:_spf.getresponse.com ~allOptional. Führen Sie include:_spf.getresponse.com in Ihre eine Root-SPF-Zeile zusammen — fügen Sie niemals einen zweiten SPF-Record hinzu. Löst zu einem flachen, reinen ip4-Record auf und kostet daher 1 DNS-Abfrage. Er autorisiert die IPs von GetResponse, richtet sich aber NICHT aus (GetResponse besitzt den Return-Path und ist dort bereits SPF-signiert), sodass DKIM DMARC trägt — viele Versender lassen diesen Record ganz weg. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comDiesen fügen Sie selbst hinzu (der automatische/Entri-Weg fügt einen p=none-Record hinzu, falls keiner existiert). Einer pro Domain; beginnen Sie bei p=none, verschärfen Sie dann zu quarantine/reject, sobald GetResponse-Post ausgerichtet besteht. |
Behalten Sie genau einen SPF-TXT-Eintrag (v=spf1) auf Ihrer Root-Domain — führen Sie jeden Absender darin zusammen. Zwei SPF-Einträge sind bereits an sich ein Fehler.
Das Budget von 10 Lookups
SPF ist auf harte 10 DNS-Lookups begrenzt — wird dieser Wert überschritten, gibt SPF einen permerror zurück und validiert überall nicht mehr. Hier sehen Sie, was die Einrichtung von GetResponse von diesem Budget verbraucht.
GetResponse verbraucht 1 Ihrer 10 Lookups; ip4:- und ip6:-Mechanismen sind kostenlos.
DKIM
DKIM ist das Herzstück der GetResponse-Authentifizierung, weil es der Mechanismus ist, der sich tatsächlich an Ihrer Domain ausrichtet. Anders als ESPs mit CNAME-Delegation (Mailchimp, SendGrid) erzeugt GetResponse einen Schlüssel und übergibt Ihnen einen selbst zu veröffentlichenden TXT-Record: einen DKIM-Identifier (einen eindeutigen, domainspezifischen selector, angezeigt als kurze Hex-Zeichenkette) und einen DKIM-Schlüssel (den Public-Key-Wert). Sie veröffentlichen einen TXT-Record mit dem Host <identifier>._domainkey.yourdomain.com und dem Wert, den GetResponse Ihnen gibt und der mit k=rsa; p=… beginnt (gleichbedeutend mit der Standardform v=DKIM1; k=rsa; p=…). GetResponse hält den passenden privaten Schlüssel und signiert Ihre ausgehende Post damit, sodass Kampagnen, sobald der Record auflöst, als d=yourdomain.com signiert sind und DMARC über die DKIM-Ausrichtung bestehen kann. Wählen Sie die von GetResponse angebotene 2048-Bit-Option statt eines veralteten 1024-Bit-Schlüssels. Zwei anbieterspezifische Stolperfallen, auf die die eigene Dokumentation von GetResponse hinweist: Weil ein 2048-Bit-Schlüssel länger ist als eine einzelne 255-Zeichen-TXT-Zeichenkette, veröffentlichen manche Hoster \"nur einen Teil des DKIM-Records\" — begrenzt Ihr Hoster die Schlüssel-/TXT-Länge, wird der Schlüssel abgeschnitten und DKIM schlägt fehl, speichern Sie also den vollständigen Wert (in Anführungszeichen gesetzte Teilstücke aufgeteilt, falls Ihr Panel das verlangt). Und weil der selector ein generierter Identifier ist, warnt GetResponse, dass ein Name, dem \"das letzte Zeichen des korrekten selectors fehlt\" (etwa 4e4a47e statt 4e4a47eb), zu einer selector-Nichtübereinstimmung führt, die stillschweigend an der Validierung scheitert. Kopieren Sie beide Felder wortgetreu. Es gibt keinen CNAME und keinen \"Signierung starten\"-Schalter: GetResponse erkennt den Record von selbst innerhalb von 24–48 Stunden und markiert die Domain als authentifiziert.
DMARC
DMARC ist ein separater Policy-TXT-Record auf Ihrer Domain. Auf dem manuellen Weg legt GetResponse ihn nicht für Sie an (auf dem automatischen/Entri-Weg fügt es einen p=none-Record hinzu, falls Sie noch keinen haben). Veröffentlichen Sie ihn unter _dmarc.yourdomain.com beginnend mit v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none ist reine Überwachung: Es ändert nichts an der Zustellung, während Sie die aggregierten (rua) Berichte auswerten, um zu bestätigen, dass GetResponse-Post DKIM besteht, ausgerichtet an Ihrer Domain. Das ist für GetResponse wichtiger als für einen Anbieter, dessen SPF sich ausrichtet: Weil GetResponse den Return-Path besitzt, ruht Ihr DMARC-Bestehen vollständig auf DKIM — nutzen Sie daher die rua-Berichte, um vor dem Verschärfen zu prüfen, dass die DKIM-Ausrichtung solide ist. Beobachten Sie die Berichte ein bis zwei Wochen, stellen Sie sicher, dass GetResponse und jeder andere legitime Versender authentifiziert, und steigern Sie dann auf p=quarantine und schließlich p=reject. Möglicherweise wird strikte Ausrichtung (adkim=s / aspf=s) erwähnt, belassen Sie die Ausrichtung jedoch bei entspannt (der Standard), sofern Sie keinen konkreten Grund haben — entspannte Ausrichtung verlangt weiterhin, dass die Organisationsdomain übereinstimmt, ist aber toleranter gegenüber Subdomains. Halten Sie genau einen _dmarc-Record für die gesamte Domain, ganz gleich, wie viele Versender Sie nutzen; fügen Sie niemals einen zweiten DMARC-Record eigens für GetResponse hinzu.
Prüfen, ob es wirklich funktioniert hat
Verlassen Sie sich nicht allein auf das \"Authentifiziert\"-Abzeichen von GetResponse — bestätigen Sie es an einer echten Nachricht. Senden Sie eine Testkampagne (oder einen schlichten Newsletter an sich selbst) an eine Gmail-Adresse, öffnen Sie sie und wählen Sie ⋮ → Original anzeigen: Sie wollen DKIM: PASS mit signed-by / d=yourdomain.com über Ihren GetResponse-selector und DMARC: PASS. SPF zeigt ein Bestehen gegen die eigene Return-Path-Domain von GetResponse — das ist zu erwarten und in Ordnung; die DKIM-Ausrichtung ist es, die DMARC hier bestehen lässt, seien Sie also nicht beunruhigt, dass SPF nicht Ihre Domain zeigt. Sie können die Rohrecords auch stichprobenartig mit dig TXT <identifier>._domainkey.yourdomain.com und dig TXT _dmarc.yourdomain.com prüfen. Lassen Sie dann Ihre Domain durch den Domain-Gesundheitscheck von Qualisend laufen, um zu bestätigen, dass der DKIM-TXT, der optionale SPF-include und der DMARC-Record allesamt sauber auflösen und dass Ihr SPF unter der Grenze von 10 Abfragen bleibt. Sobald DMARC-Aggregatberichte eintreffen, werfen Sie einen davon in die DMARC-Berichtsanalyse — GetResponse sollte als ausgerichtete, bestehende Quelle bei DKIM erscheinen.
Häufige Stolperfallen
- Abdeckung
SPF besteht, richtet sich aber nicht aus: GetResponse nutzt seine eigene Return-Path-/Bounce-Domain (auf GetResponse-Seite bereits SPF-signiert), sodass include:_spf.getresponse.com die IPs von GetResponse autorisiert und ein reines SPF-Bestehen liefert, sich aber NICHT an Ihrer Absenderdomain ausrichtet. DKIM ist der einzige Mechanismus, der Ihr DMARC-Bestehen trägt — lassen Sie den DKIM-Schlüssel niemals weg in dem Glauben, SPF decke Sie ab.
- DNS-Einrichtung
Abgeschnittener DKIM-Schlüssel: Ein 2048-Bit-Schlüssel ist länger als eine einzelne 255-Zeichen-TXT-Zeichenkette, und GetResponse warnt, dass manche Hoster 'nur einen Teil des DKIM-Records' veröffentlichen. Speichern Sie den vollständigen Wert (bei Bedarf in Anführungszeichen gesetzte Teilstücke aufgeteilt), sonst schlägt die DKIM-Validierung fehl.
- Abdeckung
selector-Nichtübereinstimmung: Der DKIM-Host ist ein generierter Identifier, und GetResponse warnt ausdrücklich vor einem Namen, dem 'das letzte Zeichen des korrekten selectors fehlt' (z. B. 4e4a47e statt 4e4a47eb). Ein falsch getippter oder abgeschnittener Identifier validiert stillschweigend nie — kopieren Sie ihn wortgetreu.
- DNS-Einrichtung
Verdopplung des Host-Felds: Viele Registrare hängen Ihre Domain automatisch an, sodass die Eingabe 1a2b3c4d._domainkey.yourdomain.com zu 1a2b3c4d._domainkey.yourdomain.com.yourdomain.com wird. Geben Sie nur das Label ein (1a2b3c4d._domainkey), wenn das Panel die Domain für Sie ergänzt.
- Abdeckung
Kostenlose/öffentliche Absenderadressen sind blockiert: GetResponse authentifiziert nicht und sendet nicht zuverlässig von gmail.com, yahoo.com, outlook.com usw. Sie müssen von einer Adresse auf Ihrer eigenen Domain senden — genau das ist der Sinn des Authentifizierens.
- DNS-Einrichtung
DKIM ist ein TXT-Record, kein CNAME: Anders als Mailchimp oder SendGrid gibt Ihnen GetResponse einen statischen Schlüssel zum Einfügen. Es gibt keinen CNAME zum Delegieren und keine automatische Schlüsselrotation, sodass Sie den TXT-Record selbst aktualisieren müssen, falls Sie den Schlüssel jemals neu erzeugen.
- Bricht die Authentifizierung
Halten Sie genau einen SPF-Record: Falls Sie auch über Google Workspace, Microsoft 365 oder ein anderes Tool senden, führen Sie include:_spf.getresponse.com in die bestehende v=spf1-Zeile zusammen. Zwei SPF-TXT-Records auf derselben Domain sind ein PermError, der SPF vollständig bricht.
- Abdeckung
Die automatische (Entri) Authentifizierung kann teilweise fehlschlagen: Weist der verbundene DNS-Hoster eine API-Änderung zurück, fügt GetResponse möglicherweise manche Records hinzu und andere nicht oder bittet Sie, manuell fertigzustellen. Prüfen Sie nach einem automatischen Durchlauf erneut, dass alle drei Records tatsächlich bei Ihrem Hoster existieren.
Erstellen Sie Ihren SPF-Eintrag
GetResponse benötigt kein SPF-include: auf Ihrer Root-Domain — nutzen Sie den Generator, um für Ihre übrigen Absender einen sauberen Eintrag zusammenzustellen, und halten Sie ihn auf einer einzigen Zeile.
Sending sources
Search for each platform you send email through and tick it.
Search for your email platform above, or .
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listGetResponse SPF — FAQ
Weiterführende Lektüre
Sobald der Eintrag veröffentlicht ist, prüfen Sie mit dem Domain-Health-Check, ob alles korrekt aufgelöst wird, und lesen Sie mit der DMARC-Berichtsanalyse nach, wer in Ihrem Namen versendet. Durchsuchen Sie alle Versandquellen im Generator. Authentifizierung ist allerdings nur die halbe Zustellbarkeit — eine gelistete Absender-IP oder -Domain bringt Sie unabhängig davon, wie sauber Ihr SPF ist, im Spam-Ordner unter, deshalb lohnt es sich, mit Blacklist-Überwachung die Blacklists im Blick zu behalten.
Authentifiziert — jetzt die Liste sauber halten
SPF, DKIM und DMARC zu bestehen bringt Sie in den Posteingang; eine saubere Liste hält Sie dort. Verifizieren Sie Ihre — starten Sie kostenlos mit 100 Credits, ohne Kreditkarte.