SPF, DKIM und DMARC: was die drei wirklich tun

Fast jede Firma, deren Mailkonfiguration wir uns ansehen, hat SPF. Viele haben zusätzlich DKIM. Und trotzdem kann jeder Fremde in ihrem Namen Rechnungen verschicken.

Das liegt nicht daran, dass die Einträge falsch wären. Es liegt daran, dass SPF und DKIM ohne DMARC folgenlos bleiben: Sie stellen fest, dass etwas nicht stimmt, sagen dem Empfänger aber nicht, was er dann tun soll. Also stellt er zu.

Die kurze Antwort

SPF legt fest, welche Server für eure Domain senden dürfen. DKIM unterschreibt jede Mail kryptografisch. DMARC verbindet beides, sagt dem Empfänger was bei einem Durchfall zu tun ist, und schickt euch Berichte darüber.

Alle drei sind TXT-Einträge im DNS. Keiner davon kostet Geld. Zusammen brauchen sie einen Nachmittag, plus einige Wochen Beobachtung, bevor man scharf stellt.

SPF: Wer darf senden?

Ein SPF-Eintrag ist eine Liste erlaubter Absender:

v=spf1 include:spf.protection.outlook.com include:_spf.mailjet.com -all

Übersetzt: „Microsoft 365 und Mailjet dürfen für uns senden. Alle anderen nicht.“ Das -all am Ende ist der entscheidende Teil, es sagt „alles Übrige ablehnen“. Steht dort ~all, heißt das nur „verdächtig, aber zustellen“. Fehlt das all ganz, ist die Liste eine Empfehlung ohne Wirkung.

Die Grenze von zehn Lookups

Hier liegt der Fehler, den wir am häufigsten finden und der am wenigsten bekannt ist:

Ein SPF-Eintrag darf beim Auswerten höchstens zehn DNS-Abfragen auslösen. Wer darüber liegt, dessen SPF gilt als fehlerhaft, manche Empfänger ignorieren ihn dann vollständig. Festgelegt in RFC 7208, Abschnitt 4.6.4.

Der Empfänger meldet das als permerror. Bei DMARC zählt es als nicht bestanden, und wenn eure Richtlinie scharf steht, gehen eigene Mails verloren.

Jedes include: zählt. Und zwar nicht nur einmal: Was hinter dem include steht, bindet oft selbst wieder etwas ein. Microsoft 365 allein kostet mehrere Lookups. Wer dazu ein Newslettersystem, ein CRM, einen Shop und einen Rechnungsdienst einbindet, ist über der Grenze, ohne es zu merken. Der Eintrag sieht ja weiterhin richtig aus.

Was zählt zu den zehn Lookups?

Nicht jeder Bestandteil kostet eine Abfrage. Die Unterscheidung ist der ganze Trick:

Ein Beispiel, das harmlos aussieht:

v=spf1 include:spf.protection.outlook.com include:_spf.mailjet.com
       include:servers.mcsv.net include:_spf.google.com ~all

Vier include: in der sichtbaren Zeile. Aufgelöst sind es je nach Anbieter schnell zehn bis fünfzehn Abfragen, weil Microsoft, Google und die Newsletter-Dienste intern weiter verzweigen. Der Eintrag ist damit ungültig, und niemand sieht es ihm an.

Wie zählt ihr selbst nach?

Ihr braucht kein Werkzeug, nur Geduld und nslookup oder dig:

nslookup -type=TXT spf.protection.outlook.com

In der Antwort steht wieder ein SPF-Eintrag. Jedes include: darin zählt erneut, und dessen Inhalt ebenfalls. So arbeitet man den Baum von oben nach unten ab und addiert.

Wer es schneller mag: Unser DMARC-Check löst die Kette automatisch auf und nennt die Zahl. Er warnt außerdem, wenn ihr bei neun oder zehn steht, denn dann kippt der nächste hinzugefügte Dienst den Eintrag.

