Über die Webseite Gemeinsames Registerportal der Länder haben Unternehmen u.a. die Möglichkeit, eine Online-Abfrage des eigenen Handelsregisterauszuges anzufragen und zusenden zu lassen. Diese Dienstleistung ist gebührenpflichtig.
Nach der Abfrage des Handelsregisterauszuges im Juli 2020 fand Anfang August 2020 eine E-Mail mit der Absenderadresse gebuehrennachweis@handelsregsiter.de ihren Weg in den Posteingang meines Postfaches. Auf der Webseite des Registerportals wird auf die Warnhinweise der Landesjustizverwaltungen und des Bundesministeriums der Justiz hingewiesen. Dieser Hinweis war Grund genug, doch einmal einen ausführlichen Blick auf die E-Mail des Gebührennachweises zu werfen. Dieser Hinweis wird in der E-Mail sogar noch einmal wiederholt.
Die allgemeine und die technische Bewertung der E-Mail mit Dateianhang des Gebührennachweises als PDF-Datei war sehr ernüchternd. Ich wurde sofort an die problematischen E-Mail-Nachrichten im Zusammenhang mit der NRW Soforthilfe erinnert. Denn auch im Fall des Registerportals werden die E-Mail-Nachrichten von Systemen der IT.NRW versendet.
Bereits in der Übersicht des Posteingangs zeigte sich die E-Mail verhaltensauffällig. Die Absenderadresse der E-Mail-Nachricht verfügt über keinerlei Klartextnamen. Die Anzeige der E-Mail-Adresse alamierte mich sofort. Der Betrefftext der Nachricht förderte mein Misstrauen nur. Das Registerportal sendet anscheinend keine Einzelnachweise, sondern monatliche Zusammenfassungen.
Ein weiterer Punkt ist, dass es sich um eine technische Nachricht handelt, auf die man als Empfänger nicht direkt anworten soll. Solch ein Vorgehen ist für Empfänger in der Regel nicht nachvollziehbar und, aus meiner Sicht, heutzutage ebenfalls ein Indikator für eine E-Mail-Nachricht zweifelhafter Herkunft.
Anwender, die solch eine Nachricht erhalten, haben keinerlei Möglichkeit, die Integrität der Nachricht oder die Gültigkeit des Absenders zu überprüfen.
Der Blick in die technischen Informationen der E-Mail-Nachricht und die Prüfung wichtiger Basis-Sicherheitsfunktionen für die E-Mail-Kommunikationen zeigen eklatante Lücken auf, die heutzutage mit einfachen Mitteln vermeidbar sind.
Der erste Blick richtet sich immer auf die Kopfinformationen einer E-Mail-Nachricht. Wie schon im Falle der E-Mail-Nachrichten zur NRW Soforthilfe werden die Namen und IP-Adressen interner Systeme nicht aus den Kopfinformationen entfernt. Das Verhalten bei der Zustellung der E-Mail ändert sich durch das Entfernen der internen Topologieinformationen nicht. Jedoch stellen diese Informationen ein Sicherheitsrisiko dar. Potentielle Angreifer erhalten ausreichend Informationen über die Namensschema und IP-Adressen interner Systeme.
Das Entfernen interner Topologieinformationen ist bereits seit Jahren Stand der Technik, wird in diesem Fall jedoch nicht angewandt.
Nach der Auswertung der E-Mail-Kopfinformationen ist die Prüfung des DNS-Eintrages für den oder die E-Mail-Server der Domäne handesregister.de an der Reihe. Ich verwende hierzu immer die Werkzeuge der Webseite MX Toolbox.
Aus den Kopfinformationen können wir ablesen, dass das versendende System auf den Namen sbmail.it.nrw.de konfiguriert ist. Der Name wird vom öffentlichen Name Server auf die IP-Adresse 93.184.132.24 aufgelöst.
Die Prüfung des MX DNS-Eintrages ergibt leider andere Informationen.
Der Empfang von Nachrichten für die Domäne handelsregister.de erfolgt über den Namen postamt.it.nrw.de, der auf die IP-Adresse 93.184.132.233 aufgelöst wird. Dies stellt für E-Mail-Server die Nachrichten an Empfänger dieser Domäne senden, kein Problem dar. Für E-Mail-Server, die Nachrichten von handelsregister.de empfangen, ist dies jedoch problematisch.
Einer der Standardprüfungen, die E-Mail-Server beim Empfang einer Nachricht durchführen, ist die Prüfung, ob die einliefernde IP-Adresse mit der IP-Adressauflösung des MX-Eintrages übereinstimmt. Wenn dies, wie in diesem Fall, nicht zutrifft, erhöht dies automatisch der Wahrlichkeit, dass es sich um eine Spam-Nachricht handelt. Je mehr Absenderprüfungen fehlschlagen, desto höher ist die Wahrscheinlichkeit.
Die Tatsache, dass unterschiedliche System für den Versand und für den Empfang von E-Mail-Nachrichten verwendet werden, ist nicht ungewöhnlich. Um solch eine Konfiguration anderen E-Mail-Servern bekanntzumachen, gibt es eine technische Lösung; das Sender Policy Framework.
Das Sender Policy Framework (SPF) unterstützt die Möglichkeit, gültige Systeme für den Versand von E-Mail-Nachrichten einer einzelnen Domäne zu definieren. HIerzu wird in der DNS-Zone ein sog. SPF-Eintrag hinterlegt, der sowohl Namen als auch IP-Adressen gültiger Systeme enthalten kann. Zusätzlich ist es möglich, Referenzen auf SPF-Einträge anderer Domänen einzutragen, wenn diese ebenfalls E-Mail-Nachrichten für die Domäne versenden.
Die Domäne handelsrgister.de existiert kein SPF-Eintrag in der externen DNS-Zone.
Dies bedeutet, dass keine gültigen Systeme für den Versand von E-Mail-Nachrichten definiert sind. Empfangende Systeme haben keine Möglichkeit zur Prüfung und nehmen somit E-Mail-Nachrichten von beliebigen Systemen aus dem Internet entgegen. Dies stellt ein enormes Sicherheitsrisiko dar und kann als fahrlässige Fehlkonfiguration eingestuft werden.
Das Fehlen des SPF-Eintrages wird beim Empfang einer Nachricht von modernen Systemen als Verstoß gegen Industriestandards bewertet und führt automatisch zu einer Erhöhung der Spam-Wahrscheinlichkeit.
DKIM - Integrität der E-Mail-Kopfinformationen
Selbst wenn keine SPF-Informationen vorliegen, können in einer E-Mail die Empfänger- und Absenderinformationen abgesichert werden. Hierzu steht die Funktion DomainKeys Identified Mail (DKIM) zu Verfügung. Hierbei erfolgt eine Signierung dieser und andere Informationen der E-Mail. Das empfangende System hat die Möglichkeit, eine DKIM-signierte E-Mail-Nachricht mit Hilfe des DKIM-Eintrages in der DNS-Zone der sendenden Domäne zu prüfen.
Hierdurch wird sichergestellt, dass die Nachricht von einem System signiert wurde, dass über den privaten DKIM-Schlüssel verfügt. Absender ohne Zugriff auf den privaten Schlüssel haben keine Möglichkeit, solch eine Signierung durchzuführen.
E-Mail-Nachrichten der Domäne handelsregister.de werden nicht durch eine DKIM-Signierung geschützt. Somit haben empfangende Systeme keinerlei Möglichkeit, die Gültigkeit einer E-Mail-Nachricht der Domäne handelsregister.de zu prüfen.
Um den MIßbrauch von E-Mail-Nachrichten einzuschränken, wurde die Funktion DMARC (Domain-based Message Authentication, Reporting and Conformance) entwickelt. DMARC kann ergänzend zu SPF und DKIM eingesetzt werden. Auch DMARC wird über einen DNS-Eintrag in der Absender-Domäne definiert. Ein DMARC-Eintrag gibt dem empfangenden System Informationen, wie mit einer E-Mail zu verfahren ist, wenn die Validierung von SPF und DKIM fehlschlägt. Zusätzlich kann in einem DMARC-Eintrag festgelegt werden, an welche E-Mail-Adresse Benachrichtigungen über fehlerhafte E-Mail-Nachrichten gesendet werden sollen. Als Betreiber einer Domäne erhalte ich so Informationen, welche System in Internet meine Domäne als Absenderdomäne verwenden.
Da weder DKIM-, noch SPF-Einträge für die Domäne handelsregister.de vorhanden sind, fehlt auch ein DMARC-Eintrag.
Gerade im Hinblick auf die Sensibilität der Informationen, die über diese Domäne versendet werden, ist die Implementierung aller drei Schutzfunktionen drigend angeraten.
Ob eine Verschlüsselung der E-Mail-Nachricht an sich notwendig ist, kann man diskutieren. Sowohl Nachricht als auch der PDF-Dateianhang waren nicht verschlüsselt. Eine S/MIME Signierung der Nachricht, als Mindestmaß zur Sicherstellung der Integtrität des Absender, fehlte ebenfalls.
Das sendende System sbmail.it.nrw.de ist nicht für eigehende Verbindungen aus dem Internet konfiguriert. Die Prüfung des MX-Endpunktes für handelsregister.de offenbahrte die bereits bekannten TLS-Schwächen.
Der Test des TLS-Endpunkte erfolgte mit dem TLS-Scanner von ImmuniWeb.
Die schlechte Beurteilung hat mehrere Gründe:
TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_IDEA_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_RC4_128_SHA TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DH_anon_WITH_RC4_128_MD5 TLS_DH_anon_WITH_3DES_EDE_CBC_SHA TLS_DH_anon_WITH_AES_128_CBC_SHA TLS_DH_anon_WITH_AES_256_CBC_SHA TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA TLS_DH_anon_WITH_SEED_CBC_SHA TLS_ECDH_anon_WITH_RC4_128_SHA TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA TLS_ECDH_anon_WITH_AES_128_CBC_SHA TLS_ECDH_anon_WITH_AES_256_CBC_SHA TLS_DH_anon_WITH_AES_128_CBC_SHA256 TLS_DH_anon_WITH_AES_256_CBC_SHA256 TLS_DH_anon_WITH_AES_128_GCM_SHA256 TLS_DH_anon_WITH_AES_256_GCM_SHA384
Auch in diesem Fall ist es nicht möglich, ein postives Fazit zu ziehen. Im Vergleich zur Problematik der E-Mail-Nachrichten zur NRW Soforthilfe handelt es sich hier um E-Mail-Nachrichten, die zu einer bundesweit bereitgestellen Diensleistung gehören. Die Bundesländer und der Bund, die diese Dienstleistung in Anspruch nehmen, tun gut daran, sich für eine Verbesserung der Sicherheit im Umgang mit E-Mail-Nachrichten einzusetzen.
Die Möglichkeiten zur Verbesserung gliedern sich in zwei Bereiche.
SPF, DKIM und DMARC sind Industriestandards. Dass diese Funktionen nicht zum Schutz von E-Mail-Nachrichten verwendet werden, ist grob fahrlässig.
Im Hinblick auf eine eGovernment-Infrastruktur und ein Vertrauen in eine sichere (E-Mail-)Kommunikation besteht bei IT.NRW noch Nachholbedarf. Die aktuelle Konfiguration öffnet Tür und Tor für Betrüger und ist geradezu eine Einladung zum Versand von Phishing- und Malware-Nachrichten. Unternehmen, die Nachrichten von solchen Domänen empfangen, können sich nur durch eine explizite Abweisung der E-Mail-Nachrichten schützen. Andere Lösungsansätze führen immer manuellen Anpassungen auf der Empfängerseite und zu einem erhöhten Aufwand beim Betrieb einer sicheren IT-Infrastruktur.
Der Handlunsbedarf liegt eindeutig auf Seiten von IT.NRW.
Different technologies are used to verify the validity of email senders. Each technology by itself represents only one component of a holistic solution. It is currently recommended to implement all three technologies.
The technologies are:
The following figure illustrates the protocol relations.
The use of SPF, DKIM, and DMARC are no substitute for email message encryption itself or transport encryption. These technologies are used to identify and asses valid senders and to protect against spam messages.
Keep in mind that SPF, DKIM, and DMARC are offerings for other emails servers. As a sending party, you do not control if and how SPF, DKIM, and DMARC are evaluated by the receiving server. But if evaluated, the configuration must be correct to avoid messages being rejected by receiving email servers.
The following sections focus on the DNS configuration for SPF, DKIM, and DMARC. This post is not intended to rate the technologies, but to describe the implementation.
Each domain is used for sending emails requires an SPF resource record (RR) in its DNS zone. An SPF record is always of the type TXT and does not use any hostname (or resource record name, if you will). An SPF RR is always valid for the entire DNS zone.
mcsmemail.de. 3600 IN TXT "v=spf1 mx a:mail.mcsmemail.de ?all"
The following screenshot illustrates adding a new SPF TXT record in a common DNS management interface (DE) of an internet provider. The hostname textbox remains empty.
Example explained:
v=spf1 SPF Version
mx MX server records defined within the DNS zone are valid senders
a:mail.mcsmemail.de The additional DNS hostname defined as A resource record is a valid sender as well
?all Neutral validation of non listed servers that send emails for this domain
SPF records can be created by using one of the various online resources.
DKIM resource records are configured as TXT resource records as well. In contrast to an SPF record, a hostname is mandatory. In this case its called selector.
A DKIM TXT record is always created as a record in the subdomain _domainkey.
nsp._domainkey.mcsmemail.eu. 3600 IN TXT "v=DKIM1\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQChZM8yjegaKfd0ssKyezTW/7xbDSNc0uPd50xa5/ecerv1v3mHKM+T7mClzRmIEx+Ji6AisVeo2uvjTYPemHFMBlQpuS/4zc2QxWHqp62FSQ7lASBOzDfUrIwayPVqwSPD6NrnfVSWoUNrFGGSVeU5uLASecBzTfxPukqTHgYKhQIDAQAB"
The following screenshot illustrates adding a new DKIM TXT record in a common DNS management interface (DE) of an internet provider. The hostname textbox contains the selector nsp followed by the subdomain _domainkey.
v=DKIM1 DKIM version
k=rsa Public key encryption method
p=MIGfMA.... The DKIM public key
DMARC is configured as a TXT resource record as well. The DMARC resource record uses the fixed hostname _dmarc.
_dmarc.mcsmemail.de. 3600 IN TXT "v=DMARC1\; p=none\; rua=mailto:DMARCRUA@mcsmemail.de\; ruf=mailto:DMARCRUF@mcsmemail.de\; fo=1\; adkim=s\; aspf=s\; rf=afrf\"
The following screenshot illustrates adding a new DMARC TXT record in a common DNS management interface (DE) of an internet provider. The hostname textbox contains always the value _dmarc.
v=DMARC1 DMARC version
p=none No DMARC policy defined (You should always start with None, before switching to Quarantine or Reject) rua=mailto:DMARCRUA@mcscmemail.de Email address for status reports
ruf=mailto:DMARCRUF@mcscmemail.de Email address for error reports
fo=1 Error report type
adkim=s DKIM alignment, s = strict
aspf=s SPF alignment, s = strict
rf=afrf Error report message format, afrf = Abuse Report Format following RFC 5965
The DMARC policy (p) should be raised step-by-step. The results for each policy type are:
Recommended reading on this topic: Google Support Post.
DMARC DNS zone entries can easily be checked by using the Net at Works PowerShell tool. The PowerShell script can only be used with NoSpamProxy11+. But there are some online tools available as well.
Do you need assistance with your Exchange Server setup? You have questions about your Exchange Server infrastructure and going hybrid with Office 365?
Contact us at office365@granikos.eu or visit our website http://www.granikos.eu.
Es gibt zahlreiche Gründe, warum externe Dienstanbieter E-Mails unter Verwendung einer E-Mail-Dömane eines Kunden senden. Beispielhafte Anwendungsfälle sind z.B.:
Die Nutzung einer E-Mail Domäne, die ein Unternehmen bereits in Verwendung hat, birgt Risiken. Bei der Nutzung durch einen Marketing-Dienstleister, der hauptsächlich E-Mail-Nachrichten an externe Empfänger sendet, treten die Probleme noch nicht so deutlich hervor. Werden jedoch Dienste in Anspruch genommen, die eine Zustellung von E-Mail-Nachrichten an interne Mitarbeiter notwendig machen, kommt es zu Problemen.
Eine der einfachsten Funktionen im Rahmen des E-Mail-Grundschutzes ist die Abweisung von E-Mails, die eine eigene Domäne (Accepted oder Owned Domain) als Absender verwenden.
Das nachfolgende Schaubild verdeutlicht die Situation.
Das Unternehmen in diesem Beispiel nutzt die E-Mail Domäne varunagroup.de als primäre E-Mail-Domäne. Der Dienstanbieter nutzt die Adresse news@varunagroup.de als Absenderadresse. E-Mail-Nachrichten an externe Empfänger können meist problemlos zugestellt werden, insofern der SPF-Eintrag des Dienstanbieters in der externen DNS-Zone varunagroup.de eingetragen ist. Die E-Mail-Sicherheitslösung am Gateway verweigert jedoch die Annahme von E-Mail-Nachrichten an interne Empfänger, da nur interne Systeme unter der Domäne varunagroup.de senden dürfen.
Am E-Mail-Gateway können natürlich Ausnahmen konfiguriert werden. Diese sind aber von Natur aus aufwändig in der Wartung und und sehr fehleranfällig.
Das Problem kann durch Nutzung von Subdomänen einfach und elegant gelöst werden.
Externe Dienstleister nutzen für den Versand von E-Mail-Nachrichten anstatt der Domäne varunagroup.de die neu konfigurierte Subdomäne email.varunagroup.de. In der zur DNS-Zone der Subdomäne werden der zugehörige SPF-Eintrag des Dienstleisters und alle erforderlichen DKIM-Einträge verwaltet.
Das nachfolgende Schaubild verdeutlicht den Unterschied zum ersten Schaubild.
Das Unternehmen nutzt weiterhin die Domäne varunagroup.de als primäre E-Mail-Domäne. Für externe Dienstanbieter wurde aber die Subdomäne email.varunagroup.de eingerichtet. Somit versendet der externe Dienstanbieter in diesem Beispiel E-Mail-Nachrichten mit der Absenderadresse news@email.varunagroup.de. Für externe Empfänger ändert sich hierdurch nichts. Für das E-Mail-Sicherheitsgateway des Unternehmens ändert sich aber alles. Die Absenderdomäne email.varunagroup.de ist ist eine vollwertige externe Domäne, die durch SPF und DKIM abgesichert wurde und entspricht keiner internen Domäne. Alle E-Mail-Nachrichten des Dienstanbieters werden angenommen und an interne Empfänger zugestellt.
Bei Bedarf kann für jeden externen Dienstanbieter eine separate Subdomäne konfiguriert werden. Dieses Vorgehen ist ein wenig aufwendiger, bietet jedoch ein verbesserte Kontrolle der DNS-Konfiguration.
Die nachfolgenden Präsentationen verdeutlichen die Problemstellung und die Lösungsmöglichkeiten.
Richten Sie für externe Dienstanbieter, die unter Ihrer E-Mail-Domäne Nachrichten versenden sollen, immer Subdomänen ein. Für Unternehmen, die Office 365 und Exchange Online nutzen, ist die Empfehlung mit der beschriebenen Subdomänen-Konfiguration zu arbeiten. Ansonsten wird Exchange Online Protection (EOP) E-Mails von externen Dienstanbietern abweisen.
Gerne unterstützen wir Sie bei der Planung und Durchführung Ihrer Exchange Server Implementierung oder Migration.
Sie denken über einen vollständigen Wechsel zu Microsoft 365 oder eine Hybrid-Konfiguration mit Office 365 nach? Wir beraten Sie umfassend und neutral über die Möglichkeiten der Office 365 Plattform und Microsoft 365.
Sie möchten mehr über Exchange Server 2019 erfahren? Gerne erläutern wir Ihnen die technischen Änderungen und Chancen für Ihr Unternehmen in einem individuellen Workshop. Bis dahin, werfen Sie doch einen Blick in das Microsoft Exchange Server 2019: Das Handbuch für Administratoren.
Weitere Informationen zu unseren Dienstleistungen finden Sie auf unserer Website (https://www.granikos.eu) oder Sie kontaktieren direkt unser Vertriebsteam: info@granikos.eu
Foto von Miguel Á. Padriñán von Pexels.
Für die Prüfung von gültigen E-Mail Absendern stehen unterschiedliche Technologien zur Verfügung. Jede für sich genommen stellt aber nur einen Baustein einer Gesamtlösung dar. Nach aktuellem Standard ist die Empfehlung, alle drei Technologien zu implementieren.
Die Technologien sind:
Das nachfolgende Schaubild verdeutlicht die Relation der Protokolle zu einander.
Die Konfiguration von SPF, DKIM und DMARC ist kein Ersatz für E-Mail Nachrichtenverschlüsselung oder eine Transportverschlüsselung bei der E-Mail Übertragung. Vielmehr mehr dienen die genannten drei Technologien der Erkennung und Bewertung von gültigen Absendern und stellen einen Schutzmechanismus vor Spam dar.
Man darf nicht vergessen, dass die Konfiguration der drei Technoligen nur ein Angebot für andere E-Mail Server darstellt. Als Absender hat man schlicht keine Kontrolle darüber, ob und wie SPF, DKIM oder DMARC von der empfangenden Seite ausgewertet werden. Werden sie aber ausgewertet, so müssen die Konfigurationen korrekt und fehlerfrei sein und keine Testeinträge mehr enthalten.
Die nachfolgenden Abschnitte beschreiben insbesondere die DNS Konfiguration für SPF, DKIM und DMARC. Dieser Blogeintrag stellt keine detaillierte Bewertung der drei Technologien dar, sondern beschreibt deren Implementierung.
Für jede Domäne, die E-Mails versendet, ist ein SPF Eintrag (Resource Record) in der DNS Zone einzutragen. Ein SPF Eintrag ist immer vom Typ TXT und nutzt keinen Hostnamen (oder Resource Record Namen). Er gilt immer für die gesamte zu betrachtende Zone.
Das nachfolgende Beispiel zeigt das Anlegen eines SPF TXT Eintrages in einer DNS Verwaltungsoberfläche eines Internet-Hosters. Das Textfeld für den Hostnamen bleibt leer.
Die im Beispiel verwendeten Einträge bedeuten:
v=spf1 Die SPF Version des Texteintrage
mx Die in der DNS Zone konfigurierten MX Servereinträge für eingehende E-Mails sind valide Sender
a:mail.mcsmemail.de Der in der DNS Zone existierende A Resource Record ist ebenfalls an valider Sender
?all Neutrale Bewertung von nicht genannten Systemen, die ebenfalls E-Mails mit dieser Domäne senden
Die Erstellung der SPF Konfiguration erfolgt am einfachsten über einen der zahlreiche Online-Konfiguratoren. Diese werten bereits die aktuelle Konfiguration der DNS Zone aus.
Bei einem DKIM Eintrag erfolgt die Konfiguration ebenfalls über einen TXT Eintrag in der DNS Zone der Absenderdomäne. Im Gegensatz zum SPF Eintrag ist ein Name für den Resource Record verpflichtend. Im Zusammenhang mit DKIM spricht man hier vom einem Selektor.
Ein DKIM DNS Eintrag erfolgt immer unterhalb der DNS Subdomäne _domainkey.
Das nachfolgende Beispiel zeigt das Anlegen eines DKIM TXT Eintrages in einer DNS Verwaltungsoberfläche eines Internet-Hosters. Das Textfeld für den Hostnamen enthält den Selektor nsp und die Subdomäne _domainkey.
v=DKIM1 Die DKIM Version des DNS Eintrages
k=rsa Verschlüsselungsmethode des öffentlichen Schlüssels
p=MIGfMA.... Der öffentliche Schlüssel des DKIM Schlüsselpaares
Die Konfiguration von DMARC erfolgt ebenfalls über einen TXT Eintrag in der DNS Zone der absendenden Domäne. Für die Konfiguration wird der definierte Resource Record Name _dmarc verwendet.
Das nachfolgende Beispiel zeigt das Anlegen eines DMARC TXT Eintrages in einer DNS Verwaltungsoberfläche eines Internet-Hosters. Das Textfeld für den Hostnamen enthält immer den Namen _dmarc.
v=DMARC1 Die DMARC Version des DNS Eintrages
p=none Keine definierte Policy für DMARC (Dies sollte immer das Startszenario sein, bevor man zu Quarantine oder Reject wechselt)
rua=mailto:DMARCRUA@mcscmemail.de E-Mail Adresse für aggregierte Statusberichte
ruf=mailto:DMARCRUF@mcscmemail.de E-Mail Adresse für Fehlerbericht
fo=1 Definition der Art des Fehlerberichtes
adkim=s Definition DKIM Prüfung, s = strict
aspf=s Definiton der SPF Prüfung, s = strict
rf=afrf Nachrichtenformat des Fehlerberichtes, afrf = Abuse Report Format nach RFC 5965
Die Richtlinie (Policy, p) zur Auswertung und Reaktion sollte langsam gesteigert werden. Je Richtlinie sind die Ergebnisse wie folgt:
Sehr empfehlenswert zu diesem Thema ist ein Supportartikel von Google.
Für die Überprüfung der DNS Zoneneinträge kann das PowerShell Tool von Net at Work verwendet werden. Das PowerShell script kann nur mit NoSpamProxy 11 oder höher verwendet werden. Ebenso stehen zahlreiche Online-Tools zur Verfügung. Unten finden Sie direkt Verlinkungen zu den Tools von MXToolbox.
Sichern Sie Ihre E-Mail Kommunikation mit PGP oder S/MIME und nutzen Sie sichere E-Mail Verschlüsselung am Gateway mit NoSpamProxy Encryption. E-Mail Security Made in Germany. Wir beraten Sie gerne: info@granikos.eu
E-Mail-Sicherheit auf Knopfdruck. Geht doch!
SPF, DKIM und DMARC sind in aller Munde und teilweise sogar zur Pflicht geworden. Viele Firmen trauen sich jedoch nicht an die Umsetzung. Unser Partner Net at Work zeigt in diesem Webcast wie einfach es sein kann, den Absender einer E-Mail zu überprüfen, wenn man die richtigen Werkzeuge verwendet.
Auf Knopfdruck geben Sie Ihren Kommunikationspartnern die Möglichkeit, E-Mails aus Ihrem Hause einwandfrei zu identifizieren und gefälschte E-Mails mit Ihrer Domäne abweisen zu können. Darüber hinaus haben Sie die Möglichkeit zu erkennen, ob Ihre Domäne für Spam- und Malware-E-Mails missbraucht wird.
Ein weiterer wichtiger Aspekt ist beispielsweise der Schutz vor gefälschten PayPal-Rechnungen. Überlassen Sie die Absenderprüfung nicht Ihren Mitarbeitern, sondern einem E-Mail-Security Gateway Made in Germany.