Zum Inhalt springen

Services, Wiki-Artikel, Blog-Beiträge und Glossar-Einträge durchsuchen

↑↓NavigierenEnterÖffnenESCSchließen
DMARC Implementierung: Schritt-für-Schritt von p=none zu p=reject - Cybersicherheit und digitaler Schutz
Netzwerk- & Endpoint Security

DMARC Implementierung: Schritt-für-Schritt von p=none zu p=reject

DMARC (Domain-based Message Authentication, Reporting and Conformance) schützt Ihre Domain vor E-Mail-Spoofing und Phishing. Dieser Guide führt durch den gesamten DMARC-Rollout: SPF und DKIM als Voraussetzungen, DMARC-Record konfigurieren, Reporting-Analyse mit Forensic und Aggregate Reports, schrittweise Richtlinien-Verschärfung von p=none über p=quarantine zu p=reject. Inklusive häufiger Fallstricke und DMARC-Monitoring-Tools.

Vincent Heinen Vincent Heinen Abteilungsleiter Offensive Services
10 Min. Lesezeit
OSCP+ OSCP OSWP OSWA

TL;DR

DMARC schützt Ihre Domain effektiv

Diese Zusammenfassung wurde KI-gestützt erstellt (EU AI Act Art. 52).

Inhaltsverzeichnis (8 Abschnitte)

E-Mail-Spoofing - das Versenden von E-Mails mit gefälschtem Absender - ist eine der häufigsten Techniken bei Phishing-Angriffen und CEO-Fraud. DMARC (Domain-based Message Authentication, Reporting and Conformance) schließt diese Lücke, indem es E-Mail-Empfängern mitteilt, wie mit Nachrichten umzugehen ist, die die Authentifizierung nicht bestehen. Die Implementierung erfordert Sorgfalt - ein falsch konfiguriertes DMARC-Record mit p=reject kann legitime E-Mails blockieren.

Warum DMARC unverzichtbar ist

Problem ohne DMARC:

  Angreifer sendet:
  From: ceo@unternehmen.de
  → Kein SPF, kein DKIM → empfangende Server akzeptieren trotzdem!
  → Mitarbeiter sieht legitimen Absender → klickt auf Link → Angriff!

  2024-Statistiken:
  → 3,4 Milliarden Phishing-E-Mails täglich
  → 94% aller Malware-Angriffe starten mit einer E-Mail
  → CEO-Fraud-Schäden: >26 Mrd. USD weltweit (seit 2013)

DMARC-Schutz:
  Mit DMARC p=reject:
  → E-Mail ohne SPF/DKIM-Alignment → sofort abgelehnt!
  → Angreifer kann Ihre Domain nicht mehr missbrauchen (technisch!)
  → Kein DMARC-konformes Spoofing möglich

DMARC-Voraussetzungen:
  □ SPF-Record für alle sendenden Domains
  □ DKIM-Signierung für alle ausgehenden E-Mails
  □ DMARC funktioniert NUR wenn SPF oder DKIM konfiguriert ist!

Schritt 1: SPF korrekt konfigurieren

SPF (Sender Policy Framework) - Voraussetzung #1:

SPF-Record erstellt in DNS (TXT-Record für die Domain):
  v=spf1 [mechanisms] [qualifier]

Qualifier:
  + (Pass, Default): IP ist autorisiert zu senden
  - (Fail):          IP ist NICHT autorisiert → ablehnen
  ~ (SoftFail):      Nicht autorisiert, aber nur markieren (für Migration)
  ? (Neutral):       Keine Aussage

Mechanisms:
  include:mxserver.example.com   → SPF der anderen Domain einbinden
  ip4:203.0.113.0/24             → IPv4-Range erlauben
  ip6:2001:db8::/32              → IPv6-Range erlauben
  mx                             → MX-Server der Domain erlauben
  a                              → A-Record der Domain erlauben
  all                            → Alles (als letztes Element!)

