Erhöhung der E-Mail-Sicherheit: Stoppen Sie Absenderbetrug mit SPF, DKIM und DMARC

Die Wahrheit lässt sich nicht herausfiltern: Sie müssen die E-Mails Ihres Unternehmens schützen.

Im Jahr 2013 wurden täglich mehr als 100 Milliarden Geschäfts-E-Mails versendet und empfangen. Nur jede fünfte der 2013 versendeten E-Mails war legitim, und 92 % aller illegitimen E-Mails enthielten Links zu potenziell bösartigen Inhalten.

Es gibt jedoch Anzeichen für eine Verbesserung: Dieser Monat ist der erste in den letzten 12 Jahren, in dem weniger als die Hälfte der E-Mails von Symantec-Kunden Spam waren.

Der Rückgang von Spam ist drei E-Mail-Sicherheitsstandards (und anderen Initiativen) zu verdanken: SPF, DKIM und DMARC. Dennoch sind Sicherheitsrisiken nach wie vor weit verbreitet. Vor kurzem wurde mir eine Geschichte über einen CFO erzählt, der einem Phishing-Versuch ausgesetzt war. Der Versuch schlug fehl, aber wenn er erfolgreich gewesen wäre, hätte er das Unternehmen 50.000 Dollar gekostet.

Was diese E-Mail-Standards betrifft, so herrscht immer noch große Verwirrung darüber. Ich hoffe, dass ich mit diesem Beitrag etwas Klarheit schaffen kann und Ihnen zeigen kann, wie Sie SPF, DKIM und DMARC implementieren können.

Sender Policy Framework (RFC 4408)

Sender Policy Framework, oder SPF, ist der alte Hase bei der E-Mail-Authentifizierung. SPF ist ein offener Standard, der laut openspf.org eine Methode zur Verhinderung der Fälschung von Absenderadressen festlegt. Es geht nicht darum, Spam zu stoppen; es geht darum, versuchte Absenderfälschungen zu kontrollieren und zu stoppen.

SPF ermöglicht es Ihnen, die legitimen E-Mail-Quellen Ihrer Domäne zu identifizieren und verhindert, dass nicht autorisierte Quellen Tausende – oder sogar Millionen – illegaler E-Mails von Ihrer Domäne senden.

Es gibt vier Arten von E-Mail-Missbrauch, die üblicherweise mit E-Mail-Absenderfälschung in Verbindung gebracht werden:

• Spam (unerwünschte Massen-E-Mails & unerwünschte kommerzielle E-Mails)
• Betrüger (419-Betrug)
• Malware (Adware, Zero Days, Viren, Trojaner usw.)
• Phisher (Spear-Phishing)

Aus offensichtlichen Gründen möchten Sie nicht, dass die Domäne Ihres Unternehmens mit einem dieser Fälle in Verbindung gebracht wird. SPF stellt sicher, dass die E-Mails Ihrer Organisation tatsächlich von Ihnen stammen.

DomainKeys Identified Mail (RFC 6376, ersetzt RFC 4871 und RFC 5672, die inzwischen veraltet sind)

DKIM oder DomainKeys Identified Mail ist ein TXT-Eintrag, der in Ihrem Domain Name System (DNS) veröffentlicht wird. Er beinhaltet etwas, das alle IT-Administratoren lieben lernen sollten: Schlüssel – öffentliche Schlüssel, um genau zu sein.

Bevor wir uns mit DKIM beschäftigen, ist es wichtig zu verstehen, was Schlüssel sind und wie sie funktionieren. Schlüssel, in diesem Fall die Public-Key-Kryptografie, bestehen aus einem öffentlichen (allen bekannten) und einem privaten (oft als geheim bezeichneten) Schlüssel. Öffentliche und private Schlüssel sind mathematisch miteinander verknüpft und ermöglichen eine sichere Kommunikation über öffentliche Kanäle.

Diese Schlüssel sind wie ein manipulationssicheres Siegel auf einem transparenten Umschlag. Sie verstecken nicht unbedingt die Nachricht, sondern authentifizieren nur mit 100%iger Sicherheit sowohl den Absender als auch die Nachricht.

Nun zurück zu DKIM.

