SPF, DKIM, DMARC, MTA-STS, BIMI klingen wie Krypto-Käse — sind aber im Kern überraschend einfach. Wir erklären's mit Analogien, Diagrammen und ein paar AHA-Momenten, die andere Tools verschweigen.
Bevor du Mail-Security verstehst, musst du verstehen was schief gehen kann. Und dafür: was passiert eigentlich, wenn du auf „Senden" klickst?
📬
Stell dir das Postsystem vor. Du wirfst einen Brief in den Briefkasten (deinen Mailserver). Die Post sortiert ihn (basierend auf der Adresse), bringt ihn zum Empfänger-Postamt, und der Postbote legt ihn in den Briefkasten der Empfängerin. Niemand prüft den Absender. „Von: Bundeskanzler" steht da? Glauben wir mal.
Die fünf Stationen
Der Knackpunkt ist Station 4: der Empfänger-Server bekommt eine Mail aus dem Internet und muss sich entscheiden — annehmen, ablehnen, in den Spam? Eine 1995-Mail würde der Server einfach annehmen, weil der Absender eben „chef@firma.ch" behauptet hat.
SPF, DKIM und DMARC sind drei Werkzeuge, die der Empfängerin helfen diese Entscheidung zu treffen — anhand prüfbarer Regeln, nicht bloßer Behauptungen des Absenders.
💡
AHA-Moment: Mail wurde 1982 (RFC 822) entworfen, in einer Zeit als das Internet ~200 vertrauenswürdige Universitäten umfasste. Niemand hat damals an Spoofing gedacht. Alle Sicherheits-Standards heute sind nachträglich draufgepappt. Das erklärt warum's so chaotisch wirkt.
1 · SPF · seit 2006
SPF — die Gästeliste in DNS
SPF beantwortet eine Frage: „Welche IP-Adressen dürfen für meine Domain Mails verschicken?" Du veröffentlichst die Antwort als TXT-Record in DNS, der Empfänger schaut nach, und vergleicht.
🚪
Stell dir einen Türsteher vor. Du gibst ihm vorab eine Gästeliste mit IP-Adressen („Google darf, Mailchimp darf, mein eigener Server darf"). Kommt ein Briefträger an die Tür und behauptet von dir zu sein, ruft der Türsteher in der DNS-Zentrale an: „Steht 185.20.99.1 auf der Liste?". Wenn ja → Pass. Wenn nein → Fail.
Wie der Record aussieht
firma.ch. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ip4:185.20.99.1 ~all"
v=spf1 → „Das ist ein SPF-Record"
include:_spf.google.com → „Alle Google-IPs sind erlaubt" (Google pflegt die Liste)
include:sendgrid.net → „Auch SendGrid darf"
ip4:185.20.99.1 → „Und unser eigener Server"
~all → „Alle anderen sind verdächtig" (-all wäre „komplett ablehnen")
Drei Probleme die SPF allein nicht löst
1. Es gibt ein 10-Lookup-Limit.
Jedes include: zählt als 1 DNS-Lookup, plus geschachtelte include:s in den ge-included Records. Übersteigt die Summe 10 → SPF schlägt komplett fehl. Häufiger Stolperstein bei Setups mit vielen Marketing-Tools.
2. Wird beim Forwarding kaputt gemacht.
Du leitest deine Mail an deine Privat-Adresse weiter? Die ursprünglichen Sender-IPs sind weg, der weiterleitende Server steht jetzt im Envelope. SPF Fail. (DKIM löst das.)
3. Es prüft nur den „Envelope"-Absender, nicht das was der Empfänger sieht.
Im Mail-Header gibt's zwei Absender: den Envelope-From (Postausen-Adresse, technisch) und den Header-From (was die Empfängerin im Mail-Client liest). SPF prüft nur den Envelope. Genau hier bohrt DMARC nach — siehe Kapitel 4.
💡
AHA-Moment: SPF wurde nie als „Anti-Phishing" gebaut. Es war eine Anti-Spam-Maßnahme, damit Empfänger Botnetz-Mails ablehnen können. Erst durch DMARC bekam SPF eine Anti-Phishing-Rolle — als Baustein. Allein liefert SPF keinen Schutz vor sichtbarem Domain-Spoofing.
2 · DKIM · seit 2007
DKIM — das Krypto-Siegel
DKIM beantwortet: „Ist diese Mail wirklich unverändert vom angeblichen Sender?" Sender signiert ein paar Header und den Body kryptografisch, Empfänger holt den Public Key aus DNS und verifiziert die Signatur.
🔏
Stell dir mittelalterliche Wachs-Siegel vor. Der Absender drückt seinen einzigartigen Stempel in heißes Wachs auf den Briefumschlag. Die Empfängerin kennt die Stempel-Form (weil im Wappenbuch — bei DKIM: in DNS). Stimmt der Wachsabdruck? Brief ist authentisch und nicht angefasst worden. Stimmt er nicht? Jemand hat unterwegs manipuliert.
Wie's konkret funktioniert
Was ein Selektor ist
Du kannst pro Domain mehrere DKIM-Keys haben — z.B. einen für deinen Mailserver, einen für Mailchimp, einen für SendGrid. Jeder Key bekommt einen eindeutigen Namen — den Selektor. Im Mail-Header steht z.B. s=k1, der Empfänger holt dann den Public Key aus k1._domainkey.firma.ch.
💡
AHA-Moment 1: Es gibt keinen offiziellen Selektor-Namen-Standard. Jeder Anbieter wählt selbst — Google nutzt datumsbasierte Selektoren wie 20240601, Microsoft nutzt selector1 und selector2, Mailcow nutzt dkim oder mta1. Genau deshalb müssen Tools wie unser Aggregator ~100 gängige Namen durchprobieren wenn sie raten wollen welche aktiv sind.
💡
AHA-Moment 2: DKIM überlebt Forwarding (im Gegensatz zu SPF). Solange niemand den signierten Header-Bereich oder Body verändert, bleibt die Signatur gültig — auch durch 5 Hops und Mailing-Listen hindurch. Genau dieser Punkt ist gleich wichtig für DMARC.
3 · DMARC · seit 2012
DMARC — der Polizist über SPF und DKIM
DMARC beantwortet: „Wenn weder SPF noch DKIM sauber durchgehen — was soll der Empfänger tun?" Plus: „Schicke mir bitte Berichte darüber, wer alles versucht hat unter meinem Namen zu senden."
👮
SPF und DKIM sind Prüfungen, DMARC ist die Anweisung. Stell dir vor SPF und DKIM sind zwei Detektoren am Flughafen — Metalldetektor und Gepäck-Scan. DMARC ist der Polizist, der sagt: „Wenn beides nichts zeigt → durchlassen. Wenn beides anschlägt → ablehnen. Wenn nur einer anschlägt → Quarantäne. Und schick mir täglich einen Bericht über alle die durch sind."
Wie der Record aussieht
_dmarc.firma.ch. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@firma.ch; pct=100"
v=DMARC1 → „Ich bin ein DMARC-Record"
p=quarantine → „Bei Fail bitte in den Spam"
rua=mailto:dmarc@firma.ch → „Schick mir tägliche Berichte hierhin"
pct=100 → „Auf 100 % der verdächtigen Mails anwenden"
Die drei Policy-Stufen
p=none
Beobachten
Nichts ändert sich am Mail-Verhalten. Aber: du bekommst Berichte. Immer der Start.
p=quarantine
In den Spam
Verdächtige Mails landen im Junk-Ordner. Empfänger sieht sie noch, kann sie zurückholen.
p=reject
Komplett ablehnen
Empfänger-Server lehnt schon beim SMTP-Handshake ab. Mail wird nie zugestellt.
💡
AHA-Moment: DMARC selbst authentifiziert nichts. Es ist nur die Regel, was passiert, wenn die anderen beiden (SPF + DKIM) durchfallen. Wer DMARC ohne SPF/DKIM setzt, hat einen Polizisten ohne Detektoren — der Polizist sagt nur „nichts gefunden, durchwinken" zu allem.
🤝 Lieber begleiten lassen? → DMARC-Service · 6-12 Wochen von p=none bis p=reject, Festpreise ab CHF 690.
4 · Alignment · der versteckte Knackpunkt
Alignment — warum 80 % aller Setups trotz allem failen
Das ist der Punkt, den die meisten Tutorials komplett übergehen. SPF und DKIM können „Pass" sein — und DMARC kann trotzdem failen. Wegen Alignment.
🪪
Stell dir vor du fliegst. Am Check-In zeigst du einen Pass auf den Namen „Hans Müller" — der Pass ist echt (DKIM Pass!). Aber dein Boarding-Pass ist auf den Namen „Maria Schmidt". Pass ist gültig — passt aber nicht zu dem Namen für den du fliegst. Würde dich da jemand durchlassen? Das ist Alignment.
Wo's passiert
In jeder Mail gibt's zwei Absender-Felder:
Header-From (was die Empfängerin sieht): news@firma.ch
SPF prüft nur den Envelope-From. Mailchimp ist berechtigt für mailchimp-server.com zu senden → SPF Pass! Aber die Domain im Envelope (mailchimp-server.com) passt nicht zur Domain im Header-From (firma.ch) → SPF-Alignment Fail. DMARC zählt's als Misserfolg.
⚠️ DMARC FAILKeine der authentifizierten Domains stimmt mit der sichtbaren Absender-Domain firma.ch überein.
SPF und DKIM sind technisch beide gültig — aber für eine andere Domain als der Empfänger sieht. Genau das ist der Alignment-Fail.
Wie du's löst
DKIM aligned signieren lassen. Mailchimp & Co. erlauben dir einen Custom-DKIM mit deiner Domain (k1._domainkey.firma.ch per CNAME). Dann ist d=firma.ch in der Signatur und Alignment passt.
Custom-Return-Path. Marketing-Tools können auch eine Sub-Domain wie bounces.firma.ch als Return-Path nutzen — wenn deine SPF-Records sie freigeben, ist auch SPF-Alignment OK.
AHA-Moment: Wenn dein DMARC-Setup „funktioniert" aber Mailchimp-Mails plötzlich im Spam landen — Alignment ist mit 90% Wahrscheinlichkeit der Grund. Lösung: Custom-Domain-Authentifizierung im Marketing-Tool aktivieren. Dauert 5 Min, fixt 80 % aller DMARC-Pannen.
MTA-STS — Verschlüsselungs-Pflicht für Inbound-Mails
Problem: Wenn ein Server dir eine Mail schickt, ist TLS optional. Wenn der Empfänger sagt „kein TLS, lass uns Klartext sprechen", funktioniert das. MTA-STS sagt: „Nein, wenn du an meine Domain schickst, MUSS TLS gehen — oder lass es bleiben."
📦
Stell dir vor du bestellst Pakete. Standard ist heute: der Lieferant kommt mit dem normalen Lkw, kein Schloss am Container. Du sagst aber: „Wenn ihr an meine Adresse liefert, dann nur in Sicherheits-LKWs mit Plombe — kein Plomben → kein Liefern." Das ist MTA-STS.
Wie's konkret aussieht
Du veröffentlichst zwei DNS-Einträge plus eine Policy-Datei auf einer HTTPS-URL:
_mta-sts.firma.ch. IN TXT "v=STSv1; id=20250101120000Z"
mta-sts.firma.ch. IN A 1.2.3.4
# https://mta-sts.firma.ch/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mail.firma.ch
max_age: 604800
Andere Mailserver, die an @firma.ch senden wollen:
Schauen den DNS-Eintrag _mta-sts.firma.ch nach.
Holen die Policy-Datei von https://mta-sts.firma.ch/.well-known/mta-sts.txt.
Cachen die Policy für max_age Sekunden.
Erzwingen TLS bei jeder Verbindung. Wenn TLS fehlschlägt → Mail wird nicht zugestellt.
Und TLS-RPT?
Der ergänzende DNS-Record _smtp._tls.firma.ch sagt: „Wenn ein Sender wegen TLS-Fehler nicht zustellen konnte, schick mir bitte einen JSON-Bericht hierhin (tlsrpt@firma.ch)." Das ist quasi RUA für TLS-Probleme.
💡
AHA-Moment 1: MTA-STS & TLS-RPT brauchst du nur als Empfänger, nicht als Sender. Wenn deine Domain Mails empfängt, schaltest du es ein. Wenn deine Domain nur sendet (z.B. Marketing-Subdomain), ist's irrelevant.
💡
AHA-Moment 2: Es ist optional — kein Compliance-Framework außer ISO 27001 / FINMA empfiehlt es zwingend. Aber: wenn du Compliance-relevant bist, ist es ein billiger Punkt. ~30 Min Setup für ein Audit-Häkchen.
6 · BIMI · seit 2020
BIMI — dein Logo neben Mails in Gmail, Yahoo & Apple
Hast du dich schon mal gefragt, warum manche Newsletter im Gmail-Posteingang ein rundes Logo neben dem Absender haben — und andere nicht? Das ist BIMI. Und es funktioniert nur, wenn deine DMARC-Hausaufgaben gemacht sind.
🏛️
BIMI ist das Briefkopf-Wappen für E-Mails. Aber nur Firmen die nachweislich seriös sind dürfen es nutzen. Der Nachweis: DMARC mind. p=quarantine, plus optional ein Verified Mark Certificate (VMC) von DigiCert oder Entrust — eine Art „Markenzeichen-Pass" für deine Domain.
Wie's funktioniert
Voraussetzung: DMARC läuft mit p=quarantine oder p=reject.
Du legst ein SVG-Logo bereit (BIMI-konformes „SVG Tiny PS"-Profil — kein normales SVG).
Optional: VMC-Zertifikat kaufen (~ CHF 1'500 / Jahr) — Pflicht für Apple Mail, optional für Gmail.
DNS-Record default._bimi.firma.ch zeigt auf Logo + Zertifikat.
Empfänger-Mailclient (Gmail, Yahoo, Apple) zeigt dein Logo neben der Mail.
default._bimi.firma.ch. IN TXT "v=BIMI1; l=https://firma.ch/logo.svg; a=https://firma.ch/cert.pem"
💡
AHA-Moment: BIMI ist nicht primär Sicherheit, sondern Marketing-Belohnung für Sicherheit. Mail-Clients sagen: „Du hast DMARC sauber? Hier, dein Logo darf rauf — gibt mehr Open-Rates." Studien zeigen 10-20% höhere Open-Rates bei BIMI-aktivierten Mails. BIMI ist die Karotte, mit der Google & Co. uns alle zu DMARC bringen.
7 · ARC · seit 2019
ARC — wie Mailing-Listen DMARC nicht mehr killen
Problem: Du schreibst eine Mail an eine Mailing-Liste. Die Liste leitet weiter — aber ändert dabei das Subject („[mailingliste] Hi alle"). DKIM-Signatur ist jetzt ungültig. DMARC failt. ARC ist die Lösung dafür.
🔗
Stell dir eine Notar-Kette vor. Deine Mail geht erst an die Mailing-Liste. Die Liste sagt: „Ich bestätige notariell — als die Mail bei mir ankam, war SPF, DKIM und Alignment alles OK." Sie hängt diese notarielle Bestätigung als ARC-Header an, signiert mit ihrem eigenen Schlüssel. Wenn die Mail dann beim Endempfänger ankommt, prüft der die ARC-Kette: „Vertraue ich der Liste als Notar? Ja → DMARC-Result von der Liste übernehmen, nicht selbst neu prüfen."
Wer's nutzt
Google Groups & Mailman setzen ARC-Header.
Outlook.com, Gmail, iCloud verifizieren ARC.
Microsoft 365 Connectors nutzen ARC um DMARC nicht zu zerstören.
Du selbst musst nichts tun wenn du nur Endsender oder Endempfänger bist. ARC ist ein Mailserver-zu-Mailserver-Standard.
💡
AHA-Moment: Wenn jemand dir sagt „DMARC funktioniert nicht mit Mailing-Listen" — die Aussage ist von 2017. Seit ARC und seit Microsoft/Google ARC verifizieren, ist das Problem zu 90 % gelöst. Mailing-Listen sind kein Grund mehr, DMARC nicht scharf zu schalten.
Verstanden — was machst du jetzt damit?
Drei naheliegende nächste Schritte. Such dir aus was passt.
DMARC