Fehler bei der Einführung von DMARC | EasyDMARC

Fehler bei der Einführung von DMARC

5 Min Lesezeit
DMARC deployment mistakes while implementing DMARC

Das Interesse an DMARC nimmt exponentiell zu, aber die meisten Unternehmen, die DMARC implementieren, nutzen nicht alle Vorteile, die DMARC gegen Spoofing bietet. Hier erfahren Sie, wie Sie die häufigsten Probleme bei der DMARC-Einführung überwinden können.

In diesem Artikel zeigen wir Ihnen die häufigsten Fehler, die Domain-Inhaber bei der Einrichtung von DMARC-Einträgen und grundlegenden E-Mail-Authentifizierungsstandards machen.

Die häufigsten Fehler bei der DMARC-Einführung

Wir sind auf Konten gestoßen, bei denen die Leute denken, dass ihre Domain geschützt ist. Aber der DMARC-Eintrag ist seit Jahren auf p=none eingestellt. Die Richtlinie p=none zusammen mit den rua- und ruf-Tags versetzt die Domain in den Überwachungsmodus, so dass DMARC-bewusste, empfangende Mailserver/Gateways aggregierte Berichte und Nachrichten über fehlgeschlagene Authentifizierungen an den Domain-Inhaber zurücksenden.

Diese Mailserver/Gateways senden jedoch nur Berichte zurück − sie stellen weiterhin alle E-Mails wie gewohnt zu, auch wenn sie nicht authentifiziert wurden. Die Überwachung ist ein nützlicher und notwendiger erster Schritt auf dem Weg zur DMARC-Implementierung, aber sie schützt nicht vor Fälschungen.

Standardmäßig gilt die DMARC-Richtlinie für 100% aller empfangenen E-Mails, es sei denn, es wird ein Prozentsatz mit dem pct-Tag angegeben. Wenn der DMARC-Eintrag den Wert p=quarantine hat und der Prozentsatz auf weniger als 100 gesetzt ist, erhalten Sie leider immer noch gefälschte E-Mails. Es gibt keine „teilweise“ DMARC-Konformität. Gehen Sie nicht davon aus, dass Ihre Domain sicher ist, wenn Ihr pct-Tag weniger als 100% anzeigt.

Die Standardeinstellung für Subdomains ist die Übernahme der Hauptrichtlinie (z. B. p=reject). Manchmal konzentrieren sich Domain-Inhaber, um Zugang zu DMARC zu erhalten, auf die Durchsetzung des Schutzes ihrer primären Domain. So verschieben sie die Arbeit, die erforderlich ist, um Subdomains in Betrieb zu nehmen, indem sie die Richtlinie sp=none für Subdomains festlegen. In Wirklichkeit bedeutet dies, dass alle Subdomains (bestehende und nicht bestehende) weiterhin gefälscht werden können. Um die Regeln durchzusetzen, müssen die Subdomains genau wie die Hauptdomain der Organisation geschützt werden.

DMARC-deployment-mistakes-while-implementing- DMARC

Probleme bei der DMARC-Einführung

Viele Leute verwenden nicht die korrekte DMARC-Syntax. Beispiel: Ein DMARC-Eintrag, der eine Richtlinie enthält, z. B. p=reject, wird nach einem anderen Tag eingefügt, nicht unmittelbar nach dem v=DMARC1-Tag. Werden die Tags in der falschen Reihenfolge platziert, kann dies zu Problemen führen, da die DMARC-Authentifizierung fehlschlägt oder Mail-Gateways die DMARC-Prüfungen ganz überspringen. Weitere Informationen über DMARC-Tags finden Sie hier.

Einer der wichtigsten Aspekte von DMARC ist, dass es Domain-Inhabern durch zusammenfassende Berichte der Daten ein Feedback über den Status der E-Mail-Authentifizierung, einschließlich Auslassungen und Fehlern, liefert. Wenn Sie jedoch die E-Mail-Adresse für die Berichte nicht in den rua-Tag aufnehmen, erhalten Sie diese Daten nicht. Und Sie werden nichts über fehlgeschlagene Authentifizierungen und mögliche Angriffe mit Domain-Spoofing wissen. Die im rua-Tag angegebene(n) E-Mail-Adresse teilt den empfangenden E-Mail-Servern mit, wohin sie Berichte mit aggregierten DMARC-Daten übermitteln müssen.

