Best Practice für die E-Mail-Authentifizierung – optimale Möglichkeiten zur Bereitstellung von SPF, DKIM und DMARC

Einleitung

In diesem Leitfaden werden drei derzeit vorherrschende E-Mail-Authentifizierungstechnologien beschrieben - SPF, DKIM und DMARC. Außerdem werden verschiedene Aspekte ihrer Implementierung erläutert. Es werden verschiedene Situationen der realen E-Mail-Architektur sowie Richtlinien zu ihrer Implementierung für die Cisco E-Mail Security-Produktpalette vorgestellt. Da es sich hierbei um einen praktischen Leitfaden handelt, wird auf einige der komplexeren Materialien verzichtet. Bei Bedarf können bestimmte Begriffe vereinfacht oder zusammengefasst werden, um das Verständnis des dargestellten Sachverhalts zu erleichtern.

Anforderungen an das Produktwissen

Dieser Leitfaden ist ein Dokument der erweiterten Ebene. Um das vorgestellte Material durchzuarbeiten, muss der Leser über Produktkenntnisse der Cisco Email Security Appliance bis hin zur Zertifizierung als Cisco Email Security Field Engineer verfügen. Darüber hinaus sollten die Leser über eine starke Kontrolle über DNS und SMTP und deren Betrieb verfügen. Die Kenntnis der Grundlagen von SPF, DKIM und DMARC ist ein Plus.

E-Mail-Authentifizierung - ein kurzer Überblick

Absenderrichtlinien-Framework (SPF)

Das Absenderrichtlinien-Framework wurde erstmals 2006 als RFC 4408 veröffentlicht. Die aktuelle Version wird in RFC 7208 angegeben und in RFC 7372 aktualisiert. Im Wesentlichen bietet es einem Domäneninhaber eine einfache Möglichkeit, seine legitimen E-Mail-Quellen mittels DNS an die Empfänger weiterzugeben. Obwohl SPF primär die Rückgabepfad-Adresse (MAIL FROM) authentifiziert, wird in der Spezifikation empfohlen (und ein Mechanismus bereitgestellt), auch das SMTP HELO/EHLO-Argument (FQDN des Absender-Gateways, wie während der SMTP-Konversation übertragen) zu authentifizieren.

SPF verwendet den TXT-Typ "DNS Resource Records" mit relativ einfacher Syntax:

spirit.com text = "v=spf1 mx a ip4:38.103.84.0/24 a:mx3.spirit.com a:mx4.spirit.com include:spf.protection.outlook.com ~all"

Der Spirit Airlines-Datensatz oben ermöglicht es, dass E-Mails von @spirit.com aus einem bestimmten /24-Subnetz, zwei durch einen FQDN identifizierten Systemen und der Microsoft Office365-Umgebung stammen. Der "~all"-Qualifizierer am Ende weist die Empfänger an, alle anderen Quellen als "Soft Fail" (weicher Fehler) zu betrachten - als einen von zwei Fehlermodi von SPF. Beachten Sie, dass Absender nicht angeben, was Empfänger mit fehlerhaften Nachrichten tun sollen, sondern nur angeben, in welchem Ausmaß sie fehlschlagen werden.

Delta hingegen verwendet ein anderes SPF-Schema:

delta.com text = "v=spf1 a:smtp.hosts.delta.com include:_spf.vendor.delta.com -all"

Um die Anzahl der erforderlichen DNS-Abfragen auf ein Minimum zu reduzieren, erstellte Delta einen einzelnen A-Eintrag, in dem alle SMTP-Gateways aufgeführt sind. Sie stellen außerdem einen separaten SPF-Datensatz für ihre Anbieter in "_spf.vendor.delta.com" bereit. Sie enthalten auch Anweisungen zum Hard Fail für alle Nachrichten, die nicht von SPF authentifiziert wurden ("-all"-Qualifizierer). Darüber hinaus können wir den SPF-Datensatz des Anbieters nachschlagen:

_spf.vendor.delta.com text = "v=spf1 include:_spf-delta.vrli.com include:_spf-ncr.delta.com a:delta-spf.niceondemand.com include:_spf.airfrance.fr include:_spf.qemailserver.com include:skytel.com include:epsl1.com ?all"

E-Mails von Absendern von @delta.com können beispielsweise aus den E-Mail-Gateways von Air France stammen.

United hingegen verwendet ein viel einfacheres SPF-Schema:

united.com text = "v=spf1 include:spf.enviaremails.com.br include:spf.usa.net include:coair.com ip4:161.215.0.0/16 ip4:209.87.112.0/20 ip4:74.112.71.93 ip4:74.209.251.0/24 mx ~all"

Neben ihren eigenen Mail-Gateways gehören dazu auch ihre E-Mail-Marketing-Anbieter ("usa.net" und "enviaremails.com.br"), die älteren Gateways von Continental Air Lines sowie alle in ihren MX-Datensätzen aufgeführten Elemente ("MX"-Mechanismus). Beachten Sie, dass MX (ein Eingangs-Mail-Gateway für eine Domäne) möglicherweise nicht dasselbe ist wie Ausgehend. Während sie für kleinere Unternehmen in der Regel identisch sind, verfügen größere Unternehmen über eine separate Infrastruktur für die Bearbeitung eingehender E-Mails und die separate Bearbeitung ausgehender Zustellungen.

Außerdem ist zu beachten, dass in allen oben genannten Beispielen zusätzliche DNS-Verweise ("include"-Mechanismen) umfassend genutzt werden. Aus Leistungsgründen beschränkt die SPF-Spezifikation die Gesamtzahl der DNS-Lookups, die zum Abrufen eines endgültigen Datensatzes erforderlich sind, auf zehn. Jede SPF-Suche mit mehr als 10 Stufen der DNS-Rekursion schlägt fehl.

DKIM (Domain Keys Identified Mail)

Die in den RFCs 5585, 6376 und 5863 beschriebene DKIM ist eine Zusammenführung zweier historischer Angebote: Yahoos DomainKeys und Cisco Identified Internet Mail. Sie bietet eine einfache Möglichkeit für Absender, ausgehende Nachrichten kryptografisch zu signieren und die Signaturen (zusammen mit anderen Verifizierungsmetadaten) in einen E-Mail-Header ("DKIM-Signatur") aufzunehmen. Absender veröffentlichen ihren öffentlichen Schlüssel im DNS, sodass jeder Empfänger diesen abrufen und die Signaturen überprüfen kann. DKIM authentifiziert nicht die Quelle der physischen Nachrichten, sondern basiert darauf, dass die Quelle, wenn sie im Besitz des privaten Schlüssels der Absenderorganisation ist, implizit autorisiert ist, eine E-Mail in ihrem Namen zu senden.

Um DKIM zu implementieren, generiert die sendende Organisation ein oder mehrere Paare öffentlicher Schlüssel und veröffentlicht die öffentlichen Schlüssel im DNS als TXT-Datensätze. Auf jedes Schlüsselpaar wird durch einen "Selektor" verwiesen, sodass DKIM-Verifizierer zwischen Schlüsseln unterscheiden können. Ausgehende Nachrichten werden signiert und ein DKIM-Signature-Header eingefügt:

DKIM-Signatur: v=1; a=rsa-sha1; c=relaxed/relaxed; s=united; d=news.united.com;h=MIME-Version:Content-Type:Content-Transfer-Encoding:Date:From:Reply-To:Subject:List-Unsubscribe:Message-ID; i=MileagePlus@news.united.com; bh=IBSWR4yzI1PSRYt WLx4SRDSWII

b=HrN5QINgnXwqkx+Zc/9VZys+yhikrP6wSZVu35KA0jfgYzhzSdfA2nA8D2JYIFTNLO8j4DGmKh1MMTyYgwYqG T01rEwL0V8MEY1MzxTrzijkLPGqt/sK1WZt9pBacEw1fMWRQLf3BxZ3jaYtLoJMRwxtgoWdfHU35CsFG2CNYLo =

Das Format der Signatur ist recht einfach. "a"-Tag gibt Algorithmen an, die für die Signatur verwendet werden, "c" gibt das (die) verwendete(n) Kanonisierungsschema(e) an [1], "s" ist der Selektor oder die Schlüsselreferenz, "d" ist die Signaturdomäne. Der Rest dieses DKIM-Signature-Headers ist nachrichtenspezifisch: "h" listet signierte Header auf, "i" listet die Identität des signierenden Benutzers auf, und schließlich endet der Header mit zwei separaten Hashes: "bh" ist ein Hash aus signierten Headern, während "b" der Hashwert für den Nachrichtentext ist.

Wenn der Empfänger eine DKIM-signierte Nachricht empfängt, sucht er den öffentlichen Schlüssel, indem er die folgende DNS-Abfrage erstellt:

<Selector>._domainkey.<Signierende Domäne>

wie im DKIM-Signature-Header angegeben. Für das obige Beispiel wäre unsere Abfrage "united.domainkey.news.united.com":

united._domainkey.news.united.com text = "g=*\; k=rsa\; n=" "Kontakt" "postmaster@responsys.com" "mit" "irgendwelche" "Fragen" "betreffend" "diese" "Signierung" "\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/VC h/xq+sSRLhL5CRU1drFTGMXX/Q2KkWgl35hO4v6dTy5Qmxcuv5AwqxLiz9d0jBaxtuvYALjlGkxmk5MemgAOcCr97GlW7Cr11eLn87qdTmyE5LevnTXxVDMjIfQJt6OFzmw6Tp1t05NPWh0PbyUohZYt4qpcbiz9Kc3UB2IBwIDAQAB\;"

Der zurückgegebene DNS-Eintrag enthält den Schlüssel sowie weitere optionale Parameter. [2]

Das Hauptproblem bei DKIM ist, dass die ursprüngliche Spezifikation keine Werbung zulässt, die ein Absender DKIM verwendet. Wenn also eine Nachricht ohne Signatur eingeht, kann der Empfänger nicht leicht erkennen, dass sie signiert sein muss und dass sie in diesem Fall höchstwahrscheinlich nicht authentisch ist. Da eine einzelne Organisation mehrere Selektoren verwenden kann (und dies in den meisten Fällen auch wird), ist es nicht unerheblich zu "schätzen", ob eine Domäne DKIM-fähig ist. Ein separater Standard, Author Domain Signing Practices, wurde entwickelt, um dies abzudecken, aber aufgrund der geringen Nutzung und andere Probleme wurde veraltet im Jahr 2013 ohne Nachfolger.

Domain-based Message Authentication, Reporting and Conformance (DMARC)

DMARC ist die jüngste der drei abgedeckten E-Mail-Authentifizierungstechnologien und wurde speziell entwickelt, um die Mängel von SPF und DKIM zu beheben. Im Gegensatz zu den beiden anderen authentifiziert es den Header From einer Nachricht und verweist auf die zuvor von den beiden anderen durchgeführten Prüfungen. DMARC ist in RFC7489 spezifiziert.

Der Mehrwert von DMARC gegenüber SPF und DKIM umfasst:

• Sicherstellen, dass alle verfügbaren Identitäten (HELO, MAIL FROM und/oder DKIM-Signaturdomäne) mit dem Von-Header ausgerichtet sind (genau übereinstimmen oder untergeordnet sind)
• Möglichkeit für den Besitzer der Absenderdomäne, eine Richtlinie für Empfänger festzulegen, wie sie mit fehlerhaften Nachrichten umgehen müssen
• Feedback für Domäneninhaber des Absenders, damit diese über fehlgeschlagene Nachrichten informiert werden und Phishing-Kampagnen oder Fehler bei der Zuweisung von SPF-, DKIM- und DMARC-Richtlinien leichter erkannt werden können

DMARC verwendet auch einen einfachen, DNS-basierten Verteilungsmechanismus für Richtlinien:

_dmarc.aa.com text = "v=DMARC1\; p=none\; fo=1\; ri=3600\; rua=mailto:american@rua.agari.com,mailto:dmarc@aa.com\; ruf=mailto:american@ruf.agari.com,mailto:dmarc@aa.com"

 Das einzige obligatorische Tag in der DMARC-Richtlinienspezifikation ist "p", das die Richtlinie für fehlerhafte Nachrichten angibt. Es kann einer der drei sein: keine, Quarantäne, Ablehnung.

