SPF und DMARC für eine reine Empfangsdomain: Spoofing stoppen

Zwei Richtungen, und Sie haben eine davon konfiguriert

Eine Domain hierher zu zeigen braucht einen einzigen DNS-Eintrag. Dieser Eintrag – der MX-Eintrag – beantwortet genau eine Frage: Wohin geht Mail, die an diese Domain adressiert ist? Das ist alles, was ein Catch-all braucht, und sobald er auflöst, funktioniert die Domain. Sie ist damit aber auch, in diesem Moment, nur halb eingerichtet, denn ein Domainname wird in zwei Richtungen genutzt, und der MX-Eintrag sagt nichts über die zweite.

Die zweite Richtung ist die interessante. Nichts im Mail-Protokoll hindert einen Fremden daran, Ihre Domain in die From:-Zeile einer Nachricht zu schreiben, die er von seiner eigenen Maschine aus verschickt. Er braucht dafür keinen Zugriff auf Ihr DNS, Ihren Registrar oder Ihr Postfach – die Adresse in einer Nachricht ist eine Behauptung, kein Nachweis, und das war sie schon immer. Was darüber entscheidet, ob dieser Behauptung geglaubt wird, ist das, was Ihre Domain darüber sagt, wer sie aufstellen darf:

Die Domain, die nichts sagt

Ein empfangender Server findet weder SPF noch eine DMARC-Richtlinie und muss auf eigene Heuristiken zurückgreifen: Reputation, Inhalt, wie sich die Domain bisher verhalten hat. Eine brandneue Domain ohne Historie und ohne Richtlinie ist so ziemlich das Idealziel für eine Fälschung, denn es gibt nichts, was der Fälschung widerspricht, und nichts, dem man hinterher die Schuld geben könnte.

Die Domain, die Nein sagt

Derselbe Server findet eine veröffentlichte Richtlinie, die besagt, dass keine Maschine irgendwo autorisiert ist, im Namen dieser Domain zu versenden, und dass Fehlschläge abgelehnt werden sollen. Es ist keine Ermessensfrage mehr. Die Nachricht wird schon an der Tür abgewiesen, meist ohne je einen Spam-Ordner zu erreichen.

Das ist kein Gedankenspiel über große Marken. Domains ohne ausgehende Mail werden genau deshalb gewählt, weil sie keine Richtlinie haben – ein Name, den niemand schützt, zwei Wochen benutzt und dann fallengelassen, ist für den Versender unerwünschter Mail mehr wert als ein Name, der sich wehrt.

Warum Sie sich den Teil sparen können, für den alle anderen sechs Monate brauchen

Wenn Sie zuvor irgendetwas über DMARC gelesen haben, dann, dass es ein langes, sorgfältiges Projekt ist. Dieser Rat ist richtig, nur betrifft er Sie nicht. Er ist für eine Domain geschrieben, die Mail versendet, und er ist aus einem Grund lang: Bevor Sie der Welt sagen können, alles abzulehnen, was fehlschlägt, müssen Sie jedes System finden, das legitim in Ihrem Namen versendet, und jedes davon zum Bestehen bringen. In einer normalen Organisation ist diese Liste länger, als irgendjemand erwartet, und sie wird entdeckt statt gewusst:

1. Veröffentlichen Sie eine Richtlinie, die nichts bewirkt. p=none bittet Empfänger, zu melden, aber nichts zu ändern, damit ein vergessener Absender nicht durch die Richtlinie selbst abgeschnitten wird.
2. Lesen Sie wochenlang Berichte. Das Rechnungssystem, der Helpdesk, das Newsletter-Tool, die Recruiting-Plattform, bei der sich 2019 jemand angemeldet hat – jedes davon taucht als Quelle auf, die fehlschlägt, und jedes muss entweder autorisiert oder abgeschaltet werden.
3. Verschärfen Sie stufenweise. Wechseln Sie zu quarantine, warten Sie, beobachten Sie, und erst dann zu reject, denn jeder Schritt der Verschärfung kann lautlos Mail stoppen, auf die sich jemand verlässt.

Jeder dieser Schritte existiert, um legitime Absender vor Ihrer eigenen Richtlinie zu schützen. Eine Domain, die auf einen reinen Empfangs-Posteingang zeigt, hat keine legitimen Absender. Die Liste ist nicht lang, nicht schwer zu ermitteln und nicht teilweise unbekannt – sie ist leer. Und eine Richtlinie, die alles ablehnt, kann keinen Absender kaputtmachen, den es nicht gibt.

Es gibt auch ein Argument zweiter Ordnung dafür, direkt zum Endzustand zu gehen. Eine Domain, die bei p=none verharrt, veröffentlicht eine Richtlinie, die nichts verlangt, und ein empfangender Server behandelt das fast genauso wie eine Domain ganz ohne Richtlinie. Der Eintrag existiert, also sieht es erledigt aus – was schlimmer ist als offensichtlich unfertig, denn niemand kommt zurück, um es fertigzustellen.

Die drei Einträge

Alle drei sind TXT-Einträge, und alle drei kommen neben den MX-Eintrag, den Sie schon haben. Namen sind so geschrieben, wie die meisten DNS-Oberflächen sie erwarten – relativ zur Zone, wobei @ die Domain selbst meint. Falls Ihre einen vollqualifizierten Namen verlangt, schreiben Sie stattdessen yourdomain.com, _dmarc.yourdomain.com und *._domainkey.yourdomain.com.

Falls Ihr Provider verlangt, dass der Wert in Anführungszeichen steht, setzen Sie sie. Manche Oberflächen fügen die Anführungszeichen selbst hinzu und speichern sie am Ende doppelt, was einen Eintrag erzeugt, den kein Prüftool lesen kann – kommt ein Wert von dig mit zwei Sätzen Anführungszeichen darum zurück, ist genau das passiert.

Die drei Werte, fertig zum Einfügen. Kopieren Sie sie, statt sie neu zu tippen: Ein fehlendes Semikolon im DMARC-Eintrag macht die gesamte Tag-Liste unlesbar für den Parser, und eine unparsebare Richtlinie wird wie gar keine Richtlinie behandelt.

SPF – auf der Domain selbstv=spf1 -allKopieren

DMARC – auf dem Namen _dmarcv=DMARC1; p=reject; sp=reject; adkim=s; aspf=sKopieren

DKIM – auf dem Namen *._domainkeyv=DKIM1; p=Kopieren

Was jedes Wort in diesen Einträgen tatsächlich bewirkt

Fünf Entscheidungen, und es lohnt sich zu wissen, welche welche ist – vor allem, damit Sie später erkennen, welche Sie lockern müssten, falls die Domain doch einmal zu versenden beginnt.

-all

Das Ende des SPF-Eintrags, und der einzige Teil davon, der hier zählt. Es bedeutet alles, was oben nicht aufgeführt ist, ist eine Fälschung, und oben ist nichts aufgeführt. Die gängige Alternative, ~all, bedeutet wahrscheinlich eine Fälschung, aber trotzdem zustellen und markieren – die richtige Antwort, solange Sie noch Ihre eigenen Absender ermitteln, und die falsche, sobald Sie sicher sind, dass es keine gibt.

p=reject

Was ein empfangender Server mit Mail tun soll, die diese Domain beansprucht und durchfällt. none bedeutet nur melden, quarantine bedeutet als verdächtig behandeln, reject bedeutet in der SMTP-Konversation zurückweisen. Reject ist die Einstellung, die die Nachricht vollständig aus dem Blickfeld eines Menschen heraushält.

sp=reject

Dasselbe, angewendet auf jede Subdomain – einschließlich derer, die es gar nicht gibt. Ohne dieses Tag nutzt ein Fälscher billing.yourdomain.com, die keine eigenen Einträge hat und nichts erbt, was sie stoppen würde. Dieses Tag greift standardmäßig auf das zurück, was p sagt, sodass sich der Eintrag ohne es identisch verhält; es wird trotzdem ausgeschrieben, weil eine Richtlinie, die Sie beim Zurücklesen des Eintrags nicht sehen, eine Richtlinie ist, die Sie für fehlend halten werden.

