MTA-STS-Richtlinien- & TLS-RPT-DNS-Eintrag-Generator

MTA-STS-Richtlinien- & TLS-RPT-DNS-Eintrag-Generator

Umfassende Dokumentation und Best Practices zur Erstellung von RFC 8461 MTA-STS-Richtliniendateien, _mta-sts DNS-TXT-Einträgen und RFC 8460 TLS-RPT-Berichtsdatensätzen.

Voreinstellungen:
Richtlinien- & DNS-Konfiguration

Richtlinien-Host: mta-sts.example.com

Strict security: rejects unencrypted/invalid TLS delivery.

Autorisierte Mail-Exchange-Hostnamen (MX)2
mx:mail.example.com
mx:mx2.example.com
7 days (1 week)

Aktualisieren Sie die ID nach Richtlinienänderungen, damit Absender neu abrufen.

TLS-RPT SMTP-Vorfallberichterstattung (RFC 8460)
Domain: example.comMode: enforceMX-Anzahl: 2
RFC 8461 STSv1
version: STSv1
mode: enforce
mx: mail.example.com
mx: mx2.example.com
max_age: 604800
Lines: 6Chars: 86Size: 86 B
Served at https://mta-sts.<domain>/.well-known/mta-sts.txt
Durchsetzungsstatus
enforceStrict TLS
Autorisierte Mailziele
2 MX Patterns
Richtlinien-Cache-Lebensdauer
7 days (1 week)

Lokale Kompilierung ohne Latenz

Erstellt RFC 8461-Richtliniendateien und DNS-TXT-Einträge blitzschnell im Browser-Speicher – ohne jegliche Netzwerkübertragung.

RFC 8461 & RFC 8460 Validierung

Prüft MX-Wildcard-Syntax, Non-IP-Beschränkungen, alphanumerische Richtlinien-ID-Grenzwerte und HTTPS-Bereitstellungsstandards.

Bereit für plattformübergreifendes Deployment

Exportiert sofort einsatzbereite Snippets für BIND, Cloudflare, Route 53, Nginx, Caddy, Apache und HashiCorp Terraform.

Technische Referenz & Architektur-Leitfaden

MTA-STS-Richtlinien & TLS-RPT DNS-Record-Generator — Referenz-Leitfaden

Umfassende Dokumentation und Best Practices zur Erstellung von RFC 8461 MTA-STS-Richtliniendateien, _mta-sts DNS-TXT-Einträgen und RFC 8460 TLS-RPT-Berichtsdatensätzen.

Wichtige Parameter & Steuerelemente

modestring (enforce | testing | none)

Bestimmt das Erzwingungsverhalten für eingehende SMTP-Verbindungen. 'testing' weist sendende MTAs an, TLS-Fehler zu melden, ohne E-Mails abzuweisen; 'enforce' blockiert nicht-konforme Verbindungen verbindlich; 'none' deaktiviert die Richtlinie.

Standard: testing
mxstring | string[]

Liste zulässiger Mail-Exchanger-Host-Muster (FQDNs oder Single-Level-Wildcards wie *.mail.example.com), zu denen absendende MTAs verschlüsselte Verbindungen aufbauen und SAN-Zertifikate validieren dürfen.

Standard: mail.example.com
max_ageinteger (Sekunden)

Gültigkeitsdauer in Sekunden, für die ein absendender MTA die MTA-STS-Richtlinie lokal zwischenspeichert. Produktionswerte liegen meist bei 604800 (1 Woche) bis 1209600 (2 Wochen). In der Testphase werden 86400 empfohlen.

Standard: 604800
policy_idstring

Eindeutiger Bezeichner im _mta-sts DNS-TXT-Eintrag (typischerweise ein Zeitstempel oder Versions-Hash wie 2026101701). Eine Änderung zwingt sendende MTAs, ihren Richtlinien-Cache sofort zu invalidieren.

Standard: 20261017000000
ruastring (mailto URI)

Ziel-E-Mail-Adresse im _smtp._tls TXT-Eintrag, an die konforme MTAs tägliche aggregierte JSON-Fehlerberichte über TLS-Verbindungsversuche (TLS-RPT) senden.

Standard: mailto:[email protected]

Profi-Tipps & Best Practices

Richten Sie Ihren _smtp._tls-Record

Richten Sie Ihren _smtp._tls-Record ein und betreiben Sie MTA-STS mindestens zwei Wochen im Modus 'testing', bevor Sie auf 'enforce' umschalten. Analysieren Sie die eintreffenden TLS-RPT-Berichte, um fehlerhafte Zertifikatsketten, veraltete Chiffren oder SNI-Fehler ohne E-Mail-Verlust aufzudecken.

Die Richtliniendatei muss zwingend

Die Richtliniendatei muss zwingend unter https://mta-sts.<domain>/.well-known/mta-sts.txt mit HTTP 200, Content-Type text/plain und einem gültigen, öffentlich vertrauenswürdigen Zertifikat erreichbar sein. Host-übergreifende Weiterleitungen oder selbstsignierte Zertifikate sind unzulässig.

Die 'mx