Die am häufigsten verwendeten optionalen Parameter haben mit der Berichterstellung zu tun: "rua" gibt eine URL an (entweder eine E-Mail-Adresse oder eine http://-Adresse mit POST-Methode), um tägliche aggregierte Berichte über alle fehlerhaften Nachrichten zu senden, die angeblich von einer bestimmten Domäne stammen. "ruf" gibt eine URL an, über die umgehend detaillierte Fehlerberichte für jede fehlgeschlagene Nachricht gesendet werden.

Gemäß Spezifikation muss ein Empfänger die angekündigte Richtlinie einhalten. Andernfalls müssen sie den Besitzer der Absenderdomäne im Aggregationsbericht benachrichtigen.

Das zentrale Konzept von DMARC ist die so genannte Identifikator-Ausrichtung. Die Identifikatorausrichtung definiert, wie eine Nachricht die DMARC-Verifizierung übergeben kann. SPF- und DKIM-Bezeichner werden getrennt voneinander ausgerichtet, und eine Nachricht muss alle Bezeichner weiterleiten, um DMARC insgesamt weiterzuleiten. Es gibt jedoch eine DMARC-Richtlinienoption, bei der der Absender die Erstellung eines Fehlerberichts anfordern kann, auch wenn eine Ausrichtung erfolgreich ist, die andere jedoch fehlschlägt. Dies ist im obigen Beispiel mit dem Tag "fo" zu sehen, der auf "1" gesetzt ist.

Es gibt zwei Möglichkeiten für Nachrichten, entweder an der Ausrichtung der DKIM- oder SPF-Bezeichner festzuhalten: strikt und entspannt. Strikte Einhaltung bedeutet, dass der FQDN des Headers From vollständig mit der Signing Domain ID ("d"-Tag) der DKIM-Signatur oder dem FQDN des MAIL FROM SMTP-Befehls für SPF übereinstimmen muss. Entspannt, auf der anderen Seite ermöglicht Header From FQDN zu einer Subdomäne der oben genannten beiden.  Dies hat wichtige Auswirkungen, wenn Sie Ihren E-Mail-Verkehr an Dritte delegieren, was später in diesem Dokument besprochen wird.

Überlegungen zur SPF-Bereitstellung

SPF für Empfänger

Die SPF-Verifizierung ist auf den virtuellen Appliances der Cisco E-Mail Security Appliance oder Cloud E-Mail Security Appliances einfach zu konfigurieren. Im weiteren Verlauf dieses Dokuments wird bei jeder Bezugnahme auf die ESA auch die CES einbezogen.

Die SPF-Verifizierung wird in Mail Flow Policies (Mail Flow-Richtlinien) konfiguriert. Die einfachste Möglichkeit, sie global auszuführen, besteht darin, sie im Abschnitt Default Policy Parameters (Standard-Policy-Parameter) der entsprechenden Listener zu aktivieren. Wenn Sie denselben Listener für die Erfassung eingehender und ausgehender E-Mails verwenden, stellen Sie sicher, dass die SPF-Verifizierung in Ihrer RELAYED Mail Flow Policy auf "Off" (Aus) gesetzt ist.

Da SPF keine Festlegung von Richtlinienaktionen zulässt, wird bei der SPF-Verifizierung (sowie bei DKIM, wie später noch zu sehen ist) nur die Nachricht verifiziert und für jede durchgeführte SPF-Prüfung eine Reihe von Headern eingefügt:

Received-SPF: Pass (mx1.hc4-93.c3s2.smtpi.com: Domäne von

  united.5765@envfrm.rsys2.com gibt 12.130.136.195 als

  allowed sender) identity=mailfrom;

  client-ip=12.130.136.195; empfänger=mx1.hc4-93.c3s2.smtpi.com;

  velope-from="united.5765@envfrm.rsys2.com";

  x-sender="united.5765@envfrm.rsys2.com";

  x-conformance=sidf_compatible; x-record-type="v=spf1"

Received-SPF: None (mx1.hc4-93.c3s2.smtpi.com: kein Absender)

  Authentizitätsinformationen verfügbar von Domäne von

  postmaster@omp.news.united.com) identity=helo;

  client-ip=12.130.136.195; empfänger=mx1.hc4-93.c3s2.smtpi.com;

  velope-from="united.5765@envfrm.rsys2.com";

  x-sender="postmaster@omp.news.united.com";

  x-konformität=sidf_compatible

Beachten Sie, dass für diese Nachricht zwei "Identitäten" von SPF verifiziert wurden: "mailfrom" gemäß der Spezifikation und "helo" gemäß derselben Empfehlung. Die Nachricht wird formell SPF passieren, da nur erstere für die SPF-Konformität relevant ist. Einige Empfänger können jedoch Absender sanktionieren, die für ihre HELO-Identitäten keine SPF-Datensätze enthalten. Daher empfiehlt es sich, die Hostnamen der ausgehenden Mail-Gateways in die SPF-Datensätze aufzunehmen.

Wenn Mail Flow Policies eine Nachricht verifizieren, ist es an den lokalen Administratoren, eine auszuführende Aktion zu konfigurieren. Dies geschieht mithilfe der Message Filter-Regel SPF-status() [3], oder durch Erstellen eines Content-Filters für eingehende E-Mails mit diesem Filter und dessen Anwendung auf die entsprechenden Mail-Policys für eingehende E-Mails.

Abbildung 1: Bedingung des SPF-Verifizierungs-Content-Filters

Empfohlene Filteraktionen sind das Löschen von Nachrichten, die fehlschlagen ("-all" im SPF-Datensatz), und das Quarantäneschalten von Nachrichten, die Softfail ("~all" im SPF-Datensatz) in einer Richtlinienquarantäne betreffen. Dies kann jedoch je nach Ihren Sicherheitsanforderungen variieren. Manche Empfänger kennzeichnen ausgefallene Nachrichten einfach mit Tags oder ergreifen keine sichtbaren Maßnahmen, sondern melden sie an die Administratoren.

In letzter Zeit hat die Popularität von SPF stark zugenommen, aber viele Domains veröffentlichen unvollständige oder falsche SPF-Datensätze. Um auf der sicheren Seite zu sein, sollten Sie alle SPF-fehlgeschlagenen Nachrichten in Quarantäne stellen und die Quarantäne eine Weile überwachen, um sicherzustellen, dass es keine "Fehlalarme" gibt.

Wenn Sie E-Mail-Services für andere Domänen oder Drittanbieter bereitstellen,

Wenn Sie E-Mail-Zustellungs- oder Hosting-Services für Drittanbieter bereitstellen, müssen diese Hostnamen und IP-Adressen hinzufügen, die Sie verwenden, um ihre Nachrichten an ihre eigenen SPF-Datensätze zu senden. Der einfachste Weg hierfür besteht darin, dass der Anbieter einen übergeordneten SPF-Datensatz erstellt und die Kunden dazu veranlasst, den Include-Mechanismus in ihren SPF-Datensätzen zu verwenden.

suncountry.com text = "v=spf1 mx ip4:207.238.249.242 ip4:146.88.177.148 ip4:146.88.177.149 ip4:67.1 09.66.68 ip4:198.179.134.238 ip4:107.20.247.57 ~ ip4:207.87.182.66 ip4:199.66.248.0/22 include:cust-spf.exacttarget.com alle"

Wie wir sehen können, hat Sun Country einige seiner E-Mails unter seiner eigenen Kontrolle, aber seine Marketing-E-Mails werden an einen Drittanbieter ausgelagert. Durch Erweitern des genannten Datensatzes wird eine Liste der aktuellen IP-Adressen angezeigt, die vom Anbieter des Marketing-Mailing-Service verwendet werden:

cust-spf.excttarget.com text = " v=spf1 ip4:64.132.92.0/24 ip4:64.132.88.0/23 ip4:66.231.80.0/20 ip4:68.232.192.0/20 ip4:199.122.120.0/21 ip4:207.67.38.0/24 ip4:207.67.98.192/27 ip4:207.250.68.0/24 ip4:209.43.22.0/28 ip4:198.245.80.0/20 ip4:136.147.128.0/20 ip4:136.147.176.0/20 ip4:13.111.0.0/18 -all"

Dank dieser Flexibilität können E-Mail-Service-Provider ihre Infrastruktur skalieren, ohne jeden Kunden anrufen zu müssen, um seine DNS-Einträge zu ändern.

Wenn Sie E-Mail-Services von Drittanbietern nutzen

Ähnlich wie im vorherigen Absatz müssen Sie eigene SPF-Datensätze in Ihre eigenen einfügen, wenn Sie E-Mail-Dienste von Drittanbietern nutzen und einen vollständig SPF-verifizierten E-Mail-Fluss einrichten möchten.

