7 externe Absender, die häufig gegen DMARC verstoßen (und wie man jeden einzelnen authentifiziert)

Die meisten Unternehmen versenden E-Mails über weitaus mehr Systeme als nur ihren Mailserver. Marketingplattformen, CRM-Systeme, Helpdesks, Abrechnungstools und eine ständig wachsende Zahl von KI-Assistenten versenden Nachrichten, in deren Absenderadresse Ihre Domain erscheint. Jedes dieser Systeme ist ein Drittanbieter-Absender, und bei jedem einzelnen kann es zu Fehlern bei SPF, DKIM und DMARC kommen, ohne dass dies jemand bemerkt.

Fehler spielen mittlerweile eine größere Rolle. Gmail, Yahoo und Outlook.com verlangen von Absendern, die mehr als 5.000 Nachrichten pro Tag versenden, dass sie sich mittels SPF, DKIM und DMARC authentifizieren und diese mit der „Von“-Domain abgleichen; andernfalls können nicht konforme Massen-E-Mails sofort abgelehnt werden. Unterhalb dieses Volumens landet eine Nachricht, die den DMARC-Check nicht besteht, mit größerer Wahrscheinlichkeit im Spam-Ordner, und sie kommt gar nicht erst an, sobald Sie auf eine Ablehnungsrichtlinie umstellen.

Dieser Leitfaden behandelt sieben Kategorien von Drittabsendern, erläutert, wie jede dieser Kategorien in der Regel gegen DMARC verstößt, und listet die Schritte zur Authentifizierung auf. Abgeschlossen wird er mit Beispielen für DNS-Einträge, einer Überprüfungsmethode und einem Einführungsplan.

Warum Absender von Drittanbietern DMARC unterlaufen

DMARC gilt als bestanden, wenn mindestens entweder SPF oder DKIM bestanden wird und mit der Domain in der sichtbaren „Von“-Adresse übereinstimmt. Die Übereinstimmung ist der Punkt, den viele übersehen.

• SPF-Abgleich vergleicht die Domain im Rückweg, auch als Absender der E-Mail-Hülle oder Bounce-Adresse bezeichnet, mit der „Von“-Domain. Anbieter verwenden in der Regel ihre eigene Bounce-Domain, sodass die SPF-Prüfung für sie zwar erfolgreich ist, aber nicht mit Ihren Angaben übereinstimmt.
• DKIM-Abgleich vergleicht die Signaturdomäne in der DKIM-Signatur (den „d=“-Wert) mit der „From“-Domäne. Anbieter signieren standardmäßig in der Regel mit ihrer eigenen Domäne, sodass DKIM zwar bestanden wird, aber keine Übereinstimmung vorliegt.
• Konfigurationsfehler beeinträchtigen den Rest. Häufige Fehler sind mehr als 10 DNS-Abfragen in SPF, mehr als ein SPF-Eintrag pro Domain, fehlende DKIM-Einträge sowie Einträge, die von Anbietern stammen, die Sie nicht mehr nutzen.

Bei der „lockeren“ Zuordnung, die standardmäßig eingestellt ist, wird eine Subdomain der übergeordneten Organisationsdomain zugeordnet. Die „strenge“ Zuordnung erfordert eine exakte Übereinstimmung. Da DKIM-Signaturen in der Regel auch bei der Weiterleitung erhalten bleiben, SPF-Einträge hingegen oft nicht, streben die meisten Teams eine DKIM-Zuordnung für jeden externen Absender an.

Die „Seven Senders“ auf einen Blick

1. KI-Protokollführer und Besprechungsassistenten

Sitzungsassistenten versenden Zusammenfassungen, Aktionspunkte und Entwürfe für Folgemaßnahmen sowie Links – oft an Teilnehmer außerhalb Ihres Unternehmens. Ganz gleich, ob Ihr Team Fathom nutzt oder gerade Fathom-Alternativen– fragen Sie den Anbieter, wie seine E-Mails authentifiziert werden, bevor Sie ein Postfach verbinden oder den Versand über Ihre Domain aktivieren.