Welche zweite Grenze kennt kaum jemand?

Im selben Abschnitt des RFC steht eine weitere Obergrenze: Höchstens zwei der Abfragen dürfen ins Leere laufen. Gemeint sind Abfragen, die nichts zurückliefern, weil der Name nicht mehr existiert oder keinen passenden Eintrag hat.

Der typische Fall ist ein include, das auf einen Dienst zeigt, den es längst nicht mehr gibt. Der Eintrag sieht unauffällig aus, kostet weiterhin eine Abfrage, und ab der dritten toten Verzweigung gilt derselbe permerror wie beim Überschreiten der Zehn.

Dazu kommen zwei Längengrenzen, die im DNS selbst stecken:

• Eine einzelne Zeichenkette in einem TXT-Eintrag darf 255 Zeichen lang sein. Längere Einträge werden in mehrere Ketten aufgeteilt, die der Empfänger wieder zusammensetzt. Das ist erlaubt, aber nicht jede DNS-Oberfläche macht es richtig.
• Passt die gesamte Antwort nicht mehr in ein UDP-Paket, muss der Empfänger über TCP nachfragen. Die meisten tun das, manche Firewalls lassen es nicht zu.

Beide Längengrenzen trifft vor allem, wer seinen Eintrag künstlich aufbläht. Womit wir beim nächsten Punkt wären.

Warum ist „SPF-Flattening“ die falsche Antwort?

Die Lösung, die man online am häufigsten liest, heißt Flattening: Man löst alle include: einmal auf und schreibt die gefundenen IP-Adressen direkt als ip4:-Bereiche in den Eintrag. Danach kostet nichts mehr eine Abfrage, und das Problem ist weg.

Für eine Woche.

Die IP-Bereiche der großen Anbieter ändern sich, ohne dass euch jemand Bescheid sagt. Genau dafür ist das include: da: Es zeigt auf eine Liste, die der Anbieter pflegt. Wer sie einfriert, übernimmt diese Pflege selbst, ohne es zu wissen. Wenn Microsoft einen Ausgangsserver umzieht, fällt eure Mail von diesem Server durch, und der Eintrag sieht weiter tadellos aus.

Es gibt Dienste, die das Flattening automatisch nachziehen. Damit hängt eure Mailzustellung an der Verfügbarkeit eines weiteren Anbieters, den ihr für ein Problem eingekauft habt, das sich meist anders lösen lässt.

Flattening ist vertretbar für eigene, feste Server, deren Adressen ihr selbst kontrolliert. Für fremde Dienste ist es eine Wette.

Was hilft stattdessen?

Erstens: aufräumen. In fast jedem Eintrag, den wir uns ansehen, stehen Dienste, die seit Jahren nichts mehr verschicken. Der Newsletter-Anbieter von davor, ein Bewerbungsportal, eine Testphase. Jeder davon kostet dauerhaft Abfragen. Das ist der billigste Gewinn und kostet zwanzig Minuten.

Zweitens: ptr streichen. Der Term ist langsam, unzuverlässig und laut RFC ausdrücklich unerwünscht. Er kommt trotzdem in alten Einträgen vor.

Drittens: Subdomains für einzelne Dienste. Der wirksamste Schritt, und der am seltensten gegangene. Der Newsletter geht nicht von firma.de raus, sondern von news.firma.de, mit eigenem SPF-Eintrag und eigenem Budget von zehn Abfragen. Die Hauptdomain behält nur das, was aus dem Haus kommt.

Das hat einen zweiten Vorteil: Fällt der Newsletter-Anbieter durch eine Sperrliste, betrifft das den Ruf der Subdomain, nicht den eurer Rechnungsadresse.

Viertens: a und mx prüfen. Beide stehen oft aus Gewohnheit im Eintrag, obwohl der Webserver gar keine Mail verschickt und die MX-Server nur empfangen. Zwei Abfragen, die niemand braucht.

DKIM: die Unterschrift

