Autokonfiguration für die Mail-Domain: SRV, Autoconfig und Autodiscover

16.07.2026 · 16 Min. Lesezeit

Eine Mailadresse und ein Passwort – mehr sollte ein Nutzer beim Einrichten seines Mailkontos eigentlich nicht eingeben müssen. IMAP-Host, Submission-Server, Ports, TLS-Modus und Benutzername kann der Client selbst ermitteln.

Das Problem: Dafür gibt es keinen universellen Mechanismus, den alle Mailclients verwenden. Stattdessen existieren mehrere Verfahren nebeneinander:

Mechanismus	Typische Unterstützung	Voraussetzungen
SRV-Records nach RFC 6186 und RFC 8314	Clients mit entsprechender DNS-Unterstützung	DNS-Zone und erreichbare Mailserver
Mozilla Autoconfig	Thunderbird und einige andere Clients	Webserver und XML-Datei
Microsoft Autodiscover	Vor allem Outlook- und Exchange-Umfeld	Autodiscover-Endpunkt und passende DNS-Einträge

Du kannst alle drei parallel anbieten. Sie ergänzen sich, ersetzen einander aber nicht.

Gerade bei SRV-Records ist wichtig, zwischen Standard und tatsächlicher Client-Unterstützung zu unterscheiden. RFC 6186 beschreibt ein sauberes Verfahren zur Ermittlung von IMAP, POP3 und SMTP Submission. Das bedeutet aber nicht, dass jeder Mailclient diese Records bei der Kontoeinrichtung auch tatsächlich abfragt.

Thunderbirds eigene Autokonfiguration verwendet beispielsweise andere Mechanismen. Für Thunderbird ist eine config-v1.1.xml deshalb wesentlich interessanter als Mail-SRV-Records.

SRV-Records nach RFC 6186 und RFC 8314

SRV-Records veröffentlichen, unter welchem Host und Port ein bestimmter Dienst erreichbar ist.

Für eine Domain, die IMAP ausschließlich mit implizitem TLS anbietet, POP3 deaktiviert und sowohl Port 465 als auch Port 587 für SMTP Submission unterstützt, könnte die Zone so aussehen:

_imaps._tcp.example.com.        SRV 0 0 993 mail.example.com.
_submissions._tcp.example.com.  SRV 0 0 465 mail.example.com.
_submission._tcp.example.com.   SRV 0 0 587 mail.example.com.

_imap._tcp.example.com.         SRV 0 0 0 .
_pop3._tcp.example.com.         SRV 0 0 0 .
_pop3s._tcp.example.com.        SRV 0 0 0 .

Die vier Werte hinter SRV sind:

Priorität
Gewicht
Port
Ziel-Host

Die Priorität bestimmt, welche Server zuerst verwendet werden. Je kleiner der Wert, desto höher die Priorität.

Das Gewicht kommt erst zum Tragen, wenn mehrere Records dieselbe Priorität haben. Darüber lässt sich die Auswahl statisch auf mehrere Server verteilen. Es ist kein dynamisches Load-Balancing anhand der aktuellen Serverlast.

Bei nur einem Server sind 0 für Priorität und Gewicht völlig ausreichend.

Die Service-Namen bedeuten:

_imaps: IMAP mit implizitem TLS, normalerweise Port 993
_submissions: SMTP Submission mit implizitem TLS, normalerweise Port 465
_submission: SMTP Submission, üblicherweise Port 587 mit STARTTLS
_imap: IMAP auf Port 143, in einem sicheren Setup mit STARTTLS
_pop3: POP3, üblicherweise Port 110
_pop3s: POP3 mit implizitem TLS, normalerweise Port 995

_submissions wurde mit RFC 8314 ergänzt. Der RFC bevorzugt für Mailzugriff und Submission implizites TLS gegenüber einem zunächst unverschlüsselten Verbindungsaufbau, der anschließend mit STARTTLS auf TLS umgestellt wird.

Für SMTP Submission empfiehlt RFC 8314 trotzdem, während der Übergangszeit sowohl Port 465 mit implizitem TLS als auch Port 587 mit STARTTLS zu unterstützen. In der Praxis ist das auch heute noch sinnvoll, weil die Client-Unterstützung nicht einheitlich ist.

Einen Dienst ausdrücklich deaktivieren

Ein einzelner Punkt als Target bedeutet, dass der betreffende Dienst für diese Domain ausdrücklich nicht angeboten wird:

_pop3._tcp.example.com. SRV 0 0 0 .

Das ist nicht dasselbe wie ein fehlender Record.

RFC 6186 verlangt von einem kompatiblen Client, einen auf . gesetzten Dienst als nicht verfügbar zu behandeln. Gibt es dagegen gar keinen passenden SRV-Record, muss der Client auf eine andere Methode ausweichen, beispielsweise eine manuelle Konfiguration oder eigene Heuristiken.

Das SRV-Ziel darf kein CNAME sein

Das Target eines SRV-Records muss ein kanonischer Hostname sein, für den Adress-Records existieren. RFC 2782 verbietet an dieser Stelle einen Alias wie CNAME.

Korrekt:

mail.example.com. A     192.0.2.10
mail.example.com. AAAA  2001:db8::10

_imaps._tcp.example.com. SRV 0 0 993 mail.example.com.

Nicht standardkonform wäre:

mail.example.com. CNAME mail.provider.example.
_imaps._tcp.example.com. SRV 0 0 993 mail.example.com.

Wenn Dein Provider einen eigenen Hostnamen vorgibt, kannst Du diesen direkt als SRV-Target eintragen, sofern er kein Alias ist:

_imaps._tcp.example.com. SRV 0 0 993 imap.provider.example.

In einer klassischen Zonendatei endet ein vollständig qualifizierter Hostname mit einem Punkt. Ohne diesen Punkt hängt der DNS-Server je nach Konfiguration noch den aktuellen Zonennamen an.

Zertifikate bleiben notwendig

SRV ersetzt TLS nicht.

Der Client verbindet sich am Ende mit dem veröffentlichten Mailserver und muss dessen Identität überprüfen können. Die RFCs definieren dafür Regeln zur Zertifikatsprüfung bei über SRV gefundenen Diensten.

Für eine möglichst breite Client-Kompatibilität solltest Du dafür sorgen, dass der tatsächlich verwendete Servername im Zertifikat abgedeckt ist. Verbindet sich der Client beispielsweise mit mail.example.com, sollte das Zertifikat für diesen Namen gültig sein.

Die Records kannst Du mit dig prüfen:

dig +short SRV _imaps._tcp.example.com
dig +short SRV _submissions._tcp.example.com
dig +short SRV _submission._tcp.example.com

Eine typische Antwort sieht so aus:

0 0 993 mail.example.com.

Ob ein konkreter Mailclient diese Records tatsächlich verwendet, musst Du separat prüfen.

Thunderbird: Mozilla Autoconfig

Thunderbird verwendet für die automatische Kontoeinrichtung ein eigenes XML-Format.

Für example.com sind insbesondere diese beiden Endpunkte interessant:

https://autoconfig.example.com/mail/config-v1.1.xml
https://example.com/.well-known/autoconfig/mail/config-v1.1.xml

Thunderbirds aktuelle Implementierung versucht diese URLs zuerst über HTTPS. Je nach Client-Einstellung können zusätzlich HTTP-Varianten zugelassen werden.

Beim Abruf kann Thunderbird die eingegebene Mailadresse als Query-Parameter mitsenden:

https://autoconfig.example.com/mail/config-v1.1.xml?emailaddress=user@example.com

Bei einer statischen Datei ist das kein Problem. nginx und andere Webserver ignorieren den Query-String bei der Dateiauswahl und liefern trotzdem dieselbe Datei aus.

HTTP würde ich trotzdem nicht bewusst als primären Weg anbieten. Die Autoconfig-Datei enthält zwar kein Passwort, legt aber fest, an welchen Server der Client später seine Zugangsdaten sendet.

Thunderbird besitzt darüber hinaus weitere Wege zur Konfigurationssuche. Dazu gehören unter anderem seine zentrale Provider-Datenbank und bei gehosteten Domains eine Suche anhand des MX-Providers.

Die eigene Autoconfig-Datei hat einen großen Vorteil: Du legst die Einstellungen für Deine Domain selbst fest und bist nicht darauf angewiesen, dass ein Client Servernamen errät.

Die Datei `config-v1.1.xml`

Eine minimale Konfiguration für IMAP und SMTP Submission mit implizitem TLS sieht so aus:

<?xml version="1.0" encoding="UTF-8"?>
<clientConfig version="1.1">
  <emailProvider id="example.com">
    <domain>example.com</domain>

    <displayName>Example Mail</displayName>
    <displayShortName>Example</displayShortName>

    <incomingServer type="imap">
      <hostname>mail.example.com</hostname>
      <port>993</port>
      <socketType>SSL</socketType>
      <authentication>password-cleartext</authentication>
      <username>%EMAILADDRESS%</username>
    </incomingServer>

    <outgoingServer type="smtp">
      <hostname>mail.example.com</hostname>
      <port>465</port>
      <socketType>SSL</socketType>
      <authentication>password-cleartext</authentication>
      <username>%EMAILADDRESS%</username>
    </outgoingServer>
  </emailProvider>
</clientConfig>

Für socketType sind unter anderem diese Werte vorgesehen:

SSL: implizites TLS, beispielsweise auf Port 993 oder 465
STARTTLS: Verbindung aufbauen und anschließend auf TLS wechseln
plain: unverschlüsselte Verbindung

Der etwas unglückliche Name password-cleartext bedeutet nicht automatisch, dass das Passwort unverschlüsselt über das Netzwerk übertragen wird.

Gemeint ist eine normale Passwortauthentifizierung, beispielsweise über SASL PLAIN, innerhalb der durch socketType definierten Verbindung. Bei SSL oder STARTTLS liegt die Authentifizierung damit innerhalb einer TLS-geschützten Verbindung.

Wichtig ist also die Kombination aus Authentifizierungsverfahren und Transportverschlüsselung.

Für den Benutzernamen gibt es unter anderem diese Platzhalter:

Platzhalter	Ergebnis für `alice@example.com`
`%EMAILADDRESS%`	`alice@example.com`
`%EMAILLOCALPART%`	`alice`
`%EMAILDOMAIN%`	`example.com`

Viele Mailserver verwenden die vollständige Mailadresse als Login. In diesem Fall ist %EMAILADDRESS% die passende Wahl.

Das Attribut id am <emailProvider> ist eine Kennung für den Provider. Als Wert bietet sich die primäre Domain an.

Für die eigentliche Zuordnung sind die <domain>-Elemente relevant. Ein Provider kann deshalb auch mehrere Domains in einer Konfiguration aufführen.

Thunderbird und SRV sind zwei verschiedene Dinge

Ein häufiger Denkfehler ist, Thunderbird-Autoconfig und RFC-6186-SRV-Records als zwei Varianten derselben Thunderbird-Funktion zu betrachten.

Das sind getrennte Mechanismen.

Thunderbirds aktuelle Autoconfig-Implementierung sucht unter anderem nach der config-v1.1.xml, in der eigenen Provider-Datenbank und über den MX-Provider. Mail-SRV-Records wie _imaps._tcp oder _submission._tcp sind nicht einfach ein Ersatz für diese XML-Datei.

Du kannst die SRV-Records trotzdem veröffentlichen. Sie sind standardisiert und können anderen Clients helfen. Für Thunderbird solltest Du Dich aber nicht darauf verlassen.

Microsoft Autodiscover

Microsoft Autodiscover stammt aus dem Exchange-Umfeld und ist deutlich komplexer als Thunderbird Autoconfig.

Das POX-Format kann auch Einstellungen für IMAP, POP3 und SMTP beschreiben. Die Microsoft Open Specifications kennen dafür unter anderem die Protokolltypen IMAP, POP3 und SMTP.

Das bedeutet allerdings nicht, dass jede Outlook-Version eine solche Antwort beim Einrichten eines beliebigen IMAP-Kontos gleich verarbeitet.

Microsoft selbst dokumentiert Fälle, in denen Outlook eine Autodiscover-Antwort mit POP- oder IMAP-Einstellungen erhält, die anschließende Kontoeinrichtung aber trotzdem scheitert.

Wenn Du Autodiscover für einen normalen IMAP-/SMTP-Server bereitstellst, solltest Du es deshalb als Kompatibilitätsfunktion für konkrete Clients betrachten, nicht als universellen Standard für alle Outlook-Varianten.

Typische Endpunkte

Zu den von Outlook verwendeten beziehungsweise dokumentierten Endpunkten gehören:

https://example.com/autodiscover/autodiscover.xml
https://autodiscover.example.com/autodiscover/autodiscover.xml

Zusätzlich kann Autodiscover über einen SRV-Record gefunden werden:

_autodiscover._tcp.example.com. SRV 0 0 443 autodiscover.example.com.

Der SRV-Record enthält Host und Port, nicht den HTTP-Pfad. Der Client verwendet anschließend den Autodiscover-Endpunkt auf diesem Server.

Für klassische Outlook-Versionen gehören neben HTTPS-URLs je nach Umgebung auch weitere Suchmethoden wie ein HTTP-Redirect und die SRV-Abfrage zum Autodiscover-Verfahren.

Das ist etwas völlig anderes als _imaps, _submission oder _submissions. _autodiscover._tcp findet einen Webdienst, der anschließend die eigentliche Konfiguration liefert.

Groß- und Kleinschreibung

Microsoft-Dokumentation und Clients verwenden den Autodiscover-Pfad in unterschiedlicher Schreibweise, beispielsweise:

/autodiscover/autodiscover.xml
/Autodiscover/Autodiscover.xml

Auf einem Windows-IIS fällt das normalerweise nicht auf. Unter einem typischen Linux-Webserver sind das dagegen unterschiedliche Pfade.

Wenn Du Autodiscover mit nginx bereitstellst, ist es deshalb sinnvoll, beide Varianten zu bedienen.

Autodiscover verwendet normalerweise POST

Die eigentliche POX-Abfrage erfolgt per HTTP-POST.

Der Request enthält unter anderem die Mailadresse und das gewünschte Antwortschema:

<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006">
  <Request>
    <EMailAddress>alice@example.com</EMailAddress>
    <AcceptableResponseSchema>http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a</AcceptableResponseSchema>
  </Request>
</Autodiscover>

Bei den XML-Namespaces gibt es eine unschöne Besonderheit in Microsofts Dokumentation.

Die Microsoft Open Specifications definieren die POX-Namespaces mit http://. Einige Seiten der normalen Microsoft-Webdokumentation zeigen dieselben Bezeichner dagegen mit https://.

XML-Namespaces sind keine URLs, die der Client abrufen muss. Sie sind Bezeichner und werden als Zeichenketten ausgewertet.

Für eine Implementierung des hier gezeigten POX-Protokolls orientiere ich mich deshalb an den Microsoft Open Specifications und verwende die dort definierten http://-Namespaces.

Eine statische Antwort für IMAP und SMTP kann beispielsweise so aussehen:

<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
  <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
    <Account>
      <AccountType>email</AccountType>
      <Action>settings</Action>

      <Protocol>
        <Type>IMAP</Type>
        <Server>mail.example.com</Server>
        <Port>993</Port>
        <SSL>on</SSL>
        <SPA>off</SPA>
        <AuthRequired>on</AuthRequired>
      </Protocol>

      <Protocol>
        <Type>SMTP</Type>
        <Server>mail.example.com</Server>
        <Port>465</Port>
        <SSL>on</SSL>
        <SPA>off</SPA>
        <AuthRequired>on</AuthRequired>
      </Protocol>
    </Account>
  </Response>
</Autodiscover>

SPA ist Outlooks Option für Secure Password Authentication. Bei einem normalen IMAP-/SMTP-Konto mit klassischer Passwortauthentifizierung wird sie üblicherweise nicht benötigt und steht deshalb auf off.

Das Problem mit dem Benutzernamen

Im Beispiel fehlt LoginName bewusst.

Eine statische XML-Datei kann schließlich nicht wissen, dass gerade alice@example.com eingerichtet wird. Das POX-Format besitzt auch keinen Thunderbird-artigen Platzhalter wie %EMAILADDRESS%.

Ein statischer Endpunkt funktioniert deshalb nur mit Clients, die den Login-Namen selbst passend ergänzen, beispielsweise aus der bereits eingegebenen Mailadresse.

Möchtest Du den Login-Namen ausdrücklich zurückgeben, verschiedene Domains unterschiedlich behandeln oder abhängig von der Mailadresse verschiedene Server ausliefern, brauchst Du einen dynamischen Endpunkt.

Der liest den POST-Body, verarbeitet <EMailAddress> und erzeugt daraus die passende Antwort.

XML-Dateien mit nginx ausliefern

Für Thunderbird brauchst Du einen HTTPS-vHost für autoconfig.example.com, den .well-known-Pfad auf der Hauptdomain oder praktischerweise beides.

Thunderbird Autoconfig

Ein eigener vHost für autoconfig.example.com kann so aussehen:

server {
    listen 443 ssl;
    server_name autoconfig.example.com;

    # ssl_certificate     /pfad/zum/fullchain.pem;
    # ssl_certificate_key /pfad/zum/privkey.pem;

    location = /mail/config-v1.1.xml {
        alias /var/www/autoconfig/config-v1.1.xml;
    }
}

Die .well-known-Variante kommt zusätzlich in den bestehenden HTTPS-vHost von example.com:

location = /.well-known/autoconfig/mail/config-v1.1.xml {
    alias /var/www/autoconfig/config-v1.1.xml;
}

Beide Endpunkte dürfen dieselbe Datei ausliefern.

Statisches Autodiscover trotz POST

Ein normaler nginx-Static-Handler liefert eine Datei per GET oder HEAD aus. Ein POST auf dieselbe Location endet dagegen normalerweise mit:

405 Method Not Allowed

Für eine vollständig statische Autodiscover-Antwort lässt sich dieses Verhalten mit error_page nutzen.

nginx führt bei einer internen Weiterleitung über error_page für andere Methoden als GET und HEAD einen internen GET aus. Damit kann ein POST auf den öffentlichen Autodiscover-Pfad auf eine interne statische Datei umgeleitet werden:

server {
    listen 443 ssl;
    server_name autodiscover.example.com;

    # ssl_certificate     /pfad/zum/fullchain.pem;
    # ssl_certificate_key /pfad/zum/privkey.pem;

    location = /Autodiscover/Autodiscover.xml {
        error_page 405 =200 /_autodiscover-static.xml;
        alias /var/www/autodiscover/autodiscover.xml;
    }

    location = /autodiscover/autodiscover.xml {
        error_page 405 =200 /_autodiscover-static.xml;
        alias /var/www/autodiscover/autodiscover.xml;
    }

    location = /_autodiscover-static.xml {
        internal;
        alias /var/www/autodiscover/autodiscover.xml;
    }
}

Der Client sendet beispielsweise:

POST /Autodiscover/Autodiscover.xml

Der Static-Handler erzeugt zunächst den Status 405. error_page führt daraufhin intern einen GET auf /_autodiscover-static.xml aus und nginx liefert die Datei mit Status 200.