jetblue.com beschreibender Text "v=spf1 include:_spf.qualtrics.com ?all"

JetBlue nutzt Qualtrics Analytics Service, und das einzige, was sie tun mussten, ist ein korrekter SPF-Datensatz von Qualtrics. Ebenso stellen die meisten anderen ESPs SPF-Datensätze bereit, die in die Kundendatensätze aufgenommen werden müssen.

Wenn Ihr ESP- oder E-Mail-Vermarkter keine SPF-Datensätze bereitstellt, müssen Sie die ausgehenden E-Mail-Gateways direkt in Ihrem auflisten. Es liegt dann jedoch in Ihrer Verantwortung, diese Aufzeichnungen korrekt zu halten, und wenn der Anbieter zusätzliche Gateways hinzufügt oder IP-Adressen oder Hostnamen ändert, kann Ihr Mail-Fluss gefährdet sein.

Eine zusätzliche Gefahr durch nicht SPF-bewusste Drittanbieter ergibt sich durch die gemeinsame Nutzung von Ressourcen: Wenn ein ESP dieselbe IP-Adresse verwendet, um E-Mails mehrerer Kunden zu senden, ist es technisch möglich, dass ein Kunde eine SPF-gültige Nachricht generiert und so tut, als wäre er ein anderer Kunde, der über dieselbe Schnittstelle E-Mails sendet. Aus diesem Grund sollten Sie vor der Einrichtung von SPF-Beschränkungen die Sicherheitsrichtlinien Ihres MSP sowie die Kenntnis der E-Mail-Authentifizierung überprüfen. Wenn der Kunde keine Antworten auf Ihre Fragen hat, sollten Sie angesichts der Tatsache, dass SPF einer der grundlegenden Mechanismen des Vertrauens im Internet ist, Ihre Wahl zum MSP gründlich überdenken. Dabei geht es nicht nur um Sicherheit - SPF, DKIM, DMARC und andere von den MSPs eingesetzte Best Practices des Absenders [4] sind eine Garantie für die Lieferbarkeit. Wenn Ihr MSP diesen nicht folgt oder ihnen nicht korrekt folgt, mindert dies ihre Vertrauenswürdigkeit bei großen Empfangssystemen und verzögert oder blockiert möglicherweise Ihre Nachrichten.

(Sub)Domänen ohne E-Mail-Verkehr

Die meisten Unternehmen besitzen heutzutage mehrere Domänen für Marketingzwecke, nutzen jedoch nur eine davon aktiv für den geschäftlichen E-Mail-Verkehr. Selbst wenn SPF in der Produktionsdomäne ordnungsgemäß bereitgestellt wird, können Angreifer andere Domänen verwenden, die nicht aktiv für eine E-Mail-Nachricht genutzt werden, um die Identität eines Unternehmens zu manipulieren. SPF kann dies durch einen speziellen "deny all"-SPF-Datensatz verhindern. Veröffentlichen Sie für alle Ihre Domänen (und Subdomänen!), die keinen E-Mail-Verkehr generieren, "v=spf1 -all" im DNS. Ein ausgezeichnetes Beispiel ist openspf.org - die Website des SPF-Rates.

Da die SPF-Delegierung nur für eine Domäne gültig ist, ist es wichtig, auch "alle verweigern" SPF-Datensätze für alle Unterdomänen zu veröffentlichen, die Sie möglicherweise verwenden und die keine E-Mail-Nachricht generieren. Selbst wenn Ihre Produktionsdomäne einen "regulären" SPF-Datensatz hat, sollten Sie sich extra bemühen, "alle" Datensätze ohne Datenverkehr zu Ihren Subdomänen hinzuzufügen. Und wieder: Vergessen Sie nicht, dass Empfangen nicht mit Senden gleichzusetzen ist: Eine Domäne kann sehr wohl E-Mails empfangen, wird aber niemals eine Quelle sein. Dies gilt vor allem für kurzfristige Marketing-Domänen (z. B. Veranstaltungen, zeitlich begrenzte Werbeaktionen, Produkteinführungen usw.), in denen E-Mails, die an diese Domänen gesendet werden, an Ihre Produktionsdomäne gesendet werden und alle Antworten auf diese E-Mails von der Produktionsdomäne gesendet werden. Diese Kurzzeit-Domänen verfügen über einen gültigen MX-Datensatz, sollten jedoch über einen SPF-Datensatz verfügen, der sie ebenfalls als keine Quelle für E-Mails identifiziert.

Überlegungen zur DKIM-Bereitstellung

DKIM für Empfänger

Die Konfiguration der DKIM-Verifizierung auf der ESA ähnelt der SPF-Verifizierung. Setzen Sie in den Standardrichtlinienparametern der Mail Flow-Richtlinien die DKIM-Verifizierung einfach auf "Ein". Da DKIM keine Richtlinienspezifikationen zulässt, wird nur die Signatur überprüft und ein Header "Authentication-Results" eingefügt:

Authentication-Results: mx1.hc4-93.c3s2.smtpi.com; dkim=pass (signaturverifiziert) header.i=MileagePlus@news.united.com

Alle Aktionen, die auf DKIM-Verifizierungsergebnissen basieren, müssen über Content-Filter durchgeführt werden:

Abbildung 2: DKIM-Überprüfung - Inhaltsfilter-Bedingung

Im Gegensatz zu SPF, das einfach aufgebaut ist, verändert DKIM den eigentlichen Nachrichtentext, sodass einige Parameter eingeschränkt sein können. Optional können Sie DKIM-Verifizierungsprofile erstellen und den verschiedenen Mail Flow Policies unterschiedliche Verifizierungsprofile zuweisen. Mit ihnen können Sie die Schlüssellänge der zu akzeptierenden Signaturen begrenzen, Maßnahmen zum Abrufen von Schlüsseln festlegen und die Tiefe der DKIM-Verifizierung konfigurieren.

Wenn eine Nachricht mehrere Gateways passiert, kann sie mehrfach signiert werden und somit mehrere Signaturen enthalten. Damit eine Nachricht die DKIM-Verifizierung übergeben kann, müssen alle Signaturen überprüft werden. Standardmäßig überprüft die ESA bis zu fünf Signaturen.

Aufgrund der historischen Offenheit von SMTP und E-Mail und der Zurückhaltung des gesamten Internets, sich an (positive) Änderungen anzupassen, gibt es immer noch Situationen, in denen DKIM-Signaturen berechtigterweise fehlschlagen könnten, z. B. wenn Mailinglisten-Manager Nachrichten direkt weiterleiten, aber ändern, oder wenn Nachrichten direkt weitergeleitet werden und nicht als Anlagen zu neuen Nachrichten. Aus diesem Grund ist es im Allgemeinen die beste Vorgehensweise für Nachrichten, die bei DKIM nicht funktionieren, weiterhin, eine Quarantäne zu erstellen oder sie zu taggen, anstatt sie zu löschen.

Signieren mit DKIM wird vorbereitet