DKIM hängt an jede ausgehende Mail eine kryptografische Signatur. Der Empfänger holt sich den öffentlichen Schlüssel aus eurem DNS und prüft, ob die Mail unterwegs verändert wurde.

Der Schlüssel liegt unter einem Selektor, einem frei gewählten Namen:

selector1._domainkey.firma.de

Deshalb kann ein Prüfwerkzeug DKIM nie mit Sicherheit ausschließen: Es müsste den Namen erraten. Unser DMARC-Check probiert zwölf verbreitete Selektoren von Microsoft 365, Google Workspace, IONOS und anderen durch. Findet er keinen, heißt das nur: nicht unter einem der üblichen Namen.

DMARC: die Entscheidung

DMARC ist der Eintrag, der aus den beiden anderen Schutz macht:

v=DMARC1; p=none; rua=mailto:dmarc@firma.de

Zwei Angaben zählen.

p= ist die Richtlinie. Sie sagt dem Empfänger, was er mit einer Mail tun soll, die weder SPF noch DKIM besteht:

rua= ist die Berichtsadresse. Dorthin schicken Google, Microsoft und die anderen großen Empfänger täglich eine Zusammenfassung: Wer hat in eurem Namen gesendet, und hat es die Prüfung bestanden? Ohne rua fliegt man blind.

Warum p=none kein Schutz ist

Bei p=none wird nur beobachtet. Gefälschte Mails werden trotzdem zugestellt.

Als Startpunkt ist das genau richtig, man braucht die Berichte, bevor man verschärft. Als Dauerzustand ist es eine Attrappe: Der Eintrag ist da, das Prüfwerkzeug zeigt grün, und schützen tut er nichts.

Wir sehen p=none bei der Mehrheit der Domains, die wir prüfen. Meistens, weil jemand vor zwei Jahren den ersten Schritt gemacht und den zweiten nie nachgeholt hat.

Die Spezifikation dahinter ist frei einsehbar: RFC 7489 beschreibt DMARC im Wortlaut, dmarc.org fasst dasselbe kürzer zusammen. Was Google und Microsoft von größeren Versendern konkret verlangen, steht in den Richtlinien für E-Mail-Absender.

Warum besteht SPF, und DMARC fällt trotzdem durch?

Hier hören die meisten Anleitungen auf, und hier kommen die meisten überraschenden Berichte her. Der Fachbegriff ist Ausrichtung, im Englischen alignment.

SPF und DKIM prüfen nämlich gar nicht die Adresse, die im Postfach steht.

• SPF prüft den Absender auf dem Umschlag, den Return-Path. Den sieht kein Mensch, und bei einem Versanddienst gehört er meist dem Dienst: bounces.dienstleister.com.
• DKIM unterschreibt für die Domain, die in der Signatur unter d= steht. Auch die gehört oft dem Dienst.
• DMARC interessiert sich für die dritte Adresse: die im Feld Von, die eure Kunden lesen.

DMARC ist nur bestanden, wenn mindestens eine der beiden ersten Domains zur Adresse im Feld Von passt. Tut sie das nicht, war die Prüfung technisch erfolgreich und trotzdem wertlos.

Der Klassiker sieht so aus: Ein Newsletter geht über einen Dienstleister raus, im Postfach steht info@firma.de als Absender. SPF besteht, für die Domain des Dienstleisters. DKIM besteht, für die Domain des Dienstleisters. DMARC fällt durch, weil keine der beiden firma.de ist. Bei p=reject wäre der Newsletter verschwunden.

Der Ausweg steht bei jedem größeren Versanddienst unter „eigene Domain verifizieren“: eine eigene Bounce-Subdomain per CNAME und ein DKIM-Schlüssel, der mit d=firma.de unterschreibt. Danach passt die Ausrichtung, und der nächste Bericht zeigt es.

