Website & E-Mail absichern: Welche Maßnahmen Unternehmen wirklich einordnen sollten

Website & E-Mail absichern Ratgeber · Stand: 24. September 2026 · Nena Celeste UG

Eine Unternehmenswebsite und die dazugehörige E-Mail-Domain sind Teil des täglichen Betriebs. Kunden schicken Anfragen, Mitarbeiter versenden Angebote und Rechnungen, Interessenten buchen Termine. Technische Einstellungen sollen diese Abläufe unterstützen und vermeidbare Risiken begrenzen.

Die Schwierigkeit beginnt oft beim Prüfbericht. Dort stehen Begriffe wie HSTS, SPF, DKIM oder DNSSEC. Für einen Betrieb ist aber zunächst eine andere Frage entscheidend: Was bedeutet dieser Befund für uns, und was sollte als Nächstes passieren?

Website- und E-Mail-Sicherheit entsteht aus mehreren zusammenwirkenden Maßnahmen. Dazu gehören verschlüsselte Verbindungen, gepflegte Systeme, abgesicherte Zugänge, überprüfbare E-Mail-Absender und ein funktionierender Wiederherstellungsprozess. Kein einzelner Eintrag macht ein Unternehmen unangreifbar. Umgekehrt ist nicht jede fehlende Zusatzfunktion automatisch eine konkrete Sicherheitslücke.

Dieser Leitfaden erklärt die wichtigsten öffentlich prüfbaren Einstellungen und zeigt, welche Informationen zusätzlich aus dem Betrieb benötigt werden. Die Beispiele sind allgemeine technische Erläuterungen und keine Diagnose Ihrer eigenen Systeme.

Die wichtigsten Schutzmaßnahmen im Überblick

1. Erst die Systeme erfassen, dann Einstellungen ändern

Bevor jemand DNS-Einträge verschärft oder Serverregeln ergänzt, braucht es eine Übersicht. Wer verwaltet die Domain? Wo liegt die Website? Wer betreibt die Postfächer? Welche zusätzlichen Programme verschicken Nachrichten im Namen des Unternehmens?

Gerade beim E-Mail-Versand ist die Antwort oft länger als erwartet. Neben dem normalen Postfach senden vielleicht ein Rechnungsprogramm, ein Newsletterdienst, die Website und ein Buchungssystem. Ein Mitarbeiter hat außerdem einen älteren Dienst im Einsatz, der in keiner aktuellen Dokumentation steht.

Diese Übersicht ist die Grundlage für eine sichere Änderung. Eine Regel, die nur den bekannten Hauptanbieter erlaubt, kann Nachrichten eines legitimen Nebenanbieters behindern. Die Technik muss zum tatsächlichen Betrieb passen.

Erfassen Sie für jedes System einen fachlichen Verantwortlichen und einen technischen Ansprechpartner. Notieren Sie auch, über welchen Zugang Änderungen vorgenommen werden und wer diesen Zugang bei einem Dienstleisterwechsel zurückfordern kann. Fehlende Zuständigkeit ist oft das erste Hindernis bei einer Störung.

2. HTTPS: Verschlüsselung der Website-Verbindung

HTTPS nutzt TLS, um die Verbindung zwischen Browser und Server zu schützen. Dabei spielt das Zertifikat eine wichtige Rolle: Der Browser prüft unter anderem, ob es zur aufgerufenen Domain passt und vertrauenswürdig ausgestellt wurde.

Ein technischer Check kann feststellen, ob die geprüfte Website HTTPS anbietet, ob HTTP-Aufrufe weitergeleitet werden und ob das Zertifikat zum Prüfzeitpunkt gültig ist. Auch unterstützte TLS-Versionen lassen sich untersuchen. Die OWASP-Empfehlungen zu TLS bieten dafür eine technische Grundlage.

Ein gültiges Zertifikat ist dennoch kein Gütesiegel für den gesamten Betrieb. Eine verschlüsselte Verbindung kann zu einer fehlerhaften Anwendung oder einer betrügerischen Website führen. HTTPS schützt den Transport; die Sicherheit von Konten, Software und Geschäftsprozessen bleibt eine eigene Aufgabe.

Was im laufenden Betrieb geprüft werden sollte

Zur Betreuung gehören die Erneuerung des Zertifikats, die Erreichbarkeit relevanter Subdomains und die Kontrolle eingebetteter Inhalte. Wenn ein wichtiges Formular auf einer anderen Subdomain liegt, sollte es ausdrücklich in den Prüfplan aufgenommen werden.

