Wenn die eigene Domain für Spamversand missbraucht wird und was man dagegen tun kann

Wieso steht da unsere Domain im Absender? Das kann doch nicht sein!

Die Absenderadresse einer E-Mail kann man genau so leicht fälschen wie den Absender auf einem klassischen Brief. Da die Domains von seriösen Unternehmen in der Regel gute Reputationen haben, werden diese dann hin und wieder von Spammern als Absender verwendet in der Hoffnung, so einfacher durch Spamfilter durch zu kommen oder dass der Absender so seriös wirkt dass infizierte Anhänge geöffnet werden.
Wenn die Spam-Mails tatsächlich nicht vom eigenen Mailserver kommen, kann man erstmal nichts tun um den Versand dieser Mails zu stoppen. Man kann lediglich den anderen, empfangenden Servern helfen zwischen den echten E-Mails mit diesem Absender und den Fälschungen zu unterscheiden.

Vorher: Sicherstellen, dass man nicht selbst versendet!

Normalerweise wird man selbst darauf ja erst aufmerksam, wenn man mit Bounces ("Backscatter") überworfen wird. Aus genau diesen Bounces sollte aber die IP-Adresse des Servers hervorgehen, der diese E-Mails erzeugt und versendet hat. Wenn das nicht eurer ist, liegt das Problem tatsächlich in gefälschten Absendern. Taucht da die IP-Adresse eures Mailservers auf, helfen euch diese Tipps erstmal nicht weiter und ihr solltet schleunigst euren Mailserver vom Netz nehmen

Variante 1: Billig, einfach, schnelle Lösung, aber ziemlich problembehaftet: SPF

SPF (Sender Policy Framework) ist im Grunde nichts weiter als ein DNS-Eintrag für die eigene Domain, in der hinterlegt wird von welchen E-Mail-Servern aus legitim versendet wird.
Bis auf das Erzeugen des DNS-Eintrags hat man erstmal keinen weiteren Aufwand oder Konfigurationsarbeiten an Mailservern vor sich und man sieht quasi innerhalb kürzester Zeit einen Effekt.

Wenn man selbst einen eigenen Mailserver mit der IP-Adresse 198.51.100.25 betreibt und ausschließlich darüber E-Mails mit der Domain "firma.tld" versendet werden, sieht der SPF-Record beispielsweise so aus:

Damit wird festgelegt...
...dass alle Server, die E-Mails unter der Domain annehmen ("MX") versenden dürfen (empfohlen)
...zusätzlich die IP-Adresse 198.51.100.25 versenden darf
...und der Rest explizit NICHTS unter der Domain versenden darf. (Nicht empfohlen, aber für das Beispiel ist es besser)

Erhält nun ein Mailserver eine E-Mail von der IP 198.51.100.25 und dem Absender "hallmackenreuther@firma.tld" prüft er durch eine DNS-Anfrage auf den TXT-Record unter "firma.tld", ob es einen SPF-Record gibt und wertet ihn aus. In diesem Fall ist unserer IP das Versenden von Mails ja explizit erlaubt, also gibt es dort grünes Licht und die E-Mail darf durch.

Klopft nun stattdessen z.B. der Spammer-Server 203.0.113.123 an und will ebenfalls eine E-Mail von "hallmackenreuther@firma.tld" einliefern wird wieder der DNS-Eintrag geholt und geprüft:
- Steht die IP-Adresse im SPF-Record? Nein, also...
- Ist dieser Server irgendwo in den MX-Records der Domain aufgeführt? Auch nicht, also...
- Greift die Regel am Ende: Nämlich fortjagen ("-all").

An sich ein einfaches Konzept und funktioniert, sofern man alles korrekt konfiguriert.
Alles? Nein, denn SPF sieht nicht vor, dass jemand möglicherweise seine E-Mails von einem Anbieter zu einem anderen WEITERLEITEN will!

SPF und Weiterleitungen

Herr Hallmackenreuther versendet nun über den Mailserver seiner Firma (198.51.100.25) eine E-Mail an "lindemann@herrenboutique.tld". Herr Lindemann ist aber im Urlaub auf Island und lässt seine E-Mails weiterleiten, an seine Tochter "tochter@t-offline.de". Und jetzt passiert das hier auf dem Server von T-Offline:

Da kommt jetzt der Mailserver von "herrenboutique.tld" (192.0.2.2) vorbei und möchte eine E-Mail von "hallmackenreuther@firma.tld" an "tochter@t-offline.de" zustellen. Der Server von T-Offline holt sich also den SPF-Record von "domain.tld" und arbeitet ihn ab:

- Steht die IP-Adresse 192.0.2.2 im SPF-Record? Nein.
- Taucht der Server 192.0.2.2 in einem MX-Record von "firma.tld" auf? Nein.
- Also: Fortjagen ("-all").

Schade, damit wird die echte E-Mail vom Herrn Hallmackenreuther abgelehnt

Dieses Problem kann man möglicherweise in den Griff kriegen, wenn man anstelle von "-all" ein "~all" (mit Tilde) benutzt und damit sagt, dass man eine ambivalente Meinung über andere Server hat. Damit kann man quasi eine Whitelist pflegen um mit seinen echten E-Mails besser durch Spamfilter zu kommen, aber eine echte Dauerlösung ist SPF leider nicht.
Als schnelle Sofortmaßnahme durchaus geeignet, aber lieber sollte man in etwas zukunftssichereres investieren:

Weiterführende Lektüre zu SPF und Test-Tools

• http://www.spf-record.de/ zum Testen der Einträge
• https://www.heinlein-support.de/blog/news/gmx-de-und-web-de-haben-mail-r ... Warum SPF keine endgültige Lösung ist

DKIM + DMARC

D-Mark? Wir haben doch Euro!
Nein, DMARC - die handliche Abkürzung von "Domain-based Message Authentication, Reporting and Conformance".
Zusammen mit DKIM, der "DomainKeys Identified Mail", ist das eine robuste Lösung um echte von gefälschten Mails zu unterscheiden - allerdings bedeutet die Konfiguration dieser Technik je nach Mailserver unterschiedlich viel Aufwand und jemanden, der sich damit auskennt.

Was macht man damit denn nun?

Mit DKIM werden die E-Mail-Header kryptographisch signiert.
Will heißen: Jede E-Mail, die Herr Hallmackenreuther über den echten Firmen-Mailserver verschickt, erhält von diesem ein paar zusätzliche unsichtbare Daten, mit denen sich die Echtheit und Integrität der E-Mail-Header (darin stehen z.B. Absender, Empfänger, Datum, Betreff u.s.w.) beweisen lässt.
Der Mailserver schaut sich dafür die Headerdaten an und errechnet darüber eine kryptographische Signatur für die Domain "firma.tld", die nur derjenige erzeugen kann, der den geheimen kryptographischen Schlüssel dafür hat (der auf dem Firmen-Mailserver gespeichert ist). Einen kleinen Teil dieses Schlüssels (der "öffentliche Schlüssel") veröffentlicht man als TXT-Record per DNS.
Dieser öffentliche Schlüssel passt nur zum geheimen, privaten Schlüssel des Mailservers.
Andere Mailserver, an die man E-Mails versendet, können mit der kryptographischen Signatur im E-Mail-Header und dem TXT-Record in der DNS-Zone nachprüfen, ob wirklich der echte Mailserver von "firma.tld" diese Signatur erzeugt hat und ob sie zwischenzeitlich (unerlaubter weise) verändert wurde.
Ist die Signatur in Ordnung wird die E-Mail angenommen, ist sie kaputt oder fehlerhaft prüft der Empfängerserver nach ob es einen DMARC-Record in der DNS-Zone von "firma.tld" gibt.
In diesem DMARC-Record steht drin, was passieren soll wenn die Signatur nicht verifiziert werden kann - z.B. ob die Mail trotzdem als OK angesehen oder direkt abgelehnt werden soll.

Das Ganze ist deutlich aufwendiger als die SPF-Lösung, aber dafür ist es hier vollkommen egal von welchen IP-Adressen aus die E-Mail verschickt wird solange die Header intakt und unverändert bleiben - und das ist normalerweise auch bei den verwinkelsten Mailweiterleitungen der Fall.
Ein Spammer kann auch nicht einfach die vorhandene Signatur einer versendeten, echten E-Mail kopieren und für eigene Zwecke missbrauchen - denn er könnte ja den Empfänger oder Betreff nicht verändern ohne dass die DKIM-Signatur kaputtgeht und ungültig wird.

Je nach Mailserver ist das unterschiedlich viel Implementationsaufwand. Zudem braucht es dafür gewisse Grundkenntnisse in Sachen E-Mail, DNS und kryptographischen Signaturen.
Im Zweifel sollte man sich notfalls einen Dienstleister holen, der einem das einmal schön einrichtet und konfiguriert.

Weiterführende Lektüre zu DKIM/DMARC und Test-Tools

• https://dmarcian.com/dmarc-inspector DMARC-Tester
• http://dkimcore.org/c/keycheck DKIM-Tester

A message claiming to be from you has failed the published DMARC
policy for your domain.

  Sender Domain: meinedomain.tld
  Sender IP Address: 190.16.87.6
  Received Date: Sun, 24 Feb 2019 14:10:14 +0100
  SPF Alignment: no
  DKIM Alignment: no
  DMARC Results: Reject

------ This is a copy of the headers that were received before the error
       was detected.

Received: from 6-87-16-190.fibertel.com.ar ([190.16.87.6])
	by mx104.antispamcloud.com with esmtp (Exim 4.89)
	(envelope-from <benutzer@meinedomain.tld>)
	id 1gxtXo-0001Ch-H1
	for matthew@???????????????.co.uk; Sun, 24 Feb 2019 14:10:14 +0100
Message-ID: <004301d4cc29$05027589$75446e85@yxpvya>
From: "matthew@????????????.co.uk" <benutzer@meinedomain.tld>
To: <matthew@??????????.co.uk>
Subject: Earn 500.000 Euro
Date: 24 Feb 2019 05:39:09 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-DKIM-Status: none /  / meinedomain.tld /  /  / 

<?xml version="1.0" encoding="UTF-8" ?>  
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <extra_contact_info>https://support.google.com/a/answer/2466580</extra_contact_info>
    <report_id>16364689978601024564</report_id>
    <date_range>
      <begin>1550880000</begin>
      <end>1550966399</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>meinedomain.tld</domain>
    <adkim>s</adkim>
    <aspf>r</aspf>
    <p>reject</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>200.119.218.195</source_ip>
      <count>5</count>
      <policy_evaluated>
        <disposition>reject</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>meinedomain.tld</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>meinedomain.tld</domain>
        <result>none</result>
      </spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>113.182.107.196</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>reject</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>meinedomain.tld</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>meinedomain.tld</domain>
        <result>none</result>
      </spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>192.114.74.103</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>reject</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>meinedomain.tld</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>meinedomain.tld</domain>
        <result>none</result>
      </spf>
    </auth_results>
  </record>
</feedback>