SPF in der Praxis: alle Versender erfassen

Modul 4: Zustellbarkeit: SPF, DKIM und DMARC in der Praxis · Lesezeit: 12 Minuten

Lernziel: Nach dieser Lektion können Sie alle Dienste aufspüren, die im Namen Ihrer Domain Mail versenden, sie in einem einzigen SPF-Record unterbringen, die Lookups rekursiv bis zur Grenze von zehn zählen und bewusst zwischen ~all und -all wählen.

Kernbegriffe: Inventar der Versender, Envelope-Absender (Return-Path), ein SPF-Record, include, redirect, Grenze von 10 DNS-Lookups (RFC 7208 Abschnitt 4.6.4), leere Lookups (void lookups, maximal 2), rekursives Zählen, permerror, Flattening, SPF für Subdomains, SPF auf einer Domain, die nicht mailt, ~all und -all

Kurz zur Wiederholung

Ein SPF-Record ist ein TXT-Record auf Ihrer Domain, der mit v=spf1 beginnt und auflistet, welche Server im Namen Ihrer Domain mailen dürfen. Der Aufbau, die Zeichen + - ~ ? und die drei bekanntesten Fehler (zwei Records, +all, mehr als zehn Lookups) stehen im DNS-Kurs, Lektion 4.3. Lesen Sie diese zuerst, wenn SPF für Sie neu ist. Diese Lektion behandelt den schwierigen Teil: In der Praxis weiß fast niemand genau, wer alles im Namen seiner Domain mailt.

Schritt 1: das Inventar

SPF funktioniert nur, wenn alle Versender erfasst sind. Vergessen Sie einen, landet dessen Mail im Spam oder wird abgewiesen, sobald Sie DMARC verschärfen. Gehen Sie daher diese Liste durch. Bei einem durchschnittlichen kleinen Unternehmen finden Sie schnell fünf oder sechs:

Zwei gute Methoden, um sie zu finden:

1. Header lesen. Schicken Sie aus jedem System eine Mail an sich selbst (eine Rechnung, eine Passwortwiederherstellung, einen Test-Newsletter) und schauen Sie in den Headern nach Return-Path und Authentication-Results (Lektion 1.5). Dort sehen Sie, über welche Domain und welchen Server sie kam.
2. DMARC-Berichte. Setzen Sie DMARC auf p=none mit einer Berichtsadresse (Lektion 4.4). Nach ein paar Wochen sehen Sie in den Berichten (Lektion 4.5) jeden Server, der im Namen Ihrer Domain gemailt hat, auch solche, die Sie vergessen hatten. Das ist das zuverlässigste Inventar.

Nicht jeder Dienst gehört in Ihr SPF

Hier geht es oft schief. SPF schaut auf den Envelope-Absender (den Return-Path), nicht auf die Von-Adresse. Viele Newsletter- und Versanddienste versenden mit einem Return-Path auf ihrer eigenen Domain, zum Beispiel bounce-123@mail.mailer.example. Der Empfänger prüft dann das SPF-Record von mailer.example, nicht Ihres. Ein include dieses Dienstes in Ihrem Record bewirkt dann nichts, außer dass es einen Lookup kostet.

Was dieser Dienst tatsächlich braucht, um DMARC zu bestehen, ist eine DKIM-Signatur mit Ihrer Domain (Lektion 4.3), oder ein eigenes Return-Path-Subdomain von Ihnen (zum Beispiel bounce.example.com als CNAME zum Dienst). Lesen Sie daher in der Anleitung des Dienstes, was er verlangt. Sagt er „setzen Sie include: in Ihr SPF ein", tun Sie das. Sagt er nur „erstellen Sie diese CNAME-Records für DKIM und die Bounce-Domain", dann muss nichts in Ihrem Hauptrecord stehen. Modul 7 geht darauf weiter ein.

Schritt 2: ein Record, und richtig zählen

Alle Versender kommen in ein Record. Angenommen, Ihr Inventar ergibt Folgendes: der Mailserver Ihres Hosting-Anbieters, Microsoft 365 für ein paar Mitarbeiter, Ihr Buchhaltungsprogramm und ein Helpdesk. Dann wird das Record beispielsweise so:

example.com.  3600  IN  TXT  "v=spf1 a mx include:spf.hosting.example include:spf.protection.outlook.com include:_spf.boekhoud.example include:mail.helpdesk.example ~all"

Wie viele Lookups sind das? Zählen Sie jedes a, mx, include, exists, ptr und redirect, und zählen Sie danach auch alles, was in den Records hinter jedem Include steht:

Bei 11 gibt der Empfänger einen permerror: Das gesamte SPF-Record zählt dann nicht, für keinen einzigen Versender. Ihre Mail von Ihrem eigenen Mailserver wird also schlechter bewertet, weil der Helpdesk drei Lookups kostet. Und das Tückische ist: Ihr Record kann heute 9 sein und morgen 11, ohne dass Sie etwas ändern, weil ein Dienst sein eigenes Record erweitert.

Außerdem: maximal zwei leere Lookups

RFC 7208 nennt auch void lookups: Lookups, die nichts ergeben (der Name existiert nicht, oder hat kein SPF- oder Adressrecord). Mehr als zwei davon führen ebenfalls zu einem permerror. Das passiert vor allem bei alten includes von Diensten, die Sie nicht mehr nutzen und die ihr Record entfernt haben, oder bei einem a: zu einem Server, der nicht mehr existiert. Also aufräumen.

Schritt 3: zurück unter die Zehn

Liegen Sie über zehn, gibt es vier Lösungen, von der besten zur am wenigsten guten:

1. Entfernen Sie, was nicht nötig ist. Dienste, die Sie nicht mehr nutzen. Dienste, die mit eigenem Return-Path versenden (siehe oben) und daher nicht in Ihr SPF gehören. a, wenn Ihre Website selbst keine Mail versendet. mx, wenn Ihr MX auf einen Dienst zeigt, der bereits mit einem include in Ihrem Record steht.
2. Nutzen Sie ein Subdomain. Lassen Sie einen Dienst von nieuws.example.com oder factuur.example.com versenden. Dieses Subdomain erhält ein eigenes SPF-Record nur mit diesem Dienst und zählt nicht in die Zehn Ihrer Hauptdomain. Alignment in DMARC (Lektion 4.4) funktioniert standardmäßig auch für Subdomains.
3. Nutzen Sie ip4: und ip6: für Ihre eigenen festen Server. Die kosten keinen Lookup. Tun Sie das nur für Adressen, die Sie selbst verwalten und die sich nicht ändern.
4. Flattening (alle Includes durch die IP-Adressen ersetzen, die aktuell dahinterstehen). Das bringt die Anzahl auf 0, aber das Record stimmt nicht mehr, sobald ein Dienst seine Adressen ändert, und große Dienste tun das regelmäßig. Tun Sie das nur mit einem Tool, das es automatisch aktuell hält, und am besten gar nicht.

redirect oder include?

redirect= bedeutet: Verwenden Sie das SPF-Record dieser anderen Domain anstelle dieses Records. Es kostet einen Lookup, genau wie ein Include. Es ist nützlich, wenn Sie viele Domains haben, die genau dieselbe Richtlinie erhalten sollen: v=spf1 redirect=_spf.example.com auf jeder Domain, und das eigentliche Record an einer Stelle. Ein Record mit redirect= darf kein all haben, denn dann wird der Redirect ignoriert. Gmail nutzt es selbst: gmail.com hat v=spf1 redirect=_spf.google.com.

Schritt 4: ~all oder -all?

Die Empfehlung dieses Kurses, gleich wie im DNS-Kurs:

• Beginnen Sie mit ~all (softfail). Mail von einem Server, der nicht in Ihrem Record steht, wird als verdächtig eingestuft, aber meist nicht sofort abgewiesen. Vergessen Sie einen Versender, ist der Schaden begrenzt.
• Gehen Sie zu -all (fail), wenn Sie sicher wissen, dass alle Versender erfasst sind, zum Beispiel nachdem Sie ein paar Wochen DMARC-Berichte angesehen haben und es keine unbekannten Quellen mehr gibt.

