DMARC: p=none beobachtet, stoppt Spoofing aber nicht

Ein DMARC-TXT-Eintrag mit p=none und rua fordert laut RFC 9989 Sammelberichte an, aber keine andere Behandlung von Nachrichten, die DMARC nicht bestehen. Wer gefälschte Absender unter der eigenen Domain eindämmen will, muss zunächst die berechtigten Versandwege erfassen und deren SPF- oder DKIM-Authentifizierung auf die sichtbare Absenderdomain ausrichten.

Danach veröffentlichen Sie den Eintrag im DNS, werten die Berichte aus und korrigieren Fehler bei legitimen Absendern. Erst wenn diese Nachrichten zuverlässig bestehen, kommt p=quarantine oder gegebenenfalls p=reject infrage. Beide Werte teilen empfangenden Servern eine strengere Behandlung fehlgeschlagener Nachrichten mit; die Entscheidung über eine einzelne Nachricht bleibt beim Empfänger.

Versandwege vor dem DNS-Eintrag erfassen

Listen Sie alle Systeme auf, die Ihre Domain im sichtbaren From-Feld verwenden: den regulären Maildienst ebenso wie Newsletter-Plattformen, Ticketsysteme, Rechnungsversand, Anwendungen und beauftragte Dienstleister. Halten Sie für jeden Weg die sichtbare Absenderdomain, die technische Envelope-From-Domain und die Domain der DKIM-Signatur fest. Notieren Sie auch seltene Aussendungen, etwa periodische Benachrichtigungen. Sonst kann ein unauffälliger Berichtstag den Eindruck erwecken, alle berechtigten Absender seien bereits berücksichtigt.

Richten Sie SPF für die autorisierten Versandsysteme und DKIM bei den genutzten Diensten ein. Die DMARC-Anleitung von Google Workspace empfiehlt, SPF und DKIM vor DMARC einzurichten und ausgehende Nachrichten damit mindestens 48 Stunden zu authentifizieren. Prüfen Sie bei Drittanbietern, welche Domains sie tatsächlich für den technischen Absender und die Signatur verwenden. Ein Dienst kann berechtigt sein, E-Mails zu verschicken, ohne dass seine voreingestellten Domains bereits zu Ihrer sichtbaren Absenderdomain passen.

SPF und DKIM mit dem From-Feld abgleichen

Für einen DMARC-Erfolg reicht ein bloßes SPF-„pass“ nicht. SPF authentifiziert die Domain des technischen SMTP-Absenders; DMARC vergleicht diesen Bezeichner mit der Domain im sichtbaren From-Feld. Alternativ genügt eine gültige DKIM-Signatur, deren Signaturdomain passend ausgerichtet ist. Mindestens einer der beiden Wege muss sowohl die Authentifizierung als auch diesen Domain-Abgleich bestehen. Bei gelockerter Ausrichtung können Domains mit derselben organisatorischen Domain zusammenpassen; strikte Ausrichtung verlangt eine identische Domain.

Ein hypothetisches Beispiel: Im From-Feld steht [email protected], während SPF nur für versand-fremddienst.example besteht und keine passende DKIM-Signatur vorliegt. SPF meldet dann zwar „pass“, DMARC aber „fail“. Signiert der Dienst dieselbe Nachricht gültig mit d=example.org, kann DKIM den erforderlichen Abgleich liefern. Sehen Sie deshalb bei einer Testnachricht nicht nur auf das Ergebnis, sondern auch auf die zugehörige SPF- beziehungsweise DKIM-Domain. Bei externen Diensten lässt sich so erkennen, ob deren Konfiguration für Ihren Absender tatsächlich geeignet ist.

Den Beobachtungseintrag veröffentlichen