„Technisch gesehen bietet DKIM eine Methode zur Validierung der Identität eines Domänennamens, der mit einer Nachricht durch kryptographische Authentifizierung verbunden ist“, so dkim.org. Mit anderen Worten: DKIM verwendet Schlüssel, um sicherzustellen, dass ein E-Mail-Absender auch wirklich der ist, für den er sich ausgibt.

Mit DKIM werden öffentliche und private Schlüsselpaare generiert, um die Authentifizierung von Mail-Servern und Kommunikation zu gewährleisten. Jeder ausgehende SMTP-Server (Simple Mail Transfer Protocol) benötigt den richtigen privaten Schlüssel und das richtige Präfix, um mit einem öffentlichen DNS-Eintrag übereinzustimmen, den der empfangende E-Mail-Server dann überprüft.

Haben Sie sich schon einmal gefragt, warum das Schlosssymbol in Google Mail angezeigt wird, wenn Sie Nachrichten von eBay, Paypal oder Ihrer Bank erhalten? Das liegt an DKIM und ein wenig an DMARC (auf das wir gleich noch eingehen werden). Unten zeigt mailed-by die SPF-Übereinstimmung und signed-by die DKIM-Übereinstimmung an. DKIM und DMARC sind noch nicht unentbehrlich, aber wie IPv6 entwickeln sie sich schnell vom Testlabor zum „better-have“.

Domain-based Message Authentication, Reporting, and Conformance (RFC 7489)

DMARC, oder Domain-based Message Authentication, Reporting, and Conformance, hilft Absendern und Empfängern bei der Zusammenarbeit, um die E-Mail-Kommunikation sicherer zu gestalten. DMARC wurde von einer Gruppe von Organisationen ins Leben gerufen, um den E-Mail-Missbrauch einzuschränken, „indem einige seit langem bestehende Probleme im Zusammenhang mit E-Mail-Authentifizierungsprotokollen in Bezug auf Betrieb, Bereitstellung und Berichterstattung gelöst wurden“, so dmarc.org.

DMARC ermöglicht es dem Absender, anzugeben, dass seine Nachrichten mit SPF und/oder DKIM geschützt sind. Eine DMARC-Richtlinie enthält klare Anweisungen für den Empfänger, die er befolgen muss, wenn eine E-Mail die SPF- oder DKIM-Authentifizierung nicht besteht, z. B. sie zurückzuweisen oder zu verwerfen.

Außerdem sendet DMARC einen Bericht an den Absender über Nachrichten, die die DMARC-Bewertung BESTANDEN und/oder nicht bestanden haben.

Wie man SPF, DKIM und DMARC implementiert

Nachdem wir nun ein besseres Verständnis für jeden dieser drei Standards haben (und warum sie wichtig sind), wollen wir uns nun ansehen, wie Sie Ihre E-Mail-Sicherheit durch deren Implementierung verbessern können.

Hinweis: Für diese Schritt-für-Schritt-Anleitung nehmen wir an, dass Sie der IT-Leiter von 301 Moved sind, einer kleinen Webdesign-Firma, die Google Apps verwendet.

In letzter Zeit hatten Sie einige Probleme mit russischen Spam-Bots. Ihre Endnutzer haben sich darüber beschwert, dass sie E-Mail-Bounce-Benachrichtigungen von Adressen erhalten haben, die sie nie gesehen oder an die sie nie Nachrichten gesendet haben. Sie stellen fest, dass jemand eindeutig betrügerische E-Mails von Ihrer Domäne aus versendet.

Wie können Sie das verhindern?

Hinweis: Ich füge das Standard-BIND-Format in Klartext und einen Screenshot des Eintrags in GoDaddy DNS bei. In GoDaddy verwenden alle Einträge für die Top-Level-Domain 301Moved.com den Host „@“, Ihr Host wird wahrscheinlich anders sein. Im Rahmen dieser Übung gehe ich nur auf ausgehende Post ein und nicht darauf, wie wir diese Standards in Bezug auf eingehende Post von externen Absendern behandeln.

Implementierung von SPF

Schritt eins: Die Anleitung von Google zur Konfiguration von SPF-Einträgen für Google Apps ist ein guter Ausgangspunkt. Nach diesen Anweisungen fügen wir einen neuen TXT-Eintrag zu unserem öffentlichen DNS hinzu.

