E-Mail-Sicherheits-Check
3.5 ungenügend

nezimont.ch

  • Domain
  • 13.11.2026, 02:30
  • 5.50/10.5 Punkte
  • Platz 17/21
  • 5 Bestanden
  • 1 Teilweise
  • 6 Nicht bestanden
  • 8 Nicht geprüft
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6

Nur DNS geprüft – Header-Tests sind nicht bewertet.

Server-Plausibilisierung (SPF)

  • Versandserver ist per SPF autorisiert Server-Plausibilisierung 1 · spf_authorized SPF vorhanden, fremde Server werden mit „-all“ abgewiesen. Bestanden 1.50/1.5

    Zweck: SPF (Sender Policy Framework) legt im DNS fest, welche Server im Namen Ihrer Domain E-Mails versenden dürfen. Empfänger erkennen damit Mails von nicht berechtigten Servern.

    Empfehlung: Erfassen Sie auf nezimont.ch einen SPF-Eintrag (TXT), der alle Ihre Versanddienste enthält (z.B. Microsoft 365, Newsletter-Tool, Webshop) und mit „-all“ oder „~all“ endet. Beispiel: v=spf1 include:spf.protection.outlook.com -all

  • SPF-Eintrag ist technisch gültig Server-Plausibilisierung 2 · spf_valid Gültig, keine Schleifen, 1 von max. 10 DNS-Lookups. Bestanden 1.50/1.5

    Zweck: Ein SPF-Eintrag darf höchstens 10 DNS-Abfragen auslösen, keine Schleifen enthalten und nur einmal vorhanden sein. Andernfalls werten Empfänger ihn als Fehler – als gäbe es gar keinen.

    Empfehlung: Entfernen Sie nicht mehr genutzte Dienste, ersetzen Sie verschachtelte include-Einträge wo möglich durch ip4-Einträge und führen Sie mehrere SPF-Einträge zu einem einzigen zusammen.

  • SPF erlaubt nur so viele Server wie nötig Server-Plausibilisierung 3 · spf_scope 3 Einträge (max. 25), 1 erlaubte IPv4-Adressen (max. 500). Nicht mitgezählt: Server von Microsoft 365 (grosser Anbieter mit eigenem Missbrauchsschutz). Bestanden 0.50/0.5

    Zweck: Je mehr Server und IP-Bereiche Ihr SPF erlaubt, desto grösser die Angriffsfläche: Breite Freigaben ermöglichen es Dritten auf denselben Systemen, in Ihrem Namen zu senden. Die Server grosser Anbieter wie Microsoft 365 und Google werden dabei nicht mitgezählt.

    Empfehlung: Erlauben Sie nur Server, die tatsächlich in Ihrem Namen senden, und entfernen Sie breite IP-Bereiche sowie veraltete Einträge.

  • Versandserver hat einen gültigen Reverse-DNS-Eintrag Server-Plausibilisierung 4 · reverse_dns Nur mit E-Mail-Header prüfbar. Nicht geprüft –

    Zweck: Empfänger prüfen, ob die IP-Adresse des Versandservers einen Namen (PTR-Eintrag) hat, der wieder auf dieselbe IP zeigt. Fehlt er, landen Mails häufig im Spam.

    Empfehlung: Lassen Sie beim Betreiber des Versandservers (Hoster bzw. Internetanbieter) einen PTR-Eintrag für die Versand-IP setzen, der auf einen Hostnamen mit passender A-Adresse zeigt.

Absender & Signatur

  • Professioneller Mail-Aufbau (MIME) Absender-Plausibilisierung · content_type Nur mit E-Mail-Header prüfbar. Nicht geprüft –

    Zweck: Professionelle Mails bestehen aus mehreren Teilen (multipart), z.B. HTML- und Textversion. Einteilige Mails werden von Spamfiltern kritischer beurteilt.

    Empfehlung: Versenden Sie Mails mit HTML- und Textversion (multipart/alternative). Mailprogramme und Newsletter-Tools bieten dafür eine Einstellung.

  • Mails sind mit DKIM signiert Inhalts-Plausibilisierung · dkim_signature Unter 42 gängigen Selektoren wurde kein DKIM-Schlüssel gefunden. Für ein sicheres Resultat bitte den E-Mail-Header prüfen. Teilweise 1.00/2.0

    Zweck: DKIM versieht jede Mail mit einer digitalen Signatur. Der Empfänger prüft sie mit dem öffentlichen Schlüssel im DNS und erkennt so, ob die Mail wirklich von Ihrer Domain stammt und unterwegs unverändert blieb.

    Empfehlung: Aktivieren Sie DKIM bei Ihrem Mail-Anbieter (Microsoft 365: Defender-Portal › E-Mail-Authentifizierung › DKIM) und veröffentlichen Sie die angezeigten DNS-Einträge. Verwenden Sie Schlüssel mit mindestens 2048 Bit.

  • DKIM-Schlüssel ist ausreichend stark Inhalts-Plausibilisierung 2 · dkim_key_strength Kein Schlüssel gefunden – Schlüssellänge nicht feststellbar. Nicht geprüft –

    Zweck: Kurze RSA-Schlüssel (1024 Bit) gelten heute als schwach. Mit genügend Rechenleistung könnten Angreifer gültige Signaturen in Ihrem Namen erzeugen.

    Empfehlung: Erzeugen Sie einen neuen DKIM-Schlüssel mit mindestens 2048 Bit, veröffentlichen Sie ihn unter einem neuen Selektor und entfernen Sie alte, kurze Schlüssel aus dem DNS von nezimont.ch.

Betrugsschutz (DMARC)

  • DMARC-Richtlinie weist Fälschungen ab Betrugsschutz 1 · dmarc_policy Richtlinie p=reject. Bestanden 0.50/0.5

    Zweck: DMARC legt fest, was mit Mails geschieht, die SPF und DKIM nicht bestehen. Nur „quarantine“ oder „reject“ schützen wirksam vor gefälschten Absendern (Phishing, CEO-Betrug).

    Empfehlung: Erfassen Sie einen TXT-Eintrag auf _dmarc.nezimont.ch, z.B. v=DMARC1; p=quarantine; rua=mailto:dmarc@nezimont.ch. Starten Sie zur Beobachtung mit p=none und erhöhen Sie danach auf quarantine bzw. reject (ohne pct-Einschränkung).

  • Subdomains sind ebenfalls geschützt Betrugsschutz 2 · dmarc_subdomain Kein sp= gesetzt, es gilt p=reject auch für Subdomains. Bestanden 0.50/0.5

    Zweck: Betrüger weichen gerne auf erfundene Subdomains aus (z.B. rechnung.nezimont.ch). Die Subdomain-Richtlinie (sp=) bestimmt, ob auch diese abgewiesen werden. Ohne sp= gilt die Hauptrichtlinie.

    Empfehlung: Setzen Sie im DMARC-Eintrag sp=quarantine oder sp=reject – oder lassen Sie sp= weg, wenn die Hauptrichtlinie bereits quarantine oder reject ist.

  • Strenger Domain-Abgleich (aspf=s) Betrugsschutz 3 · dmarc_strict SPF-Abgleich aspf=r, DKIM-Abgleich adkim=r. Nicht bestanden 0.00/1.0

    Zweck: Im strengen Modus muss die technische Absenderdomain exakt zur sichtbaren Absenderdomain passen. Das verhindert Missbrauch über andere Subdomains Ihrer Domain.

    Empfehlung: Ergänzen Sie den DMARC-Eintrag mit aspf=s (idealerweise auch adkim=s), sobald alle Versanddienste Ihre exakte Domain verwenden.

  • Mail besteht den DMARC-Abgleich Betrugsschutz 4 · dmarc_alignment Nur mit E-Mail-Header prüfbar. Nicht geprüft –

    Zweck: DMARC verlangt, dass SPF oder DKIM für genau die Domain gelten, die der Empfänger als Absender sieht. Nur dann greift Ihre DMARC-Richtlinie tatsächlich – sonst werden auch Ihre echten Mails abgewiesen.

    Empfehlung: Sorgen Sie dafür, dass Ihre Versanddienste mit Ihrer eigenen Domain signieren (DKIM mit d=nezimont.ch) oder eine Return-Path-Adresse unter nezimont.ch verwenden.

  • DMARC-Berichte werden empfangen Betrugsschutz 5 · dmarc_reports Keine Berichtsadresse (rua=) im DMARC-Eintrag. Nicht bestanden 0.00/0.3

    Zweck: Über die Berichtsadresse (rua=) erhalten Sie regelmässig Auswertungen, welche Server in Ihrem Namen senden. So bemerken Sie Missbrauch und Fehlkonfigurationen frühzeitig.

    Empfehlung: Ergänzen Sie den DMARC-Eintrag mit rua=mailto:dmarc@nezimont.ch. Liegt die Adresse auf einer fremden Domain, muss diese den Empfang mit einem Eintrag nezimont.ch._report._dmarc.<fremde-domain> freigeben.

Marken-Authentizität (BIMI)

  • BIMI-Eintrag für das Firmenlogo Marken-Authentizität 1 · bimi_record Kein BIMI-Eintrag unter default._bimi.nezimont.ch. Nicht bestanden 0.00/1.0

    Zweck: Mit BIMI zeigen Gmail, Apple Mail, Yahoo und weitere Anbieter Ihr Logo direkt neben der Mail an. Das stärkt die Wiedererkennung und lässt Fälschungen auffallen.

    Empfehlung: Erfassen Sie einen TXT-Eintrag auf default._bimi.nezimont.ch: v=BIMI1; l=https://…/logo.svg. Voraussetzung ist eine DMARC-Richtlinie mit quarantine oder reject.

  • BIMI-Logo ist korrekt hinterlegt Marken-Authentizität 2 · bimi_logo Ohne BIMI-Eintrag kein Logo. Nicht bestanden 0.00/1.0

    Zweck: Das Logo muss per HTTPS erreichbar sein und dem Format „SVG Tiny PS“ entsprechen, sonst zeigen die Mail-Anbieter es nicht an.

    Empfehlung: Wandeln Sie Ihr Logo ins Format SVG Tiny PS um (quadratisch, ohne Skripte und externe Verweise) und stellen Sie es unter einer HTTPS-Adresse bereit.

Transportverschlüsselung (Empfang)

  • MTA-STS erzwingt verschlüsselten Empfang Transportverschlüsselung 1 · mta_sts Kein MTA-STS-Eintrag unter _mta-sts.nezimont.ch. Nicht bestanden 0.00/0.5

    Zweck: MTA-STS legt fest, dass Mails an Ihre Domain nur verschlüsselt und nur an Ihre echten Mailserver zugestellt werden dürfen. Das verhindert Mitlesen und Umleiten auf dem Transportweg.

    Empfehlung: Veröffentlichen Sie unter https://mta-sts.nezimont.ch/.well-known/mta-sts.txt eine Richtlinie mit „mode: enforce“ und allen MX-Servern, und erfassen Sie den TXT-Eintrag _mta-sts.nezimont.ch (v=STSv1; id=20260101).

  • TLS-Berichte (TLS-RPT) sind eingerichtet Transportverschlüsselung 2 · tls_rpt Kein TLS-RPT-Eintrag unter _smtp._tls.nezimont.ch. Nicht bestanden 0.00/0.2

    Zweck: TLS-RPT meldet Ihnen, wenn andere Mailserver keine verschlüsselte Verbindung zu Ihnen aufbauen konnten – ein Hinweis auf Angriffe oder Zertifikatsprobleme.

    Empfehlung: Erfassen Sie einen TXT-Eintrag auf _smtp._tls.nezimont.ch: v=TLSRPTv1; rua=mailto:tls-reports@nezimont.ch

Erweiterte Prüfungen

  • Return-Path passt zur Absenderdomain Erweiterter Betrugsschutz · domain_alignment Nur mit E-Mail-Header prüfbar. Nicht geprüft –

    Zweck: Die technische Rücksendeadresse (Return-Path) sollte dieselbe Domain verwenden wie der sichtbare Absender. Das erleichtert Empfängern die Zuordnung und ist Voraussetzung für den strengen DMARC-Abgleich.

    Empfehlung: Konfigurieren Sie in Ihren Versanddiensten (Newsletter-Tool, CRM, Webshop) eine Return-Path-Adresse unter nezimont.ch.

  • Mails sind mit S/MIME signiert Erweiterte Glaubwürdigkeit · smime Nur mit E-Mail-Header prüfbar. Nicht geprüft –

    Zweck: Mit einem persönlichen S/MIME-Zertifikat wird jede Mail digital unterschrieben. Empfänger sehen ein Siegel und können die Echtheit des Absenders unabhängig vom Mailserver prüfen.

    Empfehlung: Beziehen Sie S/MIME-Zertifikate bei einer anerkannten Zertifizierungsstelle und aktivieren Sie die Signatur im Mailprogramm.

  • Automatisch rotierende DKIM-Schlüssel Aktive Hacker-Prävention · rolling_keys Nur mit E-Mail-Header prüfbar. Nicht geprüft –

    Zweck: Werden DKIM-Schlüssel regelmässig automatisch gewechselt, ist ein gestohlener oder geknackter Schlüssel nur kurze Zeit nutzbar.

    Empfehlung: Nutzen Sie einen Versanddienst mit automatischer Schlüsselrotation oder wechseln Sie Ihre DKIM-Schlüssel mindestens halbjährlich.

  • Newsletter mit Ein-Klick-Abmeldung Versandpraxis · list_unsubscribe Nur mit E-Mail-Header prüfbar. Nicht geprüft –

    Zweck: Gmail, Yahoo und weitere Anbieter verlangen bei Massenmails eine Abmeldung per Klick direkt im Mailprogramm (RFC 8058). Fehlt sie, werden Newsletter häufiger als Spam eingestuft.

    Empfehlung: Aktivieren Sie in Ihrem Newsletter-Tool die Header „List-Unsubscribe“ (mit https-Link) und „List-Unsubscribe-Post: List-Unsubscribe=One-Click“.

Bewertung und Gewichtung

Note = 1 + 5 × Punkte ÷ Max-Punkte (Viertelnoten). Warnung = Gewicht × 0.5. Nicht anwendbare Tests zählen nicht zum Maximum. Gewichte: config/config.php › scoring.weights.

Test Schlüssel Prüft Punkte Modus
Server-Plausibilisierung 1 spf_authorized Versandserver ist per SPF autorisiert 1.5 Domain + Header
Server-Plausibilisierung 2 spf_valid SPF-Eintrag ist technisch gültig 1.5 Domain + Header
Server-Plausibilisierung 3 spf_scope SPF erlaubt nur so viele Server wie nötig 0.5 Domain + Header
Server-Plausibilisierung 4 reverse_dns Versandserver hat einen gültigen Reverse-DNS-Eintrag 0.5 nur Header
Absender-Plausibilisierung content_type Professioneller Mail-Aufbau (MIME) 1.0 nur Header
Inhalts-Plausibilisierung dkim_signature Mails sind mit DKIM signiert 2.0 Domain + Header
Inhalts-Plausibilisierung 2 dkim_key_strength DKIM-Schlüssel ist ausreichend stark 0.5 Domain + Header
Betrugsschutz 1 dmarc_policy DMARC-Richtlinie weist Fälschungen ab 0.5 Domain + Header
Betrugsschutz 2 dmarc_subdomain Subdomains sind ebenfalls geschützt 0.5 Domain + Header
Betrugsschutz 3 dmarc_strict Strenger Domain-Abgleich (aspf=s) 1.0 Domain + Header
Betrugsschutz 4 dmarc_alignment Mail besteht den DMARC-Abgleich 1.0 nur Header
Betrugsschutz 5 dmarc_reports DMARC-Berichte werden empfangen 0.3 Domain + Header
Marken-Authentizität 1 bimi_record BIMI-Eintrag für das Firmenlogo 1.0 Domain + Header
Marken-Authentizität 2 bimi_logo BIMI-Logo ist korrekt hinterlegt 1.0 Domain + Header
Transportverschlüsselung 1 mta_sts MTA-STS erzwingt verschlüsselten Empfang 0.5 Domain + Header
Transportverschlüsselung 2 tls_rpt TLS-Berichte (TLS-RPT) sind eingerichtet 0.2 Domain + Header
Erweiterter Betrugsschutz domain_alignment Return-Path passt zur Absenderdomain 0.4 nur Header
Erweiterte Glaubwürdigkeit smime Mails sind mit S/MIME signiert 0.2 nur Header
Aktive Hacker-Prävention rolling_keys Automatisch rotierende DKIM-Schlüssel 0.4 nur Header
Versandpraxis list_unsubscribe Newsletter mit Ein-Klick-Abmeldung 0.3 nur Header