Wie streng verglichen wird, steuert ihr selbst. Voreingestellt genügt die Organisationsdomain, mail.firma.de passt also zu firma.de. Wer aspf=s oder adkim=s setzt, verlangt exakte Gleichheit. Das ist strenger, als die meisten gewachsenen Aufbauten vertragen, und selten nötig.

Weiterleitungen: warum Schritt 4 nicht optional ist

Es gibt einen Fall, in dem eine vollkommen echte Mail die Prüfung nicht besteht, und der ist häufiger als jede Fälschung: die Weiterleitung.

Wird eine Mail von einer Adresse an eine andere weitergereicht, kommt sie beim Ziel von einem anderen Server als dem, der in eurem SPF-Eintrag steht. SPF fällt durch, und zwar zu Recht, denn der weiterleitende Server steht ja nicht auf der Liste. Betroffen ist genau das, was in kleineren Firmen üblich ist: info@ verteilt auf mehrere Postfächer, eine alte Adresse zeigt auf die neue, ein Verteiler streut an zwanzig Leute.

In diesem Fall rettet nur DKIM. Die Unterschrift überlebt die Weiterleitung, weil sie an der Mail hängt und nicht am Server. Deshalb ist DKIM auf jedem sendenden System die Bedingung dafür, dass p=reject gefahrlos ist, und keine Fleißaufgabe.

Eine Einschränkung bleibt: Verteiler, die den Betreff ergänzen oder unten eine Fußzeile anhängen, verändern die Mail und machen die Unterschrift ungültig. Dann fällt auch DKIM durch. Wer solche Listen betreibt, sieht das in den Berichten und stellt sie um, bevor er verschärft.

Die Falle mit der Subdomain

Ein DMARC-Eintrag auf mail.firma.de schützt firma.de nicht.

Das ist uns selbst passiert. Ein Aggregatbericht meldete 20 von 20 bestandenen Prüfungen, für unsere Versand-Subdomain. Unter der Hauptdomain, unter der uns die Kunden kennen und unter der sie Rechnungen von uns erwarten, gab es gar keinen DMARC-Eintrag.

DMARC wird von der Organisationsdomain aus vererbt, nicht umgekehrt. Wer eine Subdomain absichert, hat die Hauptdomain nicht abgesichert. Für Subdomains gibt es dafür sp=, die eigene Richtlinie für alles unterhalb.

Die Reihenfolge, die niemand abkürzen sollte

1. SPF vervollständigen. Alle sendenden Systeme aufnehmen, danach die Lookups zählen.
2. DKIM einschalten, bei jedem sendenden System einzeln.
3. DMARC mit p=none und rua= anlegen. Ab hier laufen Berichte ein.
4. Zwei bis vier Wochen Berichte auswerten. Sie zeigen Systeme, an die sich niemand mehr erinnert: das alte Ticketsystem, den Drucker, den Dienstleister von 2019.
5. Auf p=quarantine, beobachten.
6. Auf p=reject, erst wenn über mehrere Wochen nichts Eigenes mehr durchfällt.

Wer Schritt 4 überspringt und direkt auf p=reject geht, verliert echte Mail. Nicht theoretisch: Rechnungen, Bestellbestätigungen, Newsletter. Und man merkt es erst, wenn sich jemand beschwert.

Was steht in einem DMARC-Bericht wirklich?

DMARC angelegt, rua= eingetragen, und seitdem kommt jeden Tag ein ZIP-Anhang mit XML darin. Die meisten legen einen Ordner an und schauen nie wieder hinein.

Damit fehlt aber genau der Teil, der die Umstellung erst möglich macht.

Entpackt sieht ein Bericht ungefähr so aus, hier auf das Wesentliche gekürzt:

<record>
  <row>
    <source_ip>40.107.22.11</source_ip>
    <count>34</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>firma.de</header_from>
  </identifiers>
</record>

Übersetzt: Von dieser IP kamen an diesem Tag 34 Mails mit firma.de als sichtbarem Absender. DKIM hat gepasst, SPF nicht. Zugestellt wurde trotzdem, weil p=none steht.

