SPF, DKIM und DMARC

E-Mail wurde ursprünglich ohne Absenderprüfung entworfen: Jeder kann in eine Mail jeden beliebigen Absender schreiben. SPF, DKIM und DMARC schließen diese Lücke. Sie helfen empfangenden Servern zu erkennen, ob eine Mail wirklich von der angegebenen Domain stammt – und schützen damit vor gefälschten Absendern und vor dem Spam-Ordner.

SPF: Wer darf senden?

Das Sender Policy Framework ist ein TXT-Eintrag im DNS der Domain. Er listet die Server auf, die im Namen der Domain senden dürfen. Ein vereinfachtes Beispiel:

v=spf1 include:_spf.example-mail.de -all

Der empfangende Server prüft, ob die einliefernde IP-Adresse dazugehört. -all bedeutet: alle anderen Server sind nicht berechtigt, ~all kennzeichnet sie nur als verdächtig. Wichtig: SPF prüft die technische Absenderadresse (Envelope-From), nicht unbedingt die Adresse, die im Mailprogramm angezeigt wird. Außerdem darf die Auswertung höchstens zehn DNS-Abfragen auslösen; zu viele include-Einträge machen SPF ungültig.

DKIM: Ist die Mail unverändert?

DomainKeys Identified Mail versieht jede ausgehende Nachricht mit einer kryptografischen Signatur. Den öffentlichen Schlüssel veröffentlicht die Domain im DNS unter einem sogenannten Selektor. Der Empfänger prüft damit, ob die signierten Teile der Mail unterwegs verändert wurden und ob die Signatur zur Domain passt. DKIM übersteht im Gegensatz zu SPF in vielen Fällen auch Weiterleitungen.

DMARC: Was passiert bei einem Fehlschlag?

DMARC baut auf beiden auf. Es verlangt, dass SPF oder DKIM nicht nur bestehen, sondern auch zur sichtbaren Absenderdomain passen (Alignment). Und es legt fest, was Empfänger bei einem Fehlschlag tun sollen:

• p=none – nur beobachten und berichten,
• p=quarantine – als verdächtig behandeln, etwa in den Spam-Ordner,
• p=reject – ablehnen.

Über die Angabe rua erhält die Domain Sammelberichte, welche Server in ihrem Namen senden. Bewährt ist der Weg von none über quarantine zu reject, sobald die Berichte zeigen, dass alle legitimen Versender erfasst sind.

Bedeutung für Ticketsysteme

Verschickt ein Ticketsystem Antworten unter support@ihre-domain.de, muss der versendende Server zur Domain passen. Zwei Wege sind üblich: Das Ticketsystem versendet über den eigenen Postausgangsserver der Domain per SMTP – dann gelten die vorhandenen Einträge. Oder es versendet über eigene Server – dann müssen diese in SPF und DKIM der Domain aufgenommen werden.

Ein Beispiel

Die Beispiel Werke GmbH stellt fest, dass Antworten aus ihrem Support bei mehreren Kunden im Spam landen. Die DMARC-Berichte zeigen: Ein Newsletter-Dienst und ein altes Warenwirtschaftssystem senden unter der Domain, sind aber nicht im SPF-Eintrag. Nach der Korrektur und der Einrichtung von DKIM bestehen die Prüfungen wieder.

Prüfen, ob alles stimmt

Ob eine Mail die Prüfungen besteht, steht in ihrem Quelltext, meist in der Kopfzeile Authentication-Results. Dort zeigt der empfangende Server, ob SPF, DKIM und DMARC bestanden wurden.

Diese Kopfzeile ist die beste erste Anlaufstelle bei Zustellproblemen – etwa wenn Antworten oder automatische Eingangsbestätigungen (Autoresponder) im Spam landen.

So hilft rapidFOX

Ist dein Postfach angebunden, versendet rapidFOX Antworten darüber – per SMTP oder über Microsoft 365. Damit gelten die SPF-, DKIM- und DMARC-Einträge, die deine Domain für dieses Postfach ohnehin hat. Mehr unter E-Mail-Ticketsystem und Sicherheit.