SPF, DKIM und DMARC: Warum Ihre Mails ankommen oder im Spam landen

Was die drei Einträge bewirken, wie Sie sie prüfen und warum Mails aus dem ERP dieselben Regeln brauchen wie Ihr Postfach.

5 Min. Lesezeit ERP-Einführung und Betrieb

Der Vertrieb verschickt aus Odoo ein Angebot, und der Kunde meldet sich nicht. Zwei Tage später fragt er nach: Er hat nie etwas erhalten. Die Mail lag im Spam-Ordner oder wurde vom Server des Empfängers stillschweigend verworfen. Das kostet Rückfragen, verspätete Aufträge und Zeit, weil niemand weiß, wo die Mail geblieben ist. Meist liegt die Ursache nicht im Inhalt, sondern in drei DNS-Einträgen Ihrer Domain: SPF, DKIM und DMARC. (DNS ist das Namenssystem, in dem die Einstellungen Ihrer Domain liegen.)

Was der empfangende Server prüft

Ein Mailserver erhält eine Nachricht mit dem Absender `vertrieb@ihre-firma.de`. Er kann nicht erkennen, ob sie wirklich von Ihnen kommt, denn Absenderadressen lassen sich fälschen. Deshalb fragt er in Ihrer Domain nach drei Dingen:

  • SPF (Sender Policy Framework): Ein Eintrag listet auf, welche Server für Ihre Domain Mails senden dürfen. Der Empfänger vergleicht damit die Adresse des einliefernden Servers.
  • DKIM (DomainKeys Identified Mail): Ihr Mailserver signiert jede ausgehende Nachricht mit einem privaten Schlüssel. Der passende öffentliche Schlüssel steht in Ihrem DNS. Der Empfänger prüft damit, dass die Mail von Ihrem Server stammt und unterwegs nicht verändert wurde.
  • DMARC (Domain-based Message Authentication, Reporting and Conformance): Die Regel, was der Empfänger tun soll, wenn SPF oder DKIM nicht zur Absenderdomain passen: durchlassen, in den Spam stellen oder abweisen. Außerdem legt DMARC fest, wohin Berichte über diese Prüfungen gehen.

Fehlt eines davon oder passt es nicht zum tatsächlichen Versandweg, stuft der Empfänger Ihre Mail als verdächtig ein.

Prüffrage: Wissen Sie, welche Systeme in Ihrem Namen Mails versenden? Ohne diese Liste können Sie SPF nicht richtig pflegen.

Wo bei Ihnen überall Mails entstehen

Die Probleme entstehen selten beim Büropostfach, sondern bei den Systemen, die zusätzlich senden. Gehen Sie Ihre Situationen durch:

  • Odoo selbst: Angebote, Rechnungen und Chatter-Nachrichten gehen über den Ausgangsmailserver, der in Odoo hinterlegt ist. Wenn Odoo über SMTP (das Protokoll zum Mailversand) einen anderen Server nutzt als Ihr Büro, muss dieser Server im SPF stehen und DKIM-signieren.
  • Shop-Anbindung: Bestellbestätigungen kommen oft aus dem Shop (Shopify, Shopware, WooCommerce) und nicht aus Odoo. Der Shop sendet mit Ihrer Absenderdomain, ist aber ein weiterer Versender, den SPF und DKIM kennen müssen.
  • KI-Automatisierung: Wenn ein Agent Kundenanfragen beantwortet oder Entwürfe versendet, läuft der Versand über einen Mailserver. Klären Sie, welcher es ist und ob er signiert.
  • Versionsupgrade und Umzug: Nach einem Upgrade oder einem Serverumzug ändern sich oft IP-Adresse und Mailkonfiguration. Der SPF-Eintrag nennt dann noch den alten Server, und plötzlich schlagen Prüfungen fehl.
  • Solar-PV-Betrieb: Wenn Angebote, Projektmitteilungen und Rechnungen aus einem System kommen, gilt dasselbe wie oben. Jeder Versandweg braucht einen Eintrag.

Entscheidungsregel: Wenn ein System mit Ihrer Domain als Absender sendet und weder in SPF steht noch DKIM-signiert, dann behandelt der Empfänger seine Mails als nicht authentifiziert.

Die Einträge lesen

Alle drei sind TXT-Einträge im DNS. Sie können sie bei Ihrem DNS-Anbieter einsehen oder mit einem Abfragewerkzeug wie `nslookup` oder `dig` abrufen.

SPF steht auf der Domain selbst und beginnt mit `v=spf1`. Darauf folgen erlaubte Server und am Ende eine Regel:

`v=spf1 include:mailanbieter.example ip4:Server-IP ~all`

  • `include:` übernimmt die Server Ihres Mailanbieters.
  • `ip4:` erlaubt eine feste Adresse, etwa Ihren eigenen Server.
  • `~all` bedeutet „weich ablehnen", `-all` bedeutet „ablehnen".

Pro Domain darf es nur einen SPF-Eintrag geben. Zwei Einträge machen SPF ungültig. Außerdem sind nur begrenzt viele DNS-Abfragen pro Prüfung erlaubt; zu viele `include:` führen zu einem Fehler.

DKIM liegt unter einem Namen nach dem Muster `selektor._domainkey.ihre-firma.de`. Der Selektor legt Ihr Mailsystem fest. Der Eintrag enthält den öffentlichen Schlüssel (`p=...`). Jedes System, das signiert, hat meist seinen eigenen Selektor.

DMARC liegt unter `_dmarc.ihre-firma.de`:

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

  • `p=none` beobachtet nur, `p=quarantine` schickt in den Spam, `p=reject` weist ab.
  • `rua=` ist die Adresse für die Sammelberichte.

DMARC besteht, wenn SPF oder DKIM bestehen und die geprüfte Domain zur sichtbaren Absenderdomain passt (Alignment). Ein Server kann also SPF bestehen, und DMARC schlägt trotzdem fehl, weil er unter seiner eigenen Domain sendet statt unter Ihrer.

Vorgehen, ohne Mails zu verlieren

Die häufigste Panne: Jemand setzt DMARC sofort auf `reject`, und danach werden legitime Mails abgewiesen, weil ein vergessener Versandweg nicht signiert. Gehen Sie in dieser Reihenfolge vor:

  1. Inventar erstellen: alle Systeme, die mit Ihrer Domain senden (Büro-Mail, Odoo, Shop, Newsletter, Ticketsystem, Agenten).
  2. SPF um alle diese Versender ergänzen, als einen einzigen Eintrag.
  3. DKIM für jedes System einrichten und mit einer Testmail prüfen.
  4. DMARC mit `p=none` und einer Berichtsadresse veröffentlichen.
  5. Die Berichte einige Wochen auswerten. Sie zeigen, welche Server in Ihrem Namen senden und woran die Prüfung scheitert.
  6. Erst wenn alle legitimen Quellen bestehen, auf `quarantine` und später auf `reject` stellen.

Eine Testmail lesen

Senden Sie aus Odoo eine Mail an ein externes Postfach, etwa bei einem großen Anbieter. Öffnen Sie dort den Quelltext der Nachricht und suchen Sie den Header `Authentication-Results`. Dort stehen `spf=pass`, `dkim=pass` und `dmarc=pass` oder der jeweilige Fehler.

  • `spf=fail` oder `softfail`: Der sendende Server fehlt im SPF.
  • `dkim=none`: Das System signiert nicht, oder der Schlüssel fehlt im DNS.
  • `dkim=fail`: Der Schlüssel im DNS passt nicht zur Signatur, oder die Nachricht wurde unterwegs verändert.
  • `dmarc=fail` bei bestandenem SPF: Die Domains passen nicht zusammen. Prüfen Sie, welche Absenderdomain das System verwendet.

Wiederholen Sie den Test für jeden Versandweg, nicht nur für das Büropostfach.

Nach Änderungen erneut prüfen

SPF, DKIM und DMARC veralten still. Prüfen Sie nach diesen Anlässen erneut:

  • Odoo zieht auf einen anderen Server um oder wird auf eine neue Version gebracht.
  • Ein Shop oder ein neues Werkzeug beginnt, in Ihrem Namen zu senden.
  • Ein Mailanbieter wechselt oder ändert seine Schlüssel.

Wenn sich der Versandweg ändert, dann gehört der DNS-Eintrag zur Änderungsliste, so wie Zugänge und Backups.

Ihr nächster Schritt

Schicken Sie heute aus Odoo eine Testmail an ein externes Postfach und lesen Sie dort den Header `Authentication-Results`. Notieren Sie für SPF, DKIM und DMARC jeweils pass oder fail. Fragen Sie danach Ihren DNS-Anbieter oder sehen Sie in der Zone nach: Gibt es genau einen SPF-Eintrag, und existiert ein DMARC-Eintrag? Sind beide Antworten ja, listen Sie als Nächstes alle Systeme auf, die in Ihrem Namen senden.

Alle Wissensartikel