Viele dieser Tools versenden E-Mails über ihre eigene Domain und zeigen Ihren Namen als Absendernamen an. Dies hat keinen Einfluss auf Ihre DMARC-Ergebnisse, da die Domain in der Absenderadresse die des Anbieters ist. Probleme entstehen erst bei Funktionen, die Ihre Domain in die Absenderadresse einfügen und den Versand über die Server des Anbieters abwickeln, wie beispielsweise Folge-E-Mails, die den Anschein erwecken, von Ihnen zu stammen. Diese Nachrichten tragen den Return-Path und die DKIM-Signatur des Anbieters, sodass SPF und DKIM zwar bestanden werden, die Übereinstimmung mit Ihrer Domain jedoch weiterhin fehlschlägt. Ein drittes Muster sind Tools, die über Ihr eigenes Google- oder Microsoft-Postfach versenden. Diese E-Mails werden von Ihrem E-Mail-Anbieter signiert und zugestellt, sodass die Übereinstimmung gegeben ist, solange die DKIM-Signierung dort für Ihre Domain aktiviert ist.

Fragen, die Sie dem Anbieter stellen sollten:

• Welche Domain erscheint in der Absenderadresse von Zusammenfassungen, Einladungen und Erinnerungen?
• Gibt es eine Funktion, bei der E-Mails von den Servern des Anbieters versendet werden und dabei meine Domain in der Absenderadresse verwendet wird?
• Wenn ja, kann ich mich dann mit einem benutzerdefinierten DKIM und einem benutzerdefinierten Return-Path auf einer Subdomain authentifizieren?
• Können E-Mails an externe Teilnehmer eingeschränkt oder deaktiviert werden?
• Wenn das Tool Daten über mein E-Mail-Konto versendet, welche Berechtigungen fordert es dann an?

So führen Sie die Authentifizierung durch:

• Wenn die Absenderdomain dem Anbieter gehört, müssen Sie für Ihr DMARC nichts konfigurieren. Konzentrieren Sie sich darauf, wer die E-Mails erhält.
• Wenn der Anbieter E-Mails über Ihre Domain versendet, fügen Sie die DKIM- und Return-Path-Einträge aus dessen Dokumentation hinzu, idealerweise auf einer eigenen Subdomain.
• Falls das Tool E-Mails über Ihr Postfach versendet, stellen Sie sicher, dass die DKIM-Signatur für Ihre benutzerdefinierte Domain in Google Workspace oder Microsoft 365 aktiviert ist.
• Senden Sie eine echte Zusammenfassung an ein externes Postfach und lesen Sie die Authentifizierungs-Header vor der Einführung.

2. Marketing- und E-Mail-Service-Plattformen

Marketingplattformen versenden das größte Volumen an E-Mails von Drittanbietern, was sie zur häufigsten Ursache für DMARC-Probleme macht. Standardmäßig signieren viele diese E-Mails mit dem DKIM-Schlüssel des Anbieters und verwenden dessen Bounce-Domain als Rückweg. SPF und DKIM werden dann für die Domain des Anbieters als gültig erkannt, stimmen jedoch nicht mit der Domain in Ihrer Absenderadresse überein, sodass DMARC fehlschlägt.

Mit steigendem Versandvolumen steigen auch die Anforderungen. Gmail, Yahoo und Outlook.com verlangen von Absendern, die täglich mehr als 5.000 Nachrichten versenden, eine Authentifizierung mittels SPF, DKIM und DMARC sowie die Übereinstimmung mit der „Von“-Domain. Außerdem müssen Marketing-E-Mails eine Abmeldefunktion per Klick bieten und eine niedrige Spam-Beschwerdequote aufweisen. Nicht konforme Massen-E-Mails können sofort abgelehnt werden.

So führen Sie die Authentifizierung durch:

• Versenden Sie E-Mails über eine eigene Subdomain wie news.example.com, damit die Marketing-Reputation und die DNS-Einträge von der Unternehmens-E-Mail getrennt bleiben.
• Führen Sie die Domain-Authentifizierung der Plattform durch. Dies bedeutet in der Regel, dass DKIM-Einträge – häufig CNAME-Einträge – hinzugefügt werden müssen, damit Nachrichten mit Ihrer Domain signiert werden, sowie gegebenenfalls eine benutzerdefinierte Return-Path-Domain, sofern diese angeboten wird.
• Veröffentlichen Sie den SPF-Eintrag dort, wo er benötigt wird. Wenn es sich bei dem Return-Path um eine benutzerdefinierte Subdomain handelt, befindet sich der SPF-Eintrag auf dieser Subdomain, wodurch Ihr Root-Eintrag kurz bleibt.
• Legen Sie eine DMARC-Richtlinie für die Subdomain fest, entweder mit „sp=“ im übergeordneten Eintrag oder in einem eigenen Eintrag, und lesen Sie die aggregierten Berichte.
• Fügen Sie Kopfzeilen zum Abmelden mit einem Klick hinzu und beobachten Sie die Beschwerdequoten.

3. CRM- und Sales-Engagement-Plattformen

Vertriebs-Tools versenden E-Mails in der Regel auf eine von zwei Arten. Einzel-E-Mails, die über ein verbundenes Google- oder Microsoft-Postfach versendet werden, werden von Ihrem E-Mail-Anbieter authentifiziert. Massen-E-Mail-Sequenzen und Optionen zum „Versenden über die Plattform“ nutzen die plattformeigenen Server, die entsprechend konfiguriert werden müssen. Ein häufiger Fehler ist, dass eine Plattform E-Mails von den persönlichen Adressen der Nutzer in Ihrer Domain versendet, ohne dass DKIM oder der Return-Path eingerichtet sind.

Diese Tools sammeln zudem SPF-Includes an. Jedes Include verursacht DNS-Abfragen, und SPF erlaubt nur 10 pro Auswertung (RFC 7208). Wird dieses Limit überschritten, behandeln Empfänger SPF als dauerhaften Fehler, wodurch die Prüfung fehlschlägt.

So führen Sie die Authentifizierung durch:

• Nutzen Sie den mit dem Postfach verknüpften Versand für individuelle Kontaktaufnahmen.
• Bei über die Plattform versendeten E-Mails sollten Sie eine eigene Subdomain mit benutzerdefiniertem DKIM und Return-Path authentifizieren und die Kontaktaufnahme über eine andere Domain oder Subdomain als die der Unternehmens-E-Mails abwickeln.
• Überprüfen Sie, welche Benutzer und welche Plattformen im Namen Ihrer Domain E-Mails versenden dürfen.
• Zählen Sie die SPF-Abfragen regelmäßig. Konsolidieren oder entfernen Sie Einbindungen für Tools, die Sie nicht mehr verwenden, und seien Sie vorsichtig beim „Flattening“, da „geflachten“ IP-Listen ihre Gültigkeit verlieren, wenn Anbieter ihre Adressen ändern.

4. Helpdesk- und Kundensupport-Tools

Support-Teams wünschen sich in der Regel, dass Antworten von [email protected] versendet werden. Das bedeutet, dass die Server des Helpdesks E-Mails mit Ihrer Domain in der Absenderadresse versenden, was eine SPF- oder DKIM-Konformität erfordert, um die DMARC-Prüfung zu bestehen. Viele Konfigurationen lassen dies außer Acht, da die Tickets im Testbetrieb scheinbar funktionieren: Die herstellereigenen Prüfungen werden bestanden, und die Zustellung in einen toleranten Posteingang gelingt.

Die Eingangsverarbeitung bringt eine zweite Reihe von Problemen mit sich. Die automatische Weiterleitung eines Support-Postfachs an den Helpdesk ist zwar einfach, doch führt die Weiterleitung häufig zu einer Verletzung der SPF-Regeln, da die IP-Adresse des Weiterleiters für den ursprünglichen Absender nicht autorisiert ist. DKIM-Signaturen können eine Weiterleitung überstehen, was ein Grund dafür ist, dass die DKIM-Übereinstimmung zuverlässiger ist als die SPF-Übereinstimmung.