Der Request-Body geht bei diesem Verfahren bewusst nicht in die Antwort ein.

Das ist deshalb nur sinnvoll, wenn wirklich alle Nutzer derselben Domain dieselben Server, Ports und Authentifizierungsverfahren verwenden und der Client selbst mit dem Login-Namen klarkommt.

Sobald die Antwort von <EMailAddress> abhängt, solltest Du den POST tatsächlich verarbeiten.

Zertifikate für die Web-Endpunkte

Die HTTPS-Endpunkte brauchen gültige Zertifikate für die Namen, unter denen sie aufgerufen werden:

autoconfig.example.com
autodiscover.example.com

Ein Wildcard-Zertifikat für:

*.example.com

deckt beide Subdomains ab.

Es deckt aber nicht automatisch die Hauptdomain selbst ab:

example.com

Wenn Du auch

https://example.com/.well-known/autoconfig/mail/config-v1.1.xml

oder

https://example.com/autodiscover/autodiscover.xml

bereitstellen möchtest, muss das verwendete Zertifikat deshalb auch example.com abdecken.

Wenn Du nur die DNS-Zone kontrollierst

Liegt das Postfach bei einem externen Provider, kannst Du SRV-Records weiterhin selbst veröffentlichen:

_imaps._tcp.example.com.        SRV 0 0 993 imap.provider.example.
_submissions._tcp.example.com.  SRV 0 0 465 smtp.provider.example.
_submission._tcp.example.com.   SRV 0 0 587 smtp.provider.example.

Verwende ausschließlich die vom Provider dokumentierten Hostnamen, Ports und TLS-Verfahren.

Achte außerdem darauf, dass die SRV-Targets keine CNAMEs sind.

Für Web-Endpunkte wie Thunderbird Autoconfig oder Microsoft Autodiscover sieht die Sache anders aus. Dort ist ein CNAME grundsätzlich möglich:

autoconfig.example.com.   CNAME autoconfig.provider.example.
autodiscover.example.com. CNAME autodiscover.provider.example.

Das CNAME-Verbot für SRV-Targets gilt hier nicht, weil autoconfig.example.com und autodiscover.example.com normale Web-Hostnamen sind.

Allerdings löst ein CNAME das HTTPS-Zertifikatsproblem nicht.

Der Client ruft weiterhin beispielsweise

https://autoconfig.example.com/

auf. Der Webserver am anderen Ende muss deshalb ein Zertifikat präsentieren, das für autoconfig.example.com gültig ist.

Dass DNS intern auf autoconfig.provider.example zeigt, ändert den vom Client verwendeten Hostnamen nicht.

Setze solche CNAMEs daher nur, wenn Dein Provider Custom Domains ausdrücklich auf diese Weise unterstützt.

Konfiguration testen

Bei Autokonfiguration reicht es nicht, nur zu prüfen, ob DNS ungefähr richtig aussieht. Teste DNS, HTTPS und die eigentlichen Protokolle getrennt.

SRV-Records

dig +short SRV _imaps._tcp.example.com
dig +short SRV _submissions._tcp.example.com
dig +short SRV _submission._tcp.example.com
dig +short SRV _autodiscover._tcp.example.com

Prüfe bei Mail-SRV-Records anschließend, ob das Target direkt Adress-Records besitzt:

dig +short A mail.example.com
dig +short AAAA mail.example.com

Wenn stattdessen nur ein CNAME zurückkommt, ist das Target für einen standardkonformen SRV-Record ungeeignet.

Thunderbird Autoconfig

curl --fail-with-body \
  -D - \
  'https://autoconfig.example.com/mail/config-v1.1.xml?emailaddress=alice@example.com'

Damit kannst Du unter anderem kontrollieren:

HTTP-Status
TLS- beziehungsweise Zertifikatsfehler
eventuelle Redirect-Antworten
Content-Type
ausgeliefertes XML