Ein erfolgreicher Test der Startseite reicht außerdem nicht als Aussage über alle Downloads, Portale und externen Buchungsstrecken. Der Bericht sollte den Umfang nennen, damit aus einem guten Einzelergebnis kein unbelegtes Gesamturteil wird.

3. Sicherheits-Header: Zusätzliche Regeln für den Browser

HTTP-Header werden zusammen mit einer Serverantwort übertragen. Einige davon geben dem Browser Vorgaben für den Umgang mit der Seite. Das OWASP Secure Headers Project beschreibt solche Schutzmöglichkeiten.

Die entscheidende Frage lautet nicht, wie viele Header ein Testwerkzeug zählt. Entscheidend ist, welche Regeln für die konkrete Anwendung sinnvoll sind und ob sie richtig wirken.

Häufig relevante Header einfach erklärt

Nicht jede Funktion braucht alle denkbaren Richtlinien. Einige ältere Header sind überholt oder sollten gerade nicht pauschal aktiviert werden. Die OWASP-Übersicht zu HTTP-Headern erläutert auch solche Unterschiede.

Warum ein pauschales Einfügen schaden kann

Eine Website kann Schriftdateien, Zahlungsfunktionen, Karten und Formulare aus unterschiedlichen Quellen verwenden. Werden Regeln ohne Bestandsaufnahme verschärft, kann eine benötigte Funktion ausfallen.

Planen Sie deshalb einen Test der tatsächlichen Abläufe: Navigation, Suche, Kontakt, Buchung und gegebenenfalls Zahlung. Bei geeigneten Richtlinien kann zunächst eine beobachtende Einführung sinnvoll sein. Erst wenn die Ergebnisse verstanden sind, wird verbindlich eingeschränkt.

Auch HSTS verdient einen geplanten Rollout. Einstellungen für sämtliche Subdomains oder eine Aufnahme in Vorladelisten haben weitergehende Folgen und sollten nicht als beiläufiger Zusatz aktiviert werden.

4. Was ein fehlender Header tatsächlich aussagt

Die Formulierung „In der geprüften Antwort wurde kein entsprechender Header festgestellt“ ist eine Beobachtung. „Die Website ist unsicher“ ist eine erheblich weitergehende Bewertung.

Für eine belastbare Einordnung sind zusätzliche Fragen nötig: Wurde eine normale Inhaltsseite oder nur eine Weiterleitung geprüft? Gibt es unterschiedliche Einstellungen für Unterseiten? Wird die betreffende Schutzwirkung bereits auf andere Weise erreicht? Welche Funktion soll überhaupt abgesichert werden?

Ein Prüfbericht sollte diese Unsicherheit sichtbar lassen. Das hilft bei der Priorisierung. Eine dokumentierte ausnutzbare Schwachstelle und eine nicht aktivierte zusätzliche Schutzoption gehören nicht automatisch in dieselbe Dringlichkeitsstufe.

5. E-Mail-Absenderschutz: Warum drei Verfahren zusammenwirken

Eine Nachricht kann einen bekannten Firmennamen anzeigen, ohne tatsächlich aus einem autorisierten System dieses Unternehmens zu stammen. Verfahren zur Absenderauthentifizierung helfen empfangenden Systemen, Nachrichten technisch zu bewerten.

SPF, DKIM und DMARC erfüllen unterschiedliche Aufgaben. Sie schützen nicht das Gleiche und ersetzen einander nicht vollständig. Wer seine E-Mail-Domain absichern möchte, sollte deshalb den gesamten Versand betrachten.

SPF: Welche Server dürfen senden?

SPF steht für Sender Policy Framework. Ein DNS-Eintrag beschreibt, welche Systeme für die betreffende Domain E-Mails versenden dürfen. Die technische Prüfung bezieht sich insbesondere auf die beim Transport verwendete Absenderidentität; diese muss nicht mit der im Mailprogramm sichtbaren Von-Adresse identisch sein. Grundlage ist RFC 7208.

Praktisch bedeutet das: Zuerst werden alle legitimen Versandquellen erfasst. Danach wird geprüft, ob die bestehende Konfiguration diese Quellen richtig abbildet. Mehrere separate SPF-Regeln an derselben Stelle oder zu komplexe Abfragen können Probleme verursachen.

SPF ist außerdem keine Inhaltsprüfung. Ein technisch zugelassener Versandserver kann eine unerwünschte Nachricht versenden, etwa wenn ein berechtigtes Konto missbraucht wird.

DKIM: Eine überprüfbare Signatur

DKIM steht für DomainKeys Identified Mail. Das sendende System versieht Nachrichten mit einer Signatur. Empfangende Systeme können über den dazugehörigen öffentlichen Schlüssel prüfen, ob die signierten Bestandteile zur Signatur passen. Die technische Grundlage beschreibt RFC 6376.

Bei einer Prüfung von außen ist eine wichtige Einschränkung zu beachten: DKIM verwendet sogenannte Selektoren. Ohne Kenntnis des tatsächlich eingesetzten Selektors oder eine geeignete Beispielnachricht lässt sich die Konfiguration oft nicht abschließend beurteilen.

Aus „Bei der Stichprobe kein passender Eintrag gefunden“ folgt daher nicht zuverlässig „DKIM wird nicht verwendet“. Für die weitere Prüfung sind Nachrichten aus den echten Versandsystemen hilfreich.

DMARC: Bezug zur sichtbaren Absenderdomain

DMARC verbindet die Ergebnisse von SPF und DKIM mit einem Abgleich zur Domain der sichtbaren Von-Adresse. Für ein Bestehen genügt grundsätzlich ein erfolgreiches, passend ausgerichtetes SPF- oder DKIM-Ergebnis. Zusätzlich veröffentlicht der Domaininhaber eine gewünschte Behandlung für Nachrichten, die die Prüfung nicht bestehen. Die grundlegende Funktionsweise ist in RFC 7489 beschrieben.

Die häufig genannten Richtlinien reichen von Beobachtung über eine gewünschte Quarantäne bis zur gewünschten Ablehnung. Die endgültige Behandlung liegt beim empfangenden System. DMARC-Berichte können helfen, Versandquellen und Fehler zu erkennen.

Auch bei strenger Einstellung bleiben Angriffe möglich: über ähnlich geschriebene Domains, irreführende Anzeigenamen oder kompromittierte echte Konten. DMARC ist deshalb ein wichtiger Baustein, aber keine Garantie gegen Phishing.

6. DMARC schrittweise einführen

Ein sinnvoller Ablauf beginnt mit dem Inventar der Versandsysteme. Danach werden repräsentative Testnachrichten geprüft. Dazu gehören normale Korrespondenz, Rechnungen, Formularantworten, Newsletter und weitere tatsächlich genutzte Versandwege.

In einer Beobachtungsphase wird untersucht, welche Systeme unter der Domain auftreten und welche Prüfungen bestehen. Auffälligkeiten werden den zuständigen Anbietern zugeordnet. Erst danach wird entschieden, wie weit die Richtlinie verschärft werden kann.

Beispiel: Ein vergessenes Buchungssystem

Ein fiktiver Betrieb verschickt seine tägliche Post über einen großen Mailanbieter. Zusätzlich sendet ein Buchungsdienst automatische Terminbestätigungen. Die normale Post ist korrekt eingerichtet, der Buchungsdienst jedoch nicht.

Wird die Domain sofort auf eine strengere Behandlung umgestellt, können ausgerechnet die Terminbestätigungen betroffen sein. Die passende Maßnahme ist deshalb nicht, Schutz dauerhaft auszuschalten. Zuerst wird der zusätzliche Versandweg korrekt eingerichtet und getestet.

Für die Abnahme genügt nicht allein ein grüner DNS-Test. Entscheidend ist, ob die vereinbarten realen Versandwege nach der Änderung funktionieren und die gewünschten Authentifizierungsergebnisse liefern.

7. CAA: Welche Stellen dürfen Zertifikate ausstellen?

CAA steht für Certification Authority Authorization. Mit entsprechenden DNS-Einträgen kann ein Domaininhaber festlegen, welche Zertifizierungsstellen Zertifikate für seine Domain ausstellen dürfen. Das Verfahren ist in RFC 8659 beschrieben.

CAA betrifft die Zertifikatsausstellung. Die Aussage, CAA sichere allgemein die E-Mail-Zustellung ab, wäre zu ungenau. Auch verhindert der Eintrag nicht sämtliche Formen eines Zertifikatsmissbrauchs.

Vor einer Änderung muss geklärt werden, welche Stellen der Hostinganbieter, ein vorgeschalteter Dienst oder andere berechtigte Systeme tatsächlich verwenden. Sonst kann eine gut gemeinte Einschränkung die nächste Zertifikatserneuerung behindern.

Ein fehlender CAA-Eintrag ist deshalb ein Anlass, diese zusätzliche Schutzmöglichkeit zu bewerten. Er ist für sich genommen kein Nachweis eines laufenden Angriffs.

8. DNSSEC: DNS-Antworten überprüfbar machen

DNS übersetzt beispielsweise einen Domainnamen in die für den Verbindungsaufbau benötigten Informationen. DNSSEC ergänzt kryptografische Nachweise, mit denen entsprechend prüfende Systeme die Herkunft und Unverändertheit von DNS-Daten kontrollieren können. Die Grundlagen beschreibt RFC 4033.

DNSSEC verschlüsselt den Inhalt einer Website oder E-Mail nicht. Es ersetzt weder TLS noch Maßnahmen gegen den Missbrauch von Postfächern. Auch eine korrekt signierte DNS-Antwort sagt nicht, ob der dahinterliegende Webserver eine fehlerfreie Anwendung betreibt.

Die Einführung erfordert abgestimmte Einstellungen beim DNS-Anbieter und bei der übergeordneten Registrierung. Besonders bei einem Anbieterwechsel müssen diese Zusammenhänge beachtet werden.

Für den Betrieb ist daher eine verständliche Dokumentation wichtig: Wer verwaltet die Signierung, wer überwacht Fehler und wer ist bei einem Umzug zuständig? Eine zusätzliche Schutzfunktion sollte mit einem verlässlichen Betriebsprozess verbunden sein.

9. Zugänge absichern: Die öffentlich unsichtbare Seite

Ein äußerer Scan kann nicht zuverlässig zeigen, ob Administratoren Passwörter teilen, ehemalige Dienstleister noch Zugriff haben oder eine Mehrfaktor-Anmeldung eingerichtet ist. Trotzdem sind genau solche Fragen für den Alltag wichtig.

Die OWASP-Empfehlungen zur Authentifizierung behandeln unter anderem sichere Anmeldeverfahren und zusätzliche Faktoren. Für Unternehmen ist vor allem eine umsetzbare Kontenorganisation erforderlich.

Jede zuständige Person sollte einen nachvollziehbaren eigenen Zugang erhalten. Rechte werden nach Aufgabe vergeben. Ein Redakteur benötigt möglicherweise keine Kontrolle über Domain und Postfächer. Externe Dienstleister sollten nur den Zugang bekommen, den der konkrete Auftrag erfordert.

Ebenso wichtig ist der Entzug: Wer entfernt Zugänge nach Projektende? Wo sind Wiederherstellungsmöglichkeiten hinterlegt? Können Sie den Anbieter wechseln, ohne von einer einzelnen Privatadresse abhängig zu sein?

Diese Fragen lassen sich in einer kurzen Übergabeliste festhalten. Sie verhindern nicht jeden Vorfall, schaffen aber klare Handlungsfähigkeit.

10. Wartung und Wiederherstellung gehören in den Auftrag

Eine Website besteht oft aus mehreren wartungsbedürftigen Komponenten. Im Angebot sollte erkennbar sein, wer für welche Bestandteile zuständig ist. „Hosting inklusive“ beantwortet noch nicht, wer Erweiterungen prüft oder nach einer fehlgeschlagenen Aktualisierung eingreift.

Vereinbaren Sie deshalb, welche Systeme betreut werden, wie Änderungen dokumentiert werden und wie mit Funktionsproblemen umgegangen wird. Auch die Abgrenzung ist wichtig: Ein Webdienstleister verwaltet möglicherweise nicht das Rechnungsprogramm oder den E-Mail-Anbieter.

Eine Sicherung braucht einen getesteten Rückweg

Die praktische Frage lautet: Können wir die vereinbarten Daten und Funktionen aus einer Sicherung tatsächlich wiederherstellen? Ein gespeichertes Archiv ist nur dann hilfreich, wenn es vollständig, erreichbar und verwendbar ist.

Für einen Wiederherstellungstest werden Ziel und Umfang vereinbart. Dazu kann gehören, eine Kopie der Website in einer geeigneten Testumgebung wieder einzuspielen und zentrale Funktionen zu prüfen. Ergebnisse und offene Punkte werden dokumentiert.

Der Betrieb sollte außerdem wissen, welchen Datenstand eine Sicherung abdeckt. Wenn zwischen zwei Sicherungen neue Bestellungen eingehen, müssen diese Abläufe bei der Wiederaufnahme berücksichtigt werden. Eine pauschale Aussage wie „Backups vorhanden“ erklärt das nicht.

11. Barrierefreiheit im technischen Report richtig einordnen

Lesbarkeit und Bedienbarkeit passen zu einem allgemeinen Qualitätscheck. Sie sind aber nicht dasselbe wie IT-Sicherheit. Ein Link ohne verständlichen Namen ist zunächst eine Nutzungshürde, kein Beweis einer ausnutzbaren Sicherheitslücke.

Für die Bearbeitung sollten solche Punkte eine eigene Kennzeichnung erhalten. Beispiele sind fehlende Formularbeschriftungen, unzureichende Kontraste oder eine nicht per Tastatur erreichbare Schaltfläche.

Automatische Tests decken nur einen Teil der Anforderungen ab. Die W3C Web Accessibility Initiative betont die Bedeutung ergänzender menschlicher Bewertung. Ob gesetzliche Pflichten bestehen, ist gesondert anhand des Angebots zu prüfen.

Praktisch lässt sich die Bearbeitung dennoch verbinden: Wenn ein Formular ohnehin erneuert wird, können Zugangsschutz, verständliche Fehlermeldungen und Tastaturbedienung gemeinsam in die Abnahme aufgenommen werden.

12. So wird aus einem Scan ein Arbeitsplan

Ein technischer Report ist besonders hilfreich, wenn er für jeden Befund vier Dinge nennt: beobachteter Zustand, Prüfgrenze, nächste Untersuchung und mögliche Maßnahme.

Priorität ergibt sich aus konkreter Auswirkung, Eintrittsmöglichkeiten und betroffenen Abläufen. Ein ausgefallenes Kontaktformular kann betrieblich dringender sein als eine zusätzliche DNS-Option. Ein bestätigter unbefugter Zugriff verlangt wiederum eine andere Reaktion als eine gewöhnliche Konfigurationsfrage.

Vereinbaren Sie Änderungen in nachvollziehbaren Schritten. Für jeden Schritt werden Umfang, Sicherung, Funktionsprüfung und Ergebnis festgehalten. So lässt sich später erkennen, was tatsächlich erledigt wurde.

Häufige Fragen zur Website- und E-Mail-Sicherheit

Bedeutet HTTPS, dass meine Website sicher ist?

HTTPS schützt die Verbindung. Daraus folgt keine vollständige Aussage über Software, Benutzerkonten oder Inhalte. Für diese Bereiche sind eigene Prüfungen erforderlich.

Sind fehlende Sicherheits-Header automatisch ein Rechtsverstoß?

Nein. Eine solche Schlussfolgerung lässt sich aus einem isolierten technischen Befund nicht ziehen. Anforderungen hängen unter anderem von Verarbeitung, Risiken und konkreter Systemgestaltung ab. Die rechtliche Bewertung ist von der technischen Beobachtung zu trennen.

Reicht ein SPF-Eintrag gegen gefälschte E-Mails?

SPF erfüllt nur eine Teilaufgabe. Für den Bezug zur sichtbaren Absenderdomain sind insbesondere die Zusammenarbeit mit DKIM und DMARC sowie die korrekte Konfiguration der Versanddienste wichtig.

Warum kann DKIM von außen nicht immer geprüft werden?

Die Prüfung benötigt den passenden Selektor. Er lässt sich häufig aus einer signierten Beispielnachricht oder den Anbieterangaben entnehmen. Eine Suche ohne diese Information kann unvollständig bleiben.

Sollte DMARC sofort auf die strengste Einstellung gesetzt werden?

Erst müssen die legitimen Versandwege bekannt und korrekt eingerichtet sein. Ein schrittweises Vorgehen hilft, unerwünschte Auswirkungen auf betriebliche Nachrichten zu erkennen.

Garantiert DMARC, dass meine E-Mails im Posteingang ankommen?

Nein. Zustellung hängt von weiteren Faktoren und den Entscheidungen des Empfängersystems ab. Authentifizierung ist keine Posteingangsgarantie.

Ist ein äußerer Scan ein Penetrationstest?

Nein. Die Auswertung öffentlich sichtbarer Einstellungen ist etwas anderes als eine aktive Sicherheitsprüfung auf ausnutzbare Schwachstellen. Weitergehende Tests benötigen eine ausdrückliche Freigabe und einen klar vereinbarten Umfang.

Kann ein Dienstleister absolute Sicherheit versprechen?

Ein solcher pauschaler Anspruch wäre fachlich nicht belastbar. Vereinbarbar sind konkrete Maßnahmen, Prüfungen und Dokumentation innerhalb eines beschriebenen Umfangs.

Quellen und redaktioneller Stand

Stand dieses Beitrags: 24. September 2026. Verlinkt sind technische Spezifikationen, OWASP-Dokumentation und W3C-Informationen. Die RFC-Verweise erläutern die beschriebenen Grundlagen; bei einer konkreten Implementierung sind zusätzlich aktuelle Änderungen, Anbieteranforderungen und die jeweilige Systemumgebung zu berücksichtigen.