MTA-STS für All-Inkl einrichten

DNS-Records im KAS anlegen, Subdomain mta-sts mit Let's-Encrypt-Zertifikat einrichten, Policy-Datei auf dem All-Inkl-Webspace hosten — mit TLS-RPT für automatische Fehlerberichte.

All-Inkl · MTA-STS & TLS-RPT

MTA-STS und TLS-RPT bei All-Inkl

All-Inkl bietet keine native MTA-STS-Unterstützung — die Einrichtung erfolgt über manuelle DNS-Records im KAS und das Hosting der Policy-Datei auf dem All-Inkl-Webspace mit Let's-Encrypt-Zertifikat für die Subdomain mta-sts. Die MX-Server mxNNN.kasserver.com variieren je nach Servergruppe.

Ohne MTA-STS können STRIPTLS-Angriffe die TLS-Verschlüsselung bei der E-Mail-Zustellung an Ihre All-Inkl-Domain entfernen. MTA-STS (RFC 8461) erzwingt, dass sendende Mailserver TLS verwenden und das Zertifikat validieren — ein HSTS-Äquivalent für E-Mail. Der Wolf-Agents Email Security Scanner vergleicht Policy-MX und DNS-MX zeichengenau: Er erkennt den All-Inkl-typischen Platzhalter mxNNN.kasserver.com (der nie produktiv stehen darf), warnt vor Servergruppen-Mismatches, deckt fehlendes Let's-Encrypt-Zertifikat für die mta-sts-Subdomain auf und meldet, wenn die .htaccess den .well-known-Pfad blockiert.

DSGVO Art. 32 fordert Verschlüsselung personenbezogener Daten bei der Übertragung — MTA-STS im Enforce-Modus auf All-Inkl-Domains schützt die Übertragung personenbezogener Daten in E-Mails. Für NIS2-pflichtige Unternehmen ist die Einrichtung eine Pflichtmaßnahme nach Art. 21 Abs. 2 lit. h. Die BSI TR-03108 empfiehlt MTA-STS explizit als Schutz vor STRIPTLS-Downgrade-Angriffen und sieht TLS-Erzwingung als Stand der Technik für E-Mail-Transport.

Falls Sie DMARC für All-Inkl noch nicht konfiguriert haben, starten Sie mit der DMARC-Anleitung für All-Inkl. MTA-STS baut auf einer funktionierenden E-Mail-Authentifizierung auf. All-Inkl bietet im KAS eine komfortable DNS-Verwaltung, die alle benötigten Record-Typen unterstützt.

1 Schritt 1 von 4

MX-Records prüfen

All-Inkl verwendet MX-Records im Format mxNNN.kasserver.com — die dreistellige Nummer variiert je nach Servergruppe, der Ihr Hosting-Paket zugewiesen ist. Der exakte MX-Hostname muss in der Policy-Datei stehen, eine falsche Nummer macht die gesamte MTA-STS-Konfiguration wirkungslos.

MX-Records im KAS verifizieren

  1. KAS öffnen: Melden Sie sich unter kas.all-inkl.com an und navigieren Sie zu Tools → DNS-Einstellungen
  2. Domain auswählen: Wählen Sie Ihre Domain aus der Liste. Unter den MX-Records sehen Sie den zugewiesenen Hostname wie mx2f3.kasserver.com
  3. Terminal-Prüfung: Verifizieren Sie per dig mx ihre-domain.de +short — die Ausgabe zeigt den exakten Hostname mit Priorität, z.B. 10 mx2f3.kasserver.com.
  4. Hostname notieren: Notieren Sie den exakten Hostnamen mit der dreistelligen Kennung — dieser Wert wird in Schritt 3 für die Policy-Datei benötigt
2 Schritt 2 von 4

DNS-Records im KAS anlegen

Im All-Inkl KAS legen Sie drei Einträge an: einen TXT-Record für _mta-sts, einen TXT-Record für _smtp._tls (TLS-RPT) und eine Subdomain mta-sts für das Policy-Hosting. Das KAS unterstützt alle benötigten Record-Typen — die DNS-Änderungen werden in der Regel innerhalb von 5-15 Minuten aktiv.

DNS-Records Schritt für Schritt

  1. KAS öffnen: Navigieren Sie zu Tools → DNS-Einstellungen → Ihre Domain → Neuen Record anlegen
  2. _mta-sts TXT-Record: Typ TXT, Name _mta-sts, Wert v=STSv1; id=20260408T0001 — die ID muss bei jeder Policy-Änderung aktualisiert werden
  3. _smtp._tls TXT-Record: Typ TXT, Name _smtp._tls, Wert v=TLSRPTv1; rua=mailto:tls-reports@ihre-domain.de
  4. Subdomain mta-sts: Navigieren Sie zu Domain → Subdomain anlegen und erstellen Sie mta-sts.ihre-domain.de. All-Inkl erstellt automatisch einen A-Record auf Ihren Webspace
DNS-Records (All-Inkl KAS) Konfiguration
# _mta-sts TXT-Record
_mta-sts.ihre-domain.de  TXT  "v=STSv1; id=20260408T0001"

# TLS-RPT TXT-Record
_smtp._tls.ihre-domain.de  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@ihre-domain.de"

# Subdomain mta-sts als A-Record (bei All-Inkl-Webspace)
mta-sts.ihre-domain.de  A  [Ihre Webspace-IP]

# Alternativ: CNAME für Cloudflare Pages
mta-sts.ihre-domain.de  CNAME  ihre-domain-mta-sts.pages.dev
3 Schritt 3 von 4

Policy-Datei auf Webspace hosten

Die MTA-STS-Policy muss unter https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt per HTTPS erreichbar sein. All-Inkl unterstützt Let's-Encrypt-Zertifikate für Subdomains — aktivieren Sie SSL im KAS und laden Sie die Policy-Datei per FTP oder den KAS-Dateimanager hoch. Ersetzen Sie mxNNN durch Ihren tatsächlichen MX-Hostnamen aus Schritt 1.

.well-known/mta-sts.txt Policy-Datei
version: STSv1
mode: testing
mx: mxNNN.kasserver.com
max_age: 604800

Hosting auf dem All-Inkl-Webspace

  1. Subdomain erstellen: Im KAS unter Domain → Subdomain anlegen: mta-sts.ihre-domain.de. All-Inkl legt automatisch ein Verzeichnis auf dem Webspace an
  2. Let's Encrypt aktivieren: Navigieren Sie zu Domain → SSL-Schutz → Let's Encrypt und aktivieren Sie das Zertifikat für mta-sts.ihre-domain.de. All-Inkl erneuert das Zertifikat automatisch
  3. Policy-Datei hochladen: Erstellen Sie im Root-Verzeichnis der Subdomain den Ordner .well-known und laden Sie mta-sts.txt hoch. Nutzen Sie den KAS-Dateimanager oder FTP. Ersetzen Sie mxNNN durch Ihren exakten MX-Hostnamen
  4. .htaccess prüfen: Falls eine .htaccess existiert, stellen Sie sicher, dass .well-known-Pfade nicht umgeleitet oder blockiert werden
  5. Testing-Modus: Starten Sie immer mit mode: testing und wechseln Sie erst nach 2-4 fehlerfreien Wochen zu mode: enforce. Bei jedem Moduswechsel aktualisieren Sie die id im DNS-Record
.htaccess (optional) Apache
# .htaccess für .well-known Verzeichnis
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{REQUEST_URI} ^/\.well-known/mta-sts\.txt$
  RewriteRule .* - [L]
</IfModule>

# Content-Type sicherstellen
<Files "mta-sts.txt">
  ForceType text/plain
</Files>
4 Schritt 4 von 4

Konfiguration verifizieren

Prüfen Sie alle drei Komponenten: den _mta-sts DNS-Record, die HTTPS-Erreichbarkeit der Policy-Datei unter mta-sts.ihre-domain.de und den _smtp._tls TLS-RPT-Record. All-Inkl DNS-Einträge propagieren schnell — testen Sie nach 5-15 Minuten.

Terminal / PowerShell Verifikation
# Linux / macOS — MX-Records prüfen
dig mx ihre-domain.de +short

# MTA-STS DNS-Record prüfen
dig _mta-sts.ihre-domain.de TXT +short

# TLS-RPT DNS-Record prüfen
dig _smtp._tls.ihre-domain.de TXT +short

# Policy-Datei abrufen
curl -s https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt

# Windows (PowerShell)
Resolve-DnsName -Name _mta-sts.ihre-domain.de -Type TXT | Select-Object -ExpandProperty Strings
Resolve-DnsName -Name _smtp._tls.ihre-domain.de -Type TXT | Select-Object -ExpandProperty Strings

Checkliste für All-Inkl

  1. MX-Abgleich: Der MX-Hostname in der Policy-Datei muss exakt dem Ergebnis von dig mx ihre-domain.de +short entsprechen — z.B. mx2f3.kasserver.com, nicht kasserver.com oder all-inkl.com
  2. Let's-Encrypt-Status: Prüfen Sie im KAS unter SSL-Schutz, dass das Zertifikat für mta-sts.ihre-domain.de aktiv ist und automatisch erneuert wird
  3. HTTPS-Zertifikat: Testen Sie mit curl -v https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt, dass das Zertifikat gültig ist und kein Redirect erfolgt
  4. Content-Type: Prüfen Sie mit curl -I https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt, dass der Header Content-Type: text/plain enthält
  5. Wolf-Agents Scanner: Nutzen Sie den Wolf-Agents Email Security Check für eine vollständige Validierung — er prüft DNS-Record, Policy-Datei, MX-Abgleich und TLS-RPT in einem Durchlauf

Häufige Probleme bei All-Inkl MTA-STS

Die folgenden drei Probleme treten bei der MTA-STS-Einrichtung mit All-Inkl besonders häufig auf. Jedes einzelne kann dazu führen, dass sendende Server Ihre Policy nicht finden oder die Policy-Datei nicht abrufen können — MTA-STS bleibt dann wirkungslos.

MX-Server variiert je nach Servergruppe (mxNNN)

Symptom: MTA-STS im Testing-Modus zeigt in TLS-RPT-Reports validation-failure mit dem Hinweis sts-policy-invalid. Der MX-Hostname in der Policy stimmt nicht mit dem tatsächlichen MX-Record überein.

Ursache: All-Inkl weist Domains verschiedenen Servergruppen zu — jede Gruppe hat einen eigenen MX-Hostnamen im Format mxNNN.kasserver.com. Der Platzhalter mxNNN aus Anleitungen wurde nicht durch den tatsächlichen Hostnamen ersetzt.

Lösung: Prüfen Sie den tatsächlichen MX-Record per dig mx ihre-domain.de +short und ersetzen Sie mxNNN in der Policy-Datei durch den exakten Hostnamen (z.B. mx2f3.kasserver.com). Nach der Korrektur aktualisieren Sie die id im _mta-sts DNS-Record.

Let's Encrypt für Subdomain nicht aktiviert

Symptom: Sendende Server können die Policy-Datei nicht abrufen. curl zeigt einen TLS-Fehler oder der Browser meldet ein ungültiges Zertifikat für mta-sts.ihre-domain.de.

Ursache: Die Subdomain mta-sts.ihre-domain.de wurde im KAS angelegt, aber Let's Encrypt wurde nicht separat für die Subdomain aktiviert. All-Inkl stellt SSL-Zertifikate nicht automatisch für neue Subdomains aus — die Aktivierung muss manuell erfolgen.

Lösung: Navigieren Sie im KAS zu Domain → SSL-Schutz → mta-sts.ihre-domain.de → Let's Encrypt aktivieren. Das Zertifikat wird innerhalb weniger Minuten ausgestellt. Prüfen Sie anschließend mit curl -v https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt, dass das Zertifikat gültig ist. All-Inkl erneuert Let's-Encrypt-Zertifikate automatisch.

.well-known Verzeichnis nicht erreichbar

Symptom: Die URL https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt gibt einen 403 Forbidden oder 404 Not Found zurück. Die Datei existiert auf dem Webspace, ist aber nicht abrufbar.

Ursache: Eine .htaccess-Datei im Root-Verzeichnis blockiert den Zugriff auf versteckte Verzeichnisse (die mit einem Punkt beginnen). Manche CMS-Installationen oder Sicherheits-Plugins blockieren .well-known standardmäßig.

Lösung: Prüfen Sie die .htaccess im Root-Verzeichnis der Subdomain auf Regeln, die .well-known-Pfade blockieren. Fügen Sie eine Ausnahmeregel hinzu, die den Zugriff auf /.well-known/mta-sts.txt explizit erlaubt. Testen Sie mit curl -I https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt — der Status-Code muss 200 sein. Der Wolf-Agents Email Security Scanner erkennt blockierte Policy-Dateien und meldet den HTTP-Status-Code im Prüfbericht.

DACH-Hosting-Architektur — IONOS/Strato/All-Inkl (Multimodal)

Vergleich der drei größten DACH-Hosting-Provider: IONOS SE (Montabaur), Strato AG (Berlin) und All-Inkl.com — Neue Medien Münnich (Friedersdorf). Die Visualisierung zeigt MX-Setup, Policy-Hosting-Optionen und Konsolen-Workflows für MTA-STS (Cross-File-Reuse in ionos/strato/allinkl, Empirik 85+86).

Wie steht Ihre Domain bei MTA-STS?

Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.