Python: Web & Frameworks

SQLAlchemy: Datenbankzugriff in Python

Der Mailversand mit eigener Domain ist technisch anspruchsvoll: Ohne korrekte Einträge im Namenssystem landet jede Nachricht im Spamordner oder wird abgelehnt. Drei Mechanismen sind dafür entscheidend: SPF, DKIM und DMARC. Dieser Artikel erklärt, was jeder tut, wie sie zusammenspielen und wie man sie einrichtet.

Das Grundproblem

Das SMTP-Protokoll aus den 1980er Jahren kennt keine Absenderprüfung. Jeder kann in einer Nachricht behaupten, von einer beliebigen Adresse zu kommen. Spamfilter müssen deshalb raten, und legitime Absender leiden unter dieser Unklarheit.

Die drei Mechanismen bauen eine überprüfbare Verbindung zwischen Nachricht und Domain auf – mit unterschiedlicher Aussagekraft:

SPF    prueft, ob der SERVER berechtigt war, fuer die Domain zu senden
DKIM   prueft, ob die NACHRICHT unveraendert ist und von der Domain stammt
DMARC  prueft, was mit Nachrichten zu tun ist, die SPF/DKIM nicht bestehen,
       und wohin Berichte zu schicken sind

# Wichtig: SPF prueft den Umschlag-Absender (Return-Path / MAIL FROM),
# DKIM signiert die Kopfzeilen und den Inhalt,
# DMARC verbindet beides mit dem sichtbaren Absender (From).

SPF: Berechtigte Server

SPF ist ein TXT-Datensatz, der alle Server auflistet, die für die Domain senden dürfen. Empfangende Systeme fragen ihn ab und vergleichen mit der IP-Adresse des Absenders.

# Beispiel: eigener Server plus ein Anbieter
example.org.  TXT  "v=spf1 mx a:mail.example.org include:_spf.anbieter.de -all"

# Die wichtigsten Mechanismen
v=spf1                        Version (immer am Anfang)
mx                            Server aus den MX-Datensaetzen der Domain
a                             Server aus dem A-Datensatz
ip4:203.0.113.10              genau diese Adresse
ip4:203.0.113.0/24            dieser Bereich
include:_spf.andere.de        Mechanismen einer anderen Domain uebernehmen
include:spf.protection.outlook.com
exists:%{i}._spf.example.org  dynamische Pruefung
-all                          QUALIFIER: alles andere ablehnen (empfohlen)
~all                          Softfail: annehmen, aber markieren
?all                          neutral: keine Aussage
+all                          NIEMALS verwenden! Erlaubt allen alles.

# Prufen
dig +short example.org TXT
dig +short example.org TXT | grep spf
# Online-Werkzeuge: SPF-Record-Lookup, MXToolbox

Die drei Fehler, die am häufigsten vorkommen:

  1. Mehrere SPF-Datensätze. Es darf nur einen TXT-Datensatz mit v=spf1 geben. Existieren zwei, werten viele Systeme den Datensatz als fehlerhaft – die Prüfung schlägt immer fehl. Die Lösung ist, beide zusammenzuführen.
  2. Zu viele Namensabfragen. SPF erlaubt maximal 10 Abfragen von include, a, mx und ptr. Jedes include mit eigenem include zählt mit. Ab der Grenze wird der Datensatz als fehlerhaft behandelt (permerror) – die Prüfung schlägt fehl, obwohl die Server korrekt sind.
  3. +all oder fehlender Qualifier. +all erlaubt jedem Server das Senden im Namen der Domain. Der Standardqualifier ist neutral, was ebenfalls keine Aussage ist. Am Ende gehört -all.
# Abfragezahl pruefen (darf maximal 10 sein)
# Werkzeuge dafuer: MXToolbox SPF-Check, dmarcian, spf-record-lookup.com
# Selbst nachzaehlen ist schwierig, weil includes rekursiv sind.