Die 'mx:'-Zeilen der Richtlinie müssen exakt mit den DNS-MX-Records und den Subject Alternative Names (SAN) des Mailserver-Zertifikats übereinstimmen. Wenn der MX mail.example.com lautet, muss das Zertifikat genau diesen Namen oder *.example.com abdecken.

Häufige Fallstricke & Fehlerbehebung

Richtlinienabruf schlägt fehl: Sendende MTAs melden HTTPS- oder Zertifikatsfehler auf der Subdomain mta-sts

Überprüfen Sie die DNS-A/AAAA-Einträge für 'mta-sts.<ihredomain>' und stellen Sie sicher, dass der Webserver ein gültiges Zertifikat für mta-sts.<ihredomain> ausliefert. Port 443 muss öffentlich ohne Timeout (unter 10 Sekunden) und ohne externe Weiterleitungen antworten.

Eingehende E-Mails legitimer Absender werden im Modus 'enforce' abgewiesen

Prüfen Sie, ob das Zertifikat eines MX-Knotens abgelaufen ist oder STARTTLS fehlschlägt. Im Notfall setzen Sie die Richtlinie in der Datei und im DNS zurück auf 'testing' und inkrementieren Sie die policy_id im DNS-TXT-Eintrag, um die Caches aller MTAs umgehend zu aktualisieren.

Häufig gestellte Fragen (FAQ)

Worin besteht der Unterschied zwischen MTA-STS und DANE TLSA?▼

MTA-STS (RFC 8461) baut auf herkömmlichen Web-PKI-Zertifikaten (HTTPS-Zertifizierungsstellen) und DNS-TXT-Records auf, um Downgrade-Angriffe auf STARTTLS zu verhindern. DANE (RFC 7672) verankert kryptografische Zertifikate direkt mittels DNSSEC und TLSA-Einträgen im DNS, setzt jedoch eine lückenlose DNSSEC-Signierungskette voraus.

Warum ist der Parameter policy_id im DNS-Eintrag entscheidend?▼

Sendende MTAs speichern Richtlinien gemäß max_age für Tage oder Wochen zwischen. Um Bandbreite zu sparen, prüfen sendende MTAs nur den DNS-Wert 'id='. Erst wenn sich dieser ändert, laden sie die Datei mta-sts.txt erneut per HTTPS herunter. Ohne Änderung der policy_id bleibt eine neue Richtlinie wirkungslos.

Was passiert, wenn ein absendender Mailserver kein MTA-STS unterstützt?▼

Server ohne RFC 8461-Unterstützung ignorieren die DNS-Einträge und die HTTPS-Richtliniendatei schlichtweg. Sie wickeln die Zustellung über standardmäßiges opportunistisches STARTTLS ab und fallen im Zweifelsfall auf Klartext zurück.

Können mehrere MX-Server in einer MTA-STS-Richtlinie angegeben werden?▼

Ja. Sie können beliebig viele 'mx:'-Zeilen deklarieren (z. B. 'mx: mail1.example.com' und 'mx: mail2.example.com'). Alle in den DNS-MX-Records Ihrer Domain publizierten Server müssen durch eine entsprechende mx-Regel abgedeckt sein.

Verwandte Werkzeuge & Dienstprogramme

Alle Werkzeuge →
JWT Token Decoder & Security InspectorSicherheit

Entwickler-Werkzeug zum clientseitigen Dekodieren von JSON Web Tokens, Prüfen von RFC 7519- und OIDC-Claims, Überwachen von Ablaufzeiten und lokalen Verifizieren von HMAC-Signaturen.

Werkzeug öffnen→
Kryptografischer Passwort- & Passphrasen-GeneratorSicherheit

Erzeugen Sie kryptografisch sichere Passwörter mit hoher Entropie, einprägsame Diceware-Passphrasen, PINs und API-Token mit nativer Web Crypto CSPRNG nach NIST SP 800-63B.

Werkzeug öffnen→
Kryptografischer Hash-Generator & Prüfsummen-RechnerSicherheit

Berechnen Sie sofort SHA-256, SHA-512, MD5, SHA-1, SHA-3, Keccak und CRC32 lokal im Browser mit 100% nativer Web Crypto API Sicherheit.

Werkzeug öffnen→
JSON Web Token (JWT) Debugger & Signatur-VerifiziererSicherheit

Dekodieren, untersuchen und verifizieren Sie HMAC- und RSA-Signaturen 100% lokal im Browserspeicher via Web Crypto API. Null Cloud-Übertragung.

Werkzeug öffnen→
Passwort-Stärke-Prüfer Entwickler-ReferenzSicherheit

Technischer Leitfaden zur Analyse von Passwortstärke, Entropieberechnung und NIST-Sicherheitsbewertung im Browser.

Werkzeug öffnen→
Client-seitiges AES-GCM / CBC Verschlüsselungs- & Entschlüsselungs-ToolSicherheit

Technischer Leitfaden und Parameter-Referenz fuer browserbasierte AES-GCM- und AES-CBC-Sicherheitsoperationen.

Werkzeug öffnen→