Für die hypothetische Domain example.org lautet ein möglicher DNS-TXT-Eintrag am Namen _dmarc.example.org: „v=DMARC1; p=none; rua=mailto:[email protected]“. „v“ bezeichnet die Protokollversion, „p“ die angeforderte Behandlung bei einem DMARC-Fehler und „rua“ das Ziel für zusammengefasste Berichte. Das angegebene Postfach muss Nachrichten empfangen können; für die regelmäßige Auswertung braucht es außerdem eine geeignete Verarbeitung der Berichte.

Prüfen Sie vor dem Veröffentlichen, ob am selben DNS-Namen bereits ein DMARC-Richtlinieneintrag existiert, und aktualisieren Sie ihn gegebenenfalls. Mehrere solche Einträge am selben Namen verhindern eine eindeutige Richtlinienermittlung. Fragen Sie anschließend den öffentlich sichtbaren TXT-Eintrag ab und vergleichen Sie Name und Inhalt mit der beabsichtigten Konfiguration. Soll rua auf eine Adresse unter einer anderen Domain zeigen, muss diese Berichtsdomain den Empfang dafür zusätzlich autorisieren.

Berichte den bekannten Absendern zuordnen

Die Sammelberichte zeigen, welche sendenden Quellen empfangende Server gesehen haben und wie SPF, DKIM und DMARC dort ausgefallen sind. Vergleichen Sie diese Quellen mit Ihrem Inventar. Eine unbekannte Quelle kann ein Spoofing-Versuch sein, aber ebenso eine übersehene Anwendung. Die Berichte allein belegen nicht, wer den Versand veranlasst hat; zusammen mit den bekannten Versandwegen machen sie Fehlkonfigurationen jedoch gezielt auffindbar.

Bei berechtigten Quellen beheben Sie die konkrete Ursache: eine fehlende SPF-Autorisierung, eine ungültige DKIM-Signatur oder eine authentifizierte Domain ohne Alignment. Beobachten Sie nach der Korrektur erneut die Ergebnisse und die Zustellung. Berücksichtigen Sie dabei auch Kampagnen und Systemnachrichten, die nur gelegentlich versendet werden. Sammelberichte sind für maschinelle Auswertung gedacht; bei vielen Quellen ist ein Parser oder Berichtsservice zweckmäßiger als das Öffnen einzelner Dateien.

Subdomains prüfen und die Richtlinie verschärfen

Erfassen Sie auch Subdomains, die im sichtbaren From-Feld stehen. Ein eigener DMARC-Eintrag für eine solche Subdomain hat bei ihrer Richtlinienermittlung Vorrang. Fehlt er, gilt grundsätzlich die Richtlinie der organisatorischen Domain; mit „sp“ lässt sich für bestehende Subdomains eine abweichende Behandlung festlegen. Prüfen Sie deshalb vor einer Änderung an der Hauptdomain sowohl aktiv genutzte Versand-Subdomains als auch ungenutzte Namen, unter denen gefälschte Absender auftreten könnten.

Wenn die bekannten legitimen Versandwege DMARC bestehen und verbleibende Fehler geklärt sind, können Sie p=quarantine setzen und die Wirkung weiter beobachten. p=reject ist besonders bei Domains für allgemeine Korrespondenz sorgfältig abzuwägen: Weiterleitungen und Mailinglisten können SPF scheitern lassen oder DKIM-Signaturen verändern. Wer p=reject verwendet, sollte sich deshalb nicht allein auf SPF verlassen und gültige DKIM-Signaturen einsetzen. Ein empfangender Server kann trotz veröffentlichter Richtlinie aufgrund weiterer Informationen anders entscheiden.

Übernehmen Sie aus älteren Einrichtungsbeispielen keine schrittweise Steuerung über „pct“. Im DMARC-Tag-Verzeichnis der IANA ist „pct“ als historisch gekennzeichnet. Die risikoarme Umstellung erfolgt über die Korrektur der Versandwege, die Beobachtung ihrer Ergebnisse und eine bewusst gewählte Richtlinie für jede betroffene Domain.

Lesen Sie auch: