Ihre Domain muss bis zum 25. Oktober 2026 verlängert werden. Läuft sie aus, funktionieren Ihre Website und E-Mail nicht mehr und jemand anderes kann den Namen kaufen. Ohne Transfersperre kann jemand, der in Ihr Registrar-Konto gelangt oder Ihren Registrar täuscht, Ihre Domain leichter zu einem anderen Anbieter verschieben.
Was wir festgestellt haben: Verlängerung fällig am 25. Oktober 2026 · keine Transfersperre · Registrar: OVH SAS
Wer es beheben kann: Kontoinhaber bei der Registrierungsstelle
SPF listet die Dienste auf, die E-Mails für Ihre Domain versenden dürfen. Ohne SPF oder mit mehreren widersprüchlichen SPF-Einträgen können Kriminelle leichter E-Mails in Ihrem Namen versenden, und Ihre echten E-Mails landen eher im Spam.
Was wir festgestellt haben: Ihre Domain empfängt E-Mails, veröffentlicht aber keinen SPF-Eintrag, sodass jeder leichter E-Mails versenden kann, die angeblich von Ihnen stammen.
Wer es beheben kann: Ihr E-Mail-Administrator und wer Ihr DNS verwaltet · hier erkannt: Google Workspace (E-Mail), Cloudflare (DNS)
Ohne HSTS versuchen die Browser Ihrer Besucher womöglich zuerst die unverschlüsselte Version Ihrer Website, die in gemeinsam genutzten Netzen wie öffentlichen WLANs abgefangen werden kann.
Was wir festgestellt haben: Ihre Website sendet diese Schutzeinstellung (HTTP-Header) nicht an Browser.
Wer es beheben kann: Ihr Webhoster oder Webentwickler · hier erkannt: Cloudflare (Website), WordPress (Website)
Sicherheitsbericht für Ihre Bäckerei: Sofortige Maßnahmen zur Sicherung Ihrer Internetadresse und E-Mails.
Gemini 3.8 FlashAngepasst an Ihre Antwort „Ich bin kein Technikprofi“
Erhöhtes Risiko
Ihre Website und Ihre E-Mail-Dienste stehen auf einer soliden Basis, erfordern jedoch bei der Domain-Verlängerung und beim Absenderschutz sofortige Aufmerksamkeit. Besonders dringlich ist die Verlängerung Ihrer Internetadresse, da diese in 24 Tagen abläuft und bei Versäumnis zum Ausfall Ihres gesamten Online-Auftritts führen würde. Zusätzlich sollten Sie das Website-System auf den neuesten Stand bringen und Ihre geschäftliche E-Mail-Adresse vor Missbrauch durch Fälscher absichern. Mit wenigen gezielten Schritten gemeinsam mit Ihren Dienstleistern schützen Sie Ihren guten Ruf und die Daten Ihrer Kundschaft wirksam.
Vom Agenten erkundete Seiten Ihrer Website: 5
https://bakery.example/200
https://bakery.example/my-account/200
https://bakery.example/order/200
https://bakery.example/contact/200
https://bakery.example/privacy-policy/200
Anfragen gekennzeichnet als FmindCyber, nur lesend, beschränkt auf Ihre Domain und auf von ihr verlinkte Seiten: keine Anmeldung, kein Absenden von Formularen und keine erratenen Pfade.
Ihr Maßnahmenplan
Jetzt erledigenEin paar Minuten · Sie selbst bei Ihrem Domain-Registrar OVH SASKostenpflichtiger Dienst
Internetadresse sofort verlängern und vor unbefugtem Umzug sperren
Ihre Internetadresse läuft in 24 Tagen ab. Wenn die Registrierung nicht rechtzeitig verlängert wird, sind Ihre Website und Ihre E-Mail-Postfächer sofort nicht mehr erreichbar, und Fremde könnten Ihren bekannten Firmennamen dauerhaft übernehmen. Eine zusätzliche Transfersperre verhindert, dass Unbefugte Ihre Adresse zu einem anderen Anbieter übertragen.
So gehen Sie vor
Melden Sie sich umgehend im Kundenbereich Ihres Domain-Anbieters OVH SAS an.
Prüfen Sie unter Ihren Domains den Status von bakery.example und verlängern Sie die Registrierung sofort um mindestens ein Jahr.
Hinterlegen Sie ein gültiges Zahlungsmittel für die automatische Verlängerung, damit die Domain künftig nicht unbemerkt ausläuft.
Aktivieren Sie im selben Menü die Transfersperre (auch als Registrar-Lock oder Transferschutz bezeichnet).
Richten Sie unter den Kontoeinstellungen von OVH SAS die Zwei-Faktor-Authentifizierung für Ihren Zugang ein.
Prüfen, ob es funktioniert hat: Prüfen Sie im Kundenbereich von OVH SAS, dass das neue Ablaufdatum im Jahr 2027 liegt und der Transferschutz als aktiv markiert ist.
Nächster Schritt, sobald dies funktioniert: Kontrollieren Sie jährlich vor Ablauf, ob Ihre hinterlegte Zahlungskarte noch gültig ist.
Jetzt erledigenEin paar Stunden · Ihr Webentwickler oder Sie selbst im WordPress-DashboardMeist im Angebot Ihres Anbieters enthalten
Website-System und Erweiterungen aktualisieren sowie Zugänge schützen
Auf Ihrer Website läuft eine ältere Version des Redaktionssystems mit bekannten Schwachstellen. Kriminelle suchen im Internet automatisiert nach solchen Sicherheitslücken, um Schadcode einzuschleusen, Bestellungen abzugreifen oder die Website unbemerkt zu verändern. Durch regelmäßige Aktualisierungen und eine doppelte Bestätigung beim Anmelden schützen Sie Ihre Kundendaten und Ihr Geschäft wirksam.
So gehen Sie vor
Erstellen Sie vorab ein vollständiges Backup Ihrer Website und der Datenbank.
Melden Sie sich im Administrationsbereich von WordPress an und öffnen Sie den Bereich Dashboard → Aktualisierungen.
Aktualisieren Sie WordPress auf die neueste Hauptversion und bringen Sie alle installierten Erweiterungen sowie das Astra-Theme auf den aktuellen Stand.
Schalten Sie im selben Menü die automatischen Hintergrund-Aktualisierungen für WordPress und Erweiterungen ein.
Aktivieren Sie die Zwei-Faktor-Authentifizierung für alle Benutzerkonten mit Administratorrechten.
Löschen Sie nicht mehr genutzte Themes und Erweiterungen vollständig vom Webserver.
Einstellungen → Allgemein: WordPress-Adresse und Website-Adresse auf https:// prüfen
Dashboard → Aktualisierungen: Automatische Updates für alle Plugins und Themes aktivieren
Prüfen, ob es funktioniert hat: Rufen Sie Dashboard → Aktualisierungen auf und stellen Sie sicher, dass keine ausstehenden Updates mehr gemeldet werden.
Nächster Schritt, sobald dies funktioniert: Prüfen Sie monatlich im Administrationsbereich, ob alle installierten Komponenten aktuell sind und Backups fehlerfrei erstellt werden.
Bald erledigenEin paar Stunden · Wer Ihr DNS verwaltet, gemeinsam mit Ihrem E-Mail-AdministratorMeist im Angebot Ihres Anbieters enthalten
Absenderschutz für geschäftliche E-Mails vollständig einrichten
Bisher fehlt Ihrer Internetadresse ein vollständiger Schutzmechanismus, der fremden Empfängern beweist, welche Server in Ihrem Namen Nachrichten versenden dürfen. Kriminelle können daher leicht gefälschte Rechnungen oder Nachrichten mit Ihrer Absenderadresse verschicken, um Kunden und Geschäftspartner zu täuschen. Zudem landen Ihre echten Nachrichten ohne diesen Nachweis häufiger im Spam-Ordner.
So gehen Sie vor
Bitten Sie Ihren DNS-Verwalter, einen TXT-Eintrag für SPF auf bakery.example mit der Freigabe für Google Workspace einzutragen.
Prüfen Sie in der Google Admin-Konsole unter Apps → Google Workspace → Gmail → E-Mail-Authentifizierung, dass die digitale Signatur (DKIM) für Ihre Domain aktiv ist.
Lassen Sie auf der Subdomain _dmarc.bakery.example einen DMARC-Eintrag mit einer überwachten E-Mail-Adresse für Berichte anlegen.
Aktivieren Sie in der Google Admin-Konsole die Zwei-Schritt-Verifizierung für alle geschäftlichen E-Mail-Konten.
TXT auf bakery.example:
v=spf1 include:_spf.google.com ~all
TXT auf _dmarc.bakery.example:
v=DMARC1; p=none; rua=mailto:dmarc-reports@bakery.example
Prüfen, ob es funktioniert hat: Senden Sie eine Test-E-Mail von Ihrem geschäftlichen Postfach an einen externen Anbieter und prüfen Sie im E-Mail-Kopf, dass SPF und DKIM erfolgreich bestanden wurden.
Nächster Schritt, sobald dies funktioniert: Werten Sie nach einigen Wochen die DMARC-Berichte aus und verschärfen Sie die Richtlinie von p=none schrittweise auf p=quarantine und p=reject.
Bald erledigenEin paar Stunden · Wer Ihr Cloudflare-Konto verwaltetKostenlos
Verschlüsselung dauerhaft erzwingen und Schutz vor unsichtbarem Einbetten aktivieren
Browser Ihrer Besucher sollten automatisch und ausnahmslos auf die verschlüsselte Verbindung geleitet werden, damit Daten unterwegs nicht mitgelesen werden können. Zudem schützt eine Absicherung davor, dass fremde Websites Ihre Seiten unsichtbar einbetten, um Besucher zu unbemerkten Klicks auf Bestell- oder Bestätigungsknöpfe zu verleiten.
So gehen Sie vor
Melden Sie sich in der Cloudflare-Verwaltung an und wählen Sie Ihre Domain bakery.example aus.
Aktivieren Sie unter SSL/TLS → Edge Certificates die Option Always Use HTTPS.
Aktivieren Sie im selben Menü HTTP Strict Transport Security (HSTS) mit einer anfänglichen Laufzeit von fünf Minuten (max-age=300).
Erstellen Sie unter Rules → Transform Rules eine Regel für Antwort-Header mit dem Header X-Frame-Options und dem Wert SAMEORIGIN.
Prüfen, ob es funktioniert hat: Prüfen Sie bei einem erneuten Sicherheitscheck, dass die Schutz-Header für HSTS und X-Frame-Options ausgeliefert werden und Ihre Website ohne Fehler lädt.
Nächster Schritt, sobald dies funktioniert: Erhöhen Sie die HSTS-Laufzeit nach einem Monat fehlerfreien Betriebs schrittweise auf sechs Monate und schließlich auf ein ganzes Jahr.
Senden Sie dies an die Person, die Ihre Website verwaltet
Guten Tag,
wir haben eine Sicherheitsüberprüfung unserer Website und E-Mail-Infrastruktur für bakery.example durchführen lassen. Dabei wurden einige wichtige Punkte festgestellt, die wir gerne zeitnah mit Ihrer Unterstützung umsetzen möchten.
Bitte prüfen und veranlassen Sie folgende Maßnahmen in der genannten Reihenfolge:
1. Domain-Verlängerung und Transferschutz (Dringend):
Die Registrierung unserer Domain bakery.example bei OVH SAS läuft am 25. Oktober 2026 ab. Bitte stellen Sie sicher, dass die Domain umgehend verlängert wird und die automatische Verlängerung dauerhaft aktiv ist. Bitte aktivieren Sie zudem die Transfersperre (Registrar-Lock) im Kundenbereich.
2. WordPress- und Erweiterungs-Updates:
Auf unserer Website läuft WordPress 6.8 sowie ältere Versionen unserer Erweiterungen (unter anderem WooCommerce, Contact Form 7 und Cookie Notice). Bitte erstellen Sie ein vollständiges Backup und aktualisieren Sie WordPress auf die neueste Version (7.x) sowie alle Plugins und das Astra-Theme. Aktivieren Sie bitte automatische Sicherheitsupdates für WordPress und die Erweiterungen.
3. E-Mail-Absenderschutz (SPF und DMARC):
Wir nutzen Google Workspace für unsere geschäftlichen E-Mails, im öffentlichen DNS fehlt jedoch ein SPF-Eintrag. Bitte hinterlegen Sie folgenden TXT-Eintrag auf der Domain bakery.example:
v=spf1 include:_spf.google.com ~all
Bitte richten Sie außerdem auf _dmarc.bakery.example einen DMARC-Eintrag mit Berichtsfunktion ein:
v=DMARC1; p=none; rua=mailto:dmarc-reports@bakery.example
Nach einer Beobachtungsphase möchten wir diesen Schutz später auf p=quarantine und p=reject umstellen.
4. Web-Sicherheitseinstellungen in Cloudflare:
Bitte aktivieren Sie in unserem Cloudflare-Konto unter SSL/TLS die Option „Always Use HTTPS“ und konfigurieren Sie HSTS für bakery.example zunächst mit einer kurzen Laufzeit von fünf Minuten (max-age=300). Bitte richten Sie zudem über eine Transform Rule den Antwort-Header X-Frame-Options: SAMEORIGIN ein, um Clickjacking zu verhindern.
5. Inhalte und Formulare:
Auf der Startseite ist das Bäckerei-Logo noch über eine unverschlüsselte HTTP-Adresse eingebunden (http://bakery.example/wp-content/uploads/2019/03/logo.png). Bitte stellen Sie diesen Pfad auf HTTPS um.
Können Sie uns kurz bestätigen, sobald diese Punkte umgesetzt oder in Bearbeitung sind?
Vielen Dank für Ihre Unterstützung.
Mit freundlichen Grüßen
[Name]
Mehr aus Ihrer Analyse: Risiken, Beobachtungen des Agenten, Fahrplan und Glossar
Was schiefgehen könnte
Wahrscheinlich
Gefälschte Rechnungen im Namen Ihrer Bäckerei
Kriminelle nutzen aus, dass Ihre Internetadresse bisher nicht wirksam festlegt, welche Server in Ihrem Namen E-Mails versenden dürfen. Sie verschicken täuschend echte E-Mails mit Ihrer Firmenabsenderadresse an Kunden oder Geschäftspartner, beispielsweise mit geänderten Bankdaten für ein geplantes Catering oder eine Großbestellung. Da empfangende Mailserver keine Schutzanweisung haben, solche Nachrichten abzuweisen, landet die Fälschung direkt im Posteingang. Wenn Kunden daraufhin Geld auf fremde Konten überweisen, drohen Ihnen erhebliche Reputationsschäden und Vertrauensverlust.
Wahrscheinlich
Übernahme der Website über veraltete Softwarebausteine
Angreifer suchen im Internet mit automatisierten Programmen nach Websites, die bekannte Schwachstellen in älteren Redaktionssystemen oder Zusatzmodulen aufweisen. Gelingt es ihnen, eine dieser Lücken auszunutzen, können sie eigene Skripte auf Ihrer Website platzieren. Dadurch könnten Kundendaten aus Bestellungen abgegriffen, Formulare manipuliert oder Besucher auf unseriöse Seiten umgeleitet werden. Neben dem Schaden für betroffene Besteller verliert Ihre Bäckerei dadurch das Vertrauen ihrer Kundschaft.
Was dem Agenten auf Ihrer Website aufgefallen ist
Geschäftlicher Kontakt nutzt kostenlose Freemail-AdresseBeobachtet
In der Fußzeile aller Seiten wird als Kontaktadresse ein kostenloses Gmail-Konto angegeben, obwohl für Ihre Domain bereits Google Workspace eingerichtet ist. Eine eigene Adresse wie kontakt@bakery.example wirkt auf Kunden professioneller und stellt sicher, dass geschäftliche Korrespondenz unter der Kontrolle des Unternehmens bleibt.
Analysedienste laden vor Erteilung der BesuchereinwilligungBeobachtet
Auf allen besuchten Seiten wird der Google Tag Manager bereits beim ersten Seitenaufruf im Browser geladen, noch bevor Besucher über das vorhandene Cookie-Banner eine Einwilligung erteilen können. Um rechtliche Anforderungen zu erfüllen, sollte die Einbindung so konfiguriert werden, dass Analyse-Skripte erst nach ausdrücklicher Zustimmung ausgeführt werden; sprechen Sie dies mit Ihrem Datenschutzberater ab.
Dateiupload im Kontaktformular erfordert technische AbsicherungBeobachtet
Auf der Kontaktseite können Besucher Bilddateien hochladen. Da unkontrollierte Dateiuploads ein potenzielles Einfallstor für schädliche Dateien auf dem Webserver darstellen, sollte sichergestellt sein, dass das Formular-Plugin Dateitypen strikt auf sichere Bildformate wie JPEG oder PNG begrenzt und hochgeladene Dateien außerhalb des öffentlich zugänglichen Web-Verzeichnisses speichert.
form action: https://bakery.example/contact/#wpcf7-f42-o1, fields: ["input", "email", "textarea", "file"]https://bakery.example/contact/
Kunden-Anmeldebereich setzt Test-Cookie ohne VerschlüsselungsflagBeobachtet
Beim Aufruf des Kundenbereichs unter /my-account/ wird ein WordPress-Test-Cookie gesetzt, dem die Kennzeichnung für ausschließliche HTTPS-Übertragung fehlt. Da auf dieser Seite Passwörter eingegeben werden, sollten alle dort gesetzten Cookies konsequent mit dem Secure-Attribut ausgeliefert werden, um das Abfangen in Netzwerken zu verhindern.
Ein gültiges Sicherheitszertifikat mit modernem Verschlüsselungsstandard schützt die Verbindungen Ihrer Besucher, und unverschlüsselte Aufrufe werden automatisch auf HTTPS umgeleitet.
Der Schutz vor Dateityp-Verwechslungen (X-Content-Type-Options: nosniff) ist aktiv und verhindert, dass Browser Inhalte fälschlich als ausführbaren Programmcode interpretieren.
Ihre E-Mail-Infrastruktur nutzt bereits professionelle Google-Mailserver mit einem hinterlegten Signaturschlüssel als solide Grundlage für den Absenderschutz.
Ihre Website ist bei Sicherheitsdiensten wie Google Safe Browsing unauffällig und weist keine bekannten Warnungen vor Schadprogrammen auf.
Begriffe in diesem Bericht
DMARC
Ein E-Mail-Sicherheitsverfahren, mit dem Domain-Inhaber festlegen, wie Empfänger mit gefälschten E-Mails umgehen sollen, die unberechtigt ihren Namen tragen.
SPF
Sender Policy Framework; ein Eintrag im Domain-Verzeichnis, der auflistet, welche Server und Dienste berechtigt sind, E-Mails für Ihre Internetadresse zu versenden.
DKIM
DomainKeys Identified Mail; ein Verfahren, bei dem ausgehende E-Mails digital signiert werden, damit Empfänger die Echtheit der Nachricht prüfen können.
HSTS
HTTP Strict Transport Security; eine Einstellung, die Webbrowser anweist, eine Website für einen festgelegten Zeitraum ausschließlich über eine verschlüsselte HTTPS-Verbindung aufzurufen.
Zwei-Faktor-Authentifizierung
Eine zusätzliche Sicherheitsstufe beim Anmelden, die neben dem Passwort einen zweiten Nachweis erfordert, etwa einen Zahlencode auf dem Smartphone.
Transfersperre
Eine Schutzfunktion beim Domain-Registrar, die verhindert, dass eine Internetadresse ohne ausdrückliche Freigabe zu einem anderen Anbieter umgezogen wird.
Clickjacking
Ein Angriff, bei dem eine fremde Seite fremde Webseiten unsichtbar einbettet, um Besucher zu unbeabsichtigten Klicks auf verdeckte Schaltflächen zu verleiten.
Diese Analyse basiert auf einer rein passiven Prüfung von außen sowie dem Besuch öffentlich zugänglicher Seiten Ihres Webauftritts, darunter Ihre Startseite, der Kundenbereich, das Bestell- und das Kontaktformular sowie die Datenschutzerklärung. Wir haben zu keinem Zeitpunkt versucht, Passwörter zu erraten, Formulare abzusenden oder Sicherheitsbarrieren aktiv zu testen. Eine solche Außenansicht kann nicht hinter die Kulissen blicken: Interne Servereinstellungen, Datenbanken, die tatsächliche Sicherheit der Passwörter Ihrer Benutzerkonten oder die Konfiguration Ihres E-Mail-Postfachs können nur von Ihnen selbst oder Ihren zuständigen Administratoren eingesehen werden. Von einem KI-Agenten in einer isolierten Sandbox auf Grundlage der Belege dieses Berichts und der erkundeten Seiten geschrieben; Note und Prüfungen unten stammen aus deterministischen Tests.
Dieses Premium-Beispiel wurde auf Englisch verfasst. Ihre eigene Premium-Analyse wird in Ihrer Sprache geschrieben.
KI-Aktionsplan
Renew your domain urgently, update WordPress, and protect your bakery against email spoofing.
Premium · Gemini 4 ArgonAngepasst an Ihre Antwort „Ich verwalte meine Website über eine Verwaltungsoberfläche“
Erhöhtes Risiko
Golden Crust Bakery (bakery.example) currently earns a C grade (score 65) with an elevated risk level. Your foundation has solid pieces in place: a valid TLSv1.3 HTTPS certificate, automatic redirection from HTTP to HTTPS, x-content-type-options: nosniff protection, CAA records restricting certificate issuance to letsencrypt.org, and Google Workspace MX and candidate DKIM records. However, three urgent issues put your business at immediate risk. First, your domain registration at OVH SAS is due for renewal on October 25, 2026, and has no transfer lock enabled, meaning your website and email could stop working or be transferred away if not renewed and locked today. Second, your website runs WordPress 6.8 (while 7.1.3 is available) and loads an outdated jQuery 1.12.4 library with known security flaws, while your public user sitemap and author page (/author/marie/) expose the administrator username marie. Third, your domain publishes no SPF record and its DMARC policy (p=none) does not block fake emails or send reports to any mailbox, allowing scammers to spoof @bakery.example emails to your catering and online-order customers. Working with Pixel Agency (listed on your legal notice as your website maintainer) and using your OVH, Cloudflare, and Google Workspace dashboards, you can resolve the most urgent domain, WordPress, and email spoofing risks this week and then add browser security headers and cookie protections over the coming month.
Anfragen gekennzeichnet als FmindCyber, nur lesend, beschränkt auf Ihre Domain und auf von ihr verlinkte Seiten: keine Anmeldung, kein Absenden von Formularen und keine erratenen Pfade.
Ihr Maßnahmenplan
Jetzt erledigenEin paar Minuten · Business owner (in your OVH SAS registrar dashboard)Kostenlos
Renew your domain name immediately and turn on the registrar transfer lock
Your domain registration is due for renewal on October 25, 2026, and has no transfer lock enabled. If it expires, both your website and email stop working immediately and someone else can buy your domain name. Without a transfer lock, anyone who gets into your registrar account can move your domain to another provider.
So gehen Sie vor
Sign in to your OVH SAS control panel and open the Domain Names section for bakery.example.
Renew the domain immediately for at least one year, turn on automatic renewal, and confirm that your saved payment method is valid.
In the domain general information tab, enable the domain transfer lock (protection against transfer) and turn on two-step sign-in for your OVH account.
Prüfen, ob es funktioniert hat: Check your OVH domain panel to confirm the new expiration date is in 2027 or later and that transfer protection shows as active.
Nächster Schritt, sobald dies funktioniert: Keep automatic renewal enabled and verify your saved payment card in OVH each year at least 30 days before the renewal date.
Jetzt erledigenEin paar Stunden · Pixel Agency (your web developer) and business owner in WordPress AdminMeist im Angebot Ihres Anbieters enthalten
Update WordPress, plugins, and jQuery, and protect the administrator account
Your website runs WordPress 6.8 (while 7.1.3 is available) and loads jQuery 1.12.4, both of which have publicly known security flaws that automated bots actively target. In addition, your user sitemap and author page reveal the administrator username marie, making password-guessing attacks against your sign-in page much easier.
So gehen Sie vor
Take a full backup of your website files and database through your OVHcloud hosting panel or backup plugin before making changes.
In WordPress, go to Dashboard -> Updates, update WordPress from 6.8 to 7.1.3, update your theme (astra4.6.2) and plugins (woocommerce8.9.1, contact-form-75.9.3, cookie-notice2.4.16), and click Enable auto-updates for all plugins and themes.
Ask Pixel Agency to replace the external https://code.jquery.com/jquery-1.12.4.min.js script with the current version bundled with WordPress, and to hide public version numbers (WordPress 6.8 and ?ver= query strings).
Enable two-step sign-in for the marie administrator account and any staff accounts, change the public display name so it differs from the login username, and restrict public user sitemaps (/wp-sitemap-users-1.xml) and file upload types on /contact/.
Prüfen, ob es funktioniert hat: Check Dashboard -> Updates in WordPress to confirm version 7.1.3 and all plugin updates are installed, confirm jquery-1.12.4.min.js and the WordPress 6.8 generator tag no longer appear on your homepage, and test signing in with two-step verification.
Nächster Schritt, sobald dies funktioniert: Review installed plugins quarterly with Pixel Agency and remove any plugins or themes that are no longer used.
Jetzt erledigenEin paar Stunden · Business owner (in Google Workspace Admin) and DNS manager (in Cloudflare)Kostenlos
Publish an SPF record, confirm DKIM signing, and set up DMARC reporting
Your domain receives email through Google Workspace (smtp.google.com) and publishes a google._domainkey record, but has no SPF record at all and its DMARC policy (v=DMARC1; p=none) neither blocks fake emails nor sends reports to a mailbox. Criminals can spoof @bakery.example to send fake catering invoices to your customers, and genuine emails may land in spam.
So gehen Sie vor
List every service that sends email using @bakery.example, including Google Workspace, your website forms (woocommerce and contact-form-7), and Mailchimp if it sends from your domain.
In Cloudflare, go to DNS -> Records and publish a single TXT record on bakery.example with v=spf1 include:_spf.google.com ~all (adding any other confirmed sending services to that same record).
In the Google Workspace Admin console, go to Apps -> Google Workspace -> Gmail -> Authenticate email, select bakery.example, and confirm that DKIM signing is active for your google._domainkey record.
In Cloudflare (DNS -> Records), update the _dmarc.bakery.exampleTXT record to add a monitored reporting mailbox (rua=mailto:postmaster@bakery.example) while keeping p=none during initial monitoring, and replace goldencrust.bakery@gmail.com on your website footer with an @bakery.example address once ready.
Prüfen, ob es funktioniert hat: Send a test email from a @bakery.example Google Workspace mailbox to an external email address and check the received message headers to confirm spf=pass, dkim=pass, and dmarc=pass.
Nächster Schritt, sobald dies funktioniert: After two to four weeks of clean DMARC reports showing that all legitimate emails pass, update _dmarc.bakery.example from p=none to p=quarantine, and later to p=reject.
Bald erledigenEin paar Stunden · Pixel Agency (your web developer)Meist im Angebot Ihres Anbieters enthalten
Add Secure and HttpOnly cookie protections and fix unencrypted image links
Cookies set on your homepage (wp_lang) and sign-in page (wordpress_test_cookie) lack the Secure flag, allowing them to travel over unencrypted connections, and session cookies without HttpOnly can be stolen by malicious scripts to hijack accounts. In addition, your homepage loads its logo (http://bakery.example/wp-content/uploads/2019/03/logo.png) over unencrypted HTTP.
So gehen Sie vor
In WordPress, go to Settings -> General and confirm both WordPress Address (URL) and Site Address (URL) use https://, then update http://bakery.example/wp-content/uploads/2019/03/logo.png and any other http:// media links to https://.
Ask Pixel Agency to review the cookies set across the site (wp_lang on the homepage and wordpress_test_cookie on /my-account/) and ensure every cookie sets the Secure attribute and all sign-in or session cookies also set HttpOnly.
While reviewing /my-account/, check the WooCommerce endpoint settings (WooCommerce -> Settings -> Advanced) so customers have a working password reset flow.
Prüfen, ob es funktioniert hat: Open https://bakery.example/ and https://bakery.example/my-account/ in a browser, check the developer tools cookie list to confirm Secure (and HttpOnly for session cookies) are enabled, and verify no http:// mixed content warnings appear.
Nächster Schritt, sobald dies funktioniert: Whenever a new plugin is installed, check browser storage tools to ensure any new session cookies include Secure and HttpOnly.
Bald erledigenEin paar Minuten · Pixel Agency or business owner (in Cloudflare dashboard)Kostenlos
Enable HSTS, clickjacking protection, and Permissions-Policy headers in Cloudflare
Without Strict-Transport-Security (HSTS), visitors on public Wi-Fi can have their initial connection intercepted before redirecting to HTTPS. Without X-Frame-Options and Permissions-Policy, other websites can embed your pages in hidden frames to trick customers into clicking buttons (clickjacking), and scripts could request access to camera, microphone, or location features.
So gehen Sie vor
In the Cloudflare dashboard for bakery.example, check SSL/TLS -> Edge Certificates to confirm Always Use HTTPS is enabled and Minimum TLS Version is set to at least TLS 1.2.
Go to Rules -> Overview and create a Response Header Transform Rule matching HTTPS requests for http.host eq "bakery.example" and ssl.
Add three Set static header actions: Strict-Transport-Security with value max-age=300 (a five-minute initial trial), X-Frame-Options with value SAMEORIGIN, and Permissions-Policy with value camera=(), microphone=(), geolocation=().
Match: (http.host eq "bakery.example" and ssl)
Set static: Strict-Transport-Security = max-age=300
Set static: X-Frame-Options = SAMEORIGIN
Set static: Permissions-Policy = camera=(), microphone=(), geolocation=()
Prüfen, ob es funktioniert hat: Load https://bakery.example/ and verify in browser developer tools (Network tab) that Strict-Transport-Security, X-Frame-Options, and Permissions-Policy appear in the response headers and that all pages and the booking frame load normally.
Nächster Schritt, sobald dies funktioniert: Once you confirm all pages and subdomains work over HTTPS without errors, increase Strict-Transport-Security step by step to max-age=15768000 (six months) and then max-age=31536000 (one year).
Bald erledigenEin paar Stunden · Pixel Agency (your web developer) in CloudflareMeist im Angebot Ihres Anbieters enthalten
Deploy a Content Security Policy starting in report-only mode
Your pages load third-party scripts and frames without a Content-Security-Policy header. If a vulnerable plugin or compromised script injects malicious code into your order or sign-in pages, browsers currently have no rule stopping that code from running and stealing customer information.
So gehen Sie vor
Ask Pixel Agency to list every external script, font, style, form action, and frame origin used across your site, including www.googletagmanager.com, booking.example.net, and bakery.us21.list-manage.com.
In Cloudflare (Rules -> Overview), add a Response Header Transform Rule setting Content-Security-Policy-Report-Only first, so browsers report policy violations without blocking anything on the live site.
Test every customer journey—signing in at /my-account/, ordering pick-up items at /order/, sending a message with an image at /contact/, and loading the booking widget on the homepage—before switching to enforcement.
Prüfen, ob es funktioniert hat: Open your homepage, /my-account/, /order/, and /contact/ in a browser, confirm Content-Security-Policy-Report-Only is present in the response headers, and check the browser console to ensure legitimate features work cleanly.
Nächster Schritt, sobald dies funktioniert: After testing all key pages in report-only mode and resolving any legitimate warnings, change the header name from Content-Security-Policy-Report-Only to Content-Security-Policy to enforce the protection.
SpäterEin paar Minuten · Pixel Agency or website managerKostenlos
Publish a security.txt contact file for security researchers
No /.well-known/security.txt file is currently available on your website. If a security researcher or partner finds a problem on your site, they have no standard way to report it directly to your team.
So gehen Sie vor
Set up a monitored email address or alias on your domain (such as security@bakery.example) for receiving security reports.
Ask Pixel Agency to publish a UTF-8 plain-text file at /.well-known/security.txt containing Contact:, Expires: (in RFC 3339 format), and Canonical: lines.
Prüfen, ob es funktioniert hat: Open https://bakery.example/.well-known/security.txt in a browser and confirm it displays the plain-text contact file with a future expiration date.
Nächster Schritt, sobald dies funktioniert: Set a yearly calendar reminder to update the Expires: date before it lapses.
SpäterEin paar Minuten · DNS manager (in Cloudflare) and registrar manager (in OVH SAS)Kostenlos
Inspect and confirm end-to-end DNSSEC validation between Cloudflare and OVH SAS
Public DNS shows a published DS record for bakery.example, which helps prevent attackers from redirecting visitors or email to fake servers, but the passive check does not verify whether the cryptographic chain of trust is valid from end to end.
So gehen Sie vor
Note that this item is unassessed rather than a confirmed defect; inspect the current setup before changing anything, because an incorrect change can make your domain unreachable.
In Cloudflare (DNS -> Settings -> DNSSEC) and your OVH SAS domain control panel, check that the active zone signing key matches the published parent DS record (key tag 2371, algorithm 13).
Ask Pixel Agency or your DNS administrator to run an independent end-to-end DNSSEC chain validation and document a rollback procedure before making any future DNS changes.
Prüfen, ob es funktioniert hat: Confirm in Cloudflare's DNSSEC settings that DNSSEC shows as active and that your DNS administrator confirms end-to-end signature validation.
Nächster Schritt, sobald dies funktioniert: Before any future DNS migration or registrar change, coordinate disabling and re-enabling DNSSEC carefully so your domain stays reachable.
Senden Sie dies an die Person, die Ihre Website verwaltet
Hello Pixel Agency team,
We recently completed a security review of https://bakery.example/ and would like your help applying the following updates, ordered by priority:
1. Domain renewal and transfer lock (urgent - due October 25, 2026)
- Please confirm with us that bakery.example is renewed in the OVH SAS registrar panel, automatic renewal is enabled, and the registrar transfer lock is turned on.
2. WordPress core, plugins, jQuery, and administrator security (urgent)
- Back up the site on OVHcloud, then update WordPress from 6.8 to 7.1.3 and update the astra (4.6.2) theme and all plugins (woocommerce 8.9.1, contact-form-7 5.9.3, cookie-notice 2.4.16), enabling automatic updates.
- Replace the external https://code.jquery.com/jquery-1.12.4.min.js script with the current version bundled with WordPress.
- Remove the public WordPress 6.8 generator tag and ?ver= asset version strings, disable the public users sitemap (/wp-sitemap-users-1.xml), change the public display name for the marie administrator account, and enable two-step sign-in for all administrators.
- Verify that the file upload field on /contact/ strictly restricts allowed image types and file sizes.
3. Email authentication for @bakery.example (high priority)
- Confirm all services that send email from @bakery.example (Google Workspace, WooCommerce/Contact Form 7, and Mailchimp if applicable) and publish a single SPF TXT record on bakery.example, starting from v=spf1 include:_spf.google.com ~all.
- Confirm active DKIM signing for google._domainkey.bakery.example in Google Workspace Admin (Apps -> Google Workspace -> Gmail -> Authenticate email).
- Update _dmarc.bakery.example to include a monitored report address (v=DMARC1; p=none; rua=mailto:postmaster@bakery.example) so we can review reports and move to p=quarantine and p=reject.
4. HTTPS mixed content, cookies, and password reset link (soon)
- Update the unencrypted logo URL (http://bakery.example/wp-content/uploads/2019/03/logo.png) to https:// and verify both URLs under Settings -> General use https://.
- Ensure all cookies (including wp_lang and wordpress_test_cookie) use the Secure attribute and that sign-in/session cookies also use HttpOnly.
- Check the /my-account/lost-password/ endpoint in WooCommerce so customer password resets work properly, and check that Google Tag Manager (G-EXAMPLE) waits for cookie consent.
5. Cloudflare security headers, security.txt, and DNSSEC check (soon / later)
- In Cloudflare (Rules -> Overview), add a Response Header Transform Rule for bakery.example over HTTPS setting Strict-Transport-Security: max-age=300 (to be increased after testing), X-Frame-Options: SAMEORIGIN, and Permissions-Policy: camera=(), microphone=(), geolocation=().
- Prepare and test a Content-Security-Policy-Report-Only header covering self, https://www.googletagmanager.com, https://booking.example.net, and https://bakery.us21.list-manage.com before enforcing it.
- Publish https://bakery.example/.well-known/security.txt as plain text with a monitored contact address and future expiration date, and confirm that the DNSSEC DS record (key tag 2371) at OVH SAS validates end to end with Cloudflare.
Please let me know when Steps 1 through 3 are complete and share the schedule for the remaining items.
Best regards,
[Name]
Mehr aus Ihrer Analyse: Risiken, Beobachtungen des Agenten, Fahrplan und Glossar
Was schiefgehen könnte
Wahrscheinlich
Automated website takeover via outdated WordPress software or exposed admin username
Automated bots constantly scan websites for WordPress 6.8 and jQuery 1.12.4, and read /wp-sitemap-users-1.xml and /author/marie/ to discover that your administrator username is marie. An attacker either exploits a known flaw in the outdated software or runs automated password-guessing attacks against /my-account/ for user marie, gaining control of your store to deface pages or read customer pick-up orders.
Wahrscheinlich
Spoofed catering invoices and payment requests sent in your bakery's name
Because bakery.example publishes no SPF record and its DMARC policy is p=none with no reporting address, a scammer sends emails appearing to come from orders@bakery.example to your wedding-cake or catering customers asking them to wire a deposit to a fraudulent bank account. Receiving mail providers have no rule telling them to block these fake messages, and customers may also be confused because the website footer shows a free @gmail.com address.
Möglich
Injected script stealing customer login sessions or order details
An attacker uses the known flaw in jQuery 1.12.4 or a vulnerable plugin to inject a malicious script into /order/ or /my-account/. Because no Content-Security-Policy header restricts which scripts may run or where they can send data, the script runs in visitors' browsers, reading unprotected cookies or skimming customer names, phone numbers, and passwords as they are typed.
Unwahrscheinlich, aber möglich
Interception of unencrypted requests or cookies on shared public Wi-Fi
A customer or staff member connects to café Wi-Fi and visits bakery.example. Before the browser redirects to HTTPS—or when it requests the unencrypted http:// logo image or sends cookies (wp_lang, wordpress_test_cookie) that lack the Secure flag—someone on the same wireless network intercepts the initial connection or reads the unprotected cookies.
Was dem Agenten auf Ihrer Website aufgefallen ist
Administrator username exposed on author page and user sitemapBeobachtet
Your public user sitemap (/wp-sitemap-users-1.xml) and blog page (/blog/) link to /author/marie/, which publicly displays the administrator's username and role. Giving away the exact administrator login name makes automated password-guessing attacks against /my-account/ much easier.
Posts by Marie (administrator)https://bakery.example/author/marie/
Sign-in page sets an unprotected cookie and links to a missing password reset pageBeobachtet
The customer account page (/my-account/) serves a password login form (method="post") and sets a cookie named wordpress_test_cookie without the Secure or HttpOnly attributes. Its password reset link (/my-account/lost-password/) also points to a page we could not reach.
wordpress_test_cookie (secure: false, httponly: false) and form action https://bakery.example/my-account/ with password fieldhttps://bakery.example/my-account/
Contact form accepts file uploads via Contact Form 7Beobachtet
Your contact page (/contact/) invites customers to upload an inspiration photo using a file input field powered by the contact-form-7 plugin (version 5.9.3). File upload forms need strict checks on allowed image formats and file size so attackers cannot upload malicious scripts or fill up server storage.
Send us a message and your inspiration photo · form action https://bakery.example/contact/#wpcf7-f42-o1 with file fieldhttps://bakery.example/contact/
Google Analytics script loads alongside the cookie consent pluginBeobachtet
Every page loads Google Tag Manager (https://www.googletagmanager.com/gtag/js?id=G-EXAMPLE) immediately alongside the cookie-notice plugin (ver=2.4.16). Loading analytics scripts before a visitor accepts the cookie banner can raise privacy compliance questions that you should check with an advisor.
Public contact address uses a free Gmail account instead of your domainBeobachtet
Even though your domain has Google Workspace mail servers configured, every page lists a free Gmail address (goldencrust.bakery@gmail.com) as your public contact. Using a free webmail address makes it harder for customers to spot look-alike Gmail accounts created by scammers.
WordPress plugin versions and third-party booking and newsletter services identifiedBeobachtet
Your pages expose the exact versions of your theme (astra4.6.2) and plugins (woocommerce8.9.1, contact-form-75.9.3, cookie-notice2.4.16), which can be updated in WordPress under Dashboard -> Updates. The site also embeds a booking frame from https://booking.example.net, sends newsletter sign-ups to https://bakery.us21.list-manage.com/subscribe/post, and posts online pick-up orders from /order/ to /checkout/.
External scripts loaded without integrity verification hashesBeobachtet
Every page loads two third-party scripts (https://code.jquery.com/jquery-1.12.4.min.js and https://www.googletagmanager.com/gtag/js?id=G-EXAMPLE) without subresource integrity checks. If an external script host were ever modified, browsers would run the altered script on your sign-in and ordering pages automatically.
2 external scripts loaded from https://code.jquery.com and https://www.googletagmanager.com without integrity attributeshttps://bakery.example/
Web agency and hosting provider identified on legal notice pageBeobachtet
Your legal notice page states that the site is built and maintained by Pixel Agency and hosted by OVHcloud in Roubaix, France. Knowing that Pixel Agency manages WordPress while Cloudflare and OVH handle DNS, hosting, and domain registration helps you assign each security fix to the right team.
Publisher: Golden Crust Bakery SARL. Website built and maintained by Pixel Agency. Hosting: OVHcloud, Roubaix, France.https://bakery.example/legal-notice/
Ihr Fahrplan
Diese Woche
Renew bakery.example at OVH SAS before October 25, 2026, turn on automatic renewal, and enable the domain transfer lock.
Back up the site and update WordPress from 6.8 to 7.1.3, update all plugins and the astra theme, replace jQuery 1.12.4, and enable two-step sign-in for administrator marie.
Publish a single SPF record (v=spf1 include:_spf.google.com ~all), confirm active Google Workspace DKIM signing, and add a rua= reporting mailbox to _dmarc.bakery.example.
Diesen Monat
Fix the unencrypted http:// logo link on the homepage, add Secure and HttpOnly flags to cookies, and repair the /my-account/lost-password/ page in WooCommerce.
Add Strict-Transport-Security (max-age=300), X-Frame-Options (SAMEORIGIN), and Permissions-Policy via a Cloudflare Response Header Transform Rule.
Deploy a Content-Security-Policy-Report-Only header in Cloudflare and test sign-in, online ordering, contact uploads, and the booking widget.
Dieses Quartal
Review DMARC reports and step up _dmarc.bakery.example from p=none to p=quarantine and then p=reject, and replace goldencrust.bakery@gmail.com on the site with an @bakery.example address.
Switch Content-Security-Policy-Report-Only to an enforced Content-Security-Policy header and increase Strict-Transport-Security to max-age=31536000 (one year).
Publish /.well-known/security.txt and verify end-to-end DNSSEC chain validation between Cloudflare and OVH SAS.
Was bereits gut ist
Your HTTPS security certificate is valid until December 29, 2026, and protects connections using modern TLSv1.3 encryption.
Visitors who type your web address without https:// are automatically redirected to the encrypted HTTPS website.
Your server sends the x-content-type-options: nosniff header so browsers do not misinterpret uploaded or served file types.
Public DNS includes CAA records limiting certificate issuance to letsencrypt.org, Google Workspace MX records, and a candidate DKIM key at google._domainkey.bakery.example.
Your website is not flagged as dangerous by Google Safe Browsing and uses safe default referrer behavior across linked pages.
Begriffe in diesem Bericht
Content Security Policy (CSP)
An HTTP response header that tells browsers which scripts, frames, and connections are allowed to run on your pages, helping block injected malicious code.
DMARC
A DNS record that tells receiving email servers what to do with messages claiming to come from your domain that fail SPF or DKIM checks, and where to send summary reports.
DKIM
A digital signature added to outgoing emails by your mail provider (such as Google Workspace) so receivers can verify the message was genuinely sent by your domain.
DNSSEC
A system of digital signatures on your DNS records that prevents attackers from redirecting your domain name to a fake server.
HSTS
An HTTP header (Strict-Transport-Security) that instructs browsers to always connect to your website over encrypted HTTPS and never fall back to unencrypted HTTP.
Secure and HttpOnly cookie flags
Flags on browser cookies: Secure ensures the cookie is only sent over encrypted HTTPS, and HttpOnly blocks page scripts from reading session cookies.
SPF
A DNS TXT record listing every mail server and third-party service authorized to send email on behalf of your domain.
Transfer lock
A safety lock at your domain registrar (OVH SAS) that blocks your domain name from being moved to another registrar without your explicit approval.
This passive review examined public DNS records, HTTPS certificate settings, and publicly reachable pages on `bakery.example` (including your homepage, `/my-account/`, `/order/`, `/contact/`, `/privacy-policy/`, `/legal-notice/`, `/blog/`, `/robots.txt`, `/wp-sitemap.xml`, `/wp-sitemap-users-1.xml`, `/wp-sitemap-posts-page-1.xml`, and `/author/marie/`). Pages we could not reach (`/sitemap.xml`, `/my-account/lost-password/`, and `/.well-known/security.txt`) were not accessible. Because a passive check never signs in, submits forms, or tests for vulnerabilities, it cannot see inside your WordPress admin panel, Cloudflare or Google Workspace dashboards, server configuration, payment processing behind `/checkout/`, or whether DNSSEC signatures and DKIM email signing validate end to end. Von einem KI-Agenten in einer isolierten Sandbox auf Grundlage der Belege dieses Berichts und der erkundeten Seiten geschrieben; Note und Prüfungen unten stammen aus deterministischen Tests.
Assistent
Fragen Sie alles zu diesem Bericht
Beispielunterhaltung über die fiktive Bäckerei. Ihr eigener Bericht enthält den Assistenten.
Wurde meine Website gehackt?
Auf Basis dieser Prüfung lässt sich nicht feststellen, ob Ihre Website gehackt wurde. Die Untersuchung war rein passiv: Es wurden lediglich öffentlich zugängliche Seiten von außen betrachtet, ohne interne Systeme, Serverdateien oder Datenbanken zu prüfen.
Zum Zeitpunkt der Überprüfung führte Google Ihre Startseite nicht als schädlich oder gefährlich. Das bedeutet jedoch nicht zwingend, dass die Website vollkommen sicher oder frei von Einbrüchen ist.
Es gibt typische Warnzeichen, auf die Sie Ihre Website selbst prüfen können:
Unbekannte Benutzerkonten oder neue Profile mit Administratorrechten in Ihrem WordPress-Dashboard
Unerwartete neue Seiten, fremde Links oder automatische Weiterleitungen auf dubiose Websites
Sicherheitswarnungen in der Google Search Console oder Warnmeldungen beim Aufruf in gängigen Browsern
Veränderungen an Dateien oder plötzlich auftretende Fehlermeldungen
Wenn Sie einen konkreten Verdacht auf einen Sicherheitsvorfall haben, wenden Sie sich bitte an Ihren Webentwickler oder Webhoster. Diese können die Server-Protokolle (Logfiles) einsehen und Ihre Installation auf veränderten Programmcode untersuchen.
Worum soll ich meine Webagentur zuerst bitten?
Bitten Sie Ihre Webagentur als Erstes um zwei dringende Aufgaben, um Sicherheitsrisiken für Ihren Betrieb abzuwenden:
WordPress, Theme und Erweiterungen sofort aktualisieren
Ihre Website nutzt WordPress und ältere Bibliotheken mit öffentlich bekannten Schwachstellen. Bitten Sie Ihre Agentur, vorab ein vollständiges Backup zu erstellen und anschließend WordPress, das Theme (Astra) sowie alle Plugins auf den neuesten Stand zu bringen. Fragen Sie auch, ob automatische Sicherheitsupdates aktiviert werden können, damit bekannte Lücken künftig direkt geschlossen werden.
E-Mail-Absenderschutz (SPF und DMARC) einrichten
Ihre Domain empfängt E-Mails, hat aber keinen SPF-Eintrag veröffentlicht. Dadurch können Fremde leichter gefälschte E-Mails in Ihrem Namen versenden, was Ihrem Ruf schaden kann. Bitten Sie die Agentur bzw. die Personen, die Ihr DNS verwalten, den SPF-Eintrag für Google Workspace (v=spf1 include:_spf.google.com ~all) und einen DMARC-Eintrag (v=DMARC1; p=none; ...) einzutragen.
Prüfung nach der Umsetzung: Nach dem Update können Sie im WordPress-Dashboard unter Dashboard → Aktualisierungen nachsehen, ob alle Komponenten aktuell sind. Die E-Mail-Einstellungen lassen sich prüfen, indem Sie eine Test-E-Mail an ein externes Postfach senden und kontrollieren, ob die Nachricht ankommt, oder indem Sie diesen Sicherheitscheck erneut durchführen.
Wichtiger Hinweis vorab: Prüfen Sie bitte selbst umgehend bei Ihrem Domain-Registrar OVH SAS, ob die Internetadresse verlängert ist. Wenn eine Domain ausläuft, sind Website und E-Mails sofort offline – diese Verlängerung müssen in der Regel Sie als Inhaber selbst durchführen.
Viele Angriffe auf kleine Unternehmen beginnen mit einem gestohlenen Passwort oder einer gefälschten Rechnung, nicht mit der Website. Eine passive Prüfung sieht das nicht: Nehmen Sie sich für jeden Punkt ein paar Minuten.
Zwei-Faktor-Anmeldung für Ihre Konten (MFA)
Schalten Sie die Zwei-Faktor-Anmeldung für Ihre Konten bei Website-Verwaltung, E-Mail, Domain-Registrar und Webhoster ein. Bewahren Sie vorher die Wiederherstellungscodes an einem sicheren Ort auf und stellen Sie sicher, dass jemand den Zugang zurückerlangen kann, damit Sie sich nicht selbst aussperren.
Fragen Sie, was gesichert wird, wie oft und ob eine Kopie getrennt von der Website aufbewahrt wird, damit ein Angriff oder eine Löschung sie nicht erreichen kann. Testen Sie eine Wiederherstellung auf einer separaten Kopie, nie durch Überschreiben Ihrer Live-Website, und halten Sie schriftlich fest, wer wiederherstellen kann und wie.
Prüfen Sie, ob Ihre Adressen in einem Datenleck auftauchten
Mit Have I Been Pwned und XposedOrNot können Sie Ihre Domain selbst verifizieren und kostenlos benachrichtigt werden, wenn Adressen dieser Domain in einem veröffentlichten Datenleck auftauchen. Wir prüfen das nicht für Sie und verarbeiten nie geleakte Daten. Taucht eine Adresse auf, ändern Sie ihr Passwort und aktivieren Sie die Anmeldung in zwei Schritten.
Kopieren Sie die Prioritäten, den Hosting-Kontext und die Korrekturschritte als eine Aufgabe oder laden Sie sie als Markdown herunter.
Anweisungen für den Agenten lesen oder kopieren
Erkannte Anbieter
Diese Hinweise stammen aus erfassten Headern, dem HTML der Startseite und DNS-Einträgen. Bestätigen Sie den Dienst und Ihren Zugang, bevor Sie Einstellungen ändern. Der Zustellweg eingehender E-Mails verrät nicht jeden ausgehenden Absender.
Cloudflare — DNS-Anbieter
Cloudflare — Auslieferung der Website
Google Workspace — Eingehende E-Mails
WordPress — Website-Software
Alle Prüfungen
Zuerst behebenVerbessernGutNicht bestätigt
Sichere Verbindung Sieht gut aus
Sicherheitszertifikat (HTTPS)Gut
Das HTTPS-Zertifikat ist gültig: Browser zeigen eine sichere Verbindung an.
Warum das wichtig ist
Fehlt Ihr Zertifikat oder ist es ungültig, zeigen Browser Ihren Besuchern die Warnung „Nicht sicher“ oder „Dies ist keine sichere Verbindung“, und viele verlassen die Seite, bevor sie Sie kontaktieren oder etwas kaufen.
Wer es beheben kann
Ihr Webhoster oder Webentwickler · hier erkannt: Cloudflare (Website), WordPress (Website)
Was zu tun ist
Dieses Ergebnis erfordert keine Änderung. Behalten Sie die funktionierende Konfiguration bei und prüfen Sie sie mit diesen Schritten.
So prüfen Sie die Korrektur
Öffnen Sie Ihre Website in einem privaten Browserfenster: Sie sollte ohne Warnung laden und das Schloss-Symbol anzeigen. Führen Sie diese Prüfung danach erneut aus: Dieser Punkt sollte „Gut“ anzeigen.
Das Zertifikat ist gültig und läuft nicht bald ab.
Warum das wichtig ist
Läuft Ihr Zertifikat ab, blockieren Browser Ihre Besucher mit einer ganzseitigen Sicherheitswarnung. Ihre Website ist damit praktisch offline, bis das Zertifikat erneuert ist.
Wer es beheben kann
Ihr Webhoster (Zertifikate werden meist automatisch erneuert) · hier erkannt: Cloudflare (Website), WordPress (Website)
Was zu tun ist
Dieses Ergebnis erfordert keine Änderung. Behalten Sie die funktionierende Konfiguration bei und prüfen Sie sie mit diesen Schritten.
So prüfen Sie die Korrektur
Führen Sie diese Prüfung nach der Erneuerung erneut aus: Das Ablaufdatum sollte später liegen und dieser Punkt sollte „Gut“ anzeigen.
Ihre Website sendet diese Schutzeinstellung (HTTP-Header) nicht an Browser.
Warum das wichtig ist
Ohne HSTS versuchen die Browser Ihrer Besucher womöglich zuerst die unverschlüsselte Version Ihrer Website, die in gemeinsam genutzten Netzen wie öffentlichen WLANs abgefangen werden kann.
Wer es beheben kann
Ihr Webhoster oder Webentwickler · hier erkannt: Cloudflare (Website), WordPress (Website)
Was zu tun ist
Schalten Sie HSTS erst ein, wenn HTTPS auf Ihrer gesamten Website zuverlässig funktioniert: Browser merken sich die Einstellung, auch nachdem Sie sie entfernt haben. Bitten Sie Ihren Webhoster um den Header Strict-Transport-Security, zunächst mit kurzer Dauer (max-age=300, fünf Minuten), und erhöhen Sie diese dann schrittweise auf mindestens 180 Tage (max-age=15552000), idealerweise ein Jahr (max-age=31536000). Fügen Sie includeSubDomains oder preload erst hinzu, wenn jede Subdomain über HTTPS funktioniert: Beides lässt sich nur schwer rückgängig machen.
So prüfen Sie die Korrektur
Führen Sie diese Prüfung erneut aus: Dieser Punkt sollte „Gut“ anzeigen. Prüfen Sie dann, ob Ihre wichtigsten Seiten weiterhin normal laden.
Schritte für den vorgeschlagenen Anbieter
Strict-Transport-Security bei Cloudflare setzen
Voraussetzungen
Die erfassten Belege deuten auf Cloudflare hin. Bestätigen Sie, dass Sie den betreffenden Dienst verwalten, bevor Sie diese Schritte ausführen.
Bestätigen Sie die Kontrolle über die Cloudflare-Zone, den aktiven Proxy für diesen Hostnamen und freie Kapazität für Transform Rules. Sichern Sie bestehende Antwort-Header und Regeln; prüfen Sie nachfolgende Regeln, die diese Änderung überschreiben könnten.
Stellen Sie bei einer neuen HSTS-Einführung zuerst sicher, dass HTTPS und die Zertifikatserneuerung zuverlässig funktionieren. Behalten Sie eine bestehende stärkere Richtlinie bei. Dieser Fünf-Minuten-Test schließt Subdomains und Preload aus.
Notieren Sie bei WordPress die aktuellen Werte für „WordPress-Adresse (URL)“ und „Website-Adresse (URL)“ sowie die Proxy-Einstellungen. Prüfen Sie nach der genehmigten Änderung die Startseite, die Anmeldeseite und die Theme-Dateien auf Weiterleitungsschleifen oder gemischte Inhalte. Ändern Sie keine Website-URLs und vertrauen Sie weitergeleiteten Headern nicht, ohne die Konfiguration des Ursprungsservers zu prüfen.
Schritte
Erstellen Sie unter Rules → Overview eine Response Header Transform Rule. Ersetzen Sie YOUR_HOSTNAME im Ausdruck unten durch den genauen autorisierten Hostnamen; die Regel darf nur auf HTTPS zutreffen.
Wählen Sie Set static für Strict-Transport-Security mit dem Wert max-age=300. Speichern Sie mit Save as Draft, prüfen Sie die genaue Regel und holen Sie vor Deploy eine Freigabe ein. Ändern Sie nur diesen Header; aktivieren Sie nicht die gebündelte Transformation Add security headers.
Match: (http.host eq "YOUR_HOSTNAME" and ssl)
Operation: Set static
Header: Strict-Transport-Security
Value: max-age=300
Änderung überprüfen
Prüfen Sie auf dem vorgesehenen Hostnamen, dass über HTTPS genau ein Antwort-Header Strict-Transport-Security: max-age=300 gesendet wird. Kontrollieren Sie repräsentative Seiten und Ressourcen, einschließlich Weiterleitungen und kontrolliert ausgelöster Fehler, und prüfen Sie, dass andere Hostnamen nicht betroffen sind.
Rückgängig machen
Stellen Sie die vorherige Richtlinie wieder her, falls eine bestand. Um nur diese neue Richtlinie für den Hostnamen zurückzuziehen, liefern Sie max-age=0 über gültiges HTTPS aus; das Entfernen des Headers löscht kein zwischengespeichertes HSTS. Halten Sie HTTPS für die Dauer des bisherigen max-age-Werts funktionsfähig. Richtlinien der übergeordneten Domain und Preload müssen gesondert behandelt werden.
Dies wirkt am Cloudflare-Edge, nicht am Ursprungsserver. Ein passender Nameserver allein beweist weder den aktiven Proxy noch die Kontrolle über die Zone. Spätere Regeln können das Ergebnis überschreiben; zwischengespeichertes HSTS kann eine Rücknahme überdauern.
Ihre Website sendet diese Schutzeinstellung (HTTP-Header) nicht an Browser.
Warum das wichtig ist
Eine Content Security Policy teilt Browsern mit, welche Skripte und Ressourcen Ihre Website laden darf. Ohne sie läuft Schadcode, der in Ihre Website eingeschleust wurde (etwa über ein verwundbares Plugin), ungehindert in den Browsern Ihrer Besucher und kann abgreifen, was diese eingeben.
Wer es beheben kann
Ihr Webentwickler · hier erkannt: Cloudflare (Website), WordPress (Website)
Was zu tun ist
Hier ist Sorgfalt nötig, denn eine zu strenge Richtlinie kann dazu führen, dass Ihre Website nicht mehr richtig funktioniert. Bitten Sie Ihren Webentwickler, die Skripte, Schriften und Dienste aufzulisten, die Ihre Website nutzt (Webanalyse, Zahlungen, Chat), und eine Richtlinie zunächst im „Report-Only“-Modus zu testen, der Probleme meldet, ohne etwas zu blockieren. Stellen Sie erst auf Durchsetzung um, wenn Ihre wichtigsten Seiten funktionieren, und halten Sie die bisherige Einstellung zur Wiederherstellung bereit.
So prüfen Sie die Korrektur
Führen Sie diese Prüfung erneut aus: Dieser Punkt sollte „Gut“ anzeigen. Testen Sie dann Ihre wichtigsten Seiten (Kontaktformular, Bestellvorgang, Buchung), um sicherzugehen, dass nichts kaputtgegangen ist.
Schritte für den vorgeschlagenen Anbieter
Eine CSP-Beobachtungsregel in Cloudflare vorbereiten
Voraussetzungen
Die erfassten Belege deuten auf Cloudflare hin. Bestätigen Sie, dass Sie den betreffenden Dienst verwalten, bevor Sie diese Schritte ausführen.
Bestätigen Sie, dass Sie diesen über den Proxy geleiteten Hostnamen kontrollieren und freie Kapazität für Regeln zu Antwort-Headern haben. Erfassen Sie bestehende durchgesetzte und Report-Only-Richtlinien, einschließlich Client-side security rules. Überschreiben Sie diese nicht.
Erfassen Sie mit dem Webentwickler die benötigten Ressourcen und wichtigen Abläufe. Verwenden Sie einen vom Inhaber freigegebenen HTTPS-Endpunkt für Meldungen, mit Zugriffskontrollen und begrenzter Aufbewahrung; Meldungen können Seiten-URLs offenlegen.
Notieren Sie bei WordPress die aktuellen Werte für „WordPress-Adresse (URL)“ und „Website-Adresse (URL)“ sowie die Proxy-Einstellungen. Prüfen Sie nach der genehmigten Änderung die Startseite, die Anmeldeseite und die Theme-Dateien auf Weiterleitungsschleifen oder gemischte Inhalte. Ändern Sie keine Website-URLs und vertrauen Sie weitergeleiteten Headern nicht, ohne die Konfiguration des Ursprungsservers zu prüfen.
Schritte
Bereiten Sie unter Rules → Overview eine Response Header Transform Rule vor, die nur auf genau diesen Hostnamen zutrifft. Speichern Sie einen Entwurf; stellen Sie keine Platzhalter bereit.
Passen Sie das Beispiel ausschließlich als Beobachtungsrichtlinie an. Gibt es die Header bereits, lassen Sie deren Inhaber die Richtlinie und die Meldungsziele zusammenführen. Prüfen Sie die Reihenfolge der Regeln und holen Sie vor der Bereitstellung eine Freigabe ein.
Testen Sie die wichtigen Abläufe und prüfen Sie die eingegangenen Meldungen. Beziehen Sie bei WordPress Anmeldung, Editor, Plugins und einen eventuellen Bestellvorgang ein. Bereiten Sie eine gesondert geprüfte durchgesetzte Richtlinie erst vor, nachdem Sie legitime Verstöße behoben haben.
Prüfen Sie die beiden Antwort-Header und den Eingang einer kontrolliert ausgelösten Verstoßmeldung in einem unterstützten Browser. Report-Only blockiert keine Ressourcen und erledigt nicht den Befund dieses Berichts zur fehlenden durchgesetzten CSP.
Rückgängig machen
Deaktivieren Sie nur die neue Beobachtungsregel oder stellen Sie die erfassten Header wieder her; behalten Sie eine bereits zuvor bestehende durchgesetzte Richtlinie bei.
Dies ist ein restriktiver Ausgangspunkt zur Beobachtung, keine durchgesetzte Richtlinie. Die Unterstützung der Reporting API ist unterschiedlich. Cloudflare-DNS allein belegt nicht die Kontrolle über die öffentliche Antwort.
Einigen Cookies fehlt Secure, oder einem Anmelde- oder Sitzungscookie fehlt HttpOnly; fragen Sie nach, wozu jedes Cookie dient.
Warum das wichtig ist
Cookies können Ihre Besucher oder Mitarbeitenden angemeldet halten. Ohne das Secure-Attribut kann ein Cookie unverschlüsselt übertragen werden, und ohne HttpOnly kann Schadcode auf der Seite es auslesen. So könnte jemand eine Sitzung übernehmen.
Wer es beheben kann
Ihr Webentwickler · hier erkannt: Cloudflare (Website), WordPress (Website)
Was zu tun ist
Fragen Sie Ihren Webentwickler, wofür jedes Cookie dient. Anmelde- und Sitzungscookies sollten sowohl Secure als auch HttpOnly haben. Manche Cookies, etwa für Einwilligungsbanner oder Webanalyse, müssen berechtigterweise für die Seite lesbar sein. Ändern Sie daher nicht alle auf einmal: Testen Sie zuerst die Anmeldung und Ihre Integrationen und behalten Sie eine Möglichkeit, die Änderung rückgängig zu machen.
So prüfen Sie die Korrektur
Führen Sie diese Prüfung erneut aus und gehen Sie die Cookie-Liste mit Ihrem Webentwickler durch. Bestätigen Sie dann, dass die Anmeldung und Ihre anderen Funktionen weiterhin funktionieren.
Datei für Sicherheitskontakte (security.txt)Verbessern
Am Standardort war keine security.txt-Datei verfügbar.
Warum das wichtig ist
Entdeckt jemand ein Sicherheitsproblem auf Ihrer Website, erfährt er aus einer security.txt-Datei, wie er Sie erreicht. Ohne sie erreicht Sie ein hilfreicher Hinweis womöglich nie oder geht an die falsche Person.
Wer es beheben kann
Ihr Webentwickler oder wer Ihre Website verwaltet · hier erkannt: Cloudflare (Website), WordPress (Website)
Was zu tun ist
Veröffentlichen Sie eine reine Textdatei unter /.well-known/security.txt auf Ihrer HTTPS-Website. Sie braucht eine Zeile Contact: mit einer überwachten Adresse (zum Beispiel mailto:security@ihre-domain.example) und eine Zeile Expires: mit einem zukünftigen Datum im Format RFC 3339 (etwa 2027-12-31T23:59:59Z). Stellen Sie sich eine Erinnerung, um die Datei vor diesem Datum zu aktualisieren, und geben Sie nur Kontaktdaten an, die öffentlich sein dürfen.
So prüfen Sie die Korrektur
Öffnen Sie https://ihre-domain/.well-known/security.txt in einem Browser: Die Textdatei sollte mit Ihrem Kontakt und einem zukünftigen Datum erscheinen. Führen Sie diese Prüfung dann erneut aus. Wenn Sie eine Zeile Canonical: hinzufügen, muss sie genau diese Adresse enthalten.
Diese Korrektur an Ihren Entwickler oder KI-Assistenten senden
Besucher auf die sichere Website leiten (HTTPS-Weiterleitung)Gut
Besucher, die die Adresse ohne https:// eingeben, werden auf die sichere Website geleitet.
Warum das wichtig ist
Besucher, die Ihre Adresse ohne „https://“ eingeben, bleiben womöglich auf einer unverschlüsselten Seite. Dort kann das, was sie lesen oder eingeben (etwa Angaben im Kontaktformular), mitgelesen oder verändert werden, zum Beispiel in öffentlichen WLANs.
Wer es beheben kann
Ihr Webhoster oder Webentwickler · hier erkannt: Cloudflare (Website), WordPress (Website)
Was zu tun ist
Dieses Ergebnis erfordert keine Änderung. Behalten Sie die funktionierende Konfiguration bei und prüfen Sie sie mit diesen Schritten.
So prüfen Sie die Korrektur
Geben Sie in einem privaten Browserfenster Ihre Adresse beginnend mit http:// ein: Sie sollten auf der https://-Version derselben Adresse landen. Führen Sie diese Prüfung danach erneut aus: Dieser Punkt sollte „Gut“ anzeigen.
Ihre Website sendet diese Schutzeinstellung an Browser.
Warum das wichtig ist
Ohne diese Einstellung erraten Browser womöglich, welche Art von Datei sie erhalten. Eine versehentlich hochgeladene oder falsch gekennzeichnete Datei könnte dann als Code in den Browsern Ihrer Besucher ausgeführt werden.
Wer es beheben kann
Ihr Webentwickler oder Webhoster · hier erkannt: Cloudflare (Website), WordPress (Website)
Was zu tun ist
Dieses Ergebnis erfordert keine Änderung. Behalten Sie die funktionierende Konfiguration bei und prüfen Sie sie mit diesen Schritten.
So prüfen Sie die Korrektur
Führen Sie diese Prüfung erneut aus: Dieser Punkt sollte „Gut“ anzeigen. Prüfen Sie dann, ob Ihre Seiten weiterhin normal aussehen und funktionieren.
Ihre Domain empfängt E-Mails, veröffentlicht aber keinen SPF-Eintrag, sodass jeder leichter E-Mails versenden kann, die angeblich von Ihnen stammen.
Warum das wichtig ist
SPF listet die Dienste auf, die E-Mails für Ihre Domain versenden dürfen. Ohne SPF oder mit mehreren widersprüchlichen SPF-Einträgen können Kriminelle leichter E-Mails in Ihrem Namen versenden, und Ihre echten E-Mails landen eher im Spam.
Wer es beheben kann
Ihr E-Mail-Administrator und wer Ihr DNS verwaltet · hier erkannt: Google Workspace (E-Mail), Cloudflare (DNS)
Was zu tun ist
Listen Sie jeden Dienst auf, der E-Mails für Sie versendet: Ihren Postfach-Anbieter, aber auch Website-Formulare, Newsletter, Rechnungs- oder Buchungstools. Behalten Sie genau einen SPF-Eintrag, der alle abdeckt, mit den Werten, die jeder Anbieter dokumentiert; führen Sie Duplikate zusammen, statt einen zweiten Eintrag hinzuzufügen. Ersetzen Sie bestehende Angaben nicht durch einen strengen Eintrag, der „alles blockiert“, sonst werden Ihre legitimen E-Mails womöglich abgewiesen.
So prüfen Sie die Korrektur
Sobald die DNS-Änderung wirksam ist, führen Sie diese Prüfung erneut aus: Dieser Punkt sollte „Gut“ anzeigen. Senden Sie dann von jedem Dienst eine Test-E-Mail und prüfen Sie, ob die Header der empfangenen Nachricht spf=pass zeigen.
Schritte für den vorgeschlagenen Anbieter
SPF für Google Workspace prüfen
Voraussetzungen
Die erfassten Belege deuten auf Google Workspace hin. Bestätigen Sie, dass Sie den betreffenden Dienst verwalten, bevor Sie diese Schritte ausführen.
Bestätigen Sie, dass Google Workspace für genau diese Domain E-Mails versendet und nicht nur empfängt. Erfassen Sie Website-Formulare, Newsletter, Gateways und alle anderen Absender. Sichern Sie bestehende TXT-Einträge und TTLs; lassen Sie MX, DKIM und nicht betroffene DNS-Einträge unverändert.
Bestätigen Sie die Envelope-Absenderdomain, die SPF verwendet, und die sichtbare From-Domain, die DMARC verwendet; die beiden können sich unterscheiden.
Behalten Sie genau eine SPF-Richtlinie pro Absenderdomain. Ein MX-Eintrag für eingehende E-Mails kann nicht die vollständige Liste der ausgehenden Absender belegen.
Schritte
Führen Sie beim autoritativen DNS-Anbieter doppelte SPF-Einträge zu einer geprüften Richtlinie zusammen. Das Beispiel unten gilt nur für eine neue Richtlinie, wenn Google Workspace der einzige Absender ist. Andernfalls behalten Sie alle bestätigten Absender und den bestehenden Schutz bei; ersetzen Sie den Eintrag nicht blind.
Prüfen Sie die vollständige SPF-Auswertung gegen die Grenze von zehn Termen, die DNS-Abfragen auslösen, einschließlich verschachtelter include- und redirect-Angaben. Prüfen Sie den Diff und holen Sie vor der Veröffentlichung eine Freigabe ein.
Prüfen Sie nach der DNS-Verbreitung den autoritativen TXT-Wert und die Authentifizierungsergebnisse des empfangenden Servers für jeden Versanddienst.
TXT auf der SPF-Absenderdomain:
v=spf1 include:_spf.google.com ~all
Änderung überprüfen
Prüfen Sie, nachdem sich diese Änderung im DNS verbreitet hat, anhand einer neu empfangenen Nachricht in einem separaten Postfach spf=pass und die ausgewertete Envelope-Domain für jeden Absender. Bestätigen Sie genau eine veröffentlichte Richtlinie und ein gültiges Abfrageverhalten. Frühere Nachrichten dienen nur als Vergleichsbasis; ein DNS-Eintrag allein beweist keine Zustellung ins Postfach.
Rückgängig machen
Stellen Sie die gesicherte SPF-Richtlinie wieder her, während Sie die Absenderberechtigungen korrigieren, und lassen Sie nicht betroffene DNS-Einträge unverändert. Zwischengespeicherte Einträge verzögern die Wirkung; prüfen Sie erneut echte Nachrichten von jedem Absender.
SPF prüft die Envelope-Domain und kann nach einer Weiterleitung fehlschlagen. Es übernimmt nicht automatisch eine Richtlinie der übergeordneten Domain. Eine bestandene Prüfung für eine Domain des Anbieters bedeutet für sich allein keine Übereinstimmung (Alignment) mit Ihrer sichtbaren From-Adresse.
Ihre DMARC-Richtlinie ist „p=none“: Sie meldet gefälschte E-Mails, lässt sie aber weiterhin durch. Wechseln Sie nach Prüfung Ihrer Berichte zu „p=quarantine“ und danach zu „p=reject“.
Warum das wichtig ist
Ohne DMARC-Richtlinie können Kriminelle leichter E-Mails versenden, die scheinbar von Ihrem Unternehmen stammen, und Postfach-Anbieter haben keine Anweisung, sie zu blockieren. Gibt es mehrere DMARC-Einträge, wird keiner angewendet.
Wer es beheben kann
Ihr E-Mail-Administrator und wer Ihr DNS verwaltet · hier erkannt: Google Workspace (E-Mail), Cloudflare (DNS)
Was zu tun ist
Richten Sie zuerst SPF und DKIM für jeden Dienst ein, der E-Mails für Sie versendet. Veröffentlichen Sie dann einen einzigen DMARC-Eintrag (_dmarc.ihre-domain) mit p=none und einer überwachten Adresse für Berichte: Er überwacht, ohne zu blockieren. Wechseln Sie nach einigen Wochen mit unauffälligen Berichten schrittweise zu p=quarantine und dann zu p=reject; wer zu früh auf streng stellt, kann eigene E-Mails blockieren.
So prüfen Sie die Korrektur
Sobald die DNS-Änderung wirksam ist, führen Sie diese Prüfung erneut aus: Dieser Punkt zeigt „Gut“, sobald die Richtlinie p=quarantine oder p=reject lautet. Prüfen Sie dann in den DMARC-Berichten, ob Ihre legitimen E-Mails die Prüfung bestehen.
Schritte für den vorgeschlagenen Anbieter
DMARC für Google Workspace prüfen
Voraussetzungen
Die erfassten Belege deuten auf Google Workspace hin. Bestätigen Sie, dass Sie den betreffenden Dienst verwalten, bevor Sie diese Schritte ausführen.
Bestätigen Sie, dass Google Workspace für genau diese Domain E-Mails versendet und nicht nur empfängt. Erfassen Sie Website-Formulare, Newsletter, Gateways und alle anderen Absender. Sichern Sie bestehende TXT-Einträge und TTLs; lassen Sie MX, DKIM und nicht betroffene DNS-Einträge unverändert.
Bestätigen Sie die Envelope-Absenderdomain, die SPF verwendet, und die sichtbare From-Domain, die DMARC verwendet; die beiden können sich unterscheiden.
Prüfen Sie eine geltende DMARC-Richtlinie der übergeordneten Domain und kontrollieren Sie die Übereinstimmung von SPF/DKIM (Alignment) für legitime Absender, bevor Sie die Richtlinie ändern. Vereinbaren Sie ein Postfach für Sammelberichte (Aggregate Reports), das dem Betreiber gehört oder von ihm freigegeben ist; erfinden Sie keines.
Prüfen Sie die aktuelle DKIM-Signierung, bevor Sie Schlüssel ändern. Keine Antwort für einen gängigen Selektor ist kein Beweis, dass DKIM fehlt. Lassen Sie funktionierende Selektoren und die Signierung aktiv; ein Postfach-Alias legt die signierende Domain nicht fest.
Schritte
Wählen Sie in Google Admin → Apps → Google Workspace → Gmail → Authenticate email genau die Absenderdomain aus. Nur bei einer Neueinrichtung: Lassen Sie einen Super Admin einen 2048-Bit-Schlüssel erzeugen, sofern Ihr DNS das unterstützt, mit einem noch nicht verwendeten Selektor. Kopieren Sie den vollständigen TXT-Namen und -Wert von Google; behalten Sie einen bestehenden funktionierenden Schlüssel bei.
Veröffentlichen Sie genau diesen TXT-Eintrag beim autoritativen DNS-Anbieter und prüfen Sie, ob dieser den Domainnamen automatisch anhängt. Wählen Sie dann Start authentication und bestätigen Sie die Anzeige Authenticating email with DKIM. Bei neu aktiviertem Gmail kann es 24–72 Stunden dauern, bis ein Schlüssel erzeugt werden kann; DNS und Authentifizierung können 48 Stunden dauern.
Senden Sie nach Verbreitung und Aktivierung von jedem Dienst und jeder From-Adresse eine autorisierte neue Testnachricht an ein separates externes Postfach, das Sie kontrollieren. Prüfen Sie beim Empfänger Authentication-Results auf dkim=pass und DKIM-Signature auf die tatsächliche Domain d= und den Selektor s=; prüfen Sie die Übereinstimmung mit der sichtbaren From-Adresse. Ein anderer Alias desselben Postfachs und ältere Nachrichten sind kein Nachweis nach der Änderung.
Führen Sie beim autoritativen DNS-Anbieter doppelte _dmarc-TXT-Richtlinien zu einer einzigen, vom Inhaber freigegebenen Richtlinie zusammen. Behalten Sie eine etablierte stärkere Richtlinie bei; das Beispiel unten gilt nur für eine neue Einführung im Überwachungsmodus.
Ersetzen Sie YOUR_APPROVED_REPORT_ADDRESS durch das vereinbarte Postfach und prüfen und genehmigen Sie dann den DNS-Diff. Externe Berichtsempfänger erfordern eine Autorisierung durch den Empfänger im DNS. Fügen Sie Forensik-Berichte nicht standardmäßig hinzu.
Warten Sie bei Google Workspace nach der Einrichtung von SPF/DKIM mindestens 48 Stunden, bevor Sie DMARC einrichten, und beobachten Sie danach etwa eine Woche lang. Prüfen Sie jeden legitimen Versandweg, bevor Sie schrittweise zu quarantine und reject übergehen.
TXT auf _dmarc.YOUR_MAIL_DOMAIN:
v=DMARC1; p=none; rua=mailto:YOUR_APPROVED_REPORT_ADDRESS
Änderung überprüfen
Prüfen Sie, nachdem sich diese Änderung im DNS verbreitet hat: genau eine geltende DMARC-Richtlinie, übereinstimmendes SPF oder DKIM, dmarc=pass in den Authentifizierungsergebnissen einer neu empfangenen Nachricht und verwertbare Sammelberichte, die die geänderte Richtlinie abdecken. Frühere Nachrichten dienen nur als Vergleichsbasis. p=none überwacht; es erzwingt keine Zurückweisung.
Rückgängig machen
Stellen Sie die vorherige, vom Inhaber freigegebene Richtlinie wieder her, bei einer neuen Einführung meist p=none, während Sie die Übereinstimmung korrigieren. Lassen Sie funktionierendes SPF/DKIM unverändert. DNS-Caches verzögern die Rücknahme, und abgewiesene Nachrichten werden nicht automatisch wiederhergestellt. Behalten Sie die DKIM-TXT-Schlüssel während der Untersuchung; Google empfiehlt, sie nach dem Beenden der Signierung beizubehalten und mindestens vier Tage zu warten, bevor ein neu hinzugefügter Eintrag entfernt wird. Erzeugen Sie einen funktionierenden Schlüssel nicht als Rücknahmemaßnahme neu.
Diese Schritte erfordern Ihren E-Mail-Administrator und prüfen keine Mandanteneinstellungen (Tenant). Eingehende MX-Einträge belegen keine ausgehenden Absender. Ein DNS-Eintrag oder ein fehlender gängiger Selektor beweist weder eine aktive Signierung noch deren Fehlen; prüfen Sie tatsächlich empfangene Nachrichten.
MX-Einträge sind veröffentlicht. Ihre Ziele, ihre Erreichbarkeit und die Zustellung in Postfächer wurden nicht getestet.
Warum das wichtig ist
MX-Einträge teilen anderen Mailservern mit, wohin E-Mails für Ihre Domain zugestellt werden. Sind sie falsch oder widersprüchlich, können E-Mails Ihrer Kunden als unzustellbar zurückkommen oder verloren gehen. Eine Webadresse, die nicht für E-Mail genutzt wird, darf zu Recht keine haben.
Wer es beheben kann
Ihr E-Mail-Anbieter oder wer das DNS Ihrer Domain verwaltet · hier erkannt: Google Workspace (E-Mail), Cloudflare (DNS)
Was zu tun ist
Dieses Ergebnis erfordert keine Änderung. Behalten Sie die funktionierende Konfiguration bei und prüfen Sie sie mit diesen Schritten.
So prüfen Sie die Korrektur
Sobald die DNS-Änderung wirksam ist, führen Sie diese Prüfung erneut aus. Senden Sie dann zusätzlich eine Test-E-Mail an Ihr eigenes Postfach und eine von dort aus, um die Zustellung zu bestätigen.
Auf einem gängigen Selektor wurde ein möglicher Schlüssel gefunden. Die Signierung von Nachrichten und die Gültigkeit des Schlüssels wurden nicht getestet.
Warum das wichtig ist
DKIM versieht Ihre E-Mails mit einer digitalen Signatur, damit Empfänger prüfen können, dass sie wirklich von Ihrem Unternehmen stammen und nicht verändert wurden. Ohne DKIM landen Ihre E-Mails eher im Spam und DMARC schützt Ihre Domain weniger gut.
Wer es beheben kann
Ihr E-Mail-Administrator · hier erkannt: Google Workspace (E-Mail), Cloudflare (DNS)
Was zu tun ist
Dieses Ergebnis erfordert keine Änderung. Behalten Sie die funktionierende Konfiguration bei und prüfen Sie sie mit diesen Schritten.
So prüfen Sie die Korrektur
Sobald DKIM eingeschaltet und die DNS-Änderung wirksam ist, senden Sie eine neue E-Mail an eine externe Adresse, die Sie kontrollieren (keinen Alias und nicht die Adresse eines Kollegen). Suchen Sie in den Headern der empfangenen Nachricht nach dkim=pass und notieren Sie die Werte d= und s= in DKIM-Signature: s= ist der Selektor, den Sie im DNS nachschlagen.
Ein DS-Eintrag ist veröffentlicht; die DNSSEC-Signaturen und die Vertrauenskette wurden nicht validiert.
Warum das wichtig ist
DNSSEC signiert die DNS-Antworten Ihrer Domain digital. Das erschwert es Angreifern, Ihre Besucher oder Ihre E-Mails auf einen gefälschten Server umzuleiten. Es ist eine zusätzliche Schutzebene, keine Grundvoraussetzung.
Wer es beheben kann
Wer das DNS Ihrer Domain verwaltet, gemeinsam mit Ihrem Domain-Registrar · hier erkannt: Cloudflare (DNS)
Was zu tun ist
DNSSEC scheint aktiviert zu sein: Ihr Domain-Registrar veröffentlicht die zugehörige Verknüpfung (DS-Eintrag). Sie müssen nichts ändern. Wenn Sie Ihr DNS zu einem anderen Anbieter umziehen, bitten Sie zuerst beide Anbieter, die DNSSEC-Umstellung gemeinsam zu planen.
So prüfen Sie die Korrektur
Bitten Sie Ihren DNS-Anbieter zu bestätigen, dass DNSSEC durchgängig korrekt validiert wird. Diese Prüfung kann zeigen, dass DNSSEC veröffentlicht ist, nicht aber, dass es funktioniert.
Diese Korrektur an Ihren Entwickler oder KI-Assistenten senden
Für diesen Hostnamen sind CAA-Einträge veröffentlicht. Ihre Einschränkungen und ihre Verarbeitung durch Zertifikatsanbieter wurden nicht bewertet.
Warum das wichtig ist
Ein CAA-Eintrag legt fest, welche Organisationen HTTPS-Zertifikate für Ihre Domain ausstellen dürfen. Das erschwert es, ein betrügerisches Zertifikat zu erhalten. Er ist optional, und ein falscher Eintrag kann die Erneuerung Ihres eigenen Zertifikats verhindern.
Wer es beheben kann
Wer Ihr DNS verwaltet, gemeinsam mit Ihrem Webhoster · hier erkannt: Cloudflare (DNS)
Was zu tun ist
Dieses Ergebnis erfordert keine Änderung. Behalten Sie die funktionierende Konfiguration bei und prüfen Sie sie mit diesen Schritten.
So prüfen Sie die Korrektur
Bitten Sie Ihren Webhoster, die tatsächlich geltenden CAA-Regeln zu bestätigen, einschließlich der von Ihrer Hauptdomain oder von Aliasen übernommenen, und zu bestätigen, dass sich Ihr Website-Zertifikat weiterhin erneuern lässt.
Aus derselben Antwort der Startseite gelesen, ergänzt um Googles Liste gefährlicher Websites, mit Korrekturen für Ihre Plattform. Sie fließen noch nicht in die Note ein.
Von Google nicht als gefährlich gemeldetGut
Warum das wichtig ist
Würde Google Ihre Website als gefährlich führen, würden Browser Ihre Besucher warnen.
Google kann nicht garantieren, dass seine Informationen vollständig und fehlerfrei sind: Manche riskanten Websites werden möglicherweise nicht erkannt, und manche sicheren Websites werden möglicherweise irrtümlich als riskant eingestuft.
Domain rechtzeitig verlängert und gegen Transfers gesperrtVerbessern
Warum das wichtig ist
Ihre Domain muss bis zum 25. Oktober 2026 verlängert werden. Läuft sie aus, funktionieren Ihre Website und E-Mail nicht mehr und jemand anderes kann den Namen kaufen. Ohne Transfersperre kann jemand, der in Ihr Registrar-Konto gelangt oder Ihren Registrar täuscht, Ihre Domain leichter zu einem anderen Anbieter verschieben.
Was wir gesehen haben
Verlängerung fällig am 25. Oktober 2026 · keine Transfersperre · Registrar: OVH SAS
So beheben Sie es
Melden Sie sich bei Ihrem Domain-Registrar an und prüfen Sie, ob die automatische Verlängerung aktiv und die Zahlungskarte gültig ist, oder verlängern Sie jetzt. Aktivieren Sie im Kundenbereich Ihres Domain-Registrars die Transfersperre (auch Registrar-Sperre oder Transferschutz genannt), sofern sie angeboten wird.
Formulare und Seiteninhalte nutzen HTTPSVerbessern
Warum das wichtig ist
Bilder oder Medien auf Ihrer Startseite nutzen unverschlüsselte http://-Adressen: Browser versuchen stattdessen https:// und lassen sie weg, wenn das fehlschlägt, sodass sie eventuell nicht angezeigt werden.
Was wir gesehen haben
Bilder oder Medien über http://: 1
So beheben Sie es
Stellen Sie in WordPress beide Adressen unter Einstellungen → Allgemein auf https:// um und ersetzen Sie alte http://-Links mit einem Suchen-und-Ersetzen-Plugin (vorher sichern).
Keine Website-Bibliotheken mit bekannten SchwachstellenVerbessern
Warum das wichtig ist
Alte Versionen dieser Bibliotheken haben öffentlich bekannte Schwachstellen, die Angreifer gegen Ihre Besucher nutzen können, etwa um eigene Skripte auf Ihren Seiten auszuführen.
Was wir gesehen haben
jQuery 1.12.4 (CVE-2020-11022)
So beheben Sie es
Aktualisieren Sie WordPress, Ihr Theme und Ihre Plugins; eine alte Bibliothek stammt meist von einem veralteten Theme oder Plugin. Bitten Sie Ihren Entwickler, den Rest zu entfernen oder zu aktualisieren.
WordPress-Version ohne bekannte SchwachstellenVerbessern
Warum das wichtig ist
Diese WordPress-Version hat öffentlich bekannte Sicherheitslücken, nach denen Angreifer automatisch suchen.
Was wir gesehen haben
WordPress 6.8 · neueste 7.1.3
So beheben Sie es
Erstellen Sie ein Backup und installieren Sie dann in WordPress unter Dashboard → Aktualisierungen die neueste Version; aktivieren Sie automatische Updates. Wenn eine Agentur Ihre Website erstellt hat, bitten Sie sie darum.
Schutz vor verstecktem EinbettenVerbessern
Warum das wichtig ist
Ohne diesen Schutz kann eine andere Website Ihre Seiten in einem unsichtbaren Rahmen anzeigen und Besucher dazu verleiten, auf Schaltflächen zu klicken, die sie nicht sehen (Clickjacking).
So beheben Sie es
Fügen Sie in Cloudflare eine Transform Rule für Antwort-Header hinzu: X-Frame-Options: SAMEORIGIN.
Grenzen für Kamera, Mikrofon und StandortVerbessern
Warum das wichtig ist
Eine Permissions-Policy verhindert, dass Skripte auf Ihren Seiten, auch die von Drittanbietern, Zugriff auf Kamera, Mikrofon oder Standort anfordern.
So beheben Sie es
Fügen Sie in Cloudflare eine Transform Rule hinzu: Permissions-Policy: camera=(), microphone=(), geolocation=().
Softwareversionen bleiben verborgenVerbessern
Warum das wichtig ist
Sichtbare Versionsnummern verraten Angreifern genau, welche bekannten Schwachstellen sie ausprobieren können.
Was wir gesehen haben
WordPress 6.8
So beheben Sie es
Halten Sie WordPress und seine Plugins automatisch aktuell und verbergen Sie die Version mit Ihrem Sicherheits-Plugin.
Private Seitenadressen bleiben privatGut
Warum das wichtig ist
Eine unsichere Referrer-Policy sendet vollständige Seitenadressen, die private Links oder Tokens enthalten können, an jede Website, auf die Ihre Seiten verlinken. Ohne eine solche Richtlinie verwenden Browser eine sichere Standardeinstellung.
Ihr eigener Bericht in 20 Sekunden
Kostenlos – für Ihre Note brauchen Sie kein Konto.
Mit Ihrer Einwilligung misst Google Analytics, wie Besucher unsere öffentlichen Seiten nutzen, damit wir sie verbessern können. Prüfungen, Berichte und Kontoseiten laden es nie. Vor Ihrer Wahl wird nichts geladen, und Sie können Ihre Wahl jederzeit unter Cookie-Einstellungen in der Fußzeile ändern. Datenschutz und Cookies
Fmind