adkim=s, aspf=s

Strikte Ausrichtung (Strict Alignment). Sie verlangt, dass die authentifizierte Domain exakt die Domain in der From:-Zeile ist, nicht nur mit ihr verwandt – sodass sich eine Nachricht von anything.yourdomain.com keine bestandene Prüfung der übergeordneten Domain aneignen kann. Relaxed ist der Standard, und Strict ist das, was eine Domain sagen sollte, die nichts zu autorisieren hat.

v=DKIM1; p=

Ein öffentlicher DKIM-Schlüssel ohne Schlüssel darin. Die Spezifikation legt ausdrücklich fest, dass ein leerer Schlüssel widerrufen bedeutet, sodass jede Signatur, die irgendeinen Selektor unter dieser Domain nennt, bei der Verifizierung durchfällt, statt ignoriert zu werden. Die Wildcard deckt jeden Selektornamen ab, den sich ein Fälscher ausdenken könnte, denn den Namen darf er sich aussuchen.

Und der Eintrag, der genau so bleiben muss, wie er ist

Nichts von alldem berührt eingehende Mail, und nichts davon sollte es. Der MX-Eintrag ist es, der jede Adresse auf der Domain zu einem Postfach hier macht, und er bleibt von all dem unverändert:

MX-Eintrag – unverändert10 smtp.grabmail.ioKopieren

Die drei neuen Einträge und dieser hier beantworten unterschiedliche Fragen, sie beeinflussen sich also nicht gegenseitig: SPF und DMARC werden von Servern gelesen, die entscheiden, ob sie Mail annehmen, die behauptet, von Ihnen zu sein, und der MX-Eintrag wird von Servern gelesen, die entscheiden, wohin sie Mail zustellen, die an Sie adressiert ist. Eine Domain mit allen vieren ist eine Domain, die alles empfängt und für niemanden bürgt.

Die eigene Arbeit prüfen, in drei Befehlen

DNS ist kein Ort für Vermutungen. Jeder dieser Einträge wird veröffentlicht, damit Fremde ihn lesen können, was bedeutet, dass Sie ihn genauso lesen können, wie sie es tun werden – kein Konto, kein Tool, keine Website, in die Sie Ihre Domain einfügen müssten:

$ dig +short TXT      yourdomain.com
dig +short TXT _dmarc.yourdomain.com
dig +short MX       yourdomain.com

Setzen Sie Ihre eigene Domain ein. Wonach Sie suchen, ist dies, abgesehen von den anderen TXT-Einträgen, die auf dem Namen eventuell schon vorhanden sind:

"v=spf1 -all"
"v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s"
10 smtp.grabmail.io.

Vier Arten, wie das schiefgehen kann, ungefähr nach Häufigkeit geordnet:

Der erste Befehl antwortet überhaupt nicht

Der Eintrag hat sich noch nicht verbreitet, oder er wurde am falschen Namen angelegt. TXT-Einträge auf der Domain selbst gehören auf @, nicht auf www – eine Oberfläche, die standardmäßig den zuletzt bearbeiteten Namen vorschlägt, ist meist der Übeltäter.

Zwei SPF-Einträge kommen zurück

Eine Domain darf genau einen haben. Zwei sind nicht strenger als einer – es ist ein dauerhafter Fehler, und ein empfangender Server, der zwei findet, behandelt die SPF-Prüfung als defekt statt als fehlgeschlagen. Falls Sie schon einen SPF-Eintrag hatten, bearbeiten Sie den, statt einen zweiten hinzuzufügen.

Die DMARC-Zeile kommt zurück, aber nichts setzt sie durch

Lesen Sie den Wert genau: Er muss mit v=DMARC1 beginnen, und die Tags sind durch Semikolons getrennt. Ein Eintrag ohne das Versions-Tag, oder einer, bei dem aus einem Semikolon ein Komma wurde, ist keine schwächere Richtlinie – er ist eine unparsebare, und das zählt wie gar keine Richtlinie.

Die MX-Antwort hat sich geändert

