Ein DMARC-Rollout, der deine eigene Mail nicht zerlegt

Was DMARC tatsächlich entscheidet

SPF autorisiert sendende Hosts für eine Domain; DKIM bindet eine Signatur an eine Domain. Beide können bestehen, während eine Nachricht dem Nutzer trotzdem betrügerisch deine Domain zeigt — denn keiner von beiden prüft den sichtbaren From-Header. Genau das tut DMARC: Es verlangt einen aligned Pass — SPF oder DKIM erfolgreich für dieselbe Domain, die der Nutzer sieht — und sagt Empfängern, was bei fehlgeschlagenem Alignment geschehen soll: nichts (p=none), Quarantäne oder Reject.

Diese Policy ist ein Versprechen über sämtliche Mail, die deinen Namen trägt — inklusive jedes Newsletter-Tools, CRM-Systems, Ticketsystems und Rechnungsdienstes, den irgendeine Abteilung vor Jahren angeschlossen hat. Ein DMARC-Rollout ist deshalb vor allem eine Inventur, die sich als DNS-Record verkleidet. Der technische Teil dauert Minuten; zu wissen, wer legitim in deinem Namen sendet — das dauert die Wochen.

Fundament: SPF und DKIM vor jeder Policy

Lass das Fundament inspizieren, bevor du irgendetwas publizierst: Schicke deine Domain durch den SPF/DMARC/DKIM-Prüfer. Typische Befunde, die zuerst behoben gehören: SPF-Records über dem Limit von zehn DNS-Lookups — das produziert permerror ausgerechnet bei den Empfängern, die dir wichtig sind; mehrere SPF-Records, was schlicht ungültig ist; und DKIM-Selektoren, die im Mailfluss existieren, aber nicht im DNS.

Bevorzuge für jeden legitimen Senderdienst DKIM-Alignment vor SPF-Alignment. SPF bricht bei Weiterleitung konstruktionsbedingt — der Forwarder ist nicht dein autorisierter Host —, während eine DKIM-Signatur jeden Hop übersteht, der die Nachricht nicht verändert. Ein Dienst, der mit deiner Domain als d= signiert, gibt dir Alignment, das reist. Dienste, die nur SPF über eine geteilte Return-Path-Domain können, werden dich in den Reports verfolgen.

Stufe eins: p=none ist ein Horchposten, keine Policy

Publiziere p=none mit einer rua-Reporting-Adresse und behandle die Aggregate-Reports als das eigentliche Produkt. Sie sagen dir, Empfänger für Empfänger und Quelle für Quelle, was deinen Namen trägt und wie es sich authentifiziert. Rechne mit Überraschungen: die Zutrittsanlage, die Alarme mailt, die Regionalniederlassung mit eigenem Newsletter-Tool, der Dienstleister, der Rechnungen in deinem Namen verschickt. Jede dieser Quellen wird vor jeder Durchsetzung entweder ins Alignment geholt, auf eine Subdomain migriert oder bewusst aufgegeben.

Gib dieser Stufe echte Zeit — Wochen, nicht Tage; lang genug, um Monats- und Quartalssender zu erwischen. Das Muster, das du vermeiden willst: der selbstbewusste Freitagnachmittag-Sprung auf p=reject nach einer Woche sauberer Reports — gefolgt vom Quartals-Gehaltslauf, der am Monatsende bounct.

Verschärfen: Quarantäne, Domain-Zweck und die Forwarding-Frage

Wende nach Beobachtungsfenster und Bereinigung p=quarantine auf den vollständig bewerteten Verkehr der Domain an und beobachte die Reports weiter. RFC 9989 hat das historische Tag pct= entfernt, weil Empfänger es uneinheitlich umgesetzt haben; es ist keine aktuelle Rollout-Steuerung. Das neue t=y kann einen Testzustand signalisieren, ist aber kein prozentuales Sampling und Empfänger dürfen lokal anders behandeln.

Weitergeleitete Mail verdient eine nüchterne Entscheidung statt Angst. Forwarding bricht SPF immer und DKIM nur dann, wenn der Forwarder die Nachricht verändert — Mailinglisten mit Footern und Betreff-Tags sind der Klassiker. Empfänger, die ARC auswerten, können das ursprüngliche Authentifizierungsurteil über solche Hops retten; sieh dir das an einer echten weitergeleiteten Nachricht mit dem ARC-Chain-Validator und dem E-Mail-Header-Analyzer an. Allgemeine Benutzer-Maildomains und Domains, deren Nutzer in Mailinglisten schreiben, können unter p=reject legitime Mail verlieren.

Es gibt keine universelle Ziellinie. p=reject kann nach belastbarer Evidenz für streng kontrollierte Sendedomains oder Subdomains richtig sein; für allgemeine Maildomains mit wichtigen indirekten Flüssen kann p=quarantine der sicherere Dauerzustand sein. Lass Aggregate-Reports unter beiden Policies weiterlaufen, damit neue oder geänderte Sender vor einem Ausfall auffallen.