DMARC schliesst die Lücke, die SPF und DKIM einzeln offenlassen: Es verlangt, dass mindestens eines der beiden Verfahren nicht nur bestanden wird, sondern auch zur Domain passt, die der Empfänger im «From»-Feld tatsächlich sieht. Zusätzlich legt ein DMARC-Eintrag fest, was mit Mails passiert, die diese Prüfung nicht bestehen, und schickt Ihnen dafür regelmässig Berichte zu.
Was Alignment bedeutet, und warum es fehlt
SPF prüft den versendenden Server, DKIM die Signatur – beide beziehen sich dabei auf eine technische Absenderdomain, die im Header steckt, aber für den Empfänger unsichtbar bleibt. Die Adresse, die tatsächlich im Postfach als Absender erscheint (das sichtbare «From»-Feld), kann davon abweichen, ohne dass SPF oder DKIM das bemerken. Genau diese Lücke nutzen gefälschte Mails: Technisch sauber authentifiziert, aber mit einer völlig anderen sichtbaren Absenderadresse.
DMARC verlangt «Alignment»: Mindestens eine der beiden Prüfungen muss sich auf dieselbe Domain beziehen, die der Empfänger sieht. Erst dann gilt eine Mail als DMARC-konform.
Relaxed oder strict: wie streng Alignment ausgelegt wird
Ob zwei Domains als «dieselbe» gelten, steuern die Tags aspf= (für SPF) und adkim= (für DKIM). Beide kennen zwei Modi, und die Voreinstellung ist in beiden Fällen r:
| Modus | Bedeutung | rechnung@ihredomain.ch im «From», geprüfte Domain ist … |
|---|---|---|
r (relaxed, Standard) | Die Organisationsdomain muss übereinstimmen, Subdomains sind erlaubt | mail.ihredomain.ch → aligned |
s (strict) | Die Domain muss exakt identisch sein | mail.ihredomain.ch → nicht aligned |
| beide | Eine fremde Domain genügt nie | versand.mailtool.example → nicht aligned |
Praktisch heisst das: Signiert ein Dienstleister mit seiner eigenen Domain, besteht DKIM zwar, das Alignment aber nicht. Der Dienst muss unter Ihrer Domain signieren – sonst ist die Signatur für DMARC wertlos. strict setzt man nur, wenn man weiss, dass keine Subdomain im Versand beteiligt ist; als Ausgangspunkt genügt der Standard.
Die drei Policy-Stufen
Ein DMARC-Eintrag sieht etwa so aus: v=DMARC1; p=none; rua=mailto:reports@ihredomain.ch; pct=100. Das Kernstück ist p=, die Policy:
| Stufe | Wirkung | Wann sinnvoll |
|---|---|---|
p=none | Nur beobachten, nichts wird blockiert | Immer als Startpunkt |
p=quarantine | Nicht konforme Mails wandern in den Spam-Ordner | Wenn die Reports sauber aussehen |
p=reject | Nicht konforme Mails werden hart abgewiesen | Erst nach mehrwöchiger Beobachtung |
Der Sprung direkt zu p=reject ist der häufigste Anfängerfehler. Er blockiert zuverlässig gefälschte Mails – aber genauso zuverlässig auch jeden legitimen Versandweg, der im eigenen SPF/DKIM-Setup vergessen wurde.
Was die Reports zeigen
rua= legt eine Adresse fest, an die teilnehmende Mailserver (Google, Microsoft, und weitere) täglich einen aggregierten Bericht schicken: wie viele Mails von welcher IP-Adresse im Namen Ihrer Domain unterwegs waren, und ob SPF, DKIM und Alignment bestanden wurden. Diese Berichte kommen als XML-Dateien und sind roh kaum lesbar – dafür gibt es kostenlose wie kommerzielle Auswertungswerkzeuge, die daraus eine Übersicht machen.
Genau diese Reports sind der Grund, warum p=none kein Leerlauf ist, sondern die eigentliche Arbeitsphase: Sie zeigen zuverlässige Versandwege ebenso wie vergessene – etwa ein Formular-Plugin der Website oder ein CRM, das im eigenen Namen sendet, aber nie im SPF-Record aufgetaucht ist.
Häufige Fehler beim Einführen
Ein Treuhandbüro plant, DMARC einzuführen, und setzt direkt p=reject, weil das «am sichersten» klingt. Zwei Tage später bleiben Rechnungsmails der externen Buchhaltungssoftware beim Kunden aus – der Dienst versendet im Namen der Kanzlei, war aber nie im SPF-Record erfasst und hatte keinen eigenen DKIM-Selector. Die Mails bestehen weder SPF- noch DKIM-Alignment und werden zuverlässig abgewiesen, ohne dass jemand eine Fehlermeldung sieht.
Weitere wiederkehrende Fehler:
- Subdomains vergessen. Ohne
sp=-Tag gilt die Hauptpolicy auch für Subdomains – das ist gewollt, wird aber selten bedacht. rua=nie eingerichtet. Ohne Reports fliegt man beim Verschärfen der Policy blind.- Zu schneller Sprung von
nonezureject. Der Zwischenschrittquarantine, kombiniert mitpct=zur schrittweisen Ausweitung, macht Fehler sichtbar statt destruktiv.
p=rejectist das Ziel einer DMARC-Einführung, nicht der Startpunkt.
Wie Sie DMARC schrittweise einführen, ohne den Versand abzuwürgen
Die Einführung ist kein Konfigurationsschritt, sondern ein Prozess in vier Etappen. Jede endet mit einem Kriterium, das erfüllt sein muss, bevor die nächste beginnt:
- Bestandsaufnahme im DNS.
dig TXT _dmarc.ihredomain.ch +shortzeigt, ob bereits ein Eintrag existiert. Parallel dazu SPF-Record und DKIM-Selectoren aller Versanddienste prüfen – DMARC bewertet nur, was diese beiden liefern, es fügt selbst keine Authentifizierung hinzu. - Beobachten mit
p=none. Ein TXT-Eintrag auf_dmarc.ihredomain.chmitv=DMARC1; p=none; rua=mailto:dmarc@ihredomain.ch; fo=1. Nichts wird blockiert; ab dem nächsten Tag laufen die aggregierten Reports ein. Diese Phase dauert so lange, bis mindestens ein vollständiger Geschäftszyklus mit allen wiederkehrenden Versandarten abgedeckt ist – Monatsrechnungen, Newsletter, Kampagnen, Lohnabrechnungen. - Die Reports aufräumen. Jede sendende IP-Adresse aus den Berichten muss einer der drei Kategorien zugeordnet werden: bekannt und korrekt authentifiziert, bekannt aber noch nicht in SPF/DKIM erfasst (nachtragen), oder unbekannt und nicht erklärbar. Kriterium für den nächsten Schritt: In den Reports tauchen keine legitimen Quellen mehr auf, die scheitern.
- Verschärfen in Stufen.
p=quarantinemitpct=als Prozentsatz, der schrittweise steigt – die Policy wird dann nur auf einen Teil der nicht konformen Mails angewendet, der Rest läuft weiter. Bleiben die Reports über mehrere Wochen sauber, folgtp=reject. Dersp=-Tag steuert dabei separat, was für Subdomains gilt.
Zwei Fallstricke, an denen es in der Praxis scheitert:
rua=zeigt auf eine fremde Domain, ohne dass diese zustimmt. Lassen Sie die Berichte an einen Dienstleister schicken (rua=mailto:xyz@auswerter.example), verlangt die DMARC-Spezifikation eine ausdrückliche Erlaubnis der Zieldomain: einen TXT-Eintrag aufihredomain.ch._report._dmarc.auswerter.examplemit dem Wertv=DMARC1. Fehlt er, verwerfen viele Reporting-Server den Bericht stillschweigend – Sie warten auf Daten, die nie kommen, und halten die Stille für ein gutes Zeichen. Der Dienstleister richtet diesen Eintrag üblicherweise selbst ein; prüfen sollten Sie ihn trotzdem.p=rejectohne Monitoring wirkt rückwirkend nicht sichtbar. Eine abgewiesene Mail erzeugt beim Absender oft eine Fehlermeldung, beim betroffenen Fachdienst aber niemanden, der sie liest – automatisierte Versender aus Buchhaltung oder Ticketsystem verschlucken den Bounce. Der Ausfall fällt erst auf, wenn ein Kunde nachfragt, wo seine Rechnung bleibt. Das ist der Grund, warum die Beobachtungsphase nicht abgekürzt werden darf: Ohne Reports haben Sie keinen anderen Kanal, der Ihnen den Schaden meldet.
Die Regel, die entscheidet, was mit gefälschten Mails in Ihrem Namen passiert
Es gibt einen Punkt, an dem viele Betriebe die E-Mail-Absicherung für erledigt halten, obwohl das Wesentliche noch fehlt. Zwei Verfahren sind eingerichtet, alles sieht sauber aus – und trotzdem kann jemand eine Mail mit Ihrem Firmennamen im Absenderfeld verschicken, die technisch einwandfrei durch alle Prüfungen läuft.
Der Grund ist ein Konstruktionsdetail der E-Mail: Es gibt zwei Absenderadressen. Eine prüfen die Maschinen, die andere lesen Sie am Bildschirm. Nichts zwingt sie dazu, dieselbe zu sein. Ein Absender kann seine eigene Domain sauber ausweisen und in dem Feld, das Ihr Kunde sieht, trotzdem Ihre Firma eintragen.
Genau hier setzt die dritte Regel an. Sie verlangt zweierlei: dass die geprüfte Adresse zu der passt, die im Postfach erscheint – und sie legt fest, was passieren soll, wenn das nicht der Fall ist. Ignorieren, in den Spam-Ordner, oder gar nicht erst annehmen. Diese Entscheidung treffen Sie, und sie ist der Punkt, an dem es ernst wird.
Warum niemand diese Regel scharf stellen sollte, bevor er weiss, wer alles Post verschickt
DMARC
DMARC steht für «Domain-based Message Authentication, Reporting and Conformance» – eine Regel, die Sie für Ihre Domain veröffentlichen und die zwei Dinge festlegt: dass die technisch geprüfte Absenderadresse zu der passen muss, die der Empfänger im Postfach sieht – und wie ein Empfänger reagieren soll, wenn eine Mail das nicht erfüllt. Ohne DMARC entscheidet jeder Empfänger selbst; mit DMARC geben Sie die Antwort vor.
Policy-Stufe
Der Teil der Regel, der die Reaktion bestimmt. «Beobachten» heisst, dass nichts blockiert wird und Sie nur Berichte erhalten. «Quarantäne» schickt auffällige Mails in den Spam-Ordner. «Abweisen» sorgt dafür, dass sie gar nicht erst angenommen werden. Der Weg führt in dieser Reihenfolge – wer direkt bei «Abweisen» beginnt, blockiert zuverlässig auch die eigenen vergessenen Versandwege.
Report
Ein täglicher Bericht, den grosse Mail-Anbieter an eine von Ihnen angegebene Adresse schicken. Er listet auf, welche Server im Namen Ihrer Domain Mails verschickt haben und ob die Prüfungen bestanden wurden. Diese Berichte sind der eigentliche Wert der Beobachtungsphase: Sie zeigen die Versandwege, die niemand im Betrieb mehr auf dem Radar hatte.
Warum ich die Beobachtungsphase für den wertvollsten Teil halte
Der Reflex, den ich am häufigsten bremsen muss, ist der Wunsch, gleich die strengste Einstellung zu wählen. Die Logik dahinter ist verständlich: Wenn ich mich schon schütze, dann richtig. Nur schützt die strengste Einstellung nicht vor mehr Fälschungen als die mittlere – sie erhöht nur, was ein Fehler im eigenen Setup kostet.
Was in dieser Phase wirklich passiert, hat mit Sicherheit im engeren Sinn zunächst wenig zu tun: Sie bekommen zum ersten Mal eine vollständige Liste aller Systeme, die im Namen Ihrer Firma Mails verschicken. In den Berichten steht die Buchhaltungssoftware, die niemand erwähnt hat. Das Ticketsystem. Das Kontaktformular der Website. Der Newsletter-Dienst, den vor zwei Jahren jemand eingerichtet und nie abgeschaltet hat. Diese Inventur ist der Ertrag – die verschärfte Policy ist danach nur noch eine Zeile.
Wirtschaftlich ist die Rechnung eindeutig, aber sie zeigt nicht in die Richtung, in die man zuerst schaut. Der Schaden aus einer gefälschten Mail in Ihrem Namen ist unangenehm und schwer zu beziffern. Der Schaden aus abgewiesenen eigenen Rechnungen ist sofort da, trifft Ihren Zahlungseingang und fällt oft erst auf, wenn ein Kunde nachfragt. Beides adressiert dieselbe Konfiguration – aber nur, wenn sie in der richtigen Reihenfolge entsteht.
Einen Einwand höre ich regelmässig: Am Ende entscheidet immer der Empfänger. Sie können die strengste Stufe wählen – ob sich ein Empfängerserver daran hält, bestimmt er selbst. Das ist richtig, misst DMARC aber an einer Garantie, die kein Verfahren dieser Art einlöst. Meine Frage lautet anders: Was trägt dazu bei, dass meine Rechnung ankommt? Darauf haben die grossen Anbieter selbst geantwortet – Google und Yahoo verlangen seit Februar 2024 von Versendern ab rund 5000 Mails pro Tag eine DMARC-Regel, Microsoft seit Mai 2025 dasselbe. Diese Schwelle erreicht ein KMU nicht. Aber was dort Pflicht ist, zählt bei allen anderen als Signal – und zwar in die Richtung, in die Sie es brauchen.
Die ehrliche Grenze: DMARC schützt Ihre Domain davor, missbraucht zu werden. Es schützt Sie nicht vor dem, was in Ihrem eigenen Posteingang landet. Wer Ihnen eine gefälschte Rechnung von einer ähnlich aussehenden Domain schickt, wird von Ihrer eigenen Regel nicht aufgehalten – dafür braucht es die Aufmerksamkeit Ihrer Mitarbeitenden und keinen Eintrag im DNS, dem «Domain Name System»: dem Adressverzeichnis des Internets, in dem steht, welcher Server zu welchem Namen gehört.
Häufige Fragen
Wie lange sollte ich in `p=none` bleiben?
Mehrere Wochen, mindestens einen vollständigen Geschäftszyklus mit allen wiederkehrenden Versandarten (Rechnungen, Newsletter, Kampagnen). Erst wenn die Reports keine unerklärten Fehlschläge mehr zeigen, lohnt sich der Schritt zu quarantine.
Was mache ich konkret mit den Reports?
Ein Auswertungswerkzeug macht aus den XML-Dateien eine Liste von sendenden IP-Adressen mit Pass/Fail-Status. Jede unbekannte, aber legitime Quelle braucht einen SPF- und/oder DKIM-Eintrag; jede unbekannte und nicht erklärbare Quelle ist ein Hinweis auf Missbrauch.
Reicht es, wenn SPF oder DKIM bestehen, egal welches?
Ja, für DMARC genügt es, wenn eine der beiden Prüfungen besteht UND zur sichtbaren Absenderdomain aligned ist. Beide gleichzeitig zu erfüllen erhöht die Zuverlässigkeit zusätzlich, ist aber keine Pflicht.
Mein Newsletter-Dienst signiert mit seiner eigenen Domain — genügt das?
Für DKIM ja, für DMARC nein. Die Signatur besteht, aber sie bezieht sich auf eine fremde Domain und ist damit nicht aligned zu der Adresse, die Ihre Empfänger sehen. Der Dienst muss unter Ihrer Domain signieren – dafür hinterlegen Sie seinen Selector in Ihrem DNS.
Deckt DMARC auch Mails ab, die an mich gesendet werden?
Nein. DMARC schützt Ihre eigene Domain davor, für gefälschte Absenderadressen missbraucht zu werden. Für eingehenden Spam oder Phishing in Ihrem eigenen Postfach sind die Spamfilter Ihres Mail-Providers zuständig.