Die XML-Syntax kannst Du zusätzlich lokal prüfen:

xmllint --noout /var/www/autoconfig/config-v1.1.xml

Das bestätigt allerdings nur, dass die Datei syntaktisch gültiges XML ist. Ob Thunderbird die darin enthaltenen Elemente und Werte akzeptiert, ist eine andere Frage.

Am Ende solltest Du deshalb ein echtes Testkonto mit Thunderbird einrichten.

Autodiscover-POST

Lege zunächst einen Beispielrequest an:

cat > /tmp/autodiscover-request.xml <<'EOF'
<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006">
  <Request>
    <EMailAddress>alice@example.com</EMailAddress>
    <AcceptableResponseSchema>http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a</AcceptableResponseSchema>
  </Request>
</Autodiscover>
EOF

Anschließend sendest Du ihn per POST:

curl --fail-with-body \
  -D - \
  -H 'Content-Type: text/xml; charset=utf-8' \
  --data-binary @/tmp/autodiscover-request.xml \
  https://autodiscover.example.com/Autodiscover/Autodiscover.xml

Der Server sollte mit Status 200 und der Autodiscover-Antwort reagieren.

Teste ruhig zusätzlich die kleingeschriebene Variante:

curl --fail-with-body \
  -D - \
  -H 'Content-Type: text/xml; charset=utf-8' \
  --data-binary @/tmp/autodiscover-request.xml \
  https://autodiscover.example.com/autodiscover/autodiscover.xml

Microsofts Remote Connectivity Analyzer kann den Autodiscover-Endpunkt zusätzlich von außen testen.

Ein erfolgreicher Test beweist aber nur, dass der Endpoint technisch erreichbar ist und eine brauchbare Autodiscover-Antwort liefert. Er beweist nicht, dass jede Outlook-Version daraus erfolgreich ein generisches IMAP-Konto erzeugt.

TLS des IMAP-Servers

Das Zertifikat des IMAP-Servers kannst Du mit OpenSSL prüfen:

openssl s_client \
  -connect mail.example.com:993 \
  -servername mail.example.com \
  -verify_return_error </dev/null

SMTP Submission auf Port 465

openssl s_client \
  -connect mail.example.com:465 \
  -servername mail.example.com \
  -verify_return_error </dev/null

SMTP Submission auf Port 587

Für STARTTLS:

openssl s_client \
  -starttls smtp \
  -connect mail.example.com:587 \
  -servername mail.example.com \
  -verify_return_error </dev/null

Damit prüfst Du nicht nur, ob der Port offen ist, sondern führst tatsächlich den TLS-Handshake aus.

Typische Stolperfallen