SPF- und DMARC-Einführung

Der SPF-Eintrag ist ein im DNS veröffentlichter Texteintrag, der eine Liste von IP-Adressen zulässiger Absender und Direktiven enthält, die auf bestimmte DNS-Einträge derselben Domain oder auf SPF-Einträge externer Domains verweisen. Es gibt zwar viele Möglichkeiten, einen SPF-Eintrag falsch zu konfigurieren, aber einer der häufigsten Fehler ist die Erstellung eines Eintrags, der die empfangende Domain dazu veranlasst, mehr als 10 so genannte „DNS-Lookups“ für jede empfangene Nachricht durchzuführen. 

Ein DNS-Lookup löst im Grunde die a-, mx-, include- und redirect-Direktiven in IP-Adressen auf. Wenn also der SPF-Eintrag der sendenden Domain zu viele DNS-Lookups erfordert, kann dies den empfangenden Mailserver stark belasten. Daher können einige oder sogar alle empfangenen E-Mails die Authentifizierungsprüfung nicht bestehen.

Um diese Einschränkung der SPF-Spezifikation zu umgehen, vereinfachen einige Domain-Inhaber ihren SPF-Eintrag, indem sie alle IP-Adressen der zugelassenen Versanddienste extrahieren und in den Haupt-SPF-Eintrag aufnehmen. Der vereinfachte SPF-Eintrag gibt ausdrücklich eine Liste von IP-Adressen an. Dies bringt jedoch ein neues Problem mit sich: die Notwendigkeit, die Integrität der IP-Adressenliste jederzeit aufrechtzuerhalten, insbesondere wenn der von Ihnen verwendete E-Mail-Versanddienst IP-Adressen auf seiner Seite hinzufügt oder entfernt.

DKIM und DMARC

DomainKeys Authenticated Mail (DKIM) verwendet Kryptographie mit öffentlichem/privatem Schlüssel, um E-Mail-Nachrichten zu signieren. Damit wird bestätigt, dass die E-Mail von der Domain stammt, der der DKIM-Schlüssel zugeordnet ist, und dass die E-Mail bei der Übertragung nicht verändert wurde.

DKIM-Schlüssel sind lange Strings mit scheinbar zufälligen Daten, die im DNS leicht verwechselt werden können. Selbst ein einfaches Problem beim Kopieren und Einfügen kann Fehler verursachen, die dazu führen, dass DKIM-E-Mails von legitimen Empfängern abgelehnt werden.

Darüber hinaus empfehlen Experten, DKIM-Schlüssel mindestens alle sechs Monate zu wechseln, um zu verhindern, dass Schlüssel gestohlen oder geknackt werden. Viele Unternehmen verfügen nicht über Methoden zur Verwaltung und Rotation von Schlüsseln. Einige verwenden sogar denselben DKIM-Schlüssel für alle von ihnen genutzten E-Mail-Dienste. Wenn dieser eine Schlüssel kompromittiert wird, ist jeder Dienst anfällig für Angriffe.

Ohne ordnungsgemäß konfiguriertes SPF und DKIM kann DMARC also nicht durchgesetzt werden.

DMARC erfordert, dass die Nachricht entweder die SPF- oder DKIM-Authentifizierungsprüfung besteht. Und Domain-Abgleich (Übereinstimmung) zwischen der sichtbaren Absenderadresse der E-Mail-Nachricht und 1) der Adresse im Feld „Return-Path“ des E-Mail-Headers und 2) der Domain im Feld „DKIM-Signature“ des E-Mail-Headers. 

Sie müssen diese grundlegenden E-Mail-Authentifizierungsprotokolle richtig einstellen, bevor Sie den Schutz Ihrer Domain mit DMARC durchsetzen können.

Wenn Sie mehr darüber erfahren möchten, wie Sie diese häufigen Fehler beheben können, lesen Sie unseren Artikel: So implementieren Sie DMARC mit EasyDMARC