Das Angebot ist geschrieben, die Rechnung verschickt – und beim Kunden kommt nichts an. Oder es landet im Spam-Ordner, zwischen Gewinnspielen und angeblichen Paketbenachrichtigungen. Wer mit eigener Domain mailt, also mit Adressen wie info@ihr-betrieb.de, kennt das vielleicht. Häufig liegt es nicht am Inhalt der Mail, sondern an drei unscheinbaren DNS-Einträgen: SPF, DKIM und DMARC.
Dieser Beitrag erklärt ohne Protokollkunde, was die drei Verfahren tun, warum große Mail-Anbieter inzwischen genauer hinschauen, wie Sie den Stand Ihrer Domain prüfen – und wo die Grenzen liegen. Wer ausschließlich eine Adresse bei GMX, Web.de, Gmail oder Outlook.com nutzt, kann sich entspannt zurücklehnen: Dort kümmert sich der Anbieter um diese Einträge. Betroffen sind alle, denen eine eigene Domain gehört.
Das Grundproblem: Absender lassen sich fälschen
E-Mail stammt aus einer Zeit, in der sich die Teilnehmer im Netz weitgehend kannten. Die Absenderadresse ist deshalb im Kern nur eine Angabe – ähnlich wie der Absender auf einem Briefumschlag, den jeder beliebig beschriften kann. Genau das nutzen Phishing-Mails aus, die scheinbar von Bank, Lieferant oder der eigenen Chefin kommen.
SPF, DKIM und DMARC sind die nachträglich eingebauten Kontrollen. Sie geben dem empfangenden Mailserver die Möglichkeit zu prüfen, ob eine Mail, die angeblich von ihr-betrieb.de kommt, tatsächlich von dort stammt. Fehlen diese Einträge, kann der Empfänger echte und gefälschte Mails Ihrer Domain schlechter unterscheiden – und behandelt im Zweifel beide misstrauisch.
SPF, DKIM und DMARC in einfachen Worten
SPF: die Liste der erlaubten Absender-Server
Per SPF (Sender Policy Framework) veröffentlicht der Domaininhaber im DNS, welche Server Mails für seine Domain verschicken dürfen. Der Empfänger vergleicht: Kommt die Mail von einem dieser Server? Zwei technische Regeln aus dem Standard RFC 7208 sorgen in der Praxis regelmäßig für Ärger: Pro Domain darf es nur einen SPF-Eintrag geben – zwei Einträge führen zu einem Fehler statt zu doppelter Sicherheit. Und bei der Auswertung dürfen höchstens zehn zusätzliche DNS-Abfragen entstehen. Wer über die Jahre Newsletter-Dienst, Shop, Buchhaltung und Ticketsystem per include eingetragen hat, reißt diese Grenze schneller, als man denkt.
DKIM: die digitale Unterschrift
Bei DKIM (DomainKeys Identified Mail) unterschreibt der versendende Server jede Mail kryptografisch. Den passenden öffentlichen Schlüssel findet der Empfänger im DNS der Domain. Stimmt die Unterschrift, ist belegt, dass die Mail von einem berechtigten System kommt und unterwegs nicht verändert wurde. DKIM richtet in der Regel der Mail-Anbieter ein; oft muss der Domaininhaber nur einen oder zwei vorgegebene DNS-Einträge anlegen.
DMARC: die Hausordnung
DMARC verbindet beides mit der Absenderadresse, die der Empfänger tatsächlich sieht. Eine Mail besteht die DMARC-Prüfung nur, wenn SPF oder DKIM erfolgreich ist und die dabei geprüfte Domain zur sichtbaren Absenderdomain passt. Außerdem legt der Domaininhaber fest, was mit Mails passieren soll, die durchfallen:
- p=none – nichts Besonderes tun, nur beobachten,
- p=quarantine – als verdächtig behandeln, typischerweise Spam-Ordner,
- p=reject – annehmen verweigern.
Zusätzlich kann man sich Berichte schicken lassen, welche Server im Namen der Domain Mails verschicken. Diese Berichte kommen als XML-Dateien – sie lesen sich ungefähr so gemütlich wie eine Steuererklärung in Maschinensprache, sind aber Gold wert, um vergessene Absender zu finden.
Warum das gerade (wieder) Thema ist
Die drei Verfahren sind nicht neu. Neu ist, wie konsequent die großen Anbieter sie voraussetzen:
- Google und Yahoo verlangen seit Februar 2024 von allen Absendern mindestens SPF oder DKIM. Wer mehr als 5.000 Mails pro Tag an Gmail-Adressen schickt, braucht laut Google SPF, DKIM und eine DMARC-Richtlinie (mindestens p=none), dazu bei Werbemails eine Ein-Klick-Abmeldung. Yahoo nennt für Massenversender dieselben Bausteine, aber auf der gelesenen Seite keine Zahl.
- Microsoft stellt seit Mai 2025 vergleichbare Anforderungen an Absender, die mehr als 5.000 Mails täglich an Outlook.com-, Hotmail- und Live-Adressen schicken. Laut Fachberichten über die Ankündigung landen nicht konforme Mails zunächst im Junk-Ordner und sollen später abgewiesen werden.
- Der DMARC-Standard selbst wurde im Mai 2026 als RFC 9989 neu gefasst und ersetzt die bisherige Fassung RFC 7489. Für kleine Betriebe ändert sich dadurch wenig; Details dazu weiter unten.
- Das BSI hat mit der Technischen Richtlinie TR-03182 Anforderungen an die E-Mail-Authentifizierung für Mail-Anbieter und Organisationen mit eigenem Mailbetrieb formuliert und 2025 zum „Jahr der E-Mail-Sicherheit“ erklärt.
Ein kleiner Betrieb liegt meist weit unter 5.000 Mails pro Tag. Die Mindestanforderung „SPF oder DKIM“ gilt bei Google und Yahoo aber für jeden. Und unabhängig von festen Schwellen bewerten Spamfilter eine sauber authentifizierte Domain schlicht besser als eine, bei der niemand nachprüfen kann, wer eigentlich schreibt.
So prüfen Sie den Stand Ihrer Domain
1. Eine Testmail an ein Gmail- oder Outlook-Konto schicken
Der einfachste Test: eine normale Mail aus Ihrem Firmenpostfach an ein privates Gmail-Konto senden und dort über das Drei-Punkte-Menü Original anzeigen wählen. Im Kopfbereich der Mail stehen die Prüfergebnisse, üblicherweise in einer Zeile namens Authentication-Results. Sie wollen dort für SPF, DKIM und DMARC jeweils ein pass sehen. Steht dort fail, softfail, none oder permerror, gibt es etwas zu tun.
2. Alle Systeme auflisten, die in Ihrem Namen mailen
Das Postfach ist selten der einzige Absender. Typische Kandidaten:
- das Kontaktformular der Webseite,
- Online-Shop oder Buchungssystem,
- Newsletter-Dienst,
- Rechnungs- oder Buchhaltungssoftware, die Rechnungen direkt verschickt,
- Ticket- oder CRM-System,
- der Multifunktionsdrucker mit „Scan to Mail“.
Jedes dieser Systeme muss entweder über den offiziellen Mailserver senden oder im SPF-Eintrag berücksichtigt sein – idealerweise zusätzlich mit eigener DKIM-Signatur für Ihre Domain. Der klassische Fehler: Das Postfach ist sauber eingerichtet, aber die Rechnungen aus der Buchhaltungssoftware verschickt ein fremder Server im Namen der Domain, der nirgends eingetragen ist. Gerade bei Rechnungen ist das ärgerlich – mehr zum Rechnungsweg steht in unserem Beitrag „E-Rechnung statt PDF“.
3. Klären, wer die DNS-Einträge verwaltet
Domain, Webseite und Postfach liegen nicht immer beim selben Anbieter. Wer Zugriff auf die DNS-Verwaltung hat, ist oft die eigentliche Frage. Steht dort nur „die Agentur von damals“, sollte das als Erstes geklärt werden.
Wie die Einträge aussehen können
Die konkreten Werte gibt Ihr Mail-Anbieter vor; die folgenden Zeilen sind nur Beispiele mit Platzhaltern, keine Vorlage zum Kopieren. Ein SPF-Eintrag ist ein TXT-Eintrag direkt auf der Domain:
v=spf1 include:_spf.mailanbieter.example include:newsletter.example -all
Ein DMARC-Eintrag im Beobachtungsmodus ist ein TXT-Eintrag unter _dmarc.ihr-betrieb.de:
v=DMARC1; p=none; rua=mailto:dmarc-berichte@ihr-betrieb.de
Die sinnvolle Reihenfolge ist unspektakulär: zuerst SPF und DKIM für alle Absender sauber einrichten, dann DMARC mit p=none starten und die Berichte einige Wochen auswerten. Erst wenn klar ist, dass alle legitimen Absender bestehen, schrittweise auf quarantine und später auf reject umstellen. Wer sofort mit reject startet, testet die Einrichtung live am Kunden – meist mit den Rechnungen.
Laut der SIDN-Zusammenfassung der BSI-Richtlinie TR-03182 sind nur quarantine und reject zulässig, langfristig nur reject. p=none ist also ein Startpunkt, kein Ziel.
Tipp für Domains, die gar nicht mailen
Viele Betriebe besitzen zusätzliche Domains – Tippfehler-Varianten, alte Firmennamen, Projektadressen. Auch die lassen sich für gefälschte Absender missbrauchen. Verschickt eine Domain nie Mails, kann sie das per v=spf1 -all und einer DMARC-Richtlinie mit p=reject ausdrücklich erklären.
Was sich mit RFC 9989 ändert – und was nicht
Die neue DMARC-Fassung räumt vor allem unter der Haube auf. Für kleine Betriebe relevant sind zwei Punkte: Der Prozent-Parameter pct, mit dem man eine Richtlinie nur auf einen Teil der Mails anwenden konnte, ist entfallen; als Ersatz gibt es einen Testmodus-Schalter t. Neu ist außerdem np für Subdomains, die gar nicht existieren. Bestehende Einträge der Form v=DMARC1; p=… bleiben gültig. Wer heute pct nutzt, sollte bei Gelegenheit prüfen, ob der Eintrag noch das tut, was er soll – Panik ist nicht nötig.
Grenzen: Was SPF, DKIM und DMARC nicht leisten
- Keine Garantie für den Posteingang: Authentifizierung ist eine Voraussetzung, kein Freifahrtschein. Inhalt, Beschwerderate und Ruf des Absenders zählen weiterhin.
- Kein Schutz vor ähnlichen Domains: DMARC schützt exakt Ihre Domain. Eine Fälschung von ihr-betrieb-rechnung.de oder ihr-betreib.de erfasst es nicht.
- Kein Schutz bei gekapertem Konto: Verschickt ein Angreifer Mails aus Ihrem echten, übernommenen Postfach, bestehen diese alle Prüfungen. Dagegen hilft ein gut abgesichertes Konto – siehe „Welche Zwei-Faktor-Methode passt?“.
- Keine Verschlüsselung: Die Verfahren prüfen die Herkunft, nicht die Vertraulichkeit. Der Inhalt bleibt so lesbar wie vorher.
- Weiterleitungen und Mailinglisten: Bei Weiterleitungen schlägt SPF oft fehl, weil ein fremder Server die Mail erneut versendet. DKIM übersteht das häufig, aber nicht, wenn die Mail unterwegs verändert wird – etwa durch einen Betreff-Zusatz einer Mailingliste. Das ist einer der Gründe, mit p=none zu beginnen und die Berichte anzusehen.
Fazit: Drei Einträge, die man einmal sauber setzt
SPF, DKIM und DMARC klingen nach Rechenzentrum, sind im Kern aber drei Textzeilen im DNS. Für Selbstständige und kleine Betriebe mit eigener Domain gehören sie heute zur Grundausstattung: Sie verbessern die Chancen, dass Angebote und Rechnungen ankommen, und erschweren es Betrügern, mit Ihrem Namen zu werben. Die Arbeit steckt weniger in den Einträgen als in der Bestandsaufnahme, welche Systeme überhaupt in Ihrem Namen mailen.
Die vernünftige Reihenfolge: Testmail prüfen, Absender auflisten, SPF und DKIM vervollständigen, DMARC beobachtend starten und erst dann verschärfen. Sie möchten wissen, wie Ihre Domain dasteht, oder die Berichte nicht selbst entziffern? DGH-IT schaut sich die Einrichtung gern mit Ihnen an – ohne Verkaufsdruck.
Quellen & weiterführende Informationen
- Google Gmail-Hilfe: Richtlinien für E-Mail-Absender – Anforderungen für alle Absender und für Absender mit mehr als 5.000 Mails/Tag, gültig seit 1. Februar 2024; abgerufen 6. Oktober 2026.
- Yahoo: Sender Best Practices – Anforderungen für alle Absender und Bulk-Absender ab Februar 2024; abgerufen 6. Oktober 2026.
- Microsoft Tech Community: Outlook’s new requirements for high-volume senders – Ankündigung vom 2. April 2025.
- Mailgun: Microsoft sender requirements – Einordnung der Durchsetzung ab 5. Mai 2025; abgerufen 6. Oktober 2026.
- IETF RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC) – Mai 2026, ersetzt RFC 7489.
- IETF RFC 7208: Sender Policy Framework (SPF) – April 2014; Abschnitte 3.2, 4.5 und 4.6.4 zu Mehrfacheinträgen und DNS-Abfragegrenze.
- BSI: TR-03182 E-Mail-Authentifizierung – Version 1.0, Seitenstand 16. Januar 2025.
- SIDN: Germany’s BSI publishes detailed technical guidelines on e-mail authentication – Zusammenfassung der TR-03182-Anforderungen; 6. Mai 2024.
- heise online: BSI – 2025 soll das Jahr der E-Mail-Sicherheit werden – abgerufen 6. Oktober 2026.
- Google Gmail-Hilfe: Vollständige Header einer E-Mail verfolgen – „Original anzeigen“; abgerufen 6. Oktober 2026.

Schreibe einen Kommentar