Mit DMARC dazu ist der Unterschied kleiner, als oft gedacht wird. DMARC entscheidet auf Basis von „SPF oder DKIM bestanden und im Alignment". Ein softfail gilt für DMARC einfach als „nicht bestanden". Der eigentliche Schutz kommt also von einer strengen DMARC-Richtlinie, nicht von -all. Manche Empfänger weisen bei -all bereits vor der DMARC-Bewertung ab; das ist ein Grund, -all erst zu wählen, wenn Ihr Record wirklich vollständig ist.

Eine Domain, die nie mailt

Haben Sie Domains, die nie Mail versenden (ein alter Markenname, eine Tippfehler-Domain)? Schützen Sie diese dann vor Missbrauch mit:

example.org.         IN  TXT  "v=spf1 -all"
_dmarc.example.org.  IN  TXT  "v=DMARC1; p=reject"
example.org.         IN  MX   0 .

Hier ist -all sofort richtig: Niemand darf mailen. Die letzte Zeile ist ein null MX (RFC 7505): „diese Domain empfängt keine Mail". example.com selbst ist genau so eingestellt.

In der Praxis: so sieht es in einem Panel aus

Bei einem Hosting-Paket von WebOké steht standardmäßig v=spf1 a mx include:webawere.nl ~all. Fügen Sie einen Dienst hinzu, passen Sie dieses Record an (in DirectAdmin: DNS-Verwaltung, der Stift hinter dem SPF-Record, Feld Domain einschließen; in Mein WebOké: die SPF-Hilfe im Tab DNS). Lassen Sie include:webawere.nl stehen, solange Ihre Mail oder Website über diese Server läuft. Bei anderen Anbietern heißt das Standard-Include anders, aber das Prinzip ist gleich: ergänzen, nicht ein zweites Record anlegen.

Zusammenfassung

• Erstellen Sie zuerst ein Inventar aller Versender; DMARC-Berichte und Header helfen dabei.
• Ein Dienst mit eigenem Return-Path gehört nicht in Ihr SPF; der braucht DKIM mit Ihrer Domain.
• Zählen Sie rekursiv: jedes include, a, mx, exists, ptr und redirect, auch innerhalb von Includes. Über zehn, oder mehr als zwei leere Lookups, bedeutet permerror.
• Kommen Sie zurück unter die Zehn, indem Sie aufräumen und Subdomains nutzen; Flattening nur mit automatischer Pflege.
• Beginnen Sie mit ~all, gehen Sie zu -all, wenn Sie sicher sind. Domains, die nie mailen: -all, DMARC reject und null MX.

Quiz

Aufgabe

Aufgabe Z4.2: SPF Ihrer Domain rekursiv zählen lassen. Geben Sie Ihre eigene Domain ein (oder sidn.nl, wenn Sie keine eigene Domain haben). Zählen Sie zuerst selbst, wie viele DNS-Lookups das SPF-Record kostet, einschließlich allem innerhalb der Includes, und tragen Sie die Zahl ein, zusammen mit dem Ende des Records (~all, -all, ?all oder +all). Das Programm zählt live nach, einschließlich leerer Lookups, und zeigt den Baum.

Aufgabe O4.2: Ihre Versenderinventur. Erstellen Sie mit der Tabelle aus dieser Lektion eine Liste aller Systeme, die im Namen Ihrer Domain Mail versenden. Notieren Sie bei jedem: über welchen Server oder Dienst, ob er in Ihr SPF gehört (eigener Return-Path oder nicht), und ob er DKIM mit Ihrer Domain signiert. Schicken Sie aus mindestens zwei Systemen eine Testmail an sich selbst und notieren Sie aus den Headern die Return-Path-Domain und die DKIM-Domain (d=).

Weiterführende Informationen

Die Schritte in diesen Artikeln gelten für die Panels von WebOké; bei anderen Anbietern funktioniert es ähnlich.

• Kostenloser DNS-Kurs 4.3: SPF: wer darf im Namen Ihrer Domain E-Mails versenden?
• DirectAdmin Anleitung 5.7: SPF einrichten und ergänzen
• Wie funktioniert der SPF-Eintrag in der DNS?
• SPF-Eintrag in DirectAdmin hinzufügen oder ändern
• WebOké Anleitung 5.5: DNS-Helfer: MX, SPF, DMARC, CAA und SRV
• RFC 7208 (SPF), Abschnitt 4.6.4 (Grenzwerte) und 6.1 (redirect); RFC 7505 (null MX)