84 % aller Domains weltweit haben keinen DMARC-Eintrag. Keine Absender-Verifizierung, kein Spoofing-Schutz, nix. Jeder kann E-Mails in ihrem Namen verschicken — und die meisten Empfänger merken es nicht mal.
Ich habe heute Nachmittag meine Domains abgesichert. somatic-web.de und farbaer.de. SPF gehärtet, DMARC auf p=reject gesetzt, BIMI mit Logo eingerichtet. Keine externe Agentur, kein teures Security-Audit. DNS-Einträge anpassen, SVG aufbereiten, fertig. Und weil ich dabei gemerkt habe, wie wenige das tun — und warum — schreibe ich auf, was ich gemacht habe.
Was SPF, DKIM und DMARC eigentlich tun
Kurz und schmerzlos, ohne Vorlesung.
SPF (Sender Policy Framework) legt fest, welche Server E-Mails für deine Domain versenden dürfen. Ein DNS-Eintrag, eine Zeile. Alles, was nicht auf der Liste steht, ist nicht autorisiert.
DKIM (DomainKeys Identified Mail) signiert jede ausgehende E-Mail kryptografisch. Der empfangende Server prüft die Signatur gegen einen öffentlichen Schlüssel in deinem DNS. Stimmt die Signatur nicht — wurde die Mail unterwegs manipuliert oder kommt gar nicht von dir.
DMARC (Domain-based Message Authentication, Reporting and Conformance) baut auf beiden auf. Es sagt dem Empfänger: Wenn SPF oder DKIM fehlschlagen — was soll passieren? Drei Optionen: p=none (nix tun, nur berichten), p=quarantine (ab in den Spam) oder p=reject (komplett ablehnen). Erst bei reject ist die Tür wirklich zu.
Das Problem: Die meisten Domains, die überhaupt einen DMARC-Eintrag haben, stehen auf p=none. Das ist wie eine Alarmanlage, die zwar piept, aber die Tür offen lässt.
Was ich konkret gemacht habe
SPF: Vom breiten Include zum expliziten Server
Mein alter SPF-Record sah so aus:
v=spf1 a mx include:spf.kasserver.com ~allZwei Schwachstellen. Das include:spf.kasserver.com autorisiert potenziell alle Kasserver-Kunden zum Versand in meinem Namen — nicht nur meinen eigenen Server. Und ~all ist ein Softfail: Unautorisierte Mails werden markiert, aber nicht abgelehnt.
Neu:
v=spf1 a mx a:w009d1da.kasserver.com -allJetzt ist nur noch mein konkreter Server autorisiert. Und -all bedeutet Hardfail — alles andere wird abgewiesen. Kein Spielraum, kein Vielleicht.
Kurzer Einschub zur Debatte Softfail vs. Hardfail: Viele Guides empfehlen ~all in Kombination mit DMARC, weil DMARC ohnehin beide gleich behandelt. Das stimmt technisch. Aber ich will, dass auch Server ohne DMARC-Unterstützung eine klare Ansage bekommen. Gürtel und Hosenträger.
DMARC: Von „none“ auf „reject“ mit striktem Alignment
Der alte DMARC-Eintrag für somatic-web.de stand auf p=none — Monitoring-Modus. Schön zum Schauen, bringt aber keinen Schutz. farbaer.de hatte immerhin p=quarantine. Jetzt beide:
v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@somatic-web.de; ruf=mailto:dmarc@somatic-web.de; fo=1; pct=100Was hier passiert: p=reject blockt unautorisierte Mails komplett. sp=reject schützt auch alle Subdomains — damit niemand über irgendwas.somatic-web.de Mails fälschen kann. adkim=s und aspf=s erzwingen striktes Alignment: Die Domain im From-Header muss exakt mit der SPF- und DKIM-Domain übereinstimmen. Kein Subdomain-Matching, kein Schlupfloch. Die Reports — aggregiert und forensisch — gehen an eine dedizierte Adresse.
DKIM: Schon erledigt
Beide Domains hatten bereits zwei DKIM-Schlüssel konfiguriert — Key-Rotation durch All-Inkl. Kein Handlungsbedarf. Passt.
BIMI: Mein Logo in der Inbox
BIMI (Brand Indicators for Message Identification) ist die Kür nach der Pflicht. Wenn SPF, DKIM und DMARC sauber stehen und DMARC auf p=quarantine oder p=reject steht, kannst du ein Logo hinterlegen, das bei unterstützenden E-Mail-Clients neben deinen Mails angezeigt wird.
Die Voraussetzungen sind spezifisch. Das Logo muss als SVG Tiny 1.2 PS vorliegen — nicht irgendein SVG, sondern das Profil „Tiny Portable/Secure“. Quadratisch, idealerweise 1024×1024, solider Hintergrund, mit <title>-Element. Meine finale Datei: 1 KB. Gehostet unter https://somatic-web.de/bimi/bimi-logo-graphit.svg.
Der DNS-Eintrag:
default._bimi TXT v=BIMI1; l=https://somatic-web.de/bimi/bimi-logo-graphit.svg; a=;Das a=; steht für das Zertifikatsfeld — leer, weil ich kein VMC oder CMC habe. Ohne Zertifikat zeigen Yahoo, AOL und Fastmail das Logo trotzdem an. Gmail braucht mindestens ein Common Mark Certificate (ab ca. 650 €/Jahr), Apple Mail ein VMC (ab ca. 1.500 €/Jahr, erfordert eingetragene Marke). Für eine Einzelperson oder ein kleines Unternehmen ohne Marke ist das erstmal kein sinnvolles Investment. Aber die Grundlage steht — wenn Gmail irgendwann die Anforderungen lockert oder ich eine Marke eintrage, ist alles vorbereitet.
Von den Top-1-Million-Domains weltweit haben gerade mal knapp 10.000 einen BIMI-Eintrag. Davon sind über die Hälfte fehlerhaft konfiguriert — meistens wegen ungültiger SVG-Dateien. BIMI ist Neuland für fast alle.
Warum das fast niemand macht
Die Zahlen sind ernüchternd. Red Sifts Analyse von 73 Millionen Domains Ende 2025 zeigt: Nur 2,5 % erzwingen DMARC mit p=reject. Bei den Fortune-500-Unternehmen sieht es besser aus — rund 63 % stehen auf Reject. Aber bei schnell wachsenden Mittelständlern (Inc. 5000) sind es gerade mal 15 %. Und über die Hälfte aller DMARC-Einträge weltweit steht immer noch auf p=none.
Die Gründe, warum Unternehmen nicht von none auf reject gehen, sind fast immer dieselben:
Angst, dass legitime Mails geblockt werden. Newsletter-Tools, CRM-Systeme, Buchhaltungssoftware, Ticket-Systeme — alles verschickt E-Mails im Namen der Domain. Wer nicht weiß, welche Dienste das tun, hat Angst vor dem Reject. Zurecht, wenn man vorher nicht aufräumt. Aber die Lösung ist Aufräumen, nicht Offenlassen.
Shadow IT. Mitarbeiter nutzen Dienste, von denen die IT nix weiß. Die schicken fröhlich E-Mails über die Firmendomain — und fallen bei striktem DMARC durch. In Konzernen ein echtes Problem. Für mich als Einzelunternehmer: überschaubar.
Die Reports sind unlesbar. DMARC-Aggregate-Reports kommen als XML-Dateien. Wer die manuell auswerten will, braucht Geduld und einen XML-Parser. Fast die Hälfte aller DMARC-Einträge hat nicht mal ein Reporting-Tag gesetzt — die schicken also gar keine Reports.
Kein Druck. Bis 2024 gab es keinen zwingenden Grund. Das hat sich geändert.
Google, Yahoo und Microsoft machen Ernst
Im Februar 2024 haben Google und Yahoo neue Anforderungen für Massenversender eingeführt: SPF, DKIM und DMARC (mindestens p=none) sind Pflicht für jeden, der mehr als 5.000 Mails pro Tag an Gmail oder Yahoo schickt. Google hat die Durchsetzung schrittweise verschärft — seit November 2025 werden nicht-konforme Mails aktiv abgelehnt. Ergebnis: 265 Milliarden unauthentifizierte Mails weniger bei Gmail-Nutzern in 2024.
Microsoft zog im Mai 2025 nach. Outlook.com, Hotmail und Live.com verlangen jetzt dasselbe. Allein diese Ankündigung hat innerhalb von 30 Tagen über 400.000 neue DMARC-Einträge erzeugt.
In Deutschland hat das BSI 2025 zum „Jahr der E-Mail-Sicherheit“ erklärt und eine Empfehlung (BSI-CS 155) veröffentlicht, die SPF, DKIM, DMARC und DANE als Standard definiert. GMX und WEB.DE — Deutschlands größte Mailprovider — versenden seit August 2024 DMARC-Aggregate-Reports und haben in fünf Monaten rund 75 Millionen Reports verarbeitet.
Der Druck wächst. Wer jetzt noch auf p=none steht, wird bald Zustellprobleme bekommen.
Was das alles kostet
An einem Nachmittag von „offen wie ein Scheunentor“ zu maximal abgesichertem E-Mail-Versand mit visuellem Branding. Kein externes Tool, keine monatliche Gebühr — nur DNS-Einträge und ein sauber aufbereitetes SVG.
Die einzige potenzielle Investition: Ein BIMI-Zertifikat für Gmail-Sichtbarkeit. Das Common Mark Certificate gibt es seit September 2024 ab ca. 650 € pro Jahr — ohne Markenregistrierung, aber aktuell nur von Gmail unterstützt. Für die meisten kleinen Unternehmen kein Muss, aber gut zu wissen.
Der eigentliche Aufwand ist nicht finanziell. Er ist intellektuell: Verstehen, was die Einträge tun. Wissen, welche Server E-Mails versenden dürfen. Sich trauen, den Schalter auf Reject umzulegen. Das ist keine Raketenwissenschaft — aber es erfordert, dass man sich hinsetzt und es macht.
84 % aller Domains tun das nicht. Heute eine weniger.