Inhaltsverzeichnis

1. Zielbild in 30 Minuten
2. 1) Vorbereitung
3. 2) Record-Start (p=none)
4. 3) Provider-Umsetzung
5. 4) Eskalationspfad
6. 5) Verifikation
7. Mitigation Series (Week 1–4)
8. Tool-/Provider-abhängige Erläuterungen

---

Zielbild in 30 Minuten

Wenn SPF/DKIM bereits stehen, kann DMARC schnell von p=none in einen kontrollierten Enforcement-Pfad überführt werden.

---

1) Vorbereitung

1. Absender-Systeme erfassen (Google Workspace, M365, CRM, Newsletter).
2. Prüfen, dass SPF und DKIM für alle legitimen Sender funktionieren.
3. Reporting-Mailbox für DMARC-Reports bereitstellen.

---

2) Record-Start (p=none)

Host: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1; adkim=s; aspf=s; pct=100

24-72h beobachten: legitime und illegitime Flows trennen.

---

3) Provider-Umsetzung

Cloudflare

1. DNS-Zone öffnen → Add record.
2. TXT für _dmarc setzen.
3. TTL auf Auto oder 300, speichern, mit dig TXT _dmarc.example.com prüfen.

IONOS

1. Domain-Center → DNS-Verwaltung.
2. TXT für Host _dmarc eintragen.
3. Nach Propagation Header-Test mit realen Mails durchführen.

Microsoft 365

1. Domain-Setup in M365 kontrollieren (DKIM aktiv).
2. DMARC-Record im externen DNS setzen.
3. Reports gegen Defender/Message Trace querprüfen.

---

4) Eskalationspfad

1. Woche 1-2: p=none
2. Woche 3-4: p=quarantine
3. ab stabiler Zustellung: p=reject

---

5) Verifikation

• SPF = pass
• DKIM = pass
• DMARC = pass/aligned
• Fehlende legitime Sender in Reports sichtbar und nachgezogen

Damit sinkt das Risiko für glaubwürdiges Domain-Spoofing signifikant.

---

Mitigation Series (Week 1–4)

Bearbeite die Guides in dieser Reihenfolge, um schnell Wirkung zu erzielen:

• Week 1: DMARC Schritt für Schritt: Cloudflare, IONOS und M365 in der Praxis (du bist hier)
• Week 2: SPF richtig setzen: Provider-Blueprint für Cloudflare, IONOS und Google Workspace
• Week 3: Passwort-Rotation und MFA-Erzwingung nach Breach: 60-Minuten Playbook
• Week 4: Handle-Hygiene im Security-Kontext: Re-Identifikation über Social-Korrelation reduzieren
• Week 5: Account-Forensics nach Verdacht: Login-Historie, OAuth-Apps und Recovery-Drift prüfen
• Week 6: MX-Routing sauber absichern: IONOS, Cloudflare DNS und M365/Workspace Abgleich
• Week 7: CT- und Subdomain-Cleanup: Schatten-Assets über Zertifikatstransparenz abbauen
• Week 8: Open-Web-PII reduzieren: Suchtreffer bereinigen ohne Lösch-Illusionen
• Week 9: Kontinuierliches Exposure-Monitoring: Monatsroutine mit klaren Ownern

Sofort umsetzen: Digital Footprint Analyzer öffnen

---

Tool-/Provider-abhängige Erläuterungen

Google Mail (Gmail / Google Workspace)

• Wofür relevant? SPF, DKIM, DMARC, Login-Sicherheit, App-Zugriffe.
• Wie arbeitet es? Mail-Authentifizierung läuft primär über DNS (SPF, DKIM, DMARC), Kontoschutz über MFA/Passkeys und Security-Events.
• Worauf achten?
  1. SPF mit include:_spf.google.com konsistent halten.
  2. DKIM im Admin-Portal aktivieren und Selector im DNS prüfen.
  3. DMARC zunächst mit p=none, danach stufenweise härten.
• 3 häufige Fehler:
  1. Mehrere SPF-Records gleichzeitig publizieren.
  2. DKIM im Admin-Panel aktiviert, aber DNS-Selector fehlt/ist veraltet.
  3. DMARC zu früh auf reject, bevor alle legitimen Sender aligned sind.

Outlook (Microsoft 365)

• Wofür relevant? SPF, DKIM, DMARC, Sign-In-Risiken, OAuth-App-Governance.
• Wie arbeitet es? Zustellung und Trust basieren auf DNS-Authentifizierung; Zugriffskontrolle über Entra/Conditional Access und MFA.
• Worauf achten?
  1. SPF-Record um spf.protection.outlook.com ergänzen.
  2. DKIM in M365 aktivieren und DNS-CNAMEs sauber pflegen.
  3. Risky Sign-Ins/OAuth-Apps regelmäßig prüfen und unnötige Grants widerrufen.
• 3 häufige Fehler:
  1. SPF enthält M365 nicht oder enthält veraltete Drittanbieter-Include-Ziele.
  2. DKIM-CNAME zeigt auf falschen Tenant/Selector.
  3. Alte OAuth-App-Consents bleiben aktiv und werden nie rezertifiziert.

IONOS (Domain/DNS/Mail)

• Wofür relevant? DNS-Verwaltung, MX-Routing, SPF/DMARC Records.
• Wie arbeitet es? IONOS ist oft der autoritative DNS-Punkt; dort gesetzte Records entscheiden über Mail-Routing und Authentifizierung.
• Worauf achten?
  1. Keine doppelten SPF-TXT-Records.
  2. MX-Prioritäten auf den tatsächlich genutzten Maildienst abstimmen.
  3. DMARC/SPF-Änderungen nach Propagation per Header-Tests verifizieren.
• 3 häufige Fehler:
  1. Historische MX-Einträge bleiben nach Providerwechsel aktiv.
  2. SPF wird als zweiter TXT-Record statt als konsolidierter Record angelegt.
  3. Tests direkt nach Änderung ohne DNS-Propagation-Check.

Cloudflare (DNS/Edge)

• Wofür relevant? DNS-Records, schnelle Änderungen, Sichtbarkeit externer Assets.
• Wie arbeitet es? Als DNS/Proxy-Layer beeinflusst Cloudflare direkt SPF/DMARC/MX-Einträge und damit Mail-/Exposure-Verhalten.
• Worauf achten?
  1. DNS-Einträge im autoritativen Zone-View prüfen (nicht nur in Doku-Stand).
  2. Alte CNAME/A/MX-Einträge bereinigen, um Shadow-Assets zu vermeiden.
  3. Nach jeder Änderung Re-Scan im Analyzer für Vorher/Nachher-Vergleich.
• 3 häufige Fehler:
  1. Alt-DNS (z. B. alte CNAMEs) bleibt aktiv und erzeugt unnötige Angriffsfläche.
  2. MX-/TXT-Änderungen werden nicht gegen live aufgelöste Werte verifiziert.
  3. DNS-Änderung ohne Dokumentation/Change-Historie erschwert Incident-Analyse.

Kurz-Mapping: Welche Maßnahme betrifft welchen Provider?

• SPF/DMARC-Probleme: Google Mail, Outlook, IONOS, Cloudflare (DNS).
• MX-Routing-Probleme: IONOS/Cloudflare (DNS) + tatsächlicher Mail-Provider (Google/Microsoft).
• Account-Forensics/MFA: Google-/Microsoft-Konten sowie verbundene OAuth-Apps.
• CT/Subdomain-Cleanup: vor allem DNS-/Edge-Provider wie Cloudflare und Domainverwaltung bei IONOS.