Sicherheits-Ratgeber
SPF, DMARC und DNSSEC, erklärt
Security-Header schützen die Menschen, die Ihre Website besuchen. Diese vier DNS-Einträge schützen alle, die eine Mail bekommen, die angeblich von Ihnen stammt, und alle, die darauf vertrauen, dass Ihr Domainname zu Ihrem Server führt.
01 Warum das zählt
Ihre Domain ist eine Identität, die sich jeder ausleihen kann
Im Mailprotokoll hindert nichts einen Fremden daran, Ihre Domain in das Absenderfeld zu schreiben. Ohne veröffentlichte Richtlinie kann ein empfangender Server Ihre Rechnung nicht von einer gefälschten unterscheiden, und beim Empfänger steht in beiden Fällen Ihr Name. Genau so funktioniert Lieferantenbetrug: eine Nachricht, die von einem Unternehmen zu kommen scheint, dem jemand ohnehin vertraut, mit der Bitte um eine geänderte Bankverbindung.
DNSSEC deckt die Schicht darunter ab. Es signiert Ihre DNS-Antworten, sodass ein Resolver nachweisen kann, dass die Adresse für Ihre Domain tatsächlich die von Ihnen veröffentlichte ist und nicht unterwegs untergeschoben wurde. Die Mail-Authentifizierung sagt der Welt, wer in Ihrem Namen schreiben darf; DNSSEC sorgt dafür, dass die Abfrage, die Ihre Server findet, nicht still umgeschrieben werden kann.
02 Die Einträge
Vier Einträge, eine Kette
Sie bauen aufeinander auf, und nur der letzte hat Zähne. SPF und DKIM beantworten je eine enge Frage, DMARC macht aus diesen Antworten eine Richtlinie, nach der ein Empfänger handeln kann, und DNSSEC schützt die Abfragen, auf denen die anderen drei beruhen.
SPF
Was er macht. Veröffentlicht die Liste der Server, die für Ihre Domain Mails verschicken dürfen. Ein Empfänger vergleicht den verbindenden Server mit dieser Liste und erhält ein Pass oder ein Fail.
Warum er zählt. Der billigste Eintrag und der, den man am leichtesten unauffällig falsch macht. Schliessen Sie ihn mit -all statt mit ~all ab, sobald Sie sicher sind, dass die Liste vollständig ist, und behalten Sie das Limit von zehn Abfragen im Blick: jedes include kostet eine, und ein Eintrag, der darüber liegt, scheitert komplett, statt schwächer zu werden.
example.com. IN TXT "v=spf1 include:_spf.your-provider.example -all" DKIM
Was er macht. Signiert jede ausgehende Nachricht mit einem privaten Schlüssel und veröffentlicht den passenden öffentlichen Schlüssel im DNS, sodass ein Empfänger prüfen kann, dass Text und Kopfzeilen unterwegs nicht verändert wurden.
Warum er zählt. Anders als SPF übersteht eine DKIM-Signatur das Weiterleiten, und genau das macht DMARC in der Praxis überhaupt brauchbar. Ihr Mailanbieter erzeugt das Schlüsselpaar und gibt Ihnen den Eintrag zum Veröffentlichen; der Selektor im Eintragsnamen erlaubt einen Schlüsselwechsel ohne Lücke.
selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..." DMARC
Was er macht. Sagt Empfängern, was sie mit einer Nachricht tun sollen, die an SPF und DKIM zugleich scheitert, und wohin die Sammelberichte darüber gehen sollen.
Warum er zählt. Das ist der einzige der drei Einträge, der ein Ergebnis ändert. Ohne DMARC-Richtlinie ist eine gescheiterte SPF-Prüfung eine Notiz in einer Kopfzeile, auf die niemand reagiert. Mit p=reject wird eine gefälschte Nachricht abgewiesen, bevor sie ein Postfach erreicht.
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s" DNSSEC
Was er macht. Signiert die Einträge Ihrer Zone, sodass ein validierender Resolver nachweisen kann, dass eine Antwort wirklich von Ihnen kam und unterwegs nicht verändert wurde.
Warum er zählt. Jeder Eintrag darüber hängt davon ab, dass eine DNS-Abfrage ehrlich beantwortet wird. Ohne DNSSEC kann ein Angreifer, der einen Resolver beeinflussen kann, seinen eigenen SPF- oder DKIM-Eintrag ausliefern, und die ganze Kette stimmt ihm zu. Es ist ausserdem der Eintrag, der am häufigsten am Registrar scheitert und nicht am Aufwand.
example.com. IN DS 12345 13 2 49FD46E6C4B45C55D4AC...03 Einführung
Bei p=none anfangen und die Berichte lesen
Die Reihenfolge zählt, und der Fehler ist immer derselbe: p=reject veröffentlichen, bevor man weiß, wer alles in Ihrem Namen Mails verschickt. Newsletter-Werkzeuge, Ticketsysteme, die Rechnungssoftware und der Drucker im Hinterzimmer versenden alle als Ihre Domain, und jedes davon, das Sie vergessen, ist Post, die ab sofort still nicht mehr ankommt. Veröffentlichen Sie zuerst SPF und DKIM, danach einen DMARC-Eintrag mit p=none, der nichts verändert, aber Empfänger um Berichte bittet.
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; pct=100"Geben Sie den Berichten ein paar Wochen, ergänzen Sie die vergessenen Absender und gehen Sie dann auf p=quarantine und schließlich p=reject. Die Sammelberichte kommen als XML und sind von Hand unangenehm zu lesen; jeder der gängigen DMARC-Berichtsdienste macht daraus eine Absenderliste, und mehr brauchen Sie davon nicht.
04 Fragen
Was zur Mail-Authentifizierung gefragt wird
Wir versenden von dieser Domain gar keine Mails. Brauchen wir das trotzdem?
Ja, und bei Ihnen ist es sogar einfacher als bei allen anderen. Eine Domain, die nie Mails verschickt, sollte einen SPF-Eintrag veröffentlichen, der niemanden autorisiert, und einen DMARC-Eintrag mit p=reject. Diese Kombination sagt jedem Empfänger, alles abzuweisen, was angeblich von Ihnen kommt, und das ist für eine reine Website-Domain genau richtig.
Zerschiesst DMARC unseren Newsletter?
Nur, wenn das Newsletter-Werkzeug nie autorisiert wurde. Genau dafür ist die p=none-Phase da: die Berichte nennen jeden Server, der als Sie versendet, auch die, an die sich niemand mehr erinnert. Auf eine strengere Richtlinie gehen Sie erst, wenn die Liste Sie nicht mehr überrascht.
Ist es riskant, DNSSEC einzuschalten?
Das Fehlerbild ist real, aber eng: laufen die Signaturen ab oder passt der DS-Eintrag beim Registrar nicht mehr zu Ihrer Zone, lösen validierende Resolver Ihre Domain gar nicht mehr auf, statt auf den ungesicherten Weg zurückzufallen. Anbieter, die Signierung und Schlüsselwechsel für Sie übernehmen, nehmen fast das ganze Risiko heraus. Was nicht geht, ist einschalten und vergessen, wo die Schlüssel liegen.
Unser Registrar bietet kein DNSSEC an. Was dann?
Dann steht es Ihnen tatsächlich nicht zur Verfügung, und keine Konfiguration auf Ihrer Seite ändert daran etwas: der DS-Eintrag muss vom Registrar in der übergeordneten Zone veröffentlicht werden. Es hilft nur, das DNS zu einem Anbieter zu verlegen, der es unterstützt, oder die Domain umzuziehen. Behandeln Sie es als Einkaufsfrage, nicht als technische.
05 Im Detail
Verwandte Sicherheitsthemen
Mail und DNS sind die Hälfte Ihrer Domain, die kein Browser anzeigt. Diese Ratgeber behandeln die andere Hälfte.
HTTP-Security-Header
Was jeder Response-Header bewirkt, welche Ihre Website senden sollte und wie Sie sie richtig konfigurieren.
Content Security Policy
Der stärkste Schutz gegen Cross-Site-Scripting: welche Direktiven Sie setzen, wie Sie eine Richtlinie im Report-Only-Modus einführen und wie Sie erzwingend werden, ohne Ihre Website zu zerlegen.
HSTS
Strict-Transport-Security erklärt: was max-age, includeSubDomains und preload wirklich bewirken und warum die Preload-Liste eine Entscheidung ist, die Sie nicht schnell zurücknehmen können.
Cookie-Sicherheit
Secure, HttpOnly und SameSite: die Cookie-Attribute, die eine Sitzung vor Skripten und fremden Seiten schützen, samt Einstellungen für einen typischen Stack.
Clickjacking und X-Frame-Options
Wie eine unsichtbare Überlagerung aus einem Besucherklick eine Aktion auf Ihrer Website macht, und die zwei Header, die das verhindern: X-Frame-Options für ältere Clients, frame-ancestors für alles andere.
Referrer-Policy
Welcher Teil Ihrer URLs an fremde Seiten geht, wenn ein Besucher weiterklickt: die fünf Werte, die zählen, was jeder davon preisgibt und welcher der sinnvolle Standard ist.
Permissions-Policy
Kamera, Mikrofon, Standort und Bezahlfunktion für Ihre Website und alle eingebetteten Inhalte abschalten: die Syntax der Positivliste und warum eine nicht genannte Funktion keine abgeschaltete Funktion ist.
security.txt
Die Datei, die Sicherheitsforschern sagt, wohin eine Schwachstelle gemeldet wird. Zwei Pflichtfelder, zehn Minuten Arbeit, und der Unterschied zwischen einer privaten und einer öffentlichen Meldung.
Security-Header überwachen
Ein Header, der heute stimmt, kann nach dem nächsten Deploy fehlen. Drei Wege, das zu bemerken: ein Cronjob mit curl, eine Prüfung in Ihrer CI-Pipeline und ein geplanter Scan, jeweils mit dem, was er findet und was nicht.
CSP-Änderungen erkennen
Wie sich eine Richtlinie durch Deploys, Plugins und CDN-Regeln unbemerkt ändert und wie Sie es merken: ein Header-Diff, Verstoßmeldungen über report-to und was ein Scan-Vergleich zeigen kann und was nicht.
Weiterlesen
Weitere Ratgeber
Jeder Ratgeber steht für sich, zusammen decken sie ab, worauf unser Scanner schaut. Wählen Sie den, der Ihrer nächsten Frage am nächsten kommt.
Sehen Sie, welche Einträge Ihre Domain veröffentlicht
Unser kostenloser Quickscan liest SPF, DMARC und DNSSEC Ihrer Domain zusammen mit Ihren Security-Headern aus und erklärt jeden Befund verständlich.