Bevor Sie die DKIM-Signierung in Ihrer RELAYED Mail Flow Policy aktivieren können, müssen Sie die Schlüssel generieren/importieren, DKIM-Signaturprofile erstellen und die öffentlichen Schlüssel im DNS veröffentlichen.

Wenn Sie für eine einzelne Domäne signieren, ist der Prozess unkompliziert. Generieren Sie das Schlüsselpaar, erstellen Sie Ihr einzelnes Signaturprofil im Abschnitt Domain Keys (Domänenschlüssel) der E-Mail-Richtlinien, und klicken Sie auf die Option Generate (Generieren) unter DNS Text Record (DNS-Textdatensatz), sobald Ihr Profil bereit ist. Veröffentlichen Sie den Schlüssel wie in Ihrem DNS generiert. Aktivieren Sie abschließend die DKIM-Signierung in Ihrer Mail Flow Policy.

Wenn Sie mehrere Domains signieren, wird es noch komplizierter. In diesem Fall haben Sie zwei Möglichkeiten:

1. Verwenden Sie ein einziges Signaturprofil für alle Domänen. Sie speichern den (einzelnen) öffentlichen Schlüssel in der DNS-Zone der "primären" Domäne, und Ihre DKIM-Signaturen verweisen auf diesen Schlüssel. Diese Technik wurde in der Vergangenheit häufig von ESPs eingesetzt. Sie ermöglichte ihnen die Unterzeichnung in großem Umfang, ohne mit dem DNS-Bereich einzelner Kunden interagieren zu müssen [5].
2. Erstellen Sie für jede Domäne, für die Sie sich anmelden, ein separates Signaturprofil. Dies führt zu einer komplexeren Erstkonfiguration, bietet aber auch eine wesentlich größere Flexibilität. Erstellen Sie ein Schlüsselpaar für jede Domäne, erstellen Sie ein Profil, das nur eine Domäne (und deren Subdomänen) im Abschnitt "Profile Users" (Profilbenutzer) angibt, und veröffentlichen Sie den relevanten öffentlichen Schlüssel in der DNS-Zone dieser Domäne.

Obwohl Option #1 einfacher zu starten ist, bedenken Sie, dass es letztendlich DMARC brechen wird. Da DMARC erfordert, dass die Signaturdomänen-ID mit dem Header From (Von) übereinstimmt, schlägt die Anpassung der ID mit DKIM fehl. Wenn Sie Ihren SPF richtig konfigurieren, können Sie dies möglicherweise umgehen und sich bei der DMARC-Verifizierung auf die Ausrichtung der SPF-Kennungen verlassen.

Durch die Implementierung der Option #2 von Anfang an müssen Sie sich jedoch nicht um DMARC kümmern, und es ist ziemlich einfach, den Signierungsdienst für nur eine Domäne zu widerrufen oder neu zu konfigurieren.  Wenn Sie einige E-Mail-Dienste für eine Drittanbieter-Domäne bereitstellen, müssen Sie höchstwahrscheinlich den Schlüssel von ihnen verwenden (und ihn in Ihre ESA importieren). Dieser Schlüssel ist domänenspezifisch, daher müssen Sie ein separates Profil erstellen.

Wenn Sie E-Mail-Services von Drittanbietern nutzen

Wenn Sie das DKIM-Signieren verwenden und einen Teil Ihrer E-Mail-Verarbeitung (z. B. Marketing-E-Mails) an einen Drittanbieter auslagern, sollten im Allgemeinen nicht dieselben Schlüssel verwendet werden, die Sie in der Produktion verwenden. Dies ist einer der Hauptgründe für die Existenz von Selektoren in DKIM. Stattdessen sollten Sie ein neues Schlüsselpaar generieren, den öffentlichen Teil in Ihrer DNS-Zone veröffentlichen und den geheimen Schlüssel an die andere Partei weitergeben. Auf diese Weise können Sie diesen bestimmten Schlüssel bei Problemen schnell widerrufen und gleichzeitig Ihre DKIM-Produktionsinfrastruktur unangetastet lassen.

Obwohl es für DKIM nicht erforderlich ist (Nachrichten für dieselbe Domäne können mit mehreren verschiedenen Schlüsseln signiert werden), empfiehlt es sich, für jede E-Mail, die von einem Drittanbieter verarbeitet wird, eine separate Unterdomäne bereitzustellen. Dies erleichtert die Nachverfolgung der Nachrichten und ermöglicht später eine wesentlich sauberere Implementierung von DMARC. Betrachten Sie als Beispiel diese fünf DKIM-Signature-Header aus mehreren Mitteilungen der Lufthansa:

DKIM-Signatur: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa; d=newsletter.milesandmore.com;

DKIM-Signatur: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa2; d=newsletter.lufthansa.com;

DKIM-Signatur: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa3; d=lh.lufthansa.com;

DKIM-Signatur: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa4; d=e.milesandmore.com

DKIM-Signatur: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa5; d=fly-lh.lufthansa.com;  

Wir sehen, dass Lufthansa fünf verschiedene Schlüssel (Selektoren) verwendet, die auf fünf separate Subdomänen von zwei primären Produktionsdomänen (lufthansa.com und milesandmore.com) aufgeteilt sind. Das bedeutet, dass jede dieser Funktionen unabhängig gesteuert und an einen anderen Messaging-Service Provider ausgelagert werden kann.

Überlegungen zur DMARC-Bereitstellung

DMARC für Empfänger

Die DMARC-Verifizierung auf der ESA ist profilbasiert, aber im Gegensatz zu DKIM muss das Standardprofil bearbeitet werden, um die Spezifikation zu erfüllen. Das Standardverhalten der ESA besteht darin, Nachrichten nur nach ausdrücklicher Anweisung des Kunden zu verwerfen, sodass im standardmäßigen DMARC-Verifizierungsprofil alle Aktionen auf "No Action" (Keine Aktion) eingestellt sind. Um die korrekte Berichterstellung zu ermöglichen, müssen Sie außerdem im DMARC-Bereich von "Mail Policies" die "Global Settings" (Globale Einstellungen) bearbeiten.

Sobald ein Profil eingerichtet wurde, wird die DMARC-Verifizierung wie die beiden anderen im Abschnitt Default Policy Settings (Standardrichtlinieneinstellungen) der Mail Flow Policies (Mail-Fluss-Richtlinien) festgelegt. Stellen Sie sicher, dass Sie das Kontrollkästchen aktivieren, um aggregierte Feedback-Berichte zu senden - dies ist wohl die wichtigste Funktion von DMARC für den Absender. Zum Zeitpunkt der Erstellung dieses Dokuments bietet die ESA keine Unterstützung für die Erstellung von Fehlerberichten pro Nachricht ("ruf"-Tag der DMARC-Richtlinie).

Da DMARC-Richtlinienaktionen vom Absender empfohlen werden, gibt es im Gegensatz zu SPF oder DKIM keine spezifischen Aktionen, die außerhalb der Profilkonfiguration konfiguriert werden können. Es ist nicht erforderlich, Content-Filter zu erstellen.

Durch die DMARC-Verifizierung werden dem Header "Authentication-Results" weitere Felder hinzugefügt:

Authentifizierungsergebnisse: mx1.hc4-93.c3s2.smtpi.com; dkim=pass (signature verified) header.i=MileagePlus@news.united.com; dmarc=pass (p=none dis=none) d=news.united.com

Im obigen Beispiel wird festgestellt, dass DMARC anhand der DKIM-ID-Ausrichtung und der vom Sender angeforderten Richtlinie "none" überprüft wurde. Dies weist darauf hin, dass sie sich derzeit in der Überwachungsphase der DMARC-Bereitstellung befinden.

Wenn Sie E-Mail-Services für andere Domänen oder Drittanbieter bereitstellen,

Das größte Problem von ESPs bei der DMARC-Konformität ist die korrekte Ausrichtung der Kennungen. Wenn Sie DMARC planen, stellen Sie sicher, dass Ihr SPF korrekt eingerichtet ist, dass alle relevanten anderen Domänen Ihre ausgehenden Gateways in Ihren SPF-Datensätzen haben und dass sie keine Nachrichten senden, die nicht ausgerichtet werden können. Dies geschieht hauptsächlich durch die Verwendung verschiedener Domänen für die Identität MAIL FROM und Header From. Dieser Fehler wird meistens von Anwendungen verursacht, die E-Mail-Benachrichtigungen oder -Warnungen senden, da die Autoren von Anwendungen die Folgen der Inkonsistenz ihrer E-Mail-Identitäten nicht kennen.

Stellen Sie, wie zuvor beschrieben, sicher, dass Sie für jede Domäne ein separates DKIM-Signaturprofil verwenden und dass Ihr Signaturprofil korrekt auf die Domäne verweist, für die Sie signieren, wie in Header From (Von Header) verwendet. Wenn Sie Ihre eigenen Subdomains verwenden, können Sie mit einem einzigen Schlüssel signieren, aber stellen Sie sicher, dass Sie DKIM in der DMARC-Richtlinie ("adkim="r") entspannt einhalten.

Wenn Sie E-Mail-Services für eine größere Anzahl von Drittanbietern anbieten, über die Sie keine direkte Kontrolle haben, empfiehlt es sich, ein Dokument mit einem Leitfaden zu verfassen, in dem erläutert wird, wie Sie eine E-Mail senden, die am ehesten den gewünschten Inhalt liefert. Da sich Benutzer-zu-Benutzer-E-Mails im Allgemeinen gut verhalten, wird dies in den oben genannten Beispielen in den meisten Fällen als Richtliniendokument für Anwendungsautoren dienen.

Wenn Sie E-Mail-Services von Drittanbietern nutzen

Wenn Sie einen Teil Ihres E-Mail-Verkehrs über Drittanbieter bereitstellen, ist der optimale Weg, eine separate Subdomäne (oder eine komplett andere Domäne) an den Drittanbieter zu delegieren. Auf diese Weise können sie die SPF-Datensätze nach Bedarf verwalten, verfügen über eine separate DKIM-Signaturinfrastruktur und stören nicht den Produktionsdatenverkehr. In diesem Fall kann die DMARC-Richtlinie für ausgelagerte E-Mails anders lauten als für interne E-Mails. Stellen Sie, wie bereits erwähnt, bei der Prüfung der von einem Drittanbieter bereitgestellten E-Mail sicher, dass Ihre Kennungen übereinstimmen und dass Ihre Einhaltung von DKIM und SPF in Ihrer DMARC-Richtlinie entsprechend festgelegt ist.

(Sub)Domänen ohne E-Mail-Verkehr

Eine weitere Verbesserung von DMARC gegenüber früheren E-Mail-Authentifizierungstechnologien ist der Umgang mit Subdomänen. Standardmäßig gilt die DMARC-Richtlinie einer bestimmten Domäne für alle untergeordneten Domänen. Wenn beim Abruf von DMARC-Richtliniendatensätzen kein Datensatz auf der Ebene Header From FQDN gefunden werden kann, müssen Empfänger die Organisationsdomäne [6] des Absenders ermitteln und dort nach einem Richtliniendatensatz suchen.

Die DMARC-Richtlinie für eine Organisationsdomäne kann jedoch auch eine separate Subdomänenrichtlinie ("sp"-Tag eines DMARC-Datensatzes) angeben, die für alle Subdomänen gilt, für die keine explizite DMARC-Richtlinie veröffentlicht wurde.

In dem Szenario, das weiter oben im SPF-Kapitel besprochen wurde, würden Sie:

1. Veröffentlichen Sie einen expliziten DMARC-Datensatz für alle Subdomänen, die legitime E-Mail-Quellen sind.
2. Veröffentlichen Sie eine Subdomänenrichtlinie mit dem Vermerk "reject" (ablehnen) in Ihrem Organisationsdomänenrichtliniendatensatz, um E-Mails, die nicht sendende Domänen manipulieren, automatisch abzulehnen.

Diese Art der Strukturierung Ihrer E-Mail-Authentifizierung sorgt für den bestmöglichen Schutz Ihrer Infrastruktur und Marke.

DMARC-spezifische Probleme

Es gibt mehrere potenzielle Probleme mit DMARC, die alle von der Art und den Mängeln anderer Authentifizierungstechnologien herrühren, auf die es angewiesen ist. Das Problem ist, dass DMARC diese Probleme an die Oberfläche brachte, indem es eine Richtlinie aktiv drückte, um die E-Mail abzulehnen, und indem es alle verschiedenen Absender-IDs in einer Nachricht korrelierte.

Die meisten Probleme treten bei Mailinglisten und Mailinglisten-Verwaltungssoftware auf. Wenn eine E-Mail an eine Mailingliste gesendet wird, wird sie an alle Empfänger weitergeleitet. Die resultierende E-Mail mit einer Absenderadresse des ursprünglichen Absenders wird jedoch von der Hostinginfrastruktur des Mailinglisten-Managers zugestellt, sodass die SPF-Prüfung für den Header From (von dem die meisten Mailinglisten-Manager die Listenadresse als Umschlag From (MAIL FROM) und die Adresse des ursprünglichen Absenders als Header From) nicht besteht.

Da DMARC bei SPF ausfällt, verlassen wir uns möglicherweise auf DKIM. Die meisten Mailinglisten-Manager fügen jedoch Nachrichten Fußzeilen hinzu oder markieren Themen mit dem Listennamen, wodurch die DKIM-Signaturüberprüfung unterbrochen wird.

Die Autoren von DKIM schlagen mehrere Lösungen für das Problem vor, die alle darauf hinauslaufen, dass die Mailinglisten-Manager die Adresse der Liste in allen Absenderadressen verwenden und die ursprüngliche Absenderadresse auf andere Weise angeben müssen.

Ähnliche Probleme ergeben sich aus Nachrichten, die weitergeleitet werden, indem die ursprüngliche Nachricht einfach über SMTP auf den neuen Empfänger kopiert wird. Die meisten derzeit verwendeten Mail User Agents bilden jedoch korrekt eine neue Nachricht und enthalten die weitergeleitete Nachricht entweder inline oder als Anhang an die neue Nachricht. Auf diese Weise weitergeleitete Nachrichten werden bei Bestehen des weiterleitenden Benutzers an DMARC weitergeleitet (die Authentizität der ursprünglichen Nachricht kann natürlich nicht festgestellt werden).

Beispielaktionsplan zur Implementierung der E-Mail-Authentifizierung

Auch wenn die Technologien selbst einfach sind, kann der Weg zur Implementierung einer kompletten E-Mail-Authentifizierungsinfrastruktur lang und mühsam sein. Für kleinere Unternehmen und Unternehmen mit kontrolliertem E-Mail-Verkehr ist dies relativ unkompliziert, während größere Umgebungen eine außergewöhnliche Herausforderung darstellen. Es ist nicht unüblich, dass große Unternehmen Beratungsdienste für die Verwaltung des Implementierungsprojekts einstellen.

Schritt 1: DKIM

DKIM ist relativ unaufdringlich, da nicht signierte Nachrichten nicht abgelehnt werden. Berücksichtigen Sie vor der tatsächlichen Umsetzung alle zuvor genannten Punkte. Wenden Sie sich an Drittanbieter, an die Sie die Signierung delegieren können, stellen Sie sicher, dass Ihre Drittanbieter die DKIM-Signierung unterstützen, und berücksichtigen Sie Ihre Selektor-Management-Strategie. Einige Organisationen würden separate Schlüssel (Selektoren) für verschiedene Organisationseinheiten behalten. Möglicherweise erwägen Sie aus Sicherheitsgründen die regelmäßige Rotation von Schlüsseln. Stellen Sie jedoch sicher, dass Sie Ihre alten Schlüssel erst löschen, wenn alle Nachrichten bei der Übertragung zugestellt wurden.

Besondere Beachtung sollte den Schlüsselgrößen geschenkt werden. Obwohl im Allgemeinen "mehr ist besser", müssen Sie berücksichtigen, dass das Erstellen von zwei digitalen Signaturen pro Nachricht (einschließlich Kanonisierung, etc.) eine sehr CPU-teure Aufgabe ist und die Leistung von ausgehenden Mail-Gateways beeinflussen kann. Aufgrund des Computing-Overheads stellen 2048 Bit die größte praktikable Schlüsselgröße dar, die verwendet werden kann. Bei den meisten Bereitstellungen stellen 1024-Bit-Schlüssel jedoch einen guten Kompromiss zwischen Leistung und Sicherheit dar.

Für die erfolgreiche spätere Implementierung von DMARC sollten Sie:

1. Identifizieren aller Domänen, als die Sie senden, einschließlich der Subdomänen
2. DKIM-Schlüssel generieren und Signaturprofile für jede Domäne erstellen
3. Bereitstellung relevanter privater Schlüssel für Dritte
4. Veröffentlichung aller öffentlichen Schlüssel in den relevanten DNS-Zonen
5. überprüfen, ob Dritte bereit sind, mit der Unterzeichnung zu beginnen
6. Aktivieren Sie die DKIM-Signierung in RELAYED Mail Flow Policy auf allen ESAs.
7. Drittanbietern mitteilen, mit der Unterzeichnung zu beginnen

Schritt 2: SPF

Die ordnungsgemäße Implementierung von SPF ist wahrscheinlich der zeitaufwendigste und umständlichste Teil der Implementierung einer E-Mail-Authentifizierungsinfrastruktur. Da die E-Mail-Funktion sehr einfach zu verwenden und zu verwalten war und in Bezug auf Sicherheit und Zugriff vollständig offen war, waren in der Vergangenheit strenge Richtlinien für die Benutzer und die Art der Nutzung nicht ausreichend. Dies führte dazu, dass die meisten Unternehmen heute nicht über die vollständige Übersicht über die verschiedenen E-Mail-Quellen verfügen, und zwar sowohl intern als auch extern. Das größte Problem bei der Implementierung von SPF besteht darin, herauszufinden, wer derzeit berechtigterweise E-Mails in Ihrem Namen versendet.

Wichtige Informationen:

1. Offensichtliche Ziele - Exchange- oder andere Groupware-Server oder ausgehende Mail-Gateways
2. DLP-Lösungen oder andere E-Mail-Verarbeitungssysteme, die externe Benachrichtigungen generieren können
3. CRM-Systeme senden Informationen, die mit Kunden interagieren
4. Verschiedene Anwendungen von Drittanbietern, die E-Mails versenden können
5. Labor, Test oder andere Server, die E-Mails
6. PCs und Geräte, die so konfiguriert sind, dass sie eine externe E-Mail direkt senden

Die obige Liste ist nicht vollständig, da Organisationen über verschiedene Umgebungen verfügen. Sie sollte jedoch als allgemeine Richtlinie für die zu suchenden Elemente betrachtet werden. Sobald (die meisten) Ihrer E-Mail-Quellen identifiziert wurden, können Sie einen Schritt zurück gehen, und anstatt jede einzelne vorhandene Quelle zu autorisieren, bereinigen Sie die Liste. Im Idealfall sollten alle ausgehenden E-Mails über die Gateways für ausgehende E-Mails versendet werden, mit einigen gerechtfertigten Ausnahmen. Wenn Sie Ihre eigene Marketing-Mail-Lösung oder eine Marketing-Mail-Lösung eines Drittanbieters verwenden, sollten Sie eine separate Infrastruktur als die E-Mail-Gateways für die Produktion verwenden. Wenn Ihr Mail-Zustellnetz außerordentlich kompliziert ist, können Sie mit der Dokumentation des aktuellen Zustands in Ihrem SPF fortfahren, benötigen aber Zeit, um die Situation in Zukunft zu bereinigen.

Wenn Sie mehrere Domänen über dieselbe Infrastruktur bedienen, können Sie einen einzigen universellen SPF-Datensatz erstellen und diesen mithilfe des Include-Mechanismus in einzelnen Domänen referenzieren. Achten Sie darauf, dass Ihre SPF-Datensätze nicht zu breit sind. Wenn z. B. nur fünf Computer in einem /24-Netzwerk SMTP senden, fügen Sie diese fünf individuellen IP-Adressen zu Ihrem SPF hinzu und nicht das gesamte Netzwerk. Achten Sie darauf, dass Ihre Aufzeichnungen so präzise wie möglich sind, um das Risiko einer Gefährdung Ihrer Identität durch bösartige E-Mails zu minimieren.

Beginnen Sie mit einer Softfail-Option für nicht übereinstimmende Absender ("~all"). Ändern Sie es nur zu hardfail (-all), sobald Sie 100% sicher sind, dass Sie alle Ihre Quellen von E-Mail identifiziert haben, sonst riskieren Sie, Produktions-E-Mail zu verlieren. Später, nachdem Sie DMARC implementiert und für eine Weile im Überwachungsmodus ausgeführt haben, werden Sie in der Lage sein, alle Systeme zu identifizieren, die Sie verpasst haben, und Ihre SPF-Datensätze zu aktualisieren, um vollständig zu sein. Nur dann ist es sicher, Ihre SPF auf hardfail einzustellen.

Schritt 3: DMARC

Sobald DKIM und SPF so vollständig wie möglich eingerichtet sind, ist es an der Zeit, DMARC-Richtlinien zu erstellen. Berücksichtigen Sie die verschiedenen Situationen, die in den vorherigen Kapiteln erwähnt wurden, und bereiten Sie sich darauf vor, mehr als einen DMARC-Datensatz bereitzustellen, wenn Sie eine komplexe E-Mail-Infrastruktur haben.

Erstellen Sie E-Mail-Aliase, die Berichte empfangen, oder erstellen Sie eine Webanwendung, die diese aufzeichnen kann. Es gibt keine streng definierten E-Mail-Adressen für diesen Zweck, aber es hilft, wenn sie beschreibend sind, z. B. rua@domain.com, dmarc.rua@domain.com, mailauth-rua@domain.com, etc. Stellen Sie sicher, dass ein Operator diese Adressen überwachen und die SPF-, DKIM- und DMARC-Konfiguration entsprechend ändern kann, oder benachrichtigen Sie das Sicherheitsteam im Falle einer Spoofing-Kampagne. Der Workload wird zunächst erheblich sein, wenn Sie die Datensätze so anpassen, dass alle Fehler abgedeckt werden, die während der SPF- und DKIM-Konfiguration möglicherweise aufgetreten sind. Nach einiger Zeit werden Berichte wahrscheinlich nur noch Spoofing-Versuche anzeigen.

Legen Sie zunächst die DMARC-Richtlinie auf "none" und die forensische Option zum Senden von Berichten für fehlgeschlagene Prüfungen fest ("fo=1"). Dadurch werden Fehler in SPF und DKIM schnell erkannt, ohne den Datenverkehr zu beeinflussen. Sobald Sie mit dem Inhalt der übermittelten Berichte zufrieden sind, ändern Sie die Richtlinie je nach Sicherheitsrichtlinie und Voreinstellungen in "Quarantäne" oder "Ablehnen". Stellen Sie auch hier sicher, dass die Bediener Ihre empfangenen DMARC-Berichte kontinuierlich auf Fehlalarme analysieren.

Die vollständige und korrekte Implementierung von DMARC ist keine kleine oder kleine Aufgabe. Während einige Ergebnisse (und die formelle "Umsetzung" von DMARC) durch die Veröffentlichung einer unvollständigen Liste von Datensätzen und einer Richtlinie "keine" erzielt werden können, ist es im besten Interesse sowohl der Absenderorganisation als auch des Internet als Ganzes, dass jeder es in vollem Umfang seiner Fähigkeiten implementiert.

Was den Zeitrahmen angeht, so sind hier die einzelnen Schritte für ein typisches Projekt sehr grob umrissen. Da jede Organisation anders ist, sind diese wiederum alles andere als zutreffend:

1. Planung und Vorbereitung des DKIM	2-4 Wochen
2. DKIM-Testläufe	-2 Wochen
3. SPF - legitime Absenderkennung	2-4 Wochen
4. DMARC-Richtlinienvorbereitung	-2 Wochen
5. SPF- und DMARC-Datensätze Testlauf	4-8 Wochen
6. SPF-Testlauf mit hardfail	-2 Wochen
7. DMARC-Testlauf mit Quarantäne/Ablehnen	-4 Wochen
8. DMARC-Berichte überwachen und SPF/DKIM entsprechend anpassen	kontinuierlich

Kleinere Unternehmen werden wahrscheinlich eine kürzere Dauer der meisten Schritte erleben, insbesondere Schritt 3 und 4. Unabhängig davon, wie einfach Ihre E-Mail-Infrastruktur Ihrer Meinung nach auch sein mag, sollten Sie während der Testläufe immer ausreichend Zeit aufwenden und die Feedback-Berichte genau überwachen, um etwaige Fehler zu beheben.

In größeren Unternehmen kann die Dauer derselben Schritte sogar noch länger sein, und es gelten strengere Testanforderungen. Es ist nicht unüblich, dass Unternehmen mit komplexer E-Mail-Infrastruktur externe Hilfe einstellen, nicht nur für den technischen Aspekt der E-Mail-Authentifizierungsimplementierung, sondern auch um das gesamte Projekt zu verwalten und über Teams und Abteilungen hinweg zu koordinieren.

Weitere Referenzen

• Die Referenzwebsite für SPF: http://www.openspf.org
• Der Rat der DKIM: http://www.dkim.org
• DMARC-Haupt-Website, betrieben vom Trusted Domain Project: http://www.dmarc.org
• dmarcian - eine Hilfe- und Ressourcen-Website, die von Tim Draegen, einem der Autoren von DMARC, betrieben wird. Besuchen Sie unbedingt den Bereich "Tools": http://www.dmarcian.com
• Record Validator-Tool der Online Trust Alliance: https://otalliance.org/resources/spf-dmarc-record-validator
• DMARC Record Assistant - ein weiteres nützliches Tool zur Erstellung Ihrer DMARC-Datensätze: http://www.kitterman.com/dmarc/assistant.html
• Tools für SPF-Datensatztests: http://www.kitterman.com/spf/validate.html
• "Don’t Be a Phish: Deep Dive Into Email Authentication Techniques", eine Präsentation auf der Cisco Live 2014, BRKSEC-3770: https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=76627

[1] Die Kanonisierung geht über den Anwendungsbereich dieses Dokuments hinaus. Weitere Informationen zur DKIM-Canonicalization finden Sie im Abschnitt "Zusätzliche Referenzen".

[2] DKIM DNS-Eintragsparameter werden in diesem Dokument ebenfalls nicht behandelt.

[3] Die Erstellung von Nachrichtenfiltern geht über den Rahmen dieses Dokuments hinaus. Weitere Unterstützung finden Sie in den Benutzerhandbüchern zu AsyncOS für E-Mail.

[4] M3AAWG hat eine Reihe hervorragender Best Practices definiert, die von den meisten Unternehmen der Branche angewandt und eingehalten wurden. Das Dokument zu Best Practices für Absender finden Sie unter https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Senders_BCP_Ver3-2015-02.pdf

[5] Dieses Verhalten nutzt die Tatsache aus, dass DKIM ursprünglich die Nachrichtenquelle nicht überprüft, wie in MAIL FROM oder Header From angegeben. Es wird nur überprüft, ob die Signaturdomänen-ID ("d"-Parameter der DKIM-Signatur und "Domain Name"-Parameter in Ihrem Signaturprofil) tatsächlich den öffentlichen Schlüssel des Paars hostet, das zum Signieren der Nachricht verwendet wird. Die Absenderauthentizität wird impliziert, indem der "Von"-Header signiert wird. Stellen Sie sicher, dass Sie alle Domains (und Subdomains), für die Sie sich anmelden, im Abschnitt "Profile Users" (Profilbenutzer) auflisten.

[6] Normalerweise eine Domäne eine Ebene unter TLD oder einem relevanten ccTLD-Präfix (.ac.uk, .com.sg usw.).