So führen Sie die Authentifizierung durch:

• Fügen Sie die DKIM-Einträge des Anbieters hinzu, damit Antworten mit Ihrer Domain signiert werden, und fügen Sie gegebenenfalls die SPF- oder Return-Path-Einträge des Anbieters hinzu.
• Verwenden Sie vorzugsweise MX-Routing oder die vom Anbieter unterstützte Weiterleitungsmethode anstelle von Regeln zur automatischen Weiterleitung von E-Mails.
• Testen Sie die Antwort auf ein Ticket an ein externes Postfach und überprüfen Sie die Kopfzeilen; wiederholen Sie diesen Vorgang anschließend für automatisierte Nachrichten wie Zufriedenheitsumfragen, die manchmal aus einem anderen System stammen.
• Entfernen Sie Einträge für Helpdesk-Tools, die Sie nicht mehr verwenden.

5. Kalender- und Terminplanungs-Tools

Terminplanungs-Tools versenden Einladungen, Bestätigungen und Erinnerungen, in der Regel im Auftrag eines Veranstalters. Die meisten versenden diese E-Mails über die Domain des Anbieters, wobei Ihre Adresse im Feld „Reply-To“ angegeben ist, was keinen Einfluss auf Ihren DMARC-Status hat. Probleme entstehen durch Markenoptionen, die ohne Authentifizierung über Ihre Domain versendet werden, sowie durch Kalender-E-Mails, die ungesigniert versendet werden.

Der Fall ohne Signatur kann leicht übersehen werden. Wenn die DKIM-Signatur für Ihre benutzerdefinierte Domain in Microsoft 365 nicht aktiviert ist, werden ausgehende E-Mails stattdessen mit der Standard-Mandantendomäne signiert, die nicht mit Ihrer Absenderdomain übereinstimmt. Auch bei Google Workspace muss DKIM für Ihre Domain aktiviert sein.

So führen Sie die Authentifizierung durch:

• Überprüfen Sie, welche Domain das Tool in der Absenderadresse für jeden Nachrichtentyp verwendet.
• Aktivieren Sie bei Ihrem E-Mail-Anbieter die DKIM-Signatur für Ihre benutzerdefinierte Domain, damit Kalendereinladungen und vom Postfach versendete Nachrichten übereinstimmen.
• Wenn Sie eine Marken-Versandoption verwenden, authentifizieren Sie diese mit den DKIM- und Return-Path-Einträgen des Anbieters.
• Überprüfen Sie Erinnerungs- und Stornierungs-E-Mails getrennt von den Einladungen.

6. Abrechnungs-, Rechnungsstellungs- und Zahlungsplattformen

Rechnungen, Quittungen und Zahlungserinnerungen gehören zu den am häufigsten missbrauchten E-Mail-Typen. Angreifer ahmen diese nach, da Empfänger bei allem, was mit Geld zu tun hat, schnell reagieren, und eine gefälschte Rechnung kann eine Zahlung umleiten. Diese Plattformen versenden E-Mails oft über ihre eigene Domain mit Ihrem Firmennamen und bieten die Option, E-Mails über [email protected] zu versenden. Diese Option funktioniert im Rahmen von DMARC nur, wenn die entsprechenden DNS-Einträge vorhanden sind.

Unternehmen nutzen häufig mehrere Tools für die Rechnungsstellung gleichzeitig, beispielsweise Buchhaltungssoftware, einen Zahlungsdienstleister und einen Abonnement-Manager. Jedes dieser Tools ist ein eigenständiger Absender mit eigenen Datensätzen.

So führen Sie die Authentifizierung durch:

• Nutzen Sie die Funktion für benutzerdefinierte E-Mail-Domains der jeweiligen Plattform und veröffentlichen Sie die dort bereitgestellten DKIM-, SPF- und Return-Path-Einträge.
• Listen Sie alle Systeme auf, die Rechnungs-E-Mails versenden, und stellen Sie sicher, dass jedes einzelne System die Authentifizierung durchführt und die Daten abgleichen.
• Führen Sie eine Durchsetzungsrichtlinie ein, sobald Berichte zeigen, dass Ihre legitimen Quellen die Überprüfung bestehen. Das hindert Angreifer daran, Rechnungen zu versenden, die wie Ihre aussehen.
• Teilen Sie Ihren Kunden mit, von welchen Adressen Ihre Rechnungen versandt werden.

7. Personal-, Rekrutierungs- und Lohnabrechnungssysteme

Bewerbermanagementsysteme versenden E-Mails an Bewerber über Adressen wie „careers@“ oder „jobs@“, Onboarding-Plattformen versenden Willkommensnachrichten und Lohnabrechnungssysteme senden Benachrichtigungen an Mitarbeiter. Diese Systeme werden oft von der Personalabteilung ohne Einbeziehung der IT-Abteilung ausgewählt und konfiguriert, sodass niemand die DNS-Einstellungen überprüft. Die Folge ist, dass Stellenangebote im Spam-Ordner landen und Bewerber Einladungen zu Vorstellungsgesprächen verpassen.

Auch hier kommt Identitätsbetrug häufig vor. E-Mails mit Stellenbetrug, die das Branding eines echten Unternehmens nachahmen, sind eine bekannte Taktik, und eine durchgesetzte DMARC-Richtlinie erschwert es, solche E-Mails von Ihrer tatsächlichen Domain aus zu versenden.

So führen Sie die Authentifizierung durch:

• Beziehen Sie die DNS-Prüfung in den Kaufprozess für HR-Software ein.
• Authentifizieren Sie eine dedizierte Subdomain für Recruiting-E-Mails mithilfe der DKIM- und Return-Path-Einträge des Anbieters.
• Veröffentlichen Sie eine kurze Liste der offiziellen Adressen für die Personalbeschaffung und die Gehaltsabrechnung, damit Bewerber und Mitarbeiter diese erkennen können.
• Stellen Sie sicher, dass Einladungen zu Vorstellungsgesprächen und E-Mails mit Stellenangeboten tatsächlich in den Posteingängen ankommen, auch bei kostenlosen Webmail-Anbietern.

Beispiele für DNS-Einträge

Die genauen Bezeichnungen und Werte entnehmen Sie bitte der Konfigurationsseite des jeweiligen Anbieters. Die folgenden Beispiele zeigen, was Sie erwarten können. Die Domains sind Platzhalter.

SPF auf der sendenden Subdomain (ein Eintrag pro Domain)
mail.example.com. TXT „v=spf1 include:_spf.vendor.example ~all“

DKIM-Signatur-Einträge, die in der Regel als CNAMEs bereitgestellt werden:
selector1._domainkey.mail.example.com. CNAME selector1.dkim.vendor.example.
selector2._domainkey.mail.example.com. CNAME selector2.dkim.vendor.example.

Benutzerdefinierte Return-Path-Domain (Bounce)
bounce.mail.example.com. CNAME return.vendor.example.

DMARC-Eintrag, Start im Überwachungsmodus
_dmarc.example.com. TXT „v=DMARC1; p=none; rua=mailto:[email protected]“ 

So überprüfen Sie einen Absender, bevor Sie live gehen

Senden Sie eine echte Nachricht vom System an ein externes Postfach, öffnen Sie die Quelle der ursprünglichen Nachricht und lesen Sie die Authentifizierungsergebnisse. SPF oder DKIM sollten erfolgreich sein, und die dahinterliegende Domain sollte mit der „Von“-Domain übereinstimmen.

Abgestimmt: DMARC bestanden
spf=pass smtp.mailfrom=bounce.mail.example.com
dkim=pass header.d=mail.example.com
dmarc=pass header.from=mail.example.com

Bestanden, aber nicht abgeglichen: DMARC-Fehler
spf=pass smtp.mailfrom=bounces.vendor.example
dkim=pass header.d=vendor.example
dmarc=fail header.from=example.com 