301Moved.com. IN TXT "v=spf1 include:_spf.google.com ~all"

301 Moved verwendet auch Zendesk, ein Ticketingsystem, das E-Mails direkt von Ihrer Domain aus versendet. Sie müssen sicherstellen, dass auch von dort kein Spam versendet wird.

Zweiter Schritt: Suchen Sie den SPF-Eintrag von Zendesk und fügen Sie ihn hinzu.

301Moved.com. IN TXT "v=spf1 include:mail.zendesk.com include:_spf.google.com ~all"

Es ist wichtig zu beachten, dass wir keinen zweiten SPF-Eintrag hinzufügen, denn das würde alles kaputt machen; stattdessen kombinieren wir sie in einem einzigen Eintrag, der länger wird, wenn mehr Absender hinzugefügt werden.

Hinweis: Sie können nur einen SPF-Eintrag pro Domäne oder Subdomäne hinzufügen.

Sie wissen auch, dass 301 Moved ein altes E-Mail-Gateway in den Räumlichkeiten hat, das einige Legacy-Sachen verarbeitet, also fügen wir auch dessen IP-Block hinzu. 301 Moved verwendet den „IP4“-Mechanismus, um den eigenen IP-Block zu definieren-198.51.100.0/24 (192.51.100.0-254).

Nutzen Sie den SPF Surveyor von Dmarcian, um Ihre SPF-Einträge einzusehen.

Schritt 3: Fügen Sie einzelne IPv4-Adressen und Netzblöcke in Classless Inter-Domain Routing (CIDR)-Notation hinzu. 198.51.100.0 für eine einzelne IP-Adresse (kein /32 erforderlich) und 198.51.100.0/24 für Subnetze.

301Moved.com. IN TXT "v=spf1 ip4:198.51.100.0/24 include:mail.zendesk.com include:_spf.google.com ~all"

Das Hinzufügen des alten E-Mail-Gateways stellt sicher, dass ausgehende E-Mails vom Gateway SPF-autorisiert sind.

Die oben genannten Mechanismen sind die am häufigsten verwendeten, aber es gibt insgesamt acht – einschließlich der seltsamen und veralteten. Diese Mechanismen definieren nur den Umfang der Übereinstimmung, nicht die Aktionen selbst.

Die Qualifier im nächsten Abschnitt sind die Stellen, an denen PASS, SOFTFAIL und FAIL definiert werden können – eine Übereinstimmung würde dazu führen, dass eine der drei Aktionen (PASS, SOFTFAIL und FAIL) ausgelöst wird.

• ALL: Alles, was nicht bereits durch einen anderen Mechanismus definiert ist, wird mit dem All-Mechanismus abgeglichen
• A: Wenn der Domänenname einen Adresseintrag (A oder AAAA) hat, der in die Adresse des Absenders aufgelöst werden kann, wird er abgeglichen.
• IP4: Wenn der Absender in einem bestimmten IPv4-Adressbereich liegt, wird er abgeglichen.
• IP6: Wenn der Absender in einem bestimmten IPv6-Adressbereich liegt, wird er abgeglichen.
• MX: Wenn der Domänenname einen MX-Eintrag hat, der die Adresse des Absenders auflöst, wird er übereinstimmen (d.h. die E-Mail kommt von einem der Posteingangsserver der Domäne).
• PTR: Wenn der Domänenname (PTR-Eintrag) für die Adresse des Kunden in der gegebenen Domäne ist und dieser Domänenname die Adresse des Kunden auflöst (vorwärtsbestätigter Reverse DNS), wird er übereinstimmen. Dieser Mechanismus ist veraltet und sollte nicht mehr verwendet werden.
• EXISTS: Wenn der angegebene Domänenname zu einer beliebigen Adresse aufgelöst wird, wird er übereinstimmen (unabhängig von der Adresse, zu der er aufgelöst wird). Dies wird selten verwendet. Zusammen mit der SPF-Makrosprache bietet sie komplexere Übereinstimmungen wie DNSBL-Abfragen.
• INCLUDE: Wenn die eingeschlossene (eine falsche Bezeichnung) Richtlinie den Test besteht, passt dieser Mechanismus. Dieser Mechanismus wird in der Regel verwendet, um Richtlinien von mehr als einem ISP einzuschließen.

