Learn how email authentication works, test your domain's policy, and monitor DMARC reports — all in one place.
Klick-Anleitung: E-Mail-Sicherheit einrichten
Klicke dich Schritt für Schritt durch — mit allen Optionen, Vor-/Nachteilen & Best Practices.
E-Mail-Sicherheit einrichten
SPF, DKIM & DMARC in 8 Schritten — mit Best Practices und allen Optionen.
Schritt 1 / 8
SPF · Schritt 1 von 8
Finde heraus, welche Server für deine Domain mailen dürfen.
SPF (Sender Policy Framework) ist eine Art Einladungsliste in deinem DNS. Du trägst ein, welche Server in deinem Namen E-Mails versenden dürfen — alles andere wird von den Empfängern als möglicher Betrug erkannt.
Best Practice
Erstelle eine Liste ALLER Dienste, die in deinem Namen mailen: Newsletter-Tool, CRM, Support-System, Buchhaltung, Onlineshop — wirklich alles. Jeder vergessene Dienst verursacht später SPF-Fehlschläge. Beispiel: v=spf1include:_spf.google.cominclude:mailchimp.comip4:203.0.113.5include:spf.sendgrid.net~all
Welcher Fall trifft auf dich zu?
Variante A
E-Mail-Dienstleister
Google Workspace, Microsoft 365, IONOS, Strato, ALL-INKL & Co. stellen dir eine fertige SPF-Include bereit, die du nur noch kopieren musst.
+ Einfach: Include kopieren, fertig
− Du bist auf den Provider angewiesen
Variante B
Eigener Mailserver
Du betreibst Postfix, Exim oder einen anderen Mailserver selbst. Du trägst die IP-Adresse(n) deines Servers direkt ein.
+ Volle Kontrolle über den Eintrag
− Bei IP-Wechsel SPF manuell updaten
Nutzt du mehrere Dienste? Dann kombinierst du beide Varianten in einem SPF-Eintrag. Das Maximum sind 10 DNS-Lookups (jeder include: zählt als 1 Lookup).
Provider-unabhängig: Eigene Mailserver-IPs ermitteln
Betreibst du einen eigenen Mailserver (Postfix, Exim, Exchange on-premise)? So findest du die korrekten IPs:
IPv4:curl -4 ifconfig.me auf deinem Mailserver ausführen — oder im Hosting-Panel unter Server-IPs nachschauen
IPv6 (falls genutzt):curl -6 ifconfig.me — nur eintragen wenn dein Server auch per IPv6 mailt
Statische IP? Die meisten Mailserver brauchen eine statische (feste) IP. Dynamische IPs (DSL, Home-Server) sind für seriösen Mailversand ungeeignet — viele Empfänger blocken die pauschal
Mehrere Server? Für jeden ausgehenden Mailserver eine eigene ip4:-Zeile eintragen
Auch an Subdomains denken: Wenn z.B. dein Newsletter-Tool von newsletter.calvinconstrukt.com aus sendet und über eine Fremd-IP läuft, brauchst du entweder deren Include oder die IP im SPF. Das gilt für jede Subdomain, unter der E-Mails verschickt werden.
SPF · Schritt 2 von 8
Deinen SPF-Eintrag zusammensetzen.
Jeder SPF-Eintrag beginnt mit v=spf1 und endet mit einem All-Mechanismus. Dazwischen listest du deine Server — entweder als ip4: oder per include:.
Dein Provider nicht dabei? Google nach "[Providername] SPF record" oder schau in dessen DNS-Doku.
Der All-Mechanismus: ~all oder -all?
~all (SoftFail)
+ Mails werden markiert, aber zugestellt
+ Keine verlorenen Mails in der Testphase
− Schwächerer Schutz vor Spoofing
Empfohlen zum Start
-all (HardFail)
+ Maximaler Spoofing-Schutz
− Mails von ungelisteten Servern werden abgelehnt
− Fehler in der Liste = verlorene Mails
Ziel nach Testphase
Best Practice
Starte mit ~all. Lass den Eintrag 1–2 Wochen laufen, checke ob legitime Mails Probleme haben, und wechsle dann auf -all. Start: v=spf1 include:_spf.google.com include:mailchimp.com ~all Ziel: v=spf1 include:_spf.google.com include:mailchimp.com -all (wechselst nur ~ → -)
SPF · Schritt 3 von 8
SPF-Eintrag in deinem DNS hinterlegen.
Jetzt geht's ans Eingemachte: Du loggst dich bei deinem DNS-Provider ein und setzt den TXT-Record.
Typ:TXT
Name:@ (Root-Domain) — bei manchen Providern leer lassen
Wert: Dein SPF-String, z.B. v=spf1 include:_spf.google.com ~all
TTL:3600 (1 Stunde, zum Testen auch 300 = 5 Minuten)
Wichtig: Falls du bereits einen SPF-Eintrag hast (z.B. von deinem Provider vorkonfiguriert), überschreibe ihn nicht einfach — erweitere ihn! Einige Provider (wie IONOS) setzen automatisch einen Basis-SPF. Prüfe vorher mit dem Policy-Tester (Tab 2), was schon existiert.
Best Practice
Nach dem Setzen sofort mit dem Policy-Tester (Tab 2) prüfen, ob der Eintrag im öffentlichen DNS sichtbar ist. DNS-Änderungen können je nach TTL bis zu 48 Stunden brauchen — meist sind es aber nur Minuten. Prüfbefehl: dig TXT calvinconstrukt.com +short → "v=spf1 include:_spf.google.com ~all"
DKIM · Schritt 4 von 8
DKIM-Schlüssel von deinem Mail-Provider holen.
DKIM signiert deine E-Mails digital. Der Empfänger prüft die Signatur gegen den öffentlichen Schlüssel in deinem DNS. Anders als bei SPF generierst du den DKIM-Key nicht selbst — dein Mail-Provider macht das für dich.
Google zeigt DNS-Hostname + TXT-Wert → beides kopieren
Microsoft 365:
Exchange Admin Center → Schutz → DKIM
Domain auswählen → "Aktivieren"
Microsoft zeigt CNAME-Einträge (selector1._domainkey, selector2._domainkey)
Andere Anbieter oder eigener Mailserver:
Das Prinzip ist immer gleich, egal bei welchem Anbieter:
Melde dich im Admin-Panel deines Mail-Providers an
Suche nach einem Menüpunkt namens "DKIM", "E-Mail-Authentifizierung", "Domain-Schlüssel", "Email Authentication" oder ähnlich
Der Provider generiert ein Schlüsselpaar und zeigt dir den öffentlichen Teil (Public Key) sowie den Selektor-Namen an
Kopiere beide Werte — die brauchst du für Schritt 5
Findest du im Panel nichts? Viele kleinere Hosting-Anbieter (IONOS, Strato, ALL-INKL, Hetzner, HostEurope, netcup, manitu etc.) haben DKIM in ihren Hilfe-Dokumentationen beschrieben. Suchbegriff: "DKIM [Anbietername] einrichten".
Selbst gehosteter Mailserver:
Bei eigenen Servern generierst du DKIM-Schlüssel selbst — z.B. mit OpenDKIM (Linux-Standard), rspamd oder dem DKIM-Modul deiner Mailserver-Software (Postfix, Exim, Haraka). Die generierten Schlüssel musst du dann wie in Schritt 5 beschrieben ins DNS eintragen. Die meisten Mailserver-Distributionen haben eingebaute DKIM-Generatoren.
Microsoft 365 = CNAME, nicht TXT! MS365 nutzt CNAME-Einträge, die auf Microsofts DKIM-Infrastruktur verweisen — du setzt keinen TXT-Eintrag mit Public Key.
Best Practice
2048 Bit RSA ist der aktuelle Sicherheitsstandard. Ältere 1024-Bit-Schlüssel solltest du ersetzen. Bei Google Workspace wird standardmäßig 2048 Bit verwendet. Beispiel (gekürzt): v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQE... (p=... = öffentlicher Schlüssel, ~400 Zeichen bei 2048 Bit)
DKIM · Schritt 5 von 8
DKIM-DNS-Eintrag setzen.
Dein Provider hat dir einen Selektor und einen Public Key gegeben. Der Selektor ist der Name vor ._domainkey — z.B. google in google._domainkey.calvinconstrukt.com.
Wert: Dein DKIM-String, beginnt mit v=DKIM1; k=rsa; p=...
TXT oder CNAME? Die meisten Provider liefern ihren DKIM-Key als TXT-Eintrag. Microsoft 365 ist eine Ausnahme und nutzt CNAME. Ob TXT oder CNAME sagt dir dein Provider — das DNS-Formular bei deinem Hoster unterstützt beides. Der Name (<selektor>._domainkey) bleibt gleich, nur der Typ ändert sich.
Was tun bei mehreren Diensten?
Jeder Dienst bekommt seinen eigenen Selektor mit eigenem DKIM-Eintrag — das ist völlig normal und kein Problem. Du kannst beliebig viele Selektoren parallel betreiben.
Betreibe zwei Selektoren im Wechsel (z.B. s1 und s2). So kannst du Keys rotieren, ohne dass zwischendurch Mails ohne gültige DKIM-Signatur verschickt werden. DKIM-Keys solltest du alle 6–12 Monate erneuern. Beide parallel im DNS: s1._domainkey.calvinconstrukt.com → TXT "v=DKIM1; k=rsa; p=...keyA..." s2._domainkey.calvinconstrukt.com → TXT "v=DKIM1; k=rsa; p=...keyB..." Nach Rotation: neuer Key in s1, s2 wird neuer aktiver Selektor, alter s1 raus.
DKIM · Schritt 6 von 8
DKIM-Signing aktiv einschalten.
Der DNS-Eintrag allein reicht nicht — du musst das DKIM-Signing bei deinem Provider explizit aktivieren:
Google Workspace: Admin Console → "E-Mail authentifizieren" → "Authentifizierung starten"
Microsoft 365: Exchange Admin Center → DKIM → "Aktivieren"
Andere Anbieter: Suche im Admin-Panel nach einem Schalter für "DKIM-Signing", "DKIM aktivieren" oder "E-Mail signieren" — der ist oft im gleichen Menü wo du die Keys generiert hast
Eigener Mailserver: Starte deinen Mailserver neu (oder lade die DKIM-Konfiguration neu). Prüfe mit systemctl restart opendkim (Linux) oder dem Neustart-Kommando deiner Server-Software, ob DKIM korrekt läuft
Best Practice
Nach dem Aktivieren einige Minuten warten (TTL), dann eine Test-Mail an dich selbst senden und die Header prüfen. Alternativ: Policy-Tester (Tab 2) checkt, ob der DKIM-Eintrag öffentlich sichtbar ist. Premium-Funktionstest (Tab 4) prüft den Live-Betrieb. Header-Suche: Authentication-Results: dkim=pass oder DKIM-Signature: v=1; a=rsa-sha256; s=google; d=calvinconstrukt.com; ...
DMARC · Schritt 7 von 8
DMARC-Policy definieren — was passiert mit Mails, die SPF/DKIM nicht bestehen?
DMARC baut auf SPF und DKIM auf und sagt den Empfängern, was sie mit verdächtigen Mails tun sollen. Zusätzlich bekommst du tägliche XML-Berichte, wer in deinem Namen mailt.
Die drei Policy-Stufen:
Policy
Wirkung
Pro
Contra
p=none
Nur überwachen, keine Auswirkung
Keine verlorenen Mails
Kein Schutz
p=quarantine
Mails landen im Spam
Schutz mit geringem Risiko
Legitime Mails können im Spam landen
p=reject
Mails werden abgelehnt (Bounce)
Maximaler Schutz
Fehler in SPF/DKIM = Mails weg
Best Practice — Rollout-Plan
Phase 1:p=none für 2–4 Wochen → Reports sammeln, alle legitimen Quellen identifizieren. Phase 2:p=quarantine für 2–4 Wochen → prüfen ob legitime Mails im Spam landen. Phase 3:p=reject dauerhaft → maximaler Schutz. Reports weiter überwachen. Phase 1: v=DMARC1; p=none; rua=mailto:dmarc@calvinconstrukt.com; pct=100 Phase 2: v=DMARC1; p=quarantine; rua=mailto:dmarc@calvinconstrukt.com; pct=100 Phase 3: v=DMARC1; p=reject; rua=mailto:dmarc@calvinconstrukt.com; pct=100
Report-E-Mail-Adresse (rua):
Erstelle ein Postfach wie dmarc@calvinconstrukt.com. Die Reports kommen täglich als XML. Ohne rua fliegst du blind — du siehst nicht, wer in deinem Namen mailt.
Häufigster Fehler: Direkt mit p=reject starten → legitime Mails werden abgelehnt und gehen verloren. Immer mit p=none beginnen!
DMARC · Schritt 8 von 8
DMARC im DNS setzen & fertig.
Letzter Schritt: Setze den DMARC-TXT-Eintrag bei deinem DNS-Provider.
Provider-unabhängig: Der _dmarc-Eintrag funktioniert auf jedem DNS-Provider gleich — du musst nur einen TXT-Eintrag mit Namen _dmarc (bei manchen Providern auch _dmarc.calvinconstrukt.com als voller Name) anlegen. Falls du die DMARC-Reports (rua) an eine externe Domain schicken willst (z.B. reports@analyse-tool.com), brauchst du eine zusätzliche DNS-Autorisierung auf der Empfänger-Domain. Für die eigene Domain reicht der TXT-Eintrag aus.
# Dein Start-DMARC (copy & paste)
v=DMARC1; p=none; rua=mailto:dmarc@calvinconstrukt.com; pct=100
# Nach 2–4 Wochen:
v=DMARC1; p=quarantine; rua=mailto:dmarc@calvinconstrukt.com; pct=100
# Ziel nach ~2 Monaten:
v=DMARC1; p=reject; rua=mailto:dmarc@calvinconstrukt.com; pct=100
Best Practice
Nutze unser DMARC Reports (Tab 3) für die automatische DMARC-Report-Analyse — oder Open-Source-Tools wie parsedmarc zum Selbsthosten. Die täglichen XML-Reports sind für Menschen sonst kaum lesbar. Beispiel Report (Auszug): feedback.report_metadata.org_name: "google.com" record.row.policy_evaluated.spf: "fail" | dkim: "pass" record.identifiers.header_from: "calvinconstrukt.com"
Du hast es geschafft! Deine Domain ist jetzt mit SPF, DKIM und DMARC geschützt.
Nutze den Policy-Tester (Tab 2) um deine Einträge regelmäßig zu überprüfen.
Technischer Deep-Dive (für Fortgeschrittene)
Alle Mechanismen & RFC-Referenzen im Detail. Wähle ein Thema über die Buttons.
tbx@toolbox:~$ emailsec --explain --topic all
# Wähle ein Thema über die Buttons oben.
Datenschutz-Hinweis: Die eingegebene Domain wird via unseren eigenen n8n-Server geprüft. Domain-Daten werden temporär (24 h) gespeichert, keine Weitergabe an Dritte, keine personenbezogenen Daten.
Was dieser Test prüft — und was nicht
Dieser Test prüft nur die öffentlichen DNS-Einträge (SPF, DKIM, DMARC).
Er sagt: Sind die Records korrekt gesetzt und syntaktisch gültig?
Er testet nicht, ob dein Mailserver diese Vorgaben in der Praxis einhält.
Beispiel: Dein SPF sagt v=spf1 include:_spf.google.com ~all,
aber dein Mailserver sendet von einer IP, die nicht bei Google liegt → im Live-Test würde SPF fail.
Unser DNS-Test würde trotzdem SPF: OK anzeigen, weil der Record syntaktisch korrekt ist.
Wichtig: Subdomain vs. Root-Domain. SPF-, DKIM- und DMARC-Einträge gelten immer nur für die exakt geprüfte Domain.
Eine Subdomain wie newsletter.deine-domain.de kann andere oder gar keine Einträge haben als deine-domain.de.
Prüfe daher die konkrete Domain/Subdomain, die du einrichten willst — nicht nur die Root.
Für einen echten Funktionstest brauchst du PREMIUM:
Wir senden eine Prüf-E-Mail via unsere Infrastruktur und zeigen dir, ob SPF/DKIM/DMARC im Live-Betrieb tatsächlich passen.
Beispiele zum Ausprobieren:
Bereit für den ersten Test?
Gib oben eine Domain ein oder klicke ein Beispiel. Wir prüfen SPF, DKIM und DMARC in Echtzeit und zeigen dir, was verbessert werden kann.
Domain wird geprüft …
DMARC Reports
Empfange und analysiere DMARC-Aggregat-Reports für deine Domains — ein Premium-Feature. Melde dich an, um loszulegen.
DMARC Reports
Empfange und analysiere DMARC-Aggregat-Reports für deine Domains. Jeder Nutzer bekommt eine eigene Report-E-Mail-Adresse.
Deine persönliche DMARC-Report-Adresse
wird geladen...
Setze diese Adresse als rua=mailto:... in deinem DMARC-DNS-Eintrag.
Wir empfangen die täglichen XML-Reports und werten sie für dich aus.
Setup-Anleitung — Live-DMARC-Prüfung
Gib eine Domain ein, um den aktuellen DMARC-Record zu prüfen und eine personalisierte Setup-Anleitung zu erhalten.
Prüfe DMARC-Eintrag...
—
Reports
—
Pass Rate %
—
Fail Rate %
Source IP
Domain
Result
Count
Received
Noch keine Reports empfangen. Sobald DMARC-Reports an deine persönliche Adresse geschickt werden, erscheinen sie hier.
Email-Test: SPF / DKIM / DMARC Live-Prüfung
Sende eine E-Mail an deine persönliche Test-Adresse. Wir empfangen sie und prüfen automatisch, ob SPF, DKIM und DMARC im Live-Betrieb korrekt gesetzt sind — genau wie mail-tester.com.
Anmelden für den Email-Test
Melde dich an, um eine persönliche Test-Adresse zu erhalten und deine E-Mail-Authentifizierung live zu prüfen.
Deine persönliche Test-Adresse
wird geladen...
So funktioniert's
E-Mail senden — Sende eine E-Mail von deinem Mailserver an diese Adresse. Am besten an dich selbst mit BCC an die Test-Adresse, so dass du siehst was versendet wurde.
Automatische Prüfung — Sobald wir die E-Mail empfangen, analysieren wir die Authentication-Results-Header auf SPF, DKIM und DMARC.
Ergebnisse anzeigen — Klicke auf "Jetzt prüfen", um dein Ergebnis zu sehen.
Warte auf E-Mail-Eingang. Sende eine E-Mail an deine Test-Adresse und klicke dann erneut auf "Jetzt prüfen".
Letzte Tests
Manuelle Header-Analyse
Kein MX-Empfang möglich? Du kannst die Roh-Header einer empfangenen E-Mail manuell einfügen.
Öffne eine E-Mail, die du erhalten hast, zeige die Original-Header / Rohdaten an und kopiere sie hierher.
Hinweis: Der automatische Empfang scannt eingehende E-Mails. Sende eine E-Mail an deine Test-Adresse und klicke auf „Jetzt prüfen“. Alternativ kannst du unten die manuelle Header-Analyse nutzen.
Domain DNS-Check: Ist / Soll
Prüfe die aktuellen DNS-Einträge deiner Domain und vergleiche sie mit den Best-Practice-Empfehlungen.