Vier Felder genügen zum Verstehen:

disposition ist das Ergebnis eurer Richtlinie, nicht der Prüfung. Bei p=none steht dort immer none, auch bei einem klaren Durchfall. Wer nur auf diese Spalte schaut, hält eine offene Domain für sicher.

Welche drei Sorten Absender werdet ihr finden?

Sortiert die IP-Adressen nach Menge, dann bildet sich fast immer dasselbe Muster:

Erstens die bekannten eigenen Systeme. Postfach, Newsletter, Shop. Die sollen bestehen, und meistens tun sie das. Wenn nicht, fehlt eine Angabe im SPF-Eintrag oder das System signiert nicht mit DKIM.

Zweitens die vergessenen eigenen Systeme. Das ist der eigentliche Ertrag der Beobachtungsphase. Ein Ticketsystem von 2019, der Multifunktionsdrucker, der Scans verschickt, ein Monitoring-Dienst, das Buchhaltungsprogramm, die Agentur, die für euch einen Serienbrief rausgeschickt hat. Jede dieser Quellen fällt bei p=reject still aus, und niemand verbindet die ausbleibende Mail mit einem DNS-Eintrag, den jemand vor drei Monaten geändert hat.

Drittens tatsächlich Fremde. Einzelne IPs, kleine Zahlen, oft aus Netzbereichen, die mit eurem Geschäft nichts zu tun haben. Die dürfen durchfallen, dafür ist der Eintrag da.

Die Trennung zwischen der zweiten und der dritten Gruppe ist die ganze Arbeit. Sie lässt sich nicht raten, nur nachschlagen: IP im Whois nachschauen, im Zweifel intern fragen, wer diesen Dienst benutzt.

Woran erkennt ihr im Bericht ein Ausrichtungsproblem?

Manchmal steht unter auth_results spf: pass und dkim: pass, und die Mail zählt trotzdem als durchgefallen. Das liegt nicht an einem Fehler im Bericht, sondern an der Ausrichtung.

Woran man es im Bericht erkennt: Im Abschnitt auth_results steht die Domain, für die geprüft wurde. Weicht sie von header_from ab, ist die Ausrichtung das Problem und nicht die Prüfung selbst.

Was gilt, wenn die Berichtsadresse in einer fremden Domain liegt?

Wenn rua= auf eine Adresse zeigt, die nicht zu der geprüften Domain gehört, braucht es eine Freigabe auf der anderen Seite. In der Zone der Empfängerdomain muss ein TXT-Eintrag stehen:

firma.de._report._dmarc   TXT   v=DMARC1

Fehlt er, verwerfen die meisten Versender den Bericht kommentarlos. Das ist die häufigste Ursache dafür, dass jemand DMARC korrekt eingerichtet hat und trotzdem nie einen Bericht bekommt. Nachzulesen in RFC 7489, Abschnitt 7.1.

Wann könnt ihr auf p=reject verschärfen?

Drei Bedingungen, alle drei müssen erfüllt sein:

1. Jede eigene sendende Quelle ist identifiziert und besteht entweder SPF oder DKIM, mit passender Ausrichtung.
2. Über mindestens zwei, besser vier Wochen ist keine neue eigene Quelle mehr aufgetaucht. Monatsläufe wie Rechnungen oder Newsletter brauchen einen vollen Zyklus, sonst übersieht man sie.
3. Weiterleitungen sind bedacht. Sie brechen SPF zwangsläufig, nur DKIM überlebt sie. Wer info@ auf mehrere Postfächer verteilt, muss DKIM überall funktionierend haben.

Dann geht es auf p=quarantine, und die Berichte laufen weiter. Wenn nach zwei weiteren Wochen nichts Eigenes im Spam landet, folgt p=reject.

Der Zwischenschritt ist nicht Bürokratie. Bei quarantine landet eine fälschlich abgelehnte Mail im Spam-Ordner und ist auffindbar. Bei reject ist sie weg.