Als nächstes kommen die Qualifizierer. Es gibt unzählige Möglichkeiten, diese mit einem Blacklist- und/oder einem Whitelist-Modell zu kombinieren, aber für unsere Zwecke hier werden wir nur die drei oben erwähnten Nachschlagemechanismen mit einem einzigen Qualifier am Ende einbeziehen, um eine Whitelist zu erstellen. Unsere vier Qualifizierer sind:

• + für ein PASS-Ergebnis. Dies kann weggelassen werden; z.B. ist +mx das gleiche wie mx.
• ? für ein NEUTRAL-Ergebnis, das wie NONE (keine Richtlinie) interpretiert wird.
• ~ (Tilde) für SOFTFAIL, eine Debugging-Hilfe zwischen NEUTRAL und FAIL. Normalerweise werden Nachrichten, die ein SOFTFAIL zurückgeben, akzeptiert, aber gekennzeichnet.
• – (Minus) für FAIL, die Nachricht sollte zurückgewiesen werden (siehe unten).

Schritt Vier: Wenden Sie die SOFTFAIL-Richtlinie an.

Zurzeit wird bei 301 Moved die Tilde für SOFTFAIL verwendet. Durch die Verwendung der Tilde würden alle E-Mails, die nicht zu Google, Zendesk oder dem genannten IP-Block passen, SOFTFAIL. Die Mails werden trotzdem zugestellt, aber sie werden wahrscheinlich in den Spam- oder Junk-Ordner verschoben. Dies hängt jedoch ausschließlich vom Mailserver des Empfängers ab. Es ist nicht durch irgendwelche Standards definiert.

Ein „-“ (Minus) würde in dieser Situation nicht übereinstimmende Mails komplett ablehnen (und wahrscheinlich bouncen). Sie können das einschalten, sobald Sie mehr Einblick in Ihre ausgehende Post erhalten (warten Sie auf DMARC) und sobald Sie sich mit Ihrer Mail-Infrastruktur besser auskennen.

SPF ist großartig, weil die Mailserver selbst nicht verändert werden. Die Kopfzeilen bleiben gleich. Mit einem einfachen TXT-Eintrag (der eigentliche SPF-Eintrag war nie sehr beliebt und ist inzwischen veraltet) können Sie den meisten Mailservern auf der Welt mitteilen, wer Ihren Namen verwenden soll.

Am Ende des Tages vergleicht der empfangende SMTP-Server die IP-Adresse des Absenders mit Ihrem SPF-Eintrag, den er abgefragt hat, und wendet dann die Richtlinie gemäß Ihren Anweisungen an. Mit anderen Worten: Sie ermächtigen sich selbst und Ihre Provider, (größtenteils) vertrauenswürdige E-Mails zu versenden, weil Sie eine Zugangskontrollliste (ACL) veröffentlichen.

Nachrichten können jedoch während der Übertragung verändert werden, und gewiefte Fälscher und Phisher können SPF auf interessante Weise umgehen (vielleicht ein Thema für einen anderen Tag). Es handelt sich um SMTP: End-to-End-TLS ist nicht garantiert, so dass wir immer von Klartext ausgehen müssen. Nachrichten können manipuliert oder gefälscht werden.

But enter stage right…

Implementing DomainKeys Identified Mail

Wenn Mails gesendet werden, signiert 301Moved.com (ohne Verschlüsselung) Mails mit dem privaten Schlüssel. Von nun an wird jede Änderung an der Nachricht, einschließlich des Textes, der Kopfzeilen oder der Anhänge, die Signatur brechen und die Nachricht ungültig machen. Auch hier verweisen wir auf den Artikel von Google: Authentifizierung von E-Mails mit DKIM

Schritt fünf: Fügen Sie den öffentlichen Schlüssel zu Ihrem DNS-Eintrag hinzu.

google._domainkey.301Moved.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCsC1iZ3D7AR3FrKtBYfnoKztCGgExFIReC0b1MPY1rpGZa9aTBYq7cDV6F8lzDVr8/K+z9Xt1gUV4P7tT8wuwgacR4oqiAWaUprbnINAxinJr4ohB1TIW3diX2fEA2t5kyUGCGziJFlHicZyJbk5QEaVLcSFD4V8R9f0Voz4P4jQIDAQAB"

