SPF, DKIM & DMARC für Mailtrap.
Mailtrap authentifiziert Ihre Domain über eine CNAME-basierte Domain-Verifizierung und nicht dadurch, dass Sie eine gemeinsam genutzte SPF-Zeile einfügen. In seinem Produkt Email Sending fügen Sie eine Absender-Domain hinzu, und Mailtrap stellt Ihnen auf der Seite Domain Verification fünf DNS-Einträge bereit: einen Domain-Verification-CNAME (der zugleich SPF/Return-Path abdeckt), zwei DKIM-CNAMEs auf den Selektoren rwmt1._domainkey und rwmt2._domainkey, einen optionalen Custom-Tracking-Domain-CNAME für gebrandetes Öffnungs-/Klick-Tracking sowie einen DMARC-TXT-Eintrag. Sobald diese auflösen, signiert und sendet Mailtrap unter Ihrer eigenen Domain, DMARC besteht über ausgerichtetes DKIM (und über SPF via Ihres eigenen Return-Path), und Sie müssen niemals ein rohes SPF-include veröffentlichen oder pflegen. Eine Sache verwirrt zu Beginn viele: Dies gilt ausschließlich für Mailtrap Email Sending — die separate Email-Testing-Sandbox fängt Nachrichten in einem Fake-Postfach ab und benötigt überhaupt kein DNS.
Warum Mailtrap authentifizieren?
Die Verifizierung Ihrer Absender-Domain in Mailtrap ist das Tor zwischen dem Posteingang und dem Spam-Ordner — und Mailtrap erzwingt sie, bevor überhaupt produktive Mail versendet wird. Solange eine Domain nicht verifiziert ist, beschränkt Mailtrap einen Email-Sending-Stream auf Testnachrichten an die eigene Konto-E-Mail-Adresse; echte Empfänger sind blockiert. Darüber hinaus ist das Timing entscheidend: Seit Februar 2024 verlangen Gmail und Yahoo von jedem Massenversender (grob ab 5.000 Nachrichten pro Tag), SPF, DKIM und DMARC mit Ausrichtung zu bestehen, und 2025 begann Microsoft, dieselbe Messlatte für Outlook/Hotmail/Live durchzusetzen — zunächst durch Umleitung nicht-konformer Massenmail in den Junk-Ordner, dann in Richtung vollständiger Ablehnung. Da Mailtrap ein transaktionaler/API-Versender ist, bedeutet ein nicht verifizierter Stream, dass Ihre Mail entweder gar nicht ausgeht oder nur schwach Ihrer Domain zuzuordnen ausgeht — kein ausgerichtetes DKIM, kein DMARC-Bestehen und eine Reputation, die mit Mailtraps geteilter Infrastruktur zusammengelegt wird statt mit Ihrer eigenen. Der Abschluss der Domain-Verifizierung behebt all das auf einen Schlag: Die beiden rwmt-DKIM-Selektoren signieren als d=yourdomain.com, sodass DKIM ausgerichtet ist, der Domain-Verification-CNAME legt Mailtraps Return-Path auf Ihre eigene Domain, sodass SPF besteht und ebenfalls ausgerichtet ist, DMARC besteht über beide Mechanismen, und die Versand-Reputation, die Sie aufbauen, kommt Ihrer Domain zugute.
Die SPF-Realität bei Mailtrap
Mailtrap ist ein CNAME-basierter Domain-Verifizierungsanbieter, sodass es für Ihre Root-Domain KEIN SPF-include hinzuzufügen gibt — und Mailtraps eigene Dokumentation sagt es unmissverständlich: "The SPF check for your mail is covered by the domain verification record. There is no need to add a separate SPF record on your sending domain." Und so funktioniert der Mechanismus. Wenn Sie eine Absender-Domain verifizieren, ist einer der CNAMEs, die Mailtrap Ihnen gibt, der Domain-Verification-Eintrag, der zugleich als Return-Path-/Bounce-Host auf Ihrer eigenen Domain dient und den SPF-Lookup in Mailtraps Versandinfrastruktur delegiert. Mailtraps echter, aktiver SPF-Eintrag liegt unter _spf.smtp.mailtrap.live (v=spf1 ip4:45.158.83.0/24 ip4:5.181.200.0/24 … ~all) — den veröffentlichen Sie jedoch niemals selbst; der Domain-Verification-CNAME löst für Sie in ihn hinein auf. Da dieser Return-Path-Host unter Ihrer eigenen verifizierten Domain liegt, besteht SPF und richtet sich unter relaxed alignment zugleich an Ihrer Organisations-Domain aus, was ein echter Vorteil gegenüber reinen DKIM-CNAME-Versendern (Mailchimp, Klaviyo) ist, bei denen SPF sich nie ausrichten kann. Zwei Dinge sollten Sie wissen. Erstens: Ignorieren Sie jeden alten Ratschlag, include:_spf.mailtrap.io hinzuzufügen — dieser Hostname löst überhaupt nicht als SPF-Eintrag auf, und selbst der korrekte Infra-Host (_spf.smtp.mailtrap.live) ist nichts, was Sie in Ihre Root einfügen; ihn manuell hinzuzufügen würde nur einen Ihrer 10 SPF-DNS-Lookups grundlos verbrauchen. Zweitens: Wenn Ihr DNS bei Google Cloud DNS liegt, bietet dessen Konsole weiterhin einen veralteten Eintragstyp "SPF" an — Mailtrap weist Sie ausdrücklich an, ihn zu ignorieren (er ist deprecated) und die vier CNAMEs plus den DMARC-TXT ganz normal hinzuzufügen. Nettoeffekt auf Ihr Root-SPF: Mailtrap fügt null DNS-Lookups hinzu, sodass es sich sauber mit Google Workspace, Microsoft 365 oder jedem anderen bereits gelisteten Versender stapeln lässt.
Zwei Wege zur Einrichtung
Eine dedizierte Absender-Subdomain verifizieren (z. B. mail.yourdomain.com)
- Isoliert die Mailtrap-/Transaktions-Reputation von der menschlichen E-Mail auf Ihrer Root-Domain, sodass ein Versandfehler Ihre primäre Domain nicht mit herunterziehen kann.
- DKIM signiert als d=mail.yourdomain.com und richtet sich unter relaxed DMARC-Ausrichtung dennoch an Ihrer Organisations-Domain aus — sodass DMARC besteht.
- Der Domain-Verification-CNAME legt den Return-Path auf die Subdomain, sodass SPF auch dort besteht und ausgerichtet ist.
- Sie fügen weiterhin die vier CNAMEs plus einen DMARC-TXT hinzu; Ihr Root-SPF bleibt unberührt und fügt null DNS-Lookups hinzu.
Die Root-/Organisations-Domain verifizieren (yourdomain.com)
- Am einfachsten, wenn Mailtrap Ihr einziger oder primärer Versender ist und Sie möchten, dass die Mail sichtbar von der nackten Domain kommt.
- DKIM und der Return-Path sitzen direkt auf der Organisations-Domain, sodass die Ausrichtung exakt ist und nicht auf den relaxed-Modus angewiesen ist.
- Die Reputation wird mit allem anderen geteilt, was Sie von der Root aus versenden — wägen Sie das ab, falls dort auch menschliche Mail von Google Workspace oder Microsoft 365 liegt.
- Weiterhin null zusätzliche Lookups zu Ihrem Root-SPF, da Mailtrap den Domain-Verification-CNAME nutzt und kein Root-include.
Schritt für Schritt
- 1
Email Sending öffnen, nicht Email Testing
Melden Sie sich unter mailtrap.io an und stellen Sie sicher, dass Sie sich im Produkt Email Sending befinden (der Seitenleisten-Bereich für echten ausgehenden Versand) und nicht in Email Testing (der Sandbox, die Nachrichten für die QA abfängt und kein DNS benötigt). Die Domain-Verifizierung existiert nur für Email Sending.
- 2
Ihre Absender-Domain hinzufügen
Gehen Sie in der linken Navigation zu Sending Domains und klicken Sie auf Add Domain. Geben Sie die Domain ein, von der aus Sie senden werden (z. B. yourdomain.com oder eine Subdomain wie mail.yourdomain.com, falls Sie transaktionale Mail isolieren möchten). Mailtrap generiert die DNS-Einträge für genau diesen Namen.
- 3
Die Seite Domain Verification öffnen
Wählen Sie die neue Domain aus, um ihre Seite Domain Verification zu öffnen. Sie sehen die zu veröffentlichenden Einträge, jeweils nach Zweck beschriftet: Domain Verification (CNAME), DKIM (zwei CNAMEs), Custom Tracking / Domain Tracking (CNAME) und DMARC (TXT). Beachten Sie die Spalten Type, Name und Value — Name und Value werden für Ihr Konto generiert.
- 4
Den Domain-Verification-CNAME hinzufügen
Erstellen Sie den Domain-Verification-Eintrag als CNAME mit dem exakten Name und Value, die Mailtrap anzeigt. Dieser eine Eintrag belegt sowohl die Inhaberschaft als auch deckt SPF/Return-Path ab — deshalb veröffentlichen Sie keinen separaten SPF-Eintrag. Behalten Sie den Typ als CNAME bei; konvertieren Sie ihn nicht in TXT oder A.
- 5
Die zwei DKIM-CNAMEs hinzufügen
Erstellen Sie zwei CNAME-Einträge: Name rwmt1._domainkey → Value rwmt1.dkim.mailtrap.io und Name rwmt2._domainkey → Value rwmt2.dkim.mailtrap.io (verwenden Sie die exakten Werte aus Ihrem Dashboard). Zwei Selektoren ermöglichen es Mailtrap, DKIM-Schlüssel zu rotieren, ohne dass Sie DNS erneut anfassen müssen. Diese CNAMEs sind es, die Ihre Mail als d=yourdomain.com signieren und das DMARC-Bestehen tragen.
- 6
Den Custom-Tracking-Domain-CNAME hinzufügen
Erstellen Sie den Tracking-CNAME (Mailtrap zeigt typischerweise einen Name wie mt-link an), der auf den bereitgestellten Value zeigt. Dieser liefert Öffnungs-/Klick-Tracking und Abmelde-Links von Ihrer eigenen Domain statt von einem Mailtrap-Host. Es ist der eine Eintrag, den Sie überspringen können, wenn Sie kein Link-Tracking verwenden, aber ihn hinzuzufügen hält getrackte Links markenkonform und vermeidet die geteilte Domain-Reputation eines generischen Mailtrap-Tracking-Hosts.
- 7
Den DMARC-TXT-Eintrag hinzufügen
Erstellen Sie einen einzelnen TXT-Eintrag unter Name _dmarc mit dem Value, den Mailtrap anzeigt (eine Richtlinie v=DMARC1; p=none; …). Falls Ihre Domain bereits einen _dmarc-Eintrag hat, fügen Sie KEINEN zweiten hinzu — eine Domain muss genau einen DMARC-Eintrag haben; behalten Sie stattdessen Ihren bestehenden.
- 8
Host-Verdopplung beheben und den Cloudflare-Proxy deaktivieren
Viele Registrare hängen Ihre Domain automatisch an, geben Sie also nur das Label ein (rwmt1._domainkey, nicht rwmt1._domainkey.yourdomain.com), um Verdopplung zu vermeiden — obwohl einige wenige Panels die vollständige Postfix-Form erwarten, richten Sie sich also danach, was Ihr Host erwartet. Stellen Sie in Cloudflare jeden CNAME auf DNS only (graue Wolke); Cloudflare aktiviert den Proxy standardmäßig, und ein proxied CNAME mit oranger Wolke löst nicht auf Mailtrap auf, sodass die Verifizierung fehlschlägt.
- 9
DNS in Mailtrap erneut prüfen
Klicken Sie zurück auf der Seite Domain Verification auf Re-check DNS Records. Mailtrap prüft außerdem periodisch automatisch, sodass Einträge von Missing (rot) auf Verified (grün) umschlagen, während sie sich verbreiten — üblicherweise Minuten, planen Sie aber 15 Minuten bis 24–48 Stunden ein. Manche Einträge verifizieren sich vor anderen; warten Sie, bis alle grün sind.
- 10
Einen Test senden und die Header lesen
Senden Sie eine Nachricht von einer Adresse auf der verifizierten Domain, öffnen Sie sie in Gmail und wählen Sie ⋮ → Original anzeigen. Bestätigen Sie DKIM: PASS, signiert von yourdomain.com (Selektor rwmt1 oder rwmt2), SPF: PASS und DMARC: PASS — allesamt an Ihrer Domain ausgerichtet und nicht an einem mailtrap.io-Host.
Einzutragende Einträge
Mailtrap erzeugt die genauen Werte in seinem Einrichtungsassistenten — diese zeigen die Struktur dessen, was Sie bei Ihrem DNS-Anbieter hinzufügen werden.
| Typ | Host | Wert |
|---|---|---|
| CNAME | (Mailtrap-generated verification host) | (per-account target, e.g. under smtp.mailtrap.live)Domain-Verification-Eintrag — beispielhaft. Mailtrap zeigt den exakten kontospezifischen Name und Value auf der Seite Domain Verification an. Dieser CNAME deckt auch SPF/Return-Path ab, weshalb kein separater SPF-Eintrag nötig ist. |
| CNAME | rwmt1._domainkey | rwmt1.dkim.mailtrap.ioDKIM-Schlüssel 1 (automatisch rotiert). Kopieren Sie den exakten Wert aus Ihrem Dashboard; einige DNS-Hosts benötigen die Postfix-Form rwmt1._domainkey.yourdomain.com. |
| CNAME | rwmt2._domainkey | rwmt2.dkim.mailtrap.ioDKIM-Schlüssel 2 — der zweite Selektor ermöglicht es Mailtrap, Schlüssel zu rotieren. Verwenden Sie das exakte Ziel, das in Ihrem Dashboard angezeigt wird. |
| CNAME | mt-link | (per-account tracking target)Custom Tracking Domain — beispielhafter Host/beispielhaftes Ziel. Aktiviert gebrandetes Öffnungs-/Klick-Tracking und Abmelde-Links auf Ihrer Domain. Optional, aber empfohlen; der exakte Name/Value wird kontospezifisch angezeigt. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comDMARC-Richtlinie — eine pro Domain. Mailtrap füllt einen p=none-Wert vor; behalten Sie nur einen _dmarc-Eintrag und verschärfen Sie später auf quarantine/reject. |
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 Mailtrap von diesem Budget verbraucht.
Die empfohlene Einrichtung von Mailtrap fügt 0 Lookups hinzu — alle 10 bleiben frei für die Absender, die tatsächlich ein include benötigen.
DKIM
DKIM wird über zwei CNAME-Einträge abgewickelt — rwmt1._domainkey und rwmt2._domainkey —, die Mailtrap für Ihre Domain generiert und die jeweils auf rwmt1.dkim.mailtrap.io bzw. rwmt2.dkim.mailtrap.io zeigen (kopieren Sie die exakten Werte von der Seite Domain Verification). Da es sich um an Mailtrap delegierte CNAMEs handelt — nicht um TXT-Einträge, die Sie einfügen —, hält Mailtrap die privaten Schlüssel und nutzt die beiden Selektoren, um die dahinter veröffentlichten Schlüssel zu rotieren, ohne dass Sie jemals wieder DNS bearbeiten müssen. Es gibt keinen DKIM-Public-Key zum Kopieren und keinen Selektor zu erfinden. DKIM ist hier der Mechanismus, der die Hauptarbeit für DMARC leistet: Sobald die CNAMEs auflösen, signiert Mailtrap ausgehende Mail als d=yourdomain.com, sodass sich die Signatur an Ihrer Organisations-Domain ausrichtet und DMARC eigenständig erfüllt — unabhängig von der Weiterleitung, die SPF brechen kann. Ein paar praktische Hinweise: Behalten Sie den Eintragstyp als CNAME bei (ein TXT dort, wo ein CNAME erwartet wird, bricht die Validierung); geben Sie nur das Label (rwmt1._domainkey) ein, wenn Ihr Panel die Domain automatisch anhängt, oder das vollständige rwmt1._domainkey.yourdomain.com, wenn nicht; und stellen Sie in Cloudflare beide auf DNS only (graue Wolke), damit sie auf die mailtrap.io-Ziele auflösen. Sie fügen die beiden CNAMEs hinzu, klicken auf Re-check DNS Records, und die DKIM-Zeilen werden grün.
DMARC
DMARC ist ein separater Richtlinien-Eintrag auf Ihrer Domain, und Mailtrap nimmt ihn auf der Seite Domain Verification in den Eintragssatz auf — typischerweise vorausgefüllt als v=DMARC1; p=none; … . Veröffentlichen Sie ihn als TXT-Eintrag unter _dmarc.yourdomain.com. p=none ist reines Monitoring: Es ändert nichts an der Zustellung, während Sie anhand der aggregierten (rua-)Berichte bestätigen, dass Mailtrap-Mail DKIM (und SPF) besteht und an Ihrer Domain ausgerichtet ist. Da Mailtrap Ihnen sowohl ausgerichtetes DKIM (die rwmt-Selektoren) als auch einen ausgerichteten Return-Path (den Domain-Verification-CNAME) bereitstellt, besteht eine korrekt verifizierte Domain DMARC über beide Mechanismen — das robuste Setup, das die Weiterleitung übersteht. Beobachten Sie die Berichte ein bis zwei Wochen, stellen Sie sicher, dass sich jeder legitime Versender authentifiziert, und verschärfen Sie dann auf p=quarantine und schließlich p=reject. Zwei Regeln: Behalten Sie genau einen _dmarc-Eintrag für die gesamte Domain, egal wie viele Versender Sie nutzen — wenn Sie bereits einen haben, fügen Sie nicht Mailtraps zweite Kopie hinzu, sondern behalten Sie Ihren —, und richten Sie rua auf ein Postfach (oder einen DMARC-Berichtsdienst), das Sie tatsächlich überwachen, sonst bringt p=none Ihnen nichts.
Prüfen, ob es wirklich funktioniert hat
Vertrauen Sie nicht allein dem grünen Badge "Verified" auf der Seite Domain Verification — das bestätigt nur, dass die Einträge auflösen, nicht, dass sich eine echte Nachricht authentifiziert. Senden Sie sich selbst einen Test von einer Adresse auf der verifizierten Domain, öffnen Sie ihn in Gmail und wählen Sie ⋮ → Original anzeigen: Sie möchten DKIM: PASS, signiert von yourdomain.com mit Selektor rwmt1 oder rwmt2, SPF: PASS und DMARC: PASS sehen, allesamt mit Ihrer Domain statt eines mailtrap.io-Hosts. Verwenden Sie in Mailtrap die Schaltfläche Re-check DNS Records, um eine Prüfung zu erzwingen, statt auf die periodische Abfrage zu warten. Sie können die Roheinträge stichprobenartig mit dig CNAME rwmt1._domainkey.yourdomain.com und dig TXT _dmarc.yourdomain.com prüfen. Lassen Sie Ihre Domain anschließend durch Qualisends Domain-Health-Check laufen, um zu bestätigen, dass der Domain-Verification-CNAME, beide DKIM-Selektoren, der Tracking-CNAME und der DMARC-Eintrag alle sauber auflösen und Ihr Root-SPF unter dem 10-Lookup-Limit bleibt — und sobald DMARC-Aggregatberichte eintreffen, geben Sie einen davon in den DMARC-Berichtsanalyzer, wo Mailtrap als ausgerichtete, bestehende Quelle auftauchen sollte.
Häufige Stolperfallen
- Abdeckung
Email Testing vs. Email Sending: Die Domain-Verifizierung existiert nur für das Produkt Email Sending. Die Email-Testing-Sandbox fängt Nachrichten für die QA in einem Fake-Postfach ab und benötigt überhaupt keine DNS-Einträge — wenn Sie unter Email Testing nach einem DNS-Setup suchen, sind Sie am falschen Ort.
- DNS-Einrichtung
Es gibt keinen SPF-Eintrag hinzuzufügen. Mailtraps Domain-Verification-CNAME deckt SPF/Return-Path bereits ab, fügen Sie also nicht include:_spf.mailtrap.io (löst nicht auf) oder include:_spf.smtp.mailtrap.live (Mailtraps interner Infra-Host) in Ihre Root ein — das verschwendet einen SPF-Lookup, und Mailtraps Dokumentation sagt ausdrücklich, dass kein separater SPF-Eintrag nötig ist.
- DNS-Einrichtung
Der Cloudflare-Proxy bricht die Verifizierung: Stellen Sie jeden Mailtrap-CNAME auf DNS only (graue Wolke). Cloudflare aktiviert den Proxy mit oranger Wolke standardmäßig, und ein proxied CNAME löst nicht auf die mailtrap.io-/mailtrap.live-Ziele auf, sodass sich die Einträge nie verifizieren.
- DNS-Einrichtung
Host-Feld-Verdopplung: Viele Registrare hängen Ihre Domain automatisch an, sodass aus rwmt1._domainkey rwmt1._domainkey.yourdomain.com.yourdomain.com werden kann. Geben Sie nur das Label ein, wenn das Panel die Domain hinzufügt; umgekehrt erwarten einige wenige Hosts (manche Squarespace-artige Panels) die vollständige Postfix-Form — richten Sie sich danach, was Ihr Anbieter erwartet.
- DNS-Einrichtung
Jeder Eintrag ist ein CNAME außer DMARC (TXT) — wechseln Sie nicht die Typen. Speziell bei Google Cloud DNS: Ignorieren Sie den veralteten Eintragstyp 'SPF' der Konsole; Mailtrap merkt an, dass er deprecated ist. Fügen Sie die vier CNAMEs und den einen DMARC-TXT hinzu.
- Abdeckung
Bis die Domain Verified ist, lässt Mailtrap einen Email-Sending-Stream nur Testnachrichten an Ihre eigene Konto-E-Mail-Adresse zustellen. Produktive Sendungen an echte Empfänger bleiben blockiert, schließen Sie also die Verifizierung ab, bevor Sie Mailtrap in den Live-Traffic Ihrer App einbinden.
- DNS-Einrichtung
Behalten Sie einen DMARC- und einen SPF-Eintrag. Wenn Sie auch über Google Workspace, Microsoft 365, SendGrid usw. senden, fügen Sie keinen zweiten _dmarc oder einen zweiten SPF-TXT hinzu — Mailtrap fügt null zu Ihrem Root-SPF hinzu, behalten Sie also einfach Ihre bestehenden einzelnen Einträge.
- Abdeckung
Die Verifizierung erfolgt nicht sofort: Die Verbreitung kann 15 Minuten bis 24–48 Stunden dauern, und Mailtrap prüft nach seinem eigenen Zeitplan erneut. Nutzen Sie Re-check DNS Records, um eine Prüfung zu erzwingen, und erwarten Sie, dass einige Einträge vor anderen grün werden.
Erstellen Sie Ihren SPF-Eintrag
Mailtrap 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 listMailtrap 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.