Inhaltsverzeichnis

1. Ziel
2. 1) Ist-Zustand erfassen
3. 2) Provider-spezifische Korrektur
4. 3) Härtung
5. Mitigation Series (Week 1–4)
6. Tool-/Provider-abhängige Erläuterungen

---

Ziel

Mailzustellung muss technisch konsistent sein, sonst entstehen Zustellfehler und Angriffsraum durch Fehlrouting.

---

1) Ist-Zustand erfassen

1. [MX](#glossary-mx)-Records und Prioritäten dokumentieren.
2. Zielhosts auf tatsächlich genutzte Mailplattform abgleichen.
3. DNS-TTL und Altlasten (alte Provider) identifizieren.

---

2) Provider-spezifische Korrektur

IONOS

• MX-Einträge im Domain-Center vereinheitlichen.
• Veraltete Backup-MX entfernen, wenn nicht gewollt.

Cloudflare DNS

• MX im autoritativen Zone-View prüfen.
• Keine widersprüchlichen Alt-Einträge parallel belassen.

Microsoft 365 / Google Workspace

• MX-Werte gegen Anbieter-Dokumentation validieren.
• Testmails intern/extern inklusive Header prüfen.

---

3) Härtung

1. SPF/DKIM/DMARC parallel konsistent halten.
2. DNS-Änderungen versioniert dokumentieren.
3. Quartalsweise Routing-Review einplanen.

---

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
• 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 (du bist hier)
• 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.