Jeder DKIM-Eintrag hat ein eindeutiges Selektorpräfix, was bedeutet, dass wir mehr als einen veröffentlichen können. Anstatt sie zu einem einzigen Datensatz zu kombinieren, wie wir es bei SPF getan haben, können Sie eindeutige Selektoren verwenden und so viele öffentliche Schlüssel wie nötig veröffentlichen. Auf diese Weise können wir eine große Anzahl von DKIM-autorisierten Servern ohne Obergrenzen hinzufügen.

Sie werden feststellen, dass das obige Präfix „google“ ist, der Standard, den Google Apps bei der Erstellung eines DKIM-Datensatzes für die Veröffentlichung verwendet. Sie können dies in Google und den meisten anderen Einrichtungen ändern. Wenn Sie also das Präfix „dkimawesome“ wünschen, steht dem nichts im Wege.

Einige Cloud-Anbieter gehen anders vor. Anstatt eindeutige Schlüsselpaare für jeden Cloud-Mandanten zu generieren, signieren sie alle ausgehenden E-Mails für alle Domänen mit demselben Schlüssel – und lassen Sie stattdessen einen kanonischen Namen (CNAME) für ihren Schlüssel veröffentlichen.

Zendesk macht das so, dass wir zwei verschiedene Schlüssel in unserem DNS auf ihren DNS umbenennen. Zendesk hat einen großartigen Hilfeartikel – Digitales Signieren von E-Mails mit DKIM oder DMARC (Plus und Enterprise)

Schritt sechs (falls zutreffend): CNAME Sie die Schlüssel in Ihrem DNS auf deren DNS. Jede DNS-Abfrage, die nach zendesk1._domainkey.301Moved.com sucht, wird von Ihrem DNS auf zendesk1._domainkey.zendesk.com umgeleitet. Zendesk stellt dann die DKIM-Schlüssel direkt zur Verfügung.

zendesk1._domainkey.301Moved.com IN CNAME zendesk1._domainkey.zendesk.comzendesk2._domainkey.301Moved.com IN CNAME zendesk2._domainkey.zendesk.com

Wie dies für andere Server aussieht, können wir sehen, indem wir das nslookup-Tool (für Unix oder Windows) lokal verwenden.

Nicht alle ausgehenden Absender unterstützen DKIM. Google Apps unterstützt DKIM, aber Ihre alten Mailserver möglicherweise nicht.

Implementierung von Domain-based Message Authentication, Reporting, and Conformance

DMARC, oder Domain-based Message Authentication, Reporting, and Conformance, ist das letzte Werkzeug, das wir haben, um bösartige E-Mails zu bekämpfen. Für Mailserver, die zuhören, gibt DMARC an, wie SPF und DKIM zu behandeln sind und wie sie Ihnen Bericht erstatten, so dass Sie den dringend benötigten Einblick in Ihre Zustellungsraten und die Einhaltung von Aufzeichnungen erhalten.

Und ja, DMARC ist ein weiterer TXT-Eintrag.

Schritt Sieben: Richten Sie eine DMARC-Richtlinie ein, geben Sie die mailto-Adresse an, legen Sie den Ausrichtungsmodus fest und bestimmen Sie den Prozentsatz der Nachrichten, auf die die Richtlinie angewendet werden soll (keine Sorge, das ist einfacher, als es klingt).

301Moved.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=100; sp=none"

Die obige Richtlinie ist als p=none bezeichnet. Wir ändern den Postfluss noch nicht, sondern richten nur die Richtlinie und die entsprechenden Berichte ein. Die Adresse, an die die XML-Berichte über den DMARC-Status gesendet werden, ist mit rua= bezeichnet.

Die empfangenden Mailserver senden XML-Anhänge, aus denen hervorgeht, wie Nachrichten von Ihrer Domäne – und solche, die behaupten, von Ihrer Domäne zu sein – im Vergleich zu den SPF-, DKIM- und DMARC-Anforderungen der meisten modernen Mailserver abschneiden.

Diese Berichte zeigen für jeden Umschlag, ob SPF bestanden, fehlgeschlagen oder nicht bestanden wurde. Sie zeigen, ob DKIM fehlgeschlagen ist, die Ausrichtung fehlgeschlagen ist oder erfolgreich war – und wie die oben genannten Richtlinien angewendet wurden.