Typische SPF-Records:

  # Nur Google Workspace + eigene IP:
  v=spf1 include:_spf.google.com ip4:203.0.113.1 -all

  # Microsoft 365 + Mailchimp + eigene IP:
  v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net ip4:203.0.113.1 -all

  # Mehrere E-Mail-Dienste:
  v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org ip4:203.0.113.1 -all

SPF-Fallstricke:
  → Maximum 10 DNS-Lookups! (include: zählt, jede Subdomain-Auflösung zählt)
  → Mehr als 10 → SPF "PermError" → DMARC schlägt fehl!
  → Lösung: SPF-Flattening-Dienste (konvertieren includes in IPs)

  # SPF testen:
  dig TXT example.com | grep spf
  # Tool: MXToolbox SPF Check, DMARC Analyzer

Schritt 2: DKIM konfigurieren

DKIM (DomainKeys Identified Mail) - Voraussetzung #2:

DKIM-Funktionsprinzip:
  Ausgehende E-Mail: Header wird mit privatem Schlüssel signiert
  Empfänger prüft: Signatur mit öffentlichem Schlüssel (aus DNS)

DNS-Record (TXT-Record für Selector._domainkey.example.com):
  mail._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
  # "mail" = Selektor (kann variieren, z.B. "google", "mg" für Mailgun)

DKIM für verschiedene E-Mail-Provider:

  Google Workspace:
  → Admin Console → Apps → Gmail → Authentifizierung
  → DKIM aktivieren → DNS-Record aus der Konsole kopieren
  → Selektor: "google"

  Microsoft 365:
  → Security.microsoft.com → E-Mail-Authentifizierung → DKIM
  → DKIM für Domain aktivieren → CNAME-Records erstellen
  → Selektor: "selector1", "selector2"

  Postfix (eigener Mailserver):
  # OpenDKIM installieren:
  apt install opendkim opendkim-tools
  # Schlüsselpaar generieren:
  mkdir -p /etc/opendkim/keys/example.com
  opendkim-genkey -s mail -d example.com
  # Öffentlichen Schlüssel in DNS eintragen
  cat /etc/opendkim/keys/example.com/mail.txt

  # /etc/opendkim.conf:
  Domain                  example.com
  KeyFile                 /etc/opendkim/keys/example.com/mail.private
  Selector                mail

DKIM Key-Rotation:
  → 1024-Bit RSA: veraltet, auf 2048 Bit wechseln!
  → Jährliche Rotation empfohlen
  → Mehrere Selektoren gleichzeitig aktiv halten (während Rotation)
  → "selector2" aktivieren → alt abmelden → "selector1" deaktivieren

DKIM verifizieren:
  dig TXT mail._domainkey.example.com
  # Tool: MXToolbox DKIM Lookup

Schritt 3: DMARC-Record erstellen

DMARC-Record - DNS-TXT-Record für _dmarc.example.com:

Minimaler DMARC-Record (Monitoring-Modus):
  v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Vollständiger DMARC-Record:
  v=DMARC1;
  p=quarantine;           # Policy: none / quarantine / reject
  pct=25;                 # Prozent der Mails auf die Policy angewendet wird
  sp=none;                # Subdomain-Policy (default: p-Wert)
  adkim=r;                # DKIM-Alignment: r=relaxed, s=strict
  aspf=r;                 # SPF-Alignment: r=relaxed, s=strict
  rua=mailto:dmarc@example.com;  # Aggregate Reports
  ruf=mailto:forensic@example.com;  # Forensic Reports (optional)
  fo=1;                   # Forensic: 0=beide, 1=eines schlägt fehl, d/s=DKIM/SPF

Alignment erklärt:
  relaxed (r): Org-Domain muss matchen (mail.example.com → example.com ✓)
  strict (s):  Exakte Domain muss matchen (mail.example.com → example.com ✗)

DMARC-Policy-Werte:
  p=none:       Keine Aktion (nur Reporting!) → Startzustand
  p=quarantine: DMARC-Fail → Spam-Ordner oder weich ablehnen
  p=reject:     DMARC-Fail → sofort ablehnen → stärkstes Schutzniveau!