MTA-STS und TLS-RPT: Was sichert den Transportweg?

SPF, DKIM und DMARC klären eine einzige Frage: Ist der Absender echt? Über den Weg, den die Mail nimmt, sagen sie nichts. Sie kann verschlüsselt gelaufen sein oder im Klartext, und ihr würdet den Unterschied nie erfahren.

Für diese zweite Frage gibt es zwei weitere DNS-Einträge. Sie sind Kür, nicht Pflicht, und sie sind erst sinnvoll, wenn die ersten drei stehen. Aber sie schließen eine Lücke, die viele gar nicht kennen.

Warum reicht STARTTLS allein nicht?

Zwischen zwei Mailservern läuft die Verschlüsselung heute über STARTTLS. Der empfangende Server sagt beim Verbindungsaufbau sinngemäß „ich kann verschlüsseln“, der sendende nimmt das Angebot an, und ab da ist die Verbindung dicht.

Das Verfahren hat einen Konstruktionsfehler: Es ist freiwillig, und das Angebot steht unverschlüsselt im Klartext. Wer sich zwischen die beiden Server setzt, streicht die Zeile mit dem Angebot einfach heraus. Der Sender sieht dann einen Empfänger, der angeblich kein TLS kann, und schickt die Mail im Klartext. Niemand bekommt eine Fehlermeldung, denn aus Sicht beider Seiten lief alles normal.

Diese Masche heißt STARTTLS-Stripping. Sie ist der Grund, warum es MTA-STS gibt: Der Sender soll vorher wissen, dass ihr TLS könnt, und zwar aus einer Quelle, die sich unterwegs nicht manipulieren lässt.

Wie ist MTA-STS aufgebaut?

MTA-STS besteht aus zwei Teilen, die zusammenpassen müssen. Fehlt einer, wirkt gar nichts.

Erstens ein TXT-Eintrag unter _mta-sts.firma.de:

v=STSv1; id=202608141200

Die id ist eine frei gewählte Kennung, üblich ist ein Zeitstempel. Sie ist das Signal für alle Sender: Ändert sie sich, holen sie die Regeln neu. Wer die Regeln bearbeitet und die id stehen lässt, ändert für Wochen nichts, weil alle mit der zwischengespeicherten Fassung weiterarbeiten.

Zweitens eine Datei, erreichbar unter genau dieser Adresse:

https://mta-sts.firma.de/.well-known/mta-sts.txt

Mit diesem Inhalt:

version: STSv1
mode: testing
mx: mx01.provider.de
mx: mx02.provider.de
max_age: 86400

Die mx-Zeilen müssen alle Server aufführen, die für euch Mail annehmen, also genau das, was auch in euren MX-Einträgen steht. Ein Sternchen ist erlaubt (mx: *.provider.de), aber nur für eine Ebene.

In welcher Reihenfolge stellt ihr MTA-STS scharf?

mode kennt drei Werte, und die Reihenfolge ist keine Empfehlung, sondern Selbstschutz:

Startet mit testing und einem kurzen max_age. Steht ein MX nicht in der Liste oder stimmt ein Zertifikat nicht, seht ihr das in den Berichten, statt es an ausbleibender Mail zu merken. Erst wenn über einige Wochen nichts auffällt, geht es auf enforce, und dann darf max_age auch länger werden.

Das ist dieselbe Logik wie bei DMARC, wo man von p=none über p=quarantine nach p=reject geht. Wer sie abkürzt, verliert Mail.

Wozu braucht ihr TLS-RPT?

MTA-STS allein macht euch blind streng. TLS-RPT ist die Gegenrichtung: ein einzelner TXT-Eintrag unter _smtp._tls.firma.de:

v=TLSRPTv1; rua=mailto:tls@firma.de