Schließlich geben diese Berichte Aufschluss über die endgültige Zustellungsart der Nachricht. Es gibt einige großartige Tools, die Ihnen bei der Analyse dieser Berichte helfen. Selbst wenn Sie keine Richtlinien auf Nachrichten anwenden, ist es wie bei Firewall-, DNS- und IDS/IPS-Protokollen – es ist immer gut, etwas zu haben, auf das Sie zurückgreifen und es sich ansehen können.

Das adkim=r gibt den entspannten DKIM-Ausrichtungsmodus an, „r“ steht für relaxed und „s“ für strict. Im entspannten Modus können authentifizierte DKIM d=-Domänen innerhalb einer gemeinsamen Organisationsdomäne in der Mail-Header-From: Adresse die DMARC-Prüfung PASSIEREN. Der strenge Modus erfordert eine perfekte Übereinstimmung zwischen der DKIM d=-Domäne und der Header-From-Adresse einer E-Mail. Denken Sie an Subdomains, wenn Sie diese verwenden.

aspf=r bewirkt genau dasselbe, außer bei SPF-Prüfungen.

Die pct=100 ist der Prozentsatz der Nachrichten, die tatsächlich gemäß der DKIM-Richtlinie behandelt werden. Der empfangende Mailserver wählt diesen Prozentsatz zufällig aus und setzt die Richtlinie für diesen Prozentsatz der Nachrichten von Ihrer Domäne durch. Wir verwenden 100, weil wir noch keine Richtlinie anwenden.

Bevor wir eine Richtlinie anwenden, drosseln wir diesen Wert auf fünf, so dass nur bei einer von 20 Nachrichten die Richtlinie angewendet wird, wenn wir das Kennzeichen p= policy auf quarantine oder reject setzen. Auf diese Weise werden, wenn wir es total vermasseln, immer noch 95 % unserer E-Mails zugestellt, statt 0 %, wenn wir mit pct=100 beginnen.

Nachrichten, die die DMARC-Prüfung nicht bestehen, oder Ihre adkim=- und aspf=-Ausrichtungsmodi, die wir oben eingestellt haben, werden dann wie oben für eine Quarantäne-Richtlinie weich gebounced, oder ganz gebounced, wenn sie auf reject gesetzt sind.

Es ist sehr wichtig zu beachten, dass DMARC die Nachricht durchlässt, wenn entweder SPF oder DKIM bestanden wird, und die Nachricht nur ablehnt, wenn sowohl SPF als auch DKIM abgelehnt werden. Auf diese Weise können nur SPF- und nur DKIM-Nachrichten DMARC PASSIEREN, aber Nachrichten ohne SPF/DKIM werden immer FAIL. Dies ist eine gute Nachricht, wenn Sie Mailsysteme haben, die nur SPF oder nur DKIM unterstützen.

Verwenden Sie den DMARC Inspector von Dmarcian, um Ihre DMARC-Einträge zu überprüfen.

Dmarcian ist ein kostenpflichtiges Tool, mit dem Sie Ihre DMARC-Berichte einfach verwalten können. Es gibt viele andere, aber Dmarcian ist mein Favorit.

Aktualisierung: Wir haben einige (DMARC-konforme!) E-Mails erhalten, in denen nach der Subdomain-Richtlinie sp=none gefragt wurde. Mit einer Richtlinie, die sp=none enthält, legen Sie keine DMARC-Richtlinie für Subdomains fest. Dies erfolgt manuell durch die Einrichtung eines entsprechenden DMARC-Datensatzes für jede spezifische Subdomäne oder durch Aufnahme in den Haupt-DMARC-Datensatz mit sp=quarantine oder sp=reject.

Minimum Config

Wenn Sie dies ausprobieren möchten, empfehle ich Ihnen, sehr offen zu beginnen und einfach zu bleiben, bis Sie genügend DMARC-Berichte haben, um etwas zu erzwingen.

301Moved.com. IN TXT "v=spf1 ip4:198.51.100.0/24 include:mail.zendesk.com include:_spf.google.com MX ?all"