DNS-Record setzen:
  # DNS-Eintrag (bei eurem DNS-Provider):
  Name:  _dmarc.example.com
  Typ:   TXT
  Wert:  v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

  # Verifizieren:
  dig TXT _dmarc.example.com

Schritt 4: DMARC-Reports analysieren

Aggregate Reports (rua) verstehen:

Reports werden täglich von empfangenden Mailservern gesendet:
  → XML-Format (von Google, Microsoft, Yahoo, etc.)
  → Enthält: IP-Adresse, Anzahl der E-Mails, SPF/DKIM-Ergebnis, DMARC-Policy

XML-Struktur (vereinfacht):
  <feedback>
    <report_metadata>
      <org_name>Google Inc.</org_name>
      <date_range><begin>1709251200</begin><end>1709337600</end></date_range>
    </report_metadata>
    <policy_published>
      <domain>example.com</domain>
      <p>none</p>
    </policy_published>
    <record>
      <row>
        <source_ip>209.85.220.41</source_ip>  <!-- Google IP -->
        <count>450</count>
        <policy_evaluated>
          <disposition>none</disposition>
          <dkim>pass</dkim>  <!-- DKIM-Ergebnis -->
          <spf>pass</spf>    <!-- SPF-Ergebnis -->
        </policy_evaluated>
      </row>
      <row>
        <source_ip>198.51.100.42</source_ip>  <!-- Unbekannte IP! -->
        <count>3</count>
        <policy_evaluated>
          <disposition>none</disposition>
          <dkim>fail</dkim>
          <spf>fail</spf>  <!-- Kein SPF für diese IP! -->
        </policy_evaluated>
      </row>
    </record>
  </feedback>

→ 450 Mails von Google: SPF+DKIM pass → legitimER Versand ✓
→ 3 Mails von 198.51.100.42: FAIL → Spoofing oder vergessener Mailsender!

DMARC-Reporting-Dienste (XML-Auswertung):
  → Kostenlos: Postmark DMARC (dmarcdigests.com), Google Postmaster Tools
  → Günstig: DMARC Analyzer, Valimail Monitor
  → Professionell: Agari, Red Sift OnDMARC
  → Self-Hosted: parsedmarc + Elasticsearch/Kibana

Schritt 5: Rollout-Strategie

DMARC-Rollout: Von none zu reject (empfohlener Zeitplan):

Woche 1-4: Monitoring-Phase (p=none)
  _dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

  Aktionen:
  □ Alle Aggregate Reports sammeln und analysieren
  □ Alle sendenden Systeme identifizieren (Marketing, CRM, Monitoring, etc.)
  □ SPF für alle Sender korrekt eintragen
  □ DKIM für alle Sender aktivieren
  □ Ziel: 100% DMARC-Pass für legitime E-Mails

Woche 5-8: Quarantine 25% (erste Enforcement)
  _dmarc.example.com TXT "v=DMARC1; p=quarantine; pct=25; rua=..."
  → 25% der DMARC-Fail-Mails → Spam-Ordner (Angreifer-Traffic)
  → 75% der DMARC-Fail-Mails: noch keine Aktion
  → Weiter Reports analysieren: kommen legitime Fails vor?

Woche 9-12: Quarantine 75%
  _dmarc.example.com TXT "v=DMARC1; p=quarantine; pct=75; rua=..."
  → 75% der Angreifer-E-Mails → Spam

Woche 13-16: Quarantine 100%
  _dmarc.example.com TXT "v=DMARC1; p=quarantine; pct=100; rua=..."
  → Alle DMARC-Fail → Spam

Woche 17+: Reject (Vollschutz)
  _dmarc.example.com TXT "v=DMARC1; p=reject; rua=..."
  → DMARC-Fail → sofort abgelehnt → Spoofing unmöglich!