# Wenn die Grenze erreicht ist: Includes zusammenfassen
# Viele Anbieter bieten einen SPF-Flattening-Dienst an.
# Besser: Weniger Anbieter verwenden und die Liste straffen.

DKIM: Signaturen für Nachrichten

Bei DKIM signiert der sendende Server jeden Teil der Kopfzeilen und des Inhalts mit einem privaten Schlüssel. Im Kopfzeilenfeld DKIM-Signature werden die Signatur und ein Verweis auf den öffentlichen Schlüssel mitgeschickt. Der Empfänger holt den öffentlichen Schlüssel aus dem Namenssystem und prüft.

# Kopfzeile einer signierten Nachricht (gekuerzt)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=example.org; s=mail; t=1758912000;
  h=from:to:subject:date:message-id;
  bh=...hash des Inhalts...;
  b=...die Signatur selbst...

# Veroeffentlichung: der oeffentliche Schluessel als TXT-Datensatz
# Name:  ._domainkey.example.org
mail._domainkey.example.org.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

# Abfragen
dig +short mail._domainkey.example.org TXT

Warum DKIM stärker ist als SPF: Es schützt den Inhalt. Wird eine Nachricht unterwegs verändert, schlägt die Prüfung fehl. Zusätzlich übersteht eine signierte Nachricht die Weiterleitung über einen Zwischenschritt in der Regel besser, weil der Inhalt unverändert bleibt – SPF versagt dort, wenn die Weiterleitung über einen anderen Server läuft.

Zwei praktische Hinweise: Die Signatur überlebt nur, wenn die signierten Kopfzeilen unverändert bleiben – manche Weiterleitungen fügen Text hinzu und brechen damit die Signatur. Und: Der private Schlüssel wird ein- bis zweimal jährlich gewechselt. Für die Rotation veröffentlicht man einen zweiten Selektor, stellt den Versand um und entfernt den alten nach einer Übergangszeit.

DMARC: die Richtlinie

DMARC sagt, was zu geschehen hat, wenn SPF und DKIM fehlschlagen – und verbindet beides mit der Domäne im sichtbaren From-Feld.

# Zuerst einem Domaenen-TXT-Datensatz...
_dmarc.example.org.  TXT  "v=DMARC1; p=none; rua=mailto:Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein.; ruf=mailto:Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein.; fo=1; adkim=r; aspf=r; pct=100"

# Bestandteile
v=DMARC1                     Version
p=none                       Richtlinie: nichts tun, nur berichten (Einstieg!)
p=quarantine                 In den Spamordner verschieben
p=reject                     Ablehnen (das Ziel)
sp=reject                    Richtlinie fuer Unterdomains (sonst gilt p)
pct=100                      Anteil, auf den die Richtlinie angewendet wird
rua=mailto:...               Sammelberichte (taeglich)
ruf=mailto:...               Fehlerberichte (sofort, wenig genutzt)
fo=1                         wann Fehlerberichte: 0=nur wenn alles scheitert,
                             1=bei jedem Fehlschlag, d=bei DKIM-Fehler
adkim=r / s                  Ausrichtung DKIM: relaxed / strict
aspf=r / s                   Ausrichtung SPF: relaxed / strict

# Abfragen
dig +short _dmarc.example.org TXT

Die Ausrichtung (Alignment) ist der entscheidende Begriff. DMARC prüft nicht nur, ob SPF oder DKIM besteht, sondern ob die geprüfte Domäne zur sichtbaren Absenderdomain passt. Im relaxed-Modus genügt die gemeinsame Hauptdomäne (mail.example.org passt zu example.org), im strict-Modus muss sie exakt übereinstimmen.

Der richtige Weg zur Einrichtung

Wer direkt mit p=reject beginnt, blockiert womöglich legitime Nachrichten. Die bewährte Reihenfolge:

  1. SPF aufsetzen mit ~all (Softfail). Alle sendenden Dienste eintragen, die das Unternehmen nutzt – auch Newsletter, Ticket- und CRM-Systeme.
  2. DKIM einrichten für jeden sendenden Dienst. Die meisten Anbieter liefern die Selektoren und Schlüssel.
  3. DMARC mit p=none plus rua veröffentlichen. Jetzt laufen Berichte ein – ohne Auswirkung auf die Zustellung.
  4. Berichte auswerten über mehrere Wochen. Man sieht genau, welche Server im Namen der Domain senden – auch die, die man vergessen hat.
  5. Fehlende Dienste ergänzen. Jeder legitime Absender gehört in SPF und DKIM.
  6. Auf p=quarantine wechseln, zunächst mit pct=25, dann schrittweise erhöhen.
  7. Auf p=reject wechseln. Erst jetzt ist die Domain gegen Nachahmung wirksam geschützt.
# Neben der Hauptrichtlinie: Unterdomains absichern
# Ohne sp=-Eintrag gilt p auch fuer Unterdomains.
# Fuer Domains, die nie Mails senden, ist das ein wichtiger Schutz:
_dmarc.example.org.  TXT  "v=DMARC1; p=reject; sp=reject"

# Wildcard fuer Unterdomains ohne eigene DMARC-Richtlinie
*._dmarc.example.org.  TXT  "v=DMARC1; p=reject"

# ACHTUNG: Fuer Domains, die wirklich nie senden, gehoert
# zusaetzlich ein SPF-Datensatz mit -all und ein Null-MX:
example.org.       TXT  "v=spf1 -all"
example.org.       MX   0 .
_dmarc.example.org. TXT  "v=DMARC1; p=reject"

Über DMARC hinaus

  • MTA-STS: Erzwingt verschlüsselte Übertragung zwischen Mailservern. Ein TXT-Datensatz plus eine Richtliniendatei unter https://mta-sts.example.org/.well-known/mta-sts.txt.
  • DANE/TLSA: Hinterlegt den erwarteten Zertifikatsfingerabdruck im Namenssystem – nur mit DNSSEC wirksam.
  • DNSSEC: Signiert die Namensdatensätze selbst. Ohne DNSSEC können SPF-, DKIM- und DMARC-Datensätze unterwegs gefälscht werden – damit wäre die ganze Kette umgehbar.
  • BIMI: Zeigt ein überprüftes Logo im Mailprogramm. Setzt DMARC mit p=reject oder p=quarantine voraus.
  • Reverse-DNS (PTR): Für den sendenden Server. Viele Empfänger verwerfen Nachrichten von Adressen ohne passenden PTR-Eintrag.

Prüfen und Fehlersuche

# 1. Alle relevanten Datensaetze abfragen
dig +short example.org TXT | grep spf
dig +short mail._domainkey.example.org TXT
dig +short _dmarc.example.org TXT

# 2. Senden und Kopfzeilen pruefen
python3 -c "
import smtplib
from email.message import EmailMessage
m = EmailMessage()
m['From'] = 'test@example.org'
m['To'] = 'pruefung@empfaenger.example'
m['Subject'] = 'DKIM-Test'
m.set_content('Test')
with smtplib.SMTP('localhost', 25) as s:
    s.send_message(m)
"
# Danach im empfangenden Postfach die vollstaendigen Kopfzeilen ansehen:
#   Authentication-Results: ... spf=pass ... dkim=pass ... dmarc=pass
#   DKIM-Signature: ...
#   Received-SPF: ...

# 3. Fehlerbilder
#   spf=permerror   -> mehrere SPF-Datensaetze oder >10 Abfragen
#   spf=softfail    -> ~all greift, Server fehlt in der Liste
#   dkim=neutral    -> Selektor falsch oder Schluessel zu klein
#   dmarc=fail      -> Absenderdomain passt nicht zu SPF/DKIM
#   "kein DKIM-Signaturfeld" -> Versand laeuft ueber einen anderen Weg
#      als angenommen (haeufigster Fall: eine Anwendung nutzt ihren
#      eigenen Mailserver statt des zentralen Versands)

Verwandte Grundlagen: DNS, dig und nslookup, PKI, HTTP/HTTPS verstehen.