Im zweiten Beispiel werden beide Prüfungen bestanden, allerdings für die Domain des Anbieters. Keine der beiden stimmt mit „example.com“ überein, sodass DMARC fehlschlägt. Dies ist das Kennzeichen eines nicht authentifizierten Drittabsenders.

Ein Einführungsplan

1. Erstellen Sie eine Bestandsaufnahme Ihrer Absender. Fragen Sie die Finanzabteilung nach SaaS-Abonnements, überprüfen Sie Ihre Liste der Single-Sign-On-Anwendungen, lesen Sie Ihre SPF-Einträge und überprüfen Sie die E-Mail-Protokolle.
2. Veröffentlichen Sie DMARC mit „p=none“ und einer Berichtsadresse. Die aggregierten Berichte zeigen alle Systeme an, die unter Ihrer Domain versenden, einschließlich solcher, an die sich niemand mehr erinnert.
3. Jeden legitimen Absender authentifizieren. Verwenden Sie benutzerdefiniertes DKIM und einen benutzerdefinierten Return-Path und bevorzugen Sie Subdomains für Systeme mit hohem Versandvolumen oder hohem Risiko.
4. Schreiten Sie zur Durchsetzung über. Sobald die Berichte zeigen, dass legitime E-Mails durchgelassen werden, gehen Sie zur Quarantäne über und lehnen Sie die E-Mails anschließend ab, wobei Sie die Berichte in jeder Phase im Auge behalten.
5. Machen Sie es zur Routine. Fügen Sie beim Onboarding von Anbietern eine E-Mail-Authentifizierung hinzu und löschen Sie die DNS-Einträge, wenn Sie ein Tool außer Betrieb nehmen.

FAQ

Was ist der Unterschied zwischen einem bestandenen SPF- oder DKIM-Test und einem bestandenen DMARC-Test?

SPF und DKIM können für jede beliebige Domain gültig sein, einschließlich der des Anbieters. DMARC fügt die Anforderung hinzu, dass die gültige Domain mit der Domain in Ihrer Absenderadresse übereinstimmen muss.

Muss ich jeden Anbieter in meinen SPF-Eintrag aufnehmen?

Nicht immer. Wenn ein Anbieter einen benutzerdefinierten Return-Path auf Ihrer Subdomain verwendet und mit „aligned DKIM“ signiert, kann DMARC die Überprüfung bestehen, ohne dass Ihr Root-SPF-Eintrag berührt wird. Weniger Einbindungen helfen Ihnen zudem dabei, das Limit von 10 Lookups einzuhalten.

Sollte ich für Absender von Drittanbietern Subdomains verwenden?

Oftmals, ja. Eine Subdomain trennt Reputations- und DNS-Einträge voneinander und erleichtert die Nachverfolgung und Kontrolle der einzelnen Quellen. Beachten Sie, dass Subdomains Ihre DMARC-Richtlinie übernehmen, sofern Sie nicht „sp=“ festlegen oder einen separaten Eintrag veröffentlichen.

Wie lange dauert es, bis p=reject erreicht ist?

Das hängt davon ab, wie viele Absender Sie haben und wie schnell Sie die Probleme beheben können. In vielen Organisationen dauert dies mehrere Wochen bis zu einigen Monaten, wobei man sich an den Gesamtberichten orientiert.

Was passiert, wenn ein Anbieter sich nicht mit meiner Domain anmelden kann?

Dann müsste DMARC die SPF-Übereinstimmung mit einem benutzerdefinierten Return-Path bestehen. Wenn beides nicht möglich ist, sollte der Anbieter von seiner eigenen Domain aus versenden, nicht von Ihrer.

Gilt DMARC für E-Mails, die über Google Workspace oder Microsoft 365 versendet werden?

Ja. Stellen Sie sicher, dass die DKIM-Signatur für Ihre benutzerdefinierte Domain dort aktiviert ist, da E-Mails andernfalls möglicherweise mit einer Standarddomain signiert werden, die nicht übereinstimmt.