SMTP-TLS für ALL-INKL
ALL-INKL verwaltet TLS-Konfiguration und Zertifikate auf den KAS-Mailservern zentral. Das Zertifikat ist auf den KAS-Server-Hostnamen ausgestellt (login.kasserver.com) — nicht auf Ihre Custom-Domain. STARTTLS ist auf Port 25 aktiv, Submission läuft über Port 465 (SSL/TLS) oder Port 587 (STARTTLS).
SMTP-TLS bei ALL-INKL (KAS)
ALL-INKL verwaltet die KAS-Mailcluster-Konfiguration zentral. Die offizielle ALL-INKL-Doku beschreibt: Der Verbindungshost lautet ihr-login.kasserver.com, das TLS-Zertifikat ist auf den KAS-Hostnamen ausgestellt (nicht auf Ihre Custom-Domain). Port 465 nutzt SSL/TLS, Port 587 verwendet STARTTLS. ALL-INKL liefert dazu eine Doku-Warnung mit: "you will get a certification error in your email client, because the certificate is not issued to your domain name" — das ist Designentscheidung, nicht Defekt.
Der exakte KAS-Hostname pro Domain hängt von der Server-Gruppe ab — typische Muster sind w001p005.kasserver.com, wNNN.kasserver.com oder ähnliche Bezeichnungen. Den konkreten MX-Hostnamen Ihrer Domain ermitteln Sie mit dig MX ihre-domain.de +short. Der Wolf-Agents Email Security Scanner prüft pro tatsächlichem MX-Host die TLS-Version, die Cipher-Stärke nach BSI TR-02102-2, das KAS-Zertifikat und die Chain-Vollständigkeit zeichengenau — er erkennt typische ALL-INKL-Drifts wie eine Custom-Domain mit eigenem Mail-Subdomain-Setup, die nach einem Servergruppen-Wechsel ein abgelaufenes Zertifikats-Caching trifft.
Für die Compliance-Triple (NIS2 Art. 21 Abs. 2 Buchstabe h zur Kryptografie, BSI TR-03108 zum sicheren E-Mail-Transport, DSGVO Art. 32 Abs. 1 Buchstabe a zur Verschlüsselung als technische Maßnahme) ist ALL-INKL Auftragsverarbeiter nach DSGVO Art. 28 — halten Sie den AV-Vertrag bereit. Dokumentieren Sie regelmäßige Wolf-Agents-Scans als Eigenkontrolle der technischen Maßnahmen. Wolf-Agents empfiehlt zusätzlich MTA-STS mit mx: *.kasserver.com in der Policy — damit wird der MX-Pattern automatisch für künftige KAS-Servergruppenwechsel abgedeckt.
KAS-MX-Hosts ermitteln und TLS prüfen
Da die KAS-Servergruppe pro Konto unterschiedlich vergeben wird, ermitteln Sie zuerst per dig die tatsächlichen MX-Hosts. Anschließend testen Sie pro Host den STARTTLS-Handshake mit openssl s_client — das KAS-Cluster-Zertifikat ist auf den KAS-Hostnamen ausgestellt, nicht auf Ihre Custom-Domain.
# MX-Hosts der ALL-INKL-Domain ermitteln
dig MX ihre-domain.de +short
# Erwartete Ausgabe je nach Server-Gruppe:
# 10 wNNN.kasserver.com. (NNN = numerische Server-Gruppe)
# STARTTLS auf Port 25 testen
echo | openssl s_client \
-connect wNNN.kasserver.com:25 \
-starttls smtp \
-servername wNNN.kasserver.com \
2>/dev/null | grep -E "Protocol|Cipher|subject|issuer"
# Erwartete Ausgabe:
# Protocol : TLSv1.2 oder TLSv1.3
# Cipher : ECDHE-RSA-AES256-GCM-SHA384 (oder ähnlich nach BSI TR-02102-2)
# subject=CN = *.kasserver.com (oder ähnlicher KAS-Hostname)
# issuer=C = ..., O = ..., CN = ...
# Implicit TLS auf Port 465 (Submission)
openssl s_client -connect ihr-login.kasserver.com:465 -servername ihr-login.kasserver.com
# STARTTLS auf Port 587 (Submission)
openssl s_client -connect ihr-login.kasserver.com:587 -starttls smtp -servername ihr-login.kasserver.comZertifikatsverhalten und Hostname-Match
Bei ALL-INKL führt das KAS-Cluster-Zertifikat zu einem charakteristischen Verhalten: Outlook und Thunderbird zeigen eine Zertifikatswarnung, weil das Zertifikat auf kasserver.com lautet, der Mailclient aber mail.ihre-domain.de eingegeben hat. ALL-INKL empfiehlt explizit: Verwenden Sie ihr-login.kasserver.com als Verbindungshost — dann passt das Zertifikat.
Für Server-zu-Server-Kommunikation (Port 25, MX) gilt dasselbe: Das Zertifikat passt zum KAS-Hostnamen, nicht zur Custom-Domain. Bei MTA-STS oder DANE muss die mx-Zeile der Policy entsprechend gesetzt sein — entweder mit dem konkreten wNNN.kasserver.com oder mit Wildcard *.kasserver.com. Der Wolf-Agents Email Security Scanner prüft den Match zwischen DNS-MX, Zertifikat-CN/SAN und MTA-STS-Policy zeichengenau und meldet einen Mismatch sofort.
ALL-INKL-spezifische TLS-Kontrollpunkte
- MX-Hostname: Muss auf
*.kasserver.comauflösen — Custom-Subdomains funktionieren technisch, brechen aber Hostname-Validation - Zertifikat-CN/SAN: ALL-INKL stellt für KAS-Hostnamen aus, nicht für Custom-Domains — das ist normal für Shared-Hosting
- Submission Ports: 465 SSL/TLS und 587 STARTTLS — beide laut ALL-INKL-Doku unterstützt
- Port 25 MTA-Empfang: STARTTLS aktiv — wird vom Wolf-Agents Scanner zeichengenau geprüft
- TLS-Version: ALL-INKL-Doku spezifiziert keine TLS-Mindestversion explizit — Wolf-Agents misst die tatsächlich verhandelte Version pro Host
Submission-Ports und Mailclient-Konfiguration
Für Mail-Client-Verbindungen empfiehlt ALL-INKL ausdrücklich, den KAS-Hostnamen ihr-login.kasserver.com als Eingehender und Ausgehender Mailserver einzutragen — nicht eine Custom-Subdomain. Damit passt das Zertifikat und der Mailclient zeigt keine Warnung.
Port 465 (SSL/TLS) ist der modernere Submission-Port mit Implicit TLS — die Verbindung beginnt sofort verschlüsselt. Port 587 (STARTTLS) ist der RFC-6409-konforme Submission-Port mit nachträglichem TLS-Upgrade. Für Compliance-relevante Setups (DSGVO, NIS2) ist Port 465 vorzuziehen, da kein STRIPTLS-Risiko zwischen Client und Submission-Server existiert. Der Wolf-Agents Scanner prüft beide Ports zusätzlich zum kritischen Port 25 — die SMTP-TLS-Bewertung mit 5 Punkten bezieht sich auf Port 25, die Submission-Ports werden als Zusatzinformation im Report ausgewiesen.
Häufige SMTP-TLS-Probleme bei ALL-INKL
Die folgenden drei ALL-INKL-spezifischen Probleme treten in Kundenprojekten regelmäßig auf — Zertifikatswarnung bei Custom-Domain-Submission, KAS-Servergruppen-Wechsel ohne TLS-Migration und MTA-STS-Policy ohne KAS-Wildcard-Match.
Mailclient zeigt Zertifikatswarnung bei Custom-Subdomain
Symptom: Outlook oder Thunderbird zeigt "Das Zertifikat passt nicht zum Server-Namen", wenn als Eingehender Mailserver mail.ihre-domain.de oder imap.ihre-domain.de eingetragen ist.
Ursache: Das ALL-INKL-Zertifikat ist auf den KAS-Server-Hostnamen ausgestellt (z.B. *.kasserver.com). Ihre Custom-Subdomain wird per DNS auf den KAS-Server geroutet, aber das Zertifikat im TLS-Handshake passt nicht zum eingegebenen Hostnamen — der Client zeigt die Warnung korrekt an.
Lösung: Tragen Sie im Mailclient als Eingehender/Ausgehender Mailserver ihr-login.kasserver.com ein — ALL-INKL empfiehlt das explizit. Die E-Mail-Adressen können unverändert auf Ihre Custom-Domain lauten. Alternative für SMTP-TLS-Server-zu-Server-Kommunikation: Im MTA-STS-Policy setzen Sie mx: *.kasserver.com — dann akzeptieren sendende Server den KAS-Hostnamen als gültig.
KAS-Servergruppen-Wechsel: MX zeigt auf alten Server
Symptom: Nach einem ALL-INKL-Upgrade oder Servergruppen-Wechsel kommen E-Mails verzögert oder gar nicht an. Wolf-Agents Scanner zeigt, dass der MX-Host nicht mehr auflöst oder ein veraltetes Zertifikat liefert.
Ursache: Ein DNS-Eintrag bei einem externen DNS-Provider zeigt noch auf die alte KAS-Servergruppe. ALL-INKL hat den Account migriert, der externe DNS-Cache ist aber nicht aktualisiert.
Lösung: Im KAS-Control-Panel den aktuellen MX-Hostnamen prüfen und im externen DNS-Provider aktualisieren. Bei externen DNS-Providern (Cloudflare DNS, IONOS DNS, Hetzner DNS): TTL temporär senken, MX-Record auf neuen KAS-Hostnamen ändern. Der Wolf-Agents Email Security Scanner zeigt nach DNS-Propagation den neuen MX-Host mit aktuellem Zertifikat.
MTA-STS-Policy mit konkretem KAS-Host bricht bei Servergruppen-Migration
Symptom: Sie haben eine MTA-STS-Policy mit mx: w001p005.kasserver.com hinterlegt. Nach einer KAS-Servergruppen-Migration zeigt der MX-Record jetzt auf w002p010.kasserver.com — sendende Server lehnen die Zustellung ab (Policy-MX-Mismatch).
Ursache: Eine konkrete Server-Nummer in der MTA-STS-Policy hartkodiert hat die Migration nicht überlebt. Die Policy ist seit dem letzten Scan stale.
Lösung: Verwenden Sie Wildcard in der Policy: mx: *.kasserver.com — das deckt beliebige KAS-Servergruppen ab. Aktualisieren Sie den id-Wert im DNS-TXT-Record bei jeder Policy-Änderung. Der Wolf-Agents Email Security Scanner vergleicht DNS-MX und Policy-MX zeichengenau und meldet einen Mismatch sofort — bevor sendende Server Mails ablehnen.
NIS2, BSI TR-03108 und DSGVO Art. 32: ALL-INKL als Auftragsverarbeiter
NIS2 Art. 21 Abs. 2 Buchstabe h fordert Kryptografie und Verschlüsselung — ALL-INKL erfüllt das mit STARTTLS auf Port 25 und TLS-Submission auf 465/587. BSI TR-03108 verlangt sicheren E-Mail-Transport — die TLS-Konfiguration auf den KAS-Clustern setzt das technisch um; die exakte TLS-Version pro Cluster prüft Wolf-Agents zeichengenau. DSGVO Art. 32 Abs. 1 Buchstabe a nennt Verschlüsselung als technische Maßnahme: ALL-INKL ist Auftragsverarbeiter (Art. 28), Sie als ALL-INKL-Kunde sind Verantwortlicher. Halten Sie den AV-Vertrag bereit und dokumentieren Sie regelmäßige Wolf-Agents-Scans als Eigenkontrolle. Bei ALL-INKL besonders relevant: Das KAS-Cluster-Zertifikat ist auf den KAS-Hostnamen ausgestellt — bei MTA-STS-Policies entsprechend Wildcard verwenden. Der Wolf-Agents Email Security Scanner bewertet SMTP-TLS mit 5 von 165 Punkten und prüft pro KAS-MX-Host die TLS-Version, die Cipher nach BSI TR-02102-2 und das Zertifikats-Hostname-Match zeichengenau.
SMTP-TLS-Anleitung auch für:
Wie steht Ihre Domain bei SMTP-TLS?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.