Das sollte sie nicht. Fehlt die MX-Zeile jetzt, zeigt sie einen bloßen Punkt, oder listet sie einen Host, der nicht smtp.grabmail.io ist, halten Sie inne und stellen Sie es wieder her, bevor Sie irgendetwas anderes tun – das ist der Eintrag, von dem Ihr Posteingang abhängt.

Der Teil, den fast jeder übersieht: Subdomains

DMARC und SPF teilen den Namensraum nicht auf dieselbe Weise, und genau dort entsteht das Leck einer sorgfältig geschützten Domain. sp=reject deckt tatsächlich jede Subdomain ab, ob existierend oder nicht. SPF funktioniert überhaupt nicht so: Es wird für den exakten Namen im Envelope nachgeschlagen, und ein Name ohne eigenen SPF-Eintrag hat keinen SPF-Eintrag – er erbt nicht den der übergeordneten Domain.

DMARC deckt die zweite Zeile schon von sich aus ab, es geht hier also um doppelte Absicherung, nicht um eine echte Lücke – aber ein Wildcard-SPF-Eintrag kostet nur eine Zeile und schließt die Lücke auch auf der SPF-Ebene, was für die Empfänger zählt, die SPF prüfen, aber kein DMARC implementieren:

Wildcard-SPF – ein weiterer TXT-Eintrag* TXT v=spf1 -allKopieren

Eine DNS-Wildcard antwortet nur für Namen, die keine eigenen Einträge haben. Hat mail.yourdomain.com bereits irgendeinen TXT-Eintrag, wird die Wildcard für diesen Namen nicht herangezogen, und Sie müssten den SPF-Eintrag dort explizit veröffentlichen. Für eine Domain, die nur als Catch-all genutzt wird, ist diese Situation selten genug, dass es sich lohnt, sie zu kennen, aber nicht, sie einzuplanen.

Berichte, und ob sie sich lohnen

DMARC hat eine Berichtsseite: Fügen Sie ein rua-Tag hinzu, und teilnehmende Empfänger schicken Ihnen täglich eine Zusammenfassung von allem, was behauptet hat, Ihre Domain zu sein, und was damit geschah. Das ist der eine Teil von DMARC, der Ihnen etwas sagt, das Sie nicht schon wussten, und auf einer Domain, die hierher zeigt, kostet das Sammeln nichts, weil die Adresse, an die es geht, eine Adresse auf der Domain selbst sein kann:

DMARC mit Berichten – Domain ersetzenv=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@yourdomain.comKopieren

Die Berichte an eine Adresse auf derselben Domain zu schicken, umgeht einen Teil der Spezifikation, der Leute gerne hereinlegt: Nennt rua eine Adresse auf einer anderen Domain, muss diese andere Domain einen Eintrag veröffentlichen, der sie autorisiert, Ihre Berichte zu empfangen, und bis das passiert, verschicken die meisten Absender gar keine. Gleiche Domain, kein solcher Eintrag nötig, nichts, was schiefgehen kann. Was ankommt, sollten Sie kennen, bevor Sie es aktivieren:

• Sie sind XML, gzip-komprimiert, als Anhang. Keine Zusammenfassung, die man bei einem Kaffee liest. Kleine Domains bekommen eine Handvoll pro Tag von den großen Mailbox-Anbietern, jede wenige Kilobyte groß; Sie werden etwas brauchen, das sie entpackt und liest.
• Leer ist das gute Ergebnis. Eine Domain, die nichts versendet, sollte Berichte erzeugen, die nichts als Fehlschläge auflisten, und eine ruhige Woche bedeutet, dass Sie gerade niemand fälscht – das ist eine Information, und der einzige Weg, sie zu bekommen.
• Sie kommen als ganz normale Mail an. Hier bedeutet das: ein ganz normales Postfach, lesbar im Browser und über die API wie alles andere, und nach 5 Tagen gelöscht, zusammen mit allem anderen.

Wenn Sie sie lieber gar nicht sammeln möchten, lassen Sie das Tag ganz weg. Ein DMARC-Eintrag ohne rua ist ein völlig gültiger Eintrag und schützt genauso gut; Berichte sind, wie Sie erfahren, was passiert, nicht, wie die Richtlinie durchgesetzt wird.