Häufige Fehler beim Rollout:
  → Zu schnell zu reject: vergessener Sender → legitime Mails abgelehnt!
  → SPF-Lookup-Limit überschritten (>10 DNS-Lookups)
  → DKIM für Mailing-Listen (Listen-Umschreiben bricht DKIM-Signatur)
  → Subdomains vergessen: marketing.example.com sendet ohne DMARC-Alignment

Subdomains und Multi-Domain-Szenarien

Subdomain-Handling:

Standard: DMARC-Policy gilt NUR für die angegebene Domain
  _dmarc.example.com → gilt für example.com E-Mails
  → Subdomains (mail.example.com) erben die Policy

Explizite Subdomain-Policy (sp=):
  v=DMARC1; p=reject; sp=none;
  → Hauptdomain: reject
  → Subdomains: none (kein Durchsetzen)
  → Sinnvoll wenn Subdomains noch konfiguriert werden!

Separate DMARC-Records für Subdomains:
  _dmarc.mail.example.com TXT "v=DMARC1; p=reject; ..."
  → Überschreibt geerbte Policy

Multi-Domain-Szenarien:
  example.com (Hauptdomain):        DMARC p=reject
  example.de (Deutschland-Domain):  eigener DMARC-Record!
  example-test.com (Testdomain):    DMARC p=reject + SPF "-all" ohne IPs
                                    → Niemand kann von dieser Domain senden!

Parked/Inactive Domains:
  # Domains die nicht senden: DMARC + SPF konfigurieren um Missbrauch zu verhindern!
  _dmarc.oldomain.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
  oldomain.com TXT "v=spf1 -all"   # Niemand darf senden
  # DKIM: kein Key → schlägt automatisch fehl (ok, da SPF auch fail)

DMARC-Monitoring-Tools

Kostenlose und günstige DMARC-Monitoring-Lösungen:

Kostenlose Tools:
  parsedmarc (Open Source Python):
  → Liest Reports aus IMAP-Postfach
  → Speichert in Elasticsearch oder CSV
  → Dashboard in Kibana oder Grafana
    pip install parsedmarc
    parsedmarc -c parsedmarc.ini [email.xml]

  Google Postmaster Tools:
    → postmaster.google.com
    → Zeigt Zustellrate, DMARC-Compliance, Reputation für Google-Empfänger
    → Kostenlos, aber nur Google-Traffic

  MXToolbox DMARC Report Analyzer:
    → mxtoolbox.com/dmarc
    → DMARC-Record + SPF + DKIM prüfen

Kostengünstige SaaS-Lösungen:
  DMARC Analyzer (Mailhardener): ab 25€/Monat
  EasyDMARC:                     ab 0$ (Freemium)
  Valimail Monitor:              ab 0$ (Freemium)
  dmarcian:                      ab 249$/Jahr

Wichtige KPIs für DMARC-Monitoring:
  □ DMARC-Pass-Rate: Ziel >98% (für alle legitimen Sender)
  □ Fail-Rate: senkt sich nach Rollout (Spoofing-Traffic)
  □ Sources: alle legitimEN Sender mit Pass-Rate 100%?
  □ Abuse-Reports (ruf): welche IPs spoofen die Domain?

Nächster Schritt

Unsere zertifizierten Sicherheitsexperten beraten Sie zu den Themen aus diesem Artikel — unverbindlich und kostenlos.

Kostenlos · 30 Minuten · Unverbindlich

Artikel teilen

Über den Autor

Vincent Heinen
Vincent Heinen

Abteilungsleiter Offensive Services

M.Sc. IT-Sicherheit mit über 5 Jahren Erfahrung in offensiver Sicherheitsanalyse. Leitet die Durchführung von Penetrationstests mit Spezialisierung auf Web-Applikationen, Netzwerk-Infrastruktur, Reverse Engineering und Hardware-Sicherheit. Verantwortlich für mehrere Responsible Disclosures.

OSCP+ OSCP OSWP OSWA
Zertifiziert ISO 27001ISO 9001AZAVBSI

Cookielose Analyse via Matomo (selbst gehostet, kein Tracking-Cookie). Datenschutzerklärung