E‑Mail‑Sicherheit ist ein Thema, das mich seit Jahren begleitet — nicht nur technisch, sondern auch aus der Praxis: Ich habe selbst zahlreiche Domains eingerichtet, Mailserver betrieben und mit SaaS‑Anbietern gearbeitet. In diesem Artikel erkläre ich verständlich, wie SMTP, DKIM und DMARC zusammenwirken und wie du sie für deine Domain richtig konfigurierst, damit deine E‑Mails ankommen und nicht als Spam oder Phishing erscheinen.

Worum geht's beim Gesamtkonstrukt?

Kurz gesagt: SMTP ist das Versandprotokoll, DKIM ermöglicht die kryptografische Signatur von Mails und DMARC legt Regeln fest, wie Empfänger mit nicht verifizierten Mails umgehen sollen. Dazu kommt noch SPF, das festlegt, welche Server E‑Mails für deine Domain senden dürfen. Gemeinsam sorgen diese Mechanismen dafür, dass Empfänger vertrauen können, dass eine E‑Mail wirklich von deiner Domain stammt.

SMTP — das Fundament

SMTP (Simple Mail Transfer Protocol) ist für das Versenden und Weiterleiten von E‑Mails zuständig. Wenn du einen eigenen Mailserver betreibst (z. B. Postfix, Exim, qmail), musst du darauf achten, dass:

  • Der Server eine feste, öffentliche IP hat (kein dynamischer Consumer‑IP‑Block).
  • Reverse DNS (PTR) korrekt auf deine Mail‑Hostname verweist.
  • Die IP nicht auf Blacklists steht (z. B. Spamhaus prüfen).
  • TLS für SMTP aktiviert ist (STARTTLS), damit Mails verschlüsselt übertragen werden.

    • Wenn du einen SMTP‑Relay‑Dienst wie SendGrid, Mailgun oder die SMTP‑Server deines Hosting‑Providers nutzt, übernimmt dieser viele Aufgaben. Du musst dann aber deren Hinweise für DNS‑Records (SPF/DKIM) befolgen.

    SPF — wer darf senden?

    SPF (Sender Policy Framework) ist ein DNS‑TXT‑Record, der auflistet, welche Server deine Domain zum Versenden nutzen dürfen. Ein einfaches Beispiel:

    v=spf1 include:spf.protection.outlook.com include:sendgrid.net -all

    Das bedeutet: Erlaubt sind Microsoft 365 und SendGrid, alles andere wird abgelehnt (-all). Andere Optionen sind ~all (softfail) oder ?all (neutral), die weniger strikt sind.

  • Prüfe bestehende SPF‑Records: Mehrere SPF‑Records sind nicht erlaubt — falls vorhanden, musst du sie zusammenführen.
  • Achte auf die 10‑Lookup‑Regel: SPF erlaubt nur maximal 10 DNS‑Lookups (include, a, mx, ptr, exists). Bei vielen Dienstleistern kann das zu Problemen führen.

    • DKIM — Signatur für deine E‑Mails

    DKIM (DomainKeys Identified Mail) signiert ausgehende Mails mit einem privaten Schlüssel; der Empfänger überprüft die Signatur mit dem öffentlichen Schlüssel, der in deinem DNS gespeichert ist. Üblicher Workflow:

  • Generiere ein Schlüsselpaar (z. B. mit OpenSSL oder deinem Mailserver).
  • Lege den öffentlichen Schlüssel als TXT‑Record unter einem Selector ab, z. B. default._domainkey.deinedomain.tld.
  • Konfiguriere deinen Mailserver oder SMTP‑Provider, um mit dem privaten Schlüssel Mails zu signieren.

    • Ein DKIM‑Record sieht so aus:

    default._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

    Wichtig: Wähle einen aussagekräftigen Selector‑Namen (z. B. 2025 oder sendgrid), damit du später Schlüssel rotieren kannst.

    DMARC — Richtlinie und Reporting

    DMARC (Domain-based Message Authentication, Reporting & Conformance) baut auf SPF und DKIM auf und gibt Empfängern Anweisungen, wie sie mit fehlgeschlagenen Prüfungen umgehen sollen. Ein Beispiel‑Record:

    _dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100; aspf=s; adkim=s"

  • p=none — nur Monitoring (anfangs empfehlenswert).
  • p=quarantine — Mail soll in Spam verschoben werden.
  • p=reject — Mail wird abgewiesen.

    • Wichtige Tags:

  • rua (Aggregate Reports) — XML‑Reports an diese Adresse.
  • ruf (Forensic Reports) — detaillierte Einzelberichte (aufgrund von Datenschutz nicht überall empfohlen).
  • pct — Prozentsatz der Mails, auf die die Richtlinie angewendet wird (nützlich beim schrittweisen Ausrollen).
  • aspf/adkim — Alignment für SPF/DKIM (strict oder relaxed).

    • Typische Schritt‑für‑Schritt‑Konfiguration

    Hier eine pragmatische Reihenfolge, wie ich es oft mache:

  • 1. Stelle sicher, dass dein Mailserver oder Provider korrekt arbeitet (Reverse DNS, Port 25 nicht geblockt).
  • 2. Lege einen SPF‑Record an, der alle versendenden Dienste einschließt.
  • 3. Richte DKIM ein: Erzeuge Schlüssel, füge den öffentlichen Schlüssel im DNS ein und aktiviere die Signatur.
  • 4. Setze DMARC auf p=none und sammle Reports (rua) für mindestens 2–4 Wochen.
  • 5. Analysiere die DMARC‑Aggregate‑Reports (Tools wie dmarcian, DMARC Analyzer oder kostenlose Parser helfen dabei).
  • 6. Sobald SPF und DKIM sauber sind, erhöhe DMARC auf quarantine oder reject, schrittweise mit pct.

    • Praktische Tipps für populäre Anbieter

    Cloudflare: Du fügst TXT‑Records über das DNS‑Panel hinzu. Achte darauf, dass Cloudflare keinen speziellen Umgang mit DKIM hat — der Record muss als TXT unverändert stehen.

    Google Workspace / Microsoft 365: Beide geben klare Anleitungen für SPF und DKIM. Bei Microsoft erzeugst du DKIM‑Schlüssel im Admin‑Center; bei Google meist über das Admin‑Tool oder deinen SMTP‑Relay.

    SendGrid / Mailgun / Postmark: Diese Dienste liefern fertige DKIM‑Record‑Strings und empfehlen, SPF entsprechend zu erweitern. Nutze ihre Setup‑Guides — sie vereinfachen die Arbeit erheblich.

    Fehlerquellen und Troubleshooting

  • Falscher DNS‑Record: Tippfehler im TXT‑Record werden oft übersehen — kopiere genau und überprüfe mit dig/nslookup.
  • Mehrere SPF‑Records: Diese brechen die Prüfung; füge alles zu einem Record zusammen.
  • DNS‑Propagation: Änderungen brauchen Zeit — warte bis zu 48 Stunden (meist schneller).
  • Fehlende Signatur: Prüfe Mail‑Header (z. B. Received‑DKIM‑Signature) und setze Debug‑Logs auf dem Mailserver.
  • DMARC‑Reports unlesbar: Nutze Parser/Viewer (z. B. Postmark DMARC‑Parser, dmarcian, oder opensource Tools).

    • Kurzvergleich: SPF vs DKIM vs DMARC

    MechanismusWas prüft er?Hauptzweck
    SPFAbsender‑IP gegen erlaubte SenderUnauthorized Mailserver blocken
    DKIMMailintegrität via SignaturMails vor Manipulation schützen
    DMARCAlignment von SPF/DKIM mit From‑DomainPolicy & Reporting

    Wie ich DMARC‑Reports analysiere

    Ich empfehle, die Aggregate‑Reports zu sammeln und mit einem Parser auszuwerten. Achte dabei auf:

  • Absender, die nicht in deinem SPF sind — das zeigt, wer noch für dich sendet.
  • DKIM‑Fehler — können auf falsche Signatur oder Header‑Änderungen durch Forwarder hinweisen.
  • Hohe Fehlerraten bei bestimmten IPs — gegebenenfalls blockieren oder beim Provider nachfragen.

    • Weiterführende Tools und Ressourcen

  • MXToolbox: Quick‑Checks für DNS, Blacklists, SPF, DKIM.
  • dmarcian / DMARC Analyzer: DMARC‑Reporting und Visualisierung.
  • MxCheck / Mail‑Tester: Tests für Mail‑Authentizität und Spam‑Score.
  • OpenSSL & opendkim tools: Für lokale Schlüsselgenerierung und Tests.

    • Wenn du möchtest, kann ich dir bei deiner Domain konkret helfen: Ich kann deine DNS‑Records prüfen, DMARC‑Reports analysieren oder ein kurzes Setup‑Skript für Postfix/OpenDKIM vorbereiten. Sag mir einfach, mit welchem Provider oder Mailserver du arbeitest — dann gehe ich Schritt für Schritt mit dir durch die nötigen Einstellungen.