Der Anruf wegen der Rechnung
Ein Kunde ruft an und fragt, warum Sie ihm eine Rechnung mit geänderter Bankverbindung geschickt haben. Sie haben nichts geschickt. Die Mail trug Ihren Firmennamen als Absender, Ihre Schreibweise, Ihre Signatur, und der Kunde hatte keine technische Möglichkeit, das zu erkennen.
Dieser Fall braucht keinen Einbruch in Ihre Systeme. Er braucht nur eine fehlende Zeile im öffentlichen Verzeichnis Ihrer Domain.
Was Ihre Domain über sich verrät
Zu jeder Domain sind Einträge hinterlegt, die jeder abrufen kann. Drei von ihnen entscheiden darüber, ob Fremde in Ihrem Namen senden können:
Die drei greifen ineinander. SPF und DKIM liefern die Prüfmerkmale, DMARC sagt, was mit einem negativen Prüfergebnis geschehen soll. Ohne DMARC bleiben SPF und DKIM eine Messung ohne Konsequenz.
| Eintrag | Beantwortet die Frage | Fehlt er, dann |
|---|---|---|
| SPF | Welche Server dürfen für diese Domain senden? | Empfänger können nicht prüfen, ob eine Mail von Ihnen stammt |
| DKIM | Ist die Mail unterwegs unverändert geblieben und wirklich signiert? | Die Herkunft lässt sich nicht bestätigen |
| DMARC | Was soll ein Empfänger mit einer Mail tun, die die Prüfung nicht besteht? | Nichts. Die gefälschte Mail wird zugestellt |
Der Punkt, der in der Praxis übersehen wird
Viele Domains haben einen DMARC-Eintrag, aber auf der Stufe p=none. Das bedeutet: meldet mir Fälschungen, tut aber nichts dagegen. Die gefälschte Mail wird weiterhin zugestellt.
p=none ist als Einstieg richtig. Man beobachtet einige Wochen, welche Systeme im Namen der eigenen Domain senden (Newsletterdienst, Buchhaltungssoftware, Ticketsystem, das Kopiergerät im Flur), korrigiert SPF und DKIM entsprechend und hebt dann an:
p=none beobachten, nichts blockieren p=quarantine auffällige Mails in den Spamordner p=reject auffällige Mails ablehnen
Wer bei p=none stehenbleibt, hat den Eintrag, aber nicht den Schutz.
Wie Sie es selbst prüfen
Sie brauchen dafür keinen Dienstleister und keine Software. Unter Windows genügt die Eingabeaufforderung:
nslookup -type=TXT _dmarc.ihre-domain.de nslookup -type=TXT ihre-domain.de
Der erste Aufruf zeigt Ihren DMARC-Eintrag, der zweite unter anderem den SPF-Eintrag. Kommt beim ersten Aufruf keine Antwort mit v=DMARC1, ist kein DMARC hinterlegt. Steht dort p=none, gilt der Absatz oben.
Bei DKIM ist die Prüfung von außen unzuverlässig, weil der Name des Schlüssels frei wählbar ist. Microsoft 365 verwendet üblicherweise selector1 und selector2; ein eigener Name bleibt bei einer Prüfung von außen unentdeckt. Im Zweifel prüft man es im Mailsystem selbst, nicht per Abfrage.
Was das im Betrieb bedeutet
Der Schaden hat drei Richtungen, und die zweite wird meist unterschätzt.
Nach außen: Rechnungen mit geänderter Bankverbindung, Bestellungen bei Ihren Lieferanten, Nachrichten an Ihre Kunden, jeweils mit Ihrem Namen als Absender. Der Ruf, der dabei beschädigt wird, ist Ihrer.
Nach innen: Ohne saubere SPF- und DKIM-Einträge landen Ihre eigenen Mails häufiger im Spamordner Ihrer Kunden. Ein Angebot, das nicht ankommt, sieht aus wie ein Angebot, das nicht interessiert hat.
Regulatorisch: Google und Microsoft verlangen SPF, DKIM und DMARC von Absendern mit hohem Volumen. Die Schwelle liegt bei rund 5.000 Nachrichten pro Tag. Für einen Betrieb mit fünfzig Arbeitsplätzen ist das keine Pflicht. Es zeigt aber, woran große Anbieter Zustellwürdigkeit messen, und das gilt auch unterhalb der Schwelle.
Der Aufwand
Für eine überschaubare Umgebung mit einem Mailsystem und wenigen versendenden Diensten:
Der technische Teil ist klein. Die Bestandsaufnahme ist der Teil, der Sorgfalt braucht: Wer eine SPF-Regel setzt, ohne alle versendenden Systeme zu kennen, blockiert seine eigenen Rechnungsmails. Deshalb die Beobachtungsphase, und deshalb ändert man an Mail-DNS-Einträgen nichts ohne vorherige Prüfung.
| Schritt | Aufwand |
|---|---|
| Bestand aufnehmen: welche Systeme senden in Ihrem Namen? | halber Tag, meist der aufwendigste Teil |
| SPF-Eintrag setzen oder korrigieren | eine DNS-Änderung |
| DKIM im Mailsystem aktivieren | Aktivierung plus zwei DNS-Verweise |
| DMARC auf p=none setzen und Berichte auswerten | eine DNS-Änderung, dann zwei bis vier Wochen beobachten |
| Anheben auf p=quarantine, später p=reject | je eine DNS-Änderung |
Was DMARC nicht leistet
DMARC verhindert, dass Fremde Ihre Domain als Absender verwenden. Es verhindert nicht:
Wer DMARC als Rundumschutz darstellt, verspricht zu viel. Es schließt eine bestimmte, weit offene Tür, und zwar mit geringem Aufwand.
- Mails von ähnlich aussehenden Domains, etwa mit vertauschten Buchstaben
- Mails mit gefälschtem Anzeigenamen von einer beliebigen Fremdadresse
- Phishing, das auf ein anderes Unternehmen zielt
- kompromittierte Konten im eigenen Haus, denn dort ist der Absender echt
Häufige Fragen
Brauche ich DMARC, wenn wir kaum E-Mails versenden? Der Schutz wirkt nicht beim Senden, sondern beim Empfänger. Er ist unabhängig davon, wie viel Sie selbst versenden. Auch eine Domain, von der nie eine Mail ausgeht, kann als Absender missbraucht werden.
Wir sind bei Microsoft 365. Ist das nicht automatisch dabei? SPF wird bei der Einrichtung üblicherweise gesetzt. DKIM ist zu aktivieren, DMARC ist ein eigener Eintrag, der nicht automatisch entsteht.
Kann ich direkt auf p=reject gehen? Technisch ja. In der Praxis blockiert man damit häufig eigene Systeme, die man nicht auf der Rechnung hatte. Die Beobachtungsphase kostet ein paar Wochen und erspart einen Ausfall im Rechnungsversand.
Wie merke ich, dass es wirkt? Über die DMARC-Berichte, die empfangende Systeme an eine von Ihnen angegebene Adresse senden. Sie zeigen, welche Server in Ihrem Namen senden und wie die Prüfung ausging.
Wenn Sie wissen möchten, wie Ihre Domain dasteht
Wir prüfen SPF, DKIM, DMARC, die Laufzeit Ihres TLS-Zertifikats und die Sicherheitskopfzeilen Ihrer Website, ausschließlich anhand öffentlich abrufbarer Angaben. Sie erhalten ein Blatt mit Befund, Bedeutung im Geschäftsbetrieb und Aufwand zur Behebung.
Und wenn Sie ohnehin wissen wollen, wie Ihre IT insgesamt dasteht: Unsere Infrastrukturanalyse ist kostenlos und unverbindlich. Wir prüfen Ihre gesamte IT-Infrastruktur und dokumentieren diese.
VIRMAS Systemtechnik GmbH ist ein IT-Systemhaus für Geschäftskunden in Neuenhagen bei Berlin; wir betreuen Unternehmen in Berlin und Brandenburg, mit einem festen Ansprechpartner statt einer anonymen Hotline.
Quellen
DMARC: RFC 7489, Domain-based Message Authentication, Reporting, and Conformance · SPF: RFC 7208, Sender Policy Framework for Authorizing Use of Domains in Email · DKIM: RFC 6376, DomainKeys Identified Mail Signatures · Google: Richtlinien für E-Mail-Absender · Microsoft: Funktionsweise der E-Mail-Authentifizierung in Microsoft 365 · Microsoft: Outlook, Anforderungen für Absender mit hohem Volumen
- DMARC: RFC 7489, Domain-based Message Authentication, Reporting, and Conformance
- SPF: RFC 7208, Sender Policy Framework for Authorizing Use of Domains in Email
- DKIM: RFC 6376, DomainKeys Identified Mail Signatures
- Google: Richtlinien für E-Mail-Absender
- Microsoft: Funktionsweise der E-Mail-Authentifizierung in Microsoft 365
- Microsoft: Outlook, Anforderungen für Absender mit hohem Volumen