Was das hier nicht bewirkt

Diese Einträge sind eng gefasst, und Klarheit über ihre Grenzen macht den Unterschied zwischen einer Kontrolle, auf die Sie sich richtig verlassen, und einer, auf die Sie sich falsch verlassen. Vier Dinge, die sie nicht abdecken:

Sie filtern nicht Ihren eigenen Posteingang

SPF und DMARC auf Ihrer Domain sind Anweisungen an Server, die Mail von Ihnen empfangen. Sie werden von den Mailsystemen anderer Leute gelesen, nie von Ihrem eigenen, und sie haben keine Auswirkung darauf, was im Catch-all landet. Was ankommt, ist weiterhin alles, was die Welt an eine Adresse schickt, deren einziger Nachweis darin besteht, sie zu kennen.

Sie stoppen keinen Namen in einer From-Zeile

Eine Nachricht mit Your Company <attacker@gmail.com> besteht jede Prüfung, weil die authentifizierte Domain tatsächlich dem Angreifer gehört. DMARC schützt die Domain, nicht den Anzeigenamen davor – und auf einem Smartphone ist der Anzeigename häufig alles, was zu sehen ist.

Sie rühren eine Lookalike-Domain nicht an

Eine Domain, die nur ein Zeichen von Ihrer entfernt ist, ist die Domain eines anderen mit den Einträgen eines anderen. Nichts, was Sie veröffentlichen, reicht dorthin. Das ist ein Registrar- und Monitoring-Problem, und es ist wirklich ein anderes Problem.

Sie machen das Postfach nicht privat

Es gibt hier weiterhin kein Passwort auf einer Adresse: Wer immer sie kennt, kann sie lesen, das ist der Kompromiss, auf dem der gesamte Dienst beruht. Ihre eigene Domain nimmt das Erraten weg, nicht das Lesen – die ehrliche Version davon steht in der Anleitung zu Catch-all-Domains.

Die Einrichtung, von Anfang bis Ende

Die ganze Aufgabe, in der Reihenfolge, die die Domain bei jedem Schritt funktionsfähig lässt:

1. Bestätigen Sie zuerst den MX-Eintrag. dig +short MX yourdomain.com sollte smtp.grabmail.io und sonst nichts beantworten. Beheben Sie das, bevor Sie irgendetwas hinzufügen, denn der Rest ist wertlos auf einer Domain, die nicht empfängt.
2. Fügen Sie den SPF-Eintrag hinzu auf @, sofern nicht schon einer da ist – in dem Fall bearbeiten Sie ihn, denn zwei sind ein Fehler und keine strengere Einstellung.
3. Fügen Sie den DMARC-Eintrag hinzu auf _dmarc, direkt mit der strengen Richtlinie. Es gibt hier kein Rollout zu staffeln und nichts, was durch das Überspringen kaputtgehen könnte.
4. Fügen Sie den Wildcard-DKIM-Eintrag hinzu auf *._domainkey, und den Wildcard-SPF-Eintrag, falls Sie die Subdomain-Ebene doppelt geschlossen haben wollen.
5. Lesen Sie alle vier zurück mit dig, gegen einen öffentlichen Resolver, sobald die TTL Zeit hatte abzulaufen.
6. Schicken Sie sich selbst etwas. Schreiben Sie von irgendwoher an eine Ihrer eigenen Adressen auf der Domain und öffnen Sie den Posteingang. Kommt sie an, hat die Empfangsseite die Änderung überstanden, und das ist die einzige Regression, die zu prüfen sich lohnt.

Damit ist die Domain fertig: Sie nimmt jede Adresse an, die Sie je darauf erfinden werden, und sie bürgt für niemanden. Falls Sie die Domain noch nicht verbunden haben, beginnen Sie mit der Catch-all-Anleitung – das ist ein Eintrag und dieselben fünf Minuten – und kommen Sie danach auf diese Seite zurück, das ist die Reihenfolge, die nichts halb erledigt lässt.

Fragen