Rafael Pfister

Consulting

SPF, DKIM und DMARC: E-Mail-Authentifizierung bis p=reject

Die grossen Empfänger verlangen authentifizierte Mails, das eigene DMARC steht aber seit Jahren auf p=none, und niemand weiss, welche Systeme überhaupt unter der Firmendomain versenden. Ich bringe Domains kontrolliert auf eine durchsetzbare Policy: erst die vollständige Bestandsaufnahme, dann die Verschärfung in Stufen, ohne dass legitime Mails verloren gehen.

  • SPF
  • DKIM
  • DMARC
  • p=reject
  • DMARC-Reports
  • Spoofing-Schutz
  • Zustellbarkeit

Warum das mehr ist als drei DNS-Records

Die Records selbst sind schnell publiziert. Der eigentliche Aufwand steckt in der Frage, welche Systeme legitim unter der Domain versenden: das ERP, der Newsletter-Dienst, das Ticketsystem, Multifunktionsgeräte, der externe Lohnabrechner. Jede vergessene Quelle bedeutet nach der Verschärfung verlorene Mails. Deshalb beginnt jedes DMARC-Projekt bei mir mit einer Inventur der tatsächlichen Versandquellen aus DMARC-Reports und Mail-Logs, nicht mit dem Editieren der DNS-Zone.

Leistungen

  • Versandquellen-InventurAlle Systeme identifizieren, die unter Ihren Domains versenden, inklusive der vergessenen; aus Reports, Logs und Tenant-Auswertungen.
  • Record-DesignSPF ohne Lookup-Limit-Überschreitung, DKIM-Signierung pro Versandquelle, DMARC mit sinnvoller Alignment-Strategie, auch für Subdomains und geparkte Domains.
  • Stufenplan bis p=rejectVerschärfung über none, quarantine und pct-Stufen, mit Report-Auswertung vor jedem Schritt und definierten Abbruchkriterien.
  • SonderfälleWeiterleitungen, Mailinglisten, Gateways vor Microsoft 365, ARC-Sealing: die Fälle, an denen DMARC-Projekte üblicherweise scheitern.

Beispiele aus der Praxis