Damit schicken euch Google, Microsoft und die anderen großen Versender täglich eine maschinenlesbare Zusammenfassung: Wie viele Verbindungen kamen zustande, wie viele scheiterten, und woran. Das ist die einzige Möglichkeit zu erfahren, dass jemand euch keine Mail mehr zustellen kann.

Ohne TLS-RPT ist mode: enforce ein Blindflug. Deshalb gehören die beiden zusammen, auch wenn sie technisch unabhängig sind.

Wie prüft ihr eure eigene Einrichtung?

Drei Handgriffe, alle ohne zusätzliches Werkzeug.

Der TXT-Eintrag:

nslookup -type=TXT _mta-sts.firma.de

Kommt hier nichts zurück, ist alles Weitere egal. Sender fragen zuerst an dieser Stelle nach und gehen ohne Antwort ihren gewohnten Weg, ganz gleich, was auf eurem Webserver liegt.

Die Regeldatei:

curl -v https://mta-sts.firma.de/.well-known/mta-sts.txt

Wichtig ist nicht nur der Inhalt, sondern die Zeile zum Zertifikat. Wenn curl an dieser Stelle meckert, tun es die Mailserver auch, nur ohne dass es jemand mitbekommt.

Die MX-Liste gegenprüfen:

nslookup -type=MX firma.de

Jeder Server aus dieser Antwort muss in der Regeldatei stehen. Genau hier fällt bei enforce die Post aus, und genau hier ändert sich etwas, sobald jemand einen Spamfilter vorschaltet oder den Anbieter wechselt.

Bei einem Anbieterwechsel gehören deshalb beide Stellen auf die Umzugsliste, die MX-Einträge und die Regeldatei. Wer nur die MX ändert, sperrt seine eigene Post aus.

Was geht bei MTA-STS in der Praxis schief?

Vier Fehler sehen wir immer wieder:

1. Das Zertifikat der Subdomain. Die Datei muss über HTTPS mit einem gültigen Zertifikat für mta-sts.firma.de ausgeliefert werden. Ein abgelaufenes oder auf die Hauptdomain ausgestelltes Zertifikat macht die ganze Konstruktion wirkungslos, und zwar still.
2. Die id bleibt stehen. Regeln geändert, Kennung vergessen: Für alle Sender hat sich nichts geändert.
3. Die MX-Liste ist unvollständig. Backup-Server und Spamfilter-Vorschaltungen werden gern übersehen. Bei enforce fällt genau deren Post aus.
4. max_age steht zu hoch, während noch getestet wird. Der Wert sagt Sendern, wie lange sie die Regeln zwischenspeichern dürfen. Wer beim Ausprobieren ein Jahr einträgt, kann einen Fehler nicht mehr schnell zurücknehmen.

Die Spezifikationen sind kurz und frei lesbar: RFC 8461 beschreibt MTA-STS, RFC 8460 TLS-RPT.

Wie es bei euch aussieht

Der kostenlose DMARC-Check liest eure öffentlichen DNS-Einträge und zeigt in zehn Sekunden, wo ihr steht: SPF samt Lookup-Zählung, DMARC-Richtlinie, DKIM-Selektoren, dazu MTA-STS und TLS-RPT. Ohne Anmeldung, ohne E-Mail-Adresse.

Wie eine Fälschung praktisch abläuft und was sie bei euren Kunden anrichtet, steht in E-Mail-Spoofing: wie Fremde in eurem Namen schreiben.

Wenn dabei etwas herauskommt, das jemand geradeziehen soll: Wir machen das seit über 25 Jahren und stellen schrittweise scharf, ohne dass unterwegs Mail verloren geht. Bei laufender Wartung schauen wir die Berichte turnusmäßig mit an, weil sich sonst niemand daran erinnert, sobald der erste Monat vorbei ist.

Erstgespräch vereinbaren: 30 Minuten, kostenlos, mit einer ehrlichen Einschätzung, auch wenn sie lautet, dass bei euch eine Stunde Handarbeit reicht.