Zum Hauptinhalt springen
SiteScan.top

SPF, DKIM und DMARC: Ihre Domain verschickt Mails, ob Sie wollen oder nicht

Warum jede Website-Domain E-Mail-Authentifizierung braucht, wie SPF, DKIM und DMARC zusammenspielen und wie Sie zu einer Reject-Policy kommen, ohne eigene Mails zu verlieren.

Infrastruktur · Veröffentlicht: 30. September 2026 · 6 Min. Lesezeit · Анна Ковалёва

„Wir verschicken keine E-Mails“ ist eine der häufigsten Antworten, wenn ein Scan einen fehlenden SPF- oder DMARC-Eintrag meldet. Sie geht nur am Kern vorbei. Jeder im Internet kann Ihre Domain in die From-Zeile einer Nachricht schreiben. Ob Gmail oder Outlook ihm glauben, entscheiden ein paar TXT-Einträge in Ihrem DNS — und fehlen sie, spricht niemand für Ihre Domain.

Warum das Website-Betreiber betrifft

Spoofing und Phishing. Ohne DMARC-Policy bekommen empfangende Server von Ihnen keine Anweisung, was mit Mails geschehen soll, die sich als Ihre Domain ausgeben und die Prüfungen nicht bestehen. Gefälschte Rechnungen und „Passwort zurücksetzen“-Mails von support@ihredomain kosten fast nichts und beschädigen das Vertrauen in die echte Website.

Ihre eigenen Benachrichtigungen. Kontaktformulare, Bestellbestätigungen, Passwort-Resets — selbst eine „statische“ Website verschickt meist irgendetwas. Ein Formular-Handler, der PHP mail() direkt vom Webserver aufruft und die Adresse des Besuchers in From setzt, fällt durch jede Prüfung und landet im Spam oder nirgendwo.

Anforderungen der Mailbox-Anbieter. Seit Februar 2024 verlangen Gmail und Yahoo von allen Absendern SPF oder DKIM, von Massenversendern beides, dazu einen DMARC-Eintrag (mindestens p=none) und eine From-Domain, die mit einem der beiden übereinstimmt. Andere Anbieter ziehen in dieselbe Richtung. Mails, die die Regeln nicht erfüllen, werden zunehmend abgewiesen statt nur gefiltert.

SPF: Wer darf senden

SPF ist ein TXT-Eintrag auf der Domain selbst, der die Server auflistet, die in ihrem Namen senden dürfen:

example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

Typische Stolperfallen:

SPF prüft den Envelope-Absender (die Bounce-Adresse), nicht den From-Header, den der Nutzer sieht. Deshalb reicht SPF allein nicht aus.

DKIM: eine Signatur auf jeder Nachricht

DKIM signiert ausgehende Mails mit einem privaten Schlüssel; der öffentliche Schlüssel steht im DNS unter einem Selektor:

s1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Jeder sendende Dienst — Mailbox-Anbieter, Newsletter-Tool, API für Transaktionsmails — liefert einen eigenen Selektor und Schlüssel oder einen CNAME auf einen Eintrag, den er selbst verwaltet. Verwenden Sie 2048-Bit-RSA-Schlüssel, wo der Anbieter es erlaubt, und löschen Sie Selektoren von Diensten, die Sie nicht mehr nutzen. Anders als SPF übersteht eine DKIM-Signatur die Weiterleitung und ist damit der verlässlichere der beiden Mechanismen.

DMARC: die Policy, die alles verbindet

DMARC steht unter _dmarc und sagt Empfängern, was mit einer Nachricht geschehen soll, die durchfällt, und wohin Berichte gehen:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Eine Nachricht besteht DMARC, wenn SPF oder DKIM bestanden wurde und die Domain, für die das gilt, mit der Domain im From übereinstimmt (Alignment). Ein SPF-Pass für die Bounce-Domain Ihres Mail-Dienstleisters zählt nicht; eine DKIM-Signatur mit d=example.com schon.

Führen Sie es schrittweise ein:

  1. p=none mit rua-Berichten. Nichts wird blockiert; Sie erhalten tägliche aggregierte XML-Berichte über alle Server, die als Ihre Domain senden. Nutzen Sie einen Parser oder Report-Dienst, statt XML von Hand zu lesen.
  2. Bringen Sie jeden legitimen Absender in Ordnung, der durchfällt: in SPF aufnehmen, DKIM einrichten, sicherstellen, dass From Ihre Domain verwendet.
  3. p=quarantine, optional zuerst mit pct=, um die Policy nur auf einen Teil der durchgefallenen Mails anzuwenden.
  4. p=reject. Gefälschte Mails werden schon an der Tür abgewiesen.

p=none ist ein Beobachtungsmodus, kein Schutz. Wer jahrelang dort bleibt, hat die Daten gesammelt und nie danach gehandelt.

Domains, die keine Mails senden

Geparkte Domains, reine Weiterleitungs-Domains und alte Markennamen sind beliebte Spoofing-Ziele, weil niemand sie im Blick hat. Schließen Sie sie vollständig ab:

example.net.         TXT  "v=spf1 -all"
_dmarc.example.net.  TXT  "v=DMARC1; p=reject"

Ein Null-MX-Eintrag (example.net. MX 0 .) teilt anderen Servern zusätzlich mit, dass die Domain keine Mails annimmt.

So prüfen Sie

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT s1._domainkey.example.com

Der erste Befehl sollte genau einen v=spf1-String liefern. Für DKIM brauchen Sie den Selektor: Öffnen Sie eine von Ihnen gesendete Nachricht, suchen Sie den Header DKIM-Signature und nehmen Sie den Wert von s=. Der Header Authentication-Results einer empfangenen Nachricht zeigt die Ergebnisse von SPF, DKIM und DMARC an einer Stelle.

Ein SiteScan-Report übernimmt die DNS-Seite: Er markiert einen fehlenden SPF-Eintrag, mehrere SPF-Einträge, ein zu großzügiges +all, einen fehlenden DMARC-Eintrag und eine DMARC-Policy, die auf p=none stehen geblieben ist. DKIM prüft er nicht — Selektoren lassen sich ohne Kenntnis ihrer Namen nicht über DNS ermitteln —, also prüfen Sie das an einer echten Nachricht.

Checkliste

  1. Genau ein SPF-Eintrag, unter zehn Abfragen, endet auf ~all oder -all.
  2. DKIM ist für jeden Dienst eingerichtet, der als Ihre Domain sendet.
  3. Benachrichtigungen der Website laufen über einen authentifizierten Anbieter, From ist Ihre Domain, der Besucher steht in Reply-To.
  4. DMARC existiert, rua-Berichte kommen an, und die Policy bewegt sich von p=none Richtung p=reject.
  5. Domains ohne Mailversand haben v=spf1 -all und p=reject.

Ebenfalls lesenswert

Prüfen Sie, was davon auf Ihrer Website steckt

Der kostenlose Scan zeigt kaputte Links, JS-Fehler und Performance-Probleme in einer Minute.