Definieren Sie große Provider mit einem „include:“ und alle IP-Blöcke, von denen Sie Mails senden dürfen, mit einem „IP4“ oder „IP6“. Verwenden Sie „MX“, um Ihre Posteingangsserver zu autorisieren. Wenn Sie Ihre Post nicht direkt von demselben Server senden, von dem auch Ihre Website gehostet wird (was übrigens eine sehr schlechte Praxis ist), können Sie den oben erwähnten „A“-Mechanismus weglassen. Das „?“ wendet keine Richtlinie auf Ihre Nachrichten an, sondern sorgt dafür, dass Ihr SPF-Eintrag veröffentlicht wird, damit DMARC ihn erkennen kann.

google._domainkey.301Moved.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCsC1iZ3D7AR3FrKtBYfnoKztCGgExFIReC0b1MPY1rpGZa9aTBYq7cDV6F8lzDVr8/K+z9Xt1gUV4P7tT8wuwgacR4oqiAWaUprbnINAxinJr4ohB1TIW3diX2fEA2t5kyUGCGziJFlHicZyJbk5QEaVLcSFD4V8R9f0Voz4P4jQIDAQAB"

Wählen Sie den richtigen Selektor, in diesem Fall „google“, und den richtigen Schlüssel. Denken Sie daran, dass Sie mehr als einen veröffentlichen können.

Hinweis: Bitte veröffentlichen Sie nicht den aktuellen Schlüssel, sonst kann ich Ihre E-Mail mit DKIM signieren.

301Moved.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=5; sp=none"

Für DMARC haben wir keine Richtlinie angewendet, wir sind im entspannten Modus, aber wir bitten darum, dass die XML-Berichte an ein Postfach gesendet werden, auf das wir Zugriff haben. Von dort aus gibt uns DMARC ziemlich schnell (nicht in Echtzeit) Rückmeldung darüber, wie wir die verschiedenen Richtlinien in allen drei Einträgen verschärfen können.

Aber Moment, was ist mit TLS?

Transport Layer Security, oder TLS, ist nicht Teil des DMARC-Standards und kein DNS-Eintrag.

Stattdessen ist TLS nur ein erwachsener Secure Socket Layer (SSL), den Mailserver verwenden können, um sich gegenseitig Nachrichten über öffentliche Verbindungen zu senden. Es ist SMTP in TLS verpackt, so wie man viele andere Dinge innerhalb/über TLS machen kann – SNMP über TLS und FTP über TLS sind gängige Beispiele. TLS verschlüsselt Nachrichten nur während der Übertragung, nicht im Ruhezustand.

Wenn wir eine DKIM-signierte Nachricht über TLS senden, ist sie während ihrer gesamten Lebensdauer signiert, aber nur verschlüsselt, wenn sie von Ihren Google Apps zu ihrem Cisco Ironport oder wo auch immer Ihre Post übertragen wird. TLS schützt ganz sicher keine Nachrichten im Ruhezustand, obwohl es auch für Ihre HTTPS://-Sitzung zu Webmail verwendet wird, während Sie dieselbe Nachricht lesen, aber auch das ist im Transit.

TLS ist etwas, das Sie verwenden sollten, wo immer es möglich ist, aber Sie sollten auch bereit sein, mit anderen öffentlichen Mailsystemen Klartext zu sprechen. Selbst im Jahr 2015 unterstützen einige Mailserver kein STARTTLS (Serverspeak für den Beginn des TLS-Handshakes).

Sie können die Verwendung von TLS mit bestimmten externen Domains in Google Apps mit einer einfachen Konfigurationsänderung erzwingen. Es ist eine gute Sache, TLS für verbundene externe Unternehmen, Partner und andere Organisationen zu aktivieren, aber erzwingen Sie TLS nur, wenn Sie sicher sind, dass es zuverlässig ist und von allen Mail-Servern auf dieser spezifischen Domain unterstützt wird.

Die Bedeutung der E-Mail-Sicherheit und die Vermeidung von Absenderbetrug

Ob Sie ein erfahrener IT-Administrator sind oder gerade erst anfangen, diese drei Standards haben die gleiche Bedeutung. Zugegeben, die Aufgaben der einzelnen Standards und ihr Zusammenspiel können etwas verwirrend sein, aber ihre Umsetzung ist relativ einfach und die Vorteile sind Ihre Zeit wert.