SRV-Unterstützung voraussetzen: Ein standardisierter Record bedeutet nicht, dass jeder Mailclient ihn bei der Kontoeinrichtung verwendet.
Thunderbird-SRV-Unterstützung erwarten: Thunderbirds eigenes Autoconfig-Verfahren basiert nicht einfach auf _imaps und _submission.
SRV-Target als CNAME anlegen: Das Target muss ein kanonischer Hostname mit Adress-Records sein.
Web-CNAME und SRV-Target verwechseln: Ein CNAME für autoconfig.example.com kann erlaubt sein, ein CNAME als SRV-Target nicht.
Priorität und Gewicht verwechseln: Priorität steuert die bevorzugten Server, Gewicht die Auswahl zwischen Servern derselben Priorität.
Falschen Login-Namen ausliefern: Manche Server erwarten die vollständige Mailadresse, andere nur den Local Part.
Port und TLS-Modus vermischen: Port 465 verwendet üblicherweise implizites TLS, Port 587 STARTTLS.
_submission und _submissions verwechseln: _submission gehört zur klassischen Submission, meist auf Port 587; _submissions bezeichnet Submission mit implizitem TLS, normalerweise Port 465.
Autodiscover nur per GET testen: Die eigentliche POX-Konfiguration wird normalerweise per POST mit XML-Body angefordert.
Groß- und Kleinschreibung ignorieren: Unter nginx können /Autodiscover/Autodiscover.xml und /autodiscover/autodiscover.xml unterschiedliche Pfade sein.
Microsoft-Dokumentationen blind mischen: Bei den POX-Namespaces existieren Microsoft-Seiten mit http:// und andere mit https://. Für eine protokollgetreue Implementierung solltest Du Dich an eine konkrete Spezifikation halten.
Statisches Autodiscover überschätzen: Eine statische Datei kann den individuellen Login-Namen nicht aus dem POST-Request übernehmen.
Unpassende Zertifikate: Sowohl Mailserver als auch Web-Endpunkte brauchen Zertifikate für die tatsächlich verwendeten Namen.
Redirects ungetestet lassen: Besonders bei Autodiscover gehören Redirects zum Suchverfahren. Ein unerwarteter Redirect kann aber auch dazu führen, dass ein Client an einer völlig anderen Stelle landet als geplant.
Nur mit curl testen: curl bestätigt das HTTP-Verhalten. Ob Thunderbird oder Outlook die Antwort anschließend wirklich verwenden, zeigt erst ein Test mit dem jeweiligen Client.
DNS-Caching vergessen: Nach Änderungen können Resolver und Clients alte Records bis zum Ablauf ihrer TTL weiterverwenden.

Fazit

Wenn Du eine eigene Mail-Domain betreibst, würde ich die Verfahren nicht gegeneinander ausspielen.

Standardkonforme SRV-Records nach RFC 6186 und RFC 8314 sind eine saubere DNS-basierte Beschreibung Deiner Maildienste und kosten kaum Aufwand. Verlasse Dich aber nicht darauf, dass jeder Client sie auswertet.

Für Thunderbird ist eine eigene config-v1.1.xml der wesentlich kontrollierbarere Weg. Dort kannst Du Server, Ports, TLS, Authentifizierung und das Format des Benutzernamens eindeutig vorgeben.

Autodiscover lohnt sich, wenn Outlook zu den Clients gehört, die Du unterstützen möchtest. Gerade bei einem normalen IMAP-/SMTP-Server solltest Du dabei aber mit den tatsächlich eingesetzten Outlook-Versionen testen und nicht von einer erfolgreichen XML-Abfrage auf eine erfolgreiche Kontoeinrichtung schließen.

Mit allen drei Mechanismen zusammen deckst Du deutlich mehr Clients ab. Eine universelle Autokonfiguration, die auf jedem Mailprogramm nur Mailadresse und Passwort verlangt, gibt es trotzdem nicht.

Quellen:

0 Kommentare

Noch keine Kommentare. Sei der/die Erste!

Autokonfiguration für die Mail-Domain: SRV, Autoconfig und Autodiscover

SRV-Records nach RFC 6186 und RFC 8314

Einen Dienst ausdrücklich deaktivieren

Das SRV-Ziel darf kein CNAME sein

Zertifikate bleiben notwendig

Thunderbird: Mozilla Autoconfig

Die Datei config-v1.1.xml

Thunderbird und SRV sind zwei verschiedene Dinge

Microsoft Autodiscover

Typische Endpunkte

Groß- und Kleinschreibung

Autodiscover verwendet normalerweise POST

Das Problem mit dem Benutzernamen

XML-Dateien mit nginx ausliefern

Thunderbird Autoconfig

Statisches Autodiscover trotz POST

Zertifikate für die Web-Endpunkte

Wenn Du nur die DNS-Zone kontrollierst

Konfiguration testen

SRV-Records

Thunderbird Autoconfig

Autodiscover-POST

TLS des IMAP-Servers

SMTP Submission auf Port 465

SMTP Submission auf Port 587

Typische Stolperfallen

Fazit

Ähnliche Beiträge

0 Kommentare

Die Datei `config-v1.1.xml`