MX-Infrastruktur: MX-Records richtig einrichten und prüfen

Was ein MX-Record regelt – und was nicht

Soll eine Nachricht an name@example.com zugestellt werden, fragt der sendende Mailserver im DNS nach den MX-Records von example.com. Jeder MX-Record enthält eine Präferenzzahl und den Namen eines Empfangsservers, den sogenannten Exchange. Der Sender ordnet die Ziele nach der Präferenz und baut eine SMTP-Verbindung zu einem von ihnen auf. RFC 5321, Abschnitt 5.1

Der MX-Record betrifft nur den Empfang. Welche Server Nachrichten mit Ihrer Domain versenden dürfen, beschreibt SPF; ob Nachrichten signiert sind, DKIM; wie Empfänger mit nicht authentifizierten Nachrichten umgehen sollen, DMARC. Keines dieser Verfahren setzt einen eigenen Empfangs-MX voraus. Nur der optionale SPF-Mechanismus mx greift auf die MX-Ziele zurück: Er zählt zum Limit von zehn DNS-auslösenden SPF-Termen, jeder MX-Name darf dabei höchstens zehn Adressabfragen auslösen, und fehlt ein MX-Record, gilt für diesen Mechanismus kein impliziter MX. RFC 7208, Abschnitte 4.6.4 und 5.4 Auch die Einstellungen für Mailprogramme – IMAP, POP3 oder Einlieferung – sind eine eigene Aufgabe; dafür gibt es SRV-Records nach RFC 6186 oder Konfigurationsdienste der Anbieter.

Quellen: RFC 5321, Abschnitt 5.1; RFC 7505, Abschnitte 1 und 3.

Aufbau eines MX-Eintrags

; Beispielzone mit Dokumentationsnamen und -adressen, keine echte Konfiguration
example.com.        3600  IN  MX    10 mx1.example.com.
example.com.        3600  IN  MX    20 mx2.example.com.
mx1.example.com.    3600  IN  A     203.0.113.10
mx1.example.com.    3600  IN  AAAA  2001:db8::10
mx2.example.com.    3600  IN  A     203.0.113.20

Der erste Name bezeichnet die Domain, für die empfangen wird. 3600 ist die Cachedauer (TTL) in Sekunden, 10 und 20 sind Präferenzen, der letzte Wert ist das Ziel. Die Präferenz ist eine Zahl von 0 bis 65535; kleinere Werte werden bevorzugt. RFC 1035, Abschnitt 3.3.9 In Zonendateien steht hinter vollständigen Namen ein Punkt; Verwaltungsoberflächen von DNS-Anbietern stellen dieselben Felder oft anders dar.

Das Ziel muss ein Hostname mit eigenen Adress-Records sein. Eine IP-Adresse ist kein MX-Ziel, und ein Alias (CNAME) darf dort nicht stehen. RFC 2181, Abschnitt 10.3 RFC 5321 ordnet eine Antwort, die auf einen Alias führt, ausdrücklich außerhalb des Standards ein. Ob einzelne Sender einem Alias trotzdem folgen, ist deshalb keine verlässliche Grundlage. Im Beispiel steht die AAAA-Zeile nur, weil mx1 annahmegemäß auch über IPv6 Mail annimmt; mehr dazu unter IPv4, IPv6 und Reverse DNS.

Präferenz, Ausfall und Warteschlange: was der sendende Server entscheidet

Die Präferenz bestimmt nur die Reihenfolge. Ein Sender muss die MX-Records danach sortieren; die kleinste Zahl wird zuerst versucht. Haben mehrere Ziele dieselbe Präferenz und gibt es keinen erkennbaren Grund, eines zu bevorzugen, muss der Sender die Reihenfolge zufällig wählen, um die Last zu verteilen. Eine gleichmäßige Aufteilung ist damit nicht zugesagt; sie hängt von der Zahl und dem Verhalten der Sender ab. Liefert ein Zielname mehrere Adressen, versucht der Sender sie in der Reihenfolge, die ihm sein Resolver liefert. RFC 5321, Abschnitt 5.1

Für einen einzelnen Zustellversuch verlangt RFC 5321, dass der Sender die relevanten Adressen der Reihe nach versuchen kann, bis eine Zustellung gelingt. Er darf die Zahl der Alternativen begrenzen und soll mindestens zwei Adressen versuchen. Postfix begrenzt etwa standardmäßig auf fünf MX-Adressen und auf zwei abgeschlossene SMTP-Sitzungen je Zustellanfrage (smtp_mx_address_limit, smtp_mx_session_limit). Ein drittes Ziel wird also nicht in jedem Fall im selben Durchgang erreicht. Postfix: Konfigurationsparameter

Quellen: RFC 5321, Abschnitte 4.2.1, 4.5.4.1 und 5.1.

Wiederholung und Aufgabezeit liegen beim Sender

RFC 5321 verlangt für vorübergehend nicht zustellbare Nachrichten, dass ein Sender diese in eine Warteschlange stellt und periodisch erneut versucht. Nach einem Fehlschlag muss er vor dem nächsten Versuch warten; der Abstand soll in der Regel mindestens 30 Minuten betragen. Zur Aufgabezeit heißt es, sie müsse „generally … at least 4-5 days“ betragen – eine allgemeine Richtgröße ohne verbindliches Schlüsselwort. Verbindlich ist dagegen, dass die Parameter des Wiederholungsverfahrens konfigurierbar sind. RFC 5321, Abschnitt 4.5.4.1

Entsprechend unterschiedlich sind die Voreinstellungen: Postfix gibt standardmäßig nach fünf Tagen auf (maximal_queue_lifetime), die Standardkonfiguration von Exim nach vier Tagen ab dem ersten Fehlschlag. Andere Sender können kürzere oder längere Fristen verwenden. RFC 7505 beschreibt für Ziele ohne SMTP-Dienst Wiederholungen über „typically a week“. Postfix, Exim-Standardkonfiguration, RFC 7505, Abschnitt 1

Backup-MX: wann er hilft und was er voraussetzt

Die Warteschlangen sendender Server können kurze Unterbrechungen auch bei nur einem MX überbrücken. Das setzt voraus, dass der Sender die Nachricht weiter vorhält und der Empfang vor seiner Aufgabezeit wieder funktioniert. Ein Backup-MX mit höherer Präferenzzahl nimmt Nachrichten während eines Ausfalls stattdessen an und reicht sie später weiter. Das kann sinnvoll sein, wenn Sie längere Wartungsfenster haben oder Nachrichten unter eigener Kontrolle zwischenspeichern wollen.

Ein veröffentlichter MX-Eintrag ist jedoch für alle sichtbar, und die Präferenz ist nur eine Regel für Sender. Wer eine SMTP-Verbindung aufbaut, kann jedes veröffentlichte Ziel direkt ansprechen – auch den Backup-MX, während der Hauptserver erreichbar ist. Daraus folgen drei Voraussetzungen:

1. Gleiche Empfängerprüfung: Der Backup-MX muss wissen, welche Adressen es gibt, und unbekannte Empfänger schon im SMTP-Dialog ablehnen. Hat er die vollständige Nachricht mit der abschließenden 250-Antwort nach DATA angenommen, ist er für Zustellung oder Fehlermeldung verantwortlich; scheitert die Weiterleitung später, muss er grundsätzlich eine Unzustellbarkeitsnachricht an den Rückpfad schicken, der bei Spam gefälscht sein kann. Bei leerem Rückpfad darf keine weitere Fehlermeldung entstehen. RFC 5321, Abschnitt 6.1 Postfix sieht für einen Backup-MX deshalb eine Liste gültiger Empfänger vor (relay_recipient_maps), damit sich die Warteschlange nicht mit unzustellbaren Rückmeldungen füllt. Postfix: Backup-MX
2. Gleiche Filterung: Spam- und Schadsoftwareprüfung, die nur am Hauptsystem läuft, lässt sich über den Backup-MX umgehen.
3. Gateway vor dem Postfachsystem: Steht ein Secure Email Gateway oder ein Filterdienst vor Ihrem Postfachsystem, gehören alle MX-Einträge zum Gateway, und das dahinterliegende System sollte nur Verbindungen des Gateways annehmen. Wie Gateways, Weiterleitungen und Authentifizierungsergebnisse zusammenwirken, erklärt ARC und Secure Email Gateways.

Bei gehosteten Diensten übernehmen Sie genau den vom Anbieter dokumentierten MX-Satz. Einen zusätzlichen eigenen Backup-MX sollten Sie dort nur eintragen, wenn der Anbieter das ausdrücklich vorsieht; sonst gelangen Nachrichten an dessen Empfängerprüfung und Filterung vorbei zu einem System, das der Dienst nicht kennt. Nutzen Sie die dokumentierten Werte Ihres tatsächlichen Empfangsdienstes.

Der E-Mail Security Check misst keine Backup-MX-Ziele und prüft weder Firewall- noch Filter- oder Empfängerregeln. Wenn MX-Namen zu einem bekannten Gateway- oder Anbietermuster passen, folgt daraus keine Aussage darüber, ob ein Backup abgeschirmt ist.

Null MX: erklären, dass eine Domain keine E-Mail annimmt

Ein Null MX ist ein einzelner MX-Record mit Präferenz 0 und dem Ziel ., also einem leeren Namen. Er erklärt, dass unter diesem Namen keine E-Mail angenommen wird. Neben einem Null MX darf kein weiterer MX-Record stehen. RFC 7505, Abschnitt 3

; Name, der niemals E-Mail empfangen soll (Beispiel)
static.example.com.   3600  IN  MX  0 .

Sendende Systeme erkennen damit schon beim ersten Versuch, dass eine Zustellung aussichtslos ist; Warteschlange und Wiederholungen entfallen. Falsch adressierte Nachrichten scheitern sofort statt Stunden oder Tage später, und Rückmeldungen an gefälschte Absenderadressen dieser Domain lassen sich schnell verwerfen. RFC 7505, Abschnitt 4.1

Beide Codes sind Empfehlungen (SHOULD); der Meldungstext ist frei. Hat ein sendender Server die Nachricht bereits angenommen, meldet er den Fehlschlag dem Absender per Unzustellbarkeitsnachricht. RFC 7505, Abschnitt 4.1, RFC 7504, Abschnitt 4

C: RCPT TO:<info@static.example.com>
S: 556 5.1.10 Recipient address has null MX

Veröffentlichen Sie keinen Null MX für Domains, die Sie als Rückpfad oder als sichtbare Absenderdomain verwenden: Empfänger können solche Nachrichten ablehnen; RFC 7505 empfiehlt dies ausdrücklich. RFC 7505, Abschnitt 4.2 Für Domains, die weder senden noch empfangen, ergänzt eine SPF-Policy v=spf1 -all die Erklärung zum Versand; eine DMARC-Policy ist eine weitere, getrennte Maßnahme. Null MX verhindert weder, dass jemand Ihre Domain in gefälschten Absenderangaben verwendet, noch sperrt er den Versand.

Kandidaten sind Namen, die nie E-Mail empfangen sollen, etwa reine Web-, Asset- oder Trackinghosts. Prüfen Sie vorher, dass sie weder als Absender- noch als Rückpfaddomain dienen und dass niemand dort Nachrichten erwartet. Ein Null MX gilt nur für den Namen, an dem er steht; für jede weitere Subdomain ist eine eigene Entscheidung nötig.

Der E-Mail Security Check erkennt einen gültigen Null MX am eingegebenen Namen und meldet widersprüchliche Kombinationen. Weitere Subdomains untersucht er nicht. Hat der Name einen Null MX und keinen regulären SPF-Eintrag, bewertet der Check ihn in einem eigenen Profil für nicht sendende Domains mit SPF -all, DMARC-Policy und Null MX. Ob tatsächlich niemand mit der Domain versendet, prüft er nicht.

IPv4, IPv6 und Reverse DNS: was für Empfang und Versand gilt

Ein MX-Ziel kann A-Records (IPv4), AAAA-Records (IPv6) oder beide haben; RFC 5321 schreibt keine bestimmte Kombination vor. RFC 5321, Abschnitt 5.2 Veröffentlichen Sie eine Adressfamilie nur, wenn der Server darüber tatsächlich E-Mail annimmt. Sonst können vergebliche Verbindungsversuche entstehen, bevor ein Sender eine andere Adresse versucht oder die Nachricht zurückstellt. Ein vorhandener AAAA-Record beweist keine funktionierende IPv6-Annahme; ein fehlender beweist keinen Mangel eines bewusst über IPv4 betriebenen Empfangs.

Reverse DNS (PTR) ordnet einer IP-Adresse einen Namen zu. Für reine Empfangsserver schreibt SMTP keinen PTR vor. Anders beim Versand: Google verlangt von allen Absendern an private Gmail-Konten gültige Vorwärts- und Rückwärtseinträge für die sendenden IP-Adressen; der Name im PTR muss per A (IPv4) oder AAAA (IPv6) wieder auf die sendende Adresse zeigen. Yahoo verlangt ebenfalls gültige Vorwärts- und Rückwärtseinträge für sendende IPs. Google: Richtlinien für E-Mail-Absender, Yahoo: Sender Best Practices Wer über IPv6 sendet, braucht also einen passenden IPv6-PTR. Eine Pflicht, über IPv6 zu senden oder zu empfangen, folgt daraus nicht.

Viele selbst betriebene Server empfangen und senden zugleich. Dann gelten die Anforderungen an sendende Adressen auch für den Host, der als MX eingetragen ist. Unabhängig davon empfiehlt RFC 1912, Abschnitt 2.1 (Informational), für jede IP-Adresse einen PTR zu pflegen, der zum A-Record passt. Den PTR setzt der Inhaber des Adressbereichs, meist Ihr Hosting- oder Netzanbieter über dessen Verwaltung, nicht Ihre eigene Domainzone.

; Vorwärtsauflösung in Ihrer Zone (Dokumentationsadressen)
mx1.example.com.   3600  IN  A     203.0.113.10
mx1.example.com.   3600  IN  AAAA  2001:db8::10

; Rückwärtsauflösung, gepflegt vom Inhaber des Adressbereichs
10.113.0.203.in-addr.arpa.  IN  PTR  mx1.example.com.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.  IN  PTR  mx1.example.com.

Eine Prüfung der Vorwärts-Rückwärts-Konsistenz (FCrDNS) läuft so: Adresse → PTR-Name → A- beziehungsweise AAAA-Record dieses Namens → wieder dieselbe Adresse.

Der E-Mail Security Check prüft PTR und Rückauflösung nur für die erste IPv4-Adresse des ersten MX. IPv6-Reverse-DNS, weitere Adressen, weitere MX und die tatsächlich sendenden Server prüft er nicht. Zusatzpunkte für einen passenden PTR am MX sind eine Gewichtung des Produkts, keine Normanforderung an Empfangsserver.

DNSSEC für MX-Antworten: was die Signatur schützt

Ohne DNSSEC kann ein Angreifer, der DNS-Antworten fälschen oder einen Resolver-Cache vergiften kann, einem Sender falsche MX-Ziele unterschieben. Ist Ihre Zone signiert und prüft der Resolver des Senders die Signaturen, erkennt dieser gefälschte oder veränderte Antworten und liefert sie nicht aus. Der Schutz entsteht also nur im Zusammenspiel von signierter Zone und validierendem Resolver auf der Senderseite.

DNSSEC verschlüsselt keine Nachricht, schützt nicht vor Änderungen über ein kompromittiertes Konto beim DNS-Anbieter oder Registrar und belegt keine Zustellung. Es sichert auch nicht automatisch die Zonen der MX-Ziele: Liegt mx1.example.net in einer anderen, unsignierten Zone, sind dessen Adressantworten nicht geschützt.

# Beispielabfrage, hier nicht ausgeführt
dig +dnssec example.com MX

Ein ad-Flag in der Antwort bedeutet, dass der befragte Resolver die Antwort als authentisch einstuft. RFC 4035, Abschnitt 3.2.3 Aussagekräftig ist das nur, wenn Sie diesem Resolver und dem Weg zu ihm vertrauen. Fehlt das Flag, kann die Zone unsigniert sein, der Resolver nicht validieren oder die Vertrauenskette unterbrochen sein. Scheitert die Prüfung einer signierten Antwort, meldet ein validierender Resolver SERVFAIL. RFC 4035, Abschnitt 5.5

DANE für SMTP baut auf DNSSEC auf: Es veröffentlicht TLSA-Records für die MX-Hosts und setzt DNSSEC-validierte MX- und TLSA-Antworten voraus. MTA-STS arbeitet ohne DNSSEC über eine HTTPS-Policy. Details: DNS-Sicherheit: DANE und TLSA, SMTP-TLS und MTA-STS.

Die Technische Richtlinie BSI TR-03108 (Version 2.0) macht für E-Mail-Dienstanbieter, die ihre Konformität mit dieser Richtlinie nachweisen wollen, unter anderem einen DNSSEC-validierenden Resolver, die DNSSEC-Signatur der Zonen von Empfangsdomain und Mailserver sowie DANE zur Pflicht. BSI TR-03108 Eine allgemeine Pflicht für jede Domain folgt daraus nicht. Ob für Ihre Organisation rechtliche Anforderungen gelten, behandelt das Kapitel E-Mail-Compliance.

Der E-Mail Security Check wertet für die MX- und die TXT-Antwort am eingegebenen Namen das AD-Signal seines eigenen validierenden Resolvers aus. Signaturen prüft er nicht selbst; Zonengrenzen, DS-Records, Algorithmen und die Zonen der MX-Ziele gehören nicht zu dieser Messung.

Alias-Ziele, Flattening und Proxy-Funktionen von DNS-Anbietern

Nach dem Standard zeigt ein MX auf einen Namen mit eigenen Adress-Records, nicht auf einen Alias. Manche DNS-Anbieter bieten jedoch Funktionen, die statt eines Alias direkt Adressdaten ausliefern („CNAME Flattening“) oder Webverkehr über einen Proxy leiten. Beides kann verändern, was ein Sender tatsächlich als Antwort erhält. Am Beispiel der Cloudflare-Dokumentation:

• Flattening: Cloudflare löst einen CNAME an der Zonenspitze standardmäßig auf und liefert die Zieladresse statt des Alias aus; in bezahlten Tarifen auch für alle oder einzelne CNAMEs. Zeigt das Aliasziel auf keine Adresse, bleibt die Antwort leer. Cloudflare: CNAME Flattening, Einrichtung
• Proxy: Für per Proxy ausgelieferte Namen antwortet Cloudflare mit eigenen Anycast-Adressen; SMTP läuft über diesen Proxy nicht. Zeigt ein MX auf einen solchen Namen, fügt Cloudflare in MX-Antworten automatisch einen Namen der Form _dc-mx.<kennung>.example.com ein, der auf die Ursprungsadresse zeigt. Die öffentliche MX-Antwort weicht dann vom Eintrag in der Verwaltungsoberfläche ab. Cloudflare: unerwartete DNS-Records

Andere Anbieter haben ähnliche, nicht standardisierte Funktionen unter eigenen Namen; maßgeblich ist deren Dokumentation. Verwenden Sie für MX-Ziele einen eigenen Hostnamen ohne Alias und ohne Proxy, mit den Adressen des Mailservers. Kontrollieren Sie danach die öffentlichen Antworten, wie im Abschnitt Prüfen beschrieben.

; Empfohlen: MX zeigt auf einen Namen mit eigenen Adressdaten
example.com.        IN  MX     10 mx1.example.com.
mx1.example.com.    IN  A      203.0.113.10

; Nicht standardkonform: MX zeigt auf einen Alias
example.com.        IN  MX     10 mail.example.com.
mail.example.com.   IN  CNAME  mx.provider.example.

Der E-Mail Security Check gibt für Alias-Ziele keine eigene Warnung aus; seine SMTP-Probe löst den Namen auf wie ein Sender. Wie sich die Wahl des DNS-Anbieters auf DNSSEC und Schlüsselwechsel auswirkt, erklärt DNS-Sicherheit: DNS-Anbieter wählen.

MX-Konfiguration prüfen: DNS, Verbindung und Nachricht getrennt

Drei Ebenen beantworten verschiedene Fragen. Ein Erfolg auf einer Ebene beweist die nächste nicht.

1. DNS lesen. Die folgenden Abfragen lesen nur DNS. Ersetzen Sie example.com durch Ihre Domain und mx1.example.com durch jeden zurückgegebenen MX-Host. Halten Sie Antwortstatus, verwendeten Resolver und Zeitpunkt fest. Die Befehle wurden für diesen Ratgeber nicht ausgeführt.

dig example.com MX
dig mx1.example.com A
dig mx1.example.com AAAA

Unter Windows fragen Sie DNS ausdrücklich so ab:

Resolve-DnsName -Name example.com -Type MX -DnsOnly
Resolve-DnsName -Name mx1.example.com -Type A -DnsOnly
Resolve-DnsName -Name mx1.example.com -Type AAAA -DnsOnly

Vergleichen Sie Ziele, Präferenzen und Adressen mit Ihrer Planung beziehungsweise den Vorgaben Ihres Maildienstes. Eine leere Ausgabe ohne Antwortstatus ist kein Nachweis, dass keine MX-Records existieren. BIND: dig, Microsoft: Resolve-DnsName

2. Verbindung prüfen. Testen Sie für Ihre eigenen MX-Hosts die SMTP-Annahme auf Port 25, einschließlich STARTTLS, aus einem Netz, das ausgehende Verbindungen auf Port 25 erlaubt. Die passenden Befehle und ihre Grenzen stehen im Ratgeber SMTP-TLS. Prüfen Sie nur Systeme, die Sie betreiben oder prüfen dürfen.

3. Nachricht senden. Schicken Sie von einem externen Konto eine kontrollierte Testnachricht an ein Postfach Ihrer Domain. Die Received-Kopfzeilen zeigen, welcher Server sie angenommen hat.

Was der E-Mail Security Check an MX-Daten erhebt

Der Hauptstandort startet zuerst; nach drei Sekunden ohne verwertbares Ergebnis oder früherem Fehlschlag kann der zweite Standort hinzukommen. Gewertet wird das erste vollständige Ergebnis, kein systematischer Standortvergleich. Eine Zeitüberschreitung oder ein abgebrochener Test ist ein offener Befund, kein Nachweis fehlender Verschlüsselung. Der MX-Befund selbst trägt keine Punkte. Lesen Sie im Ergebnis den genannten Host, den Zeitpunkt und die offenen Prüfungen; der Prüfumfang des Checks ist auf seiner Seite beschrieben.

Typische Fehlerbilder

• MX zeigt auf eine IP-Adresse oder einen Alias: Ziel durch einen Hostnamen mit eigenen A- oder AAAA-Records ersetzen.
• Null MX neben weiteren MX-Records: Entscheiden, ob der Name Mail empfangen soll; dann entweder nur reguläre MX-Records oder allein den Null MX veröffentlichen.
• Backup-MX nimmt jede Adresse an: Empfängerliste und Filterung an das Hauptsystem angleichen; sonst entstehen Rückmeldungen an gefälschte Absender.
• MX zeigt auf einen per Proxy ausgelieferten Webnamen: Einen eigenen Namen ohne Proxy für den Mailserver verwenden; _dc-mx-Namen in Antworten als Anbieterfunktion einordnen.
• AAAA veröffentlicht, IPv6-Empfang nicht eingerichtet: Dienst und Firewall für IPv6 einrichten oder den AAAA-Record am MX-Namen entfernen.
• Kein MX, aber ein A-Record auf den Webserver: Soll die Domain empfangen, MX-Records einrichten; soll sie nicht empfangen, einen Null MX veröffentlichen.
• Nach einem Anbieterwechsel kommen Nachrichten beim alten Dienst an: Alte MX-Records, ihre TTL und die zuständigen Nameserver prüfen. Solange Caches den alten Stand liefern, stellen manche Sender noch beim alten Dienst zu; planen Sie einen Nachlauf, in dem dort eingehende Nachrichten abgeholt werden.
• Verschiedene Resolver liefern verschiedene Antworten: Delegation und alle autoritativen Nameserver der Zone prüfen, siehe DNS-Sicherheit.

Prüfstand dokumentieren und Nachweisgrenzen

Wenn Sie den Stand intern oder gegenüber Dritten festhalten, notieren Sie Domain, DNS-Betreiber, MX-Einträge mit Präferenzen und TTL, die Zieladressen je Adressfamilie, die tatsächlich geprüften Hosts mit Zeitpunkt sowie offene oder nicht ausgeführte Prüfungen. Ein datiertes Prüfergebnis dokumentiert eine Momentaufnahme; es ersetzt weder eine laufende Überwachung noch einen Nachweis rechtlicher Pflichten. Welche Anforderungen für Ihre Organisation gelten können, behandelt das Kapitel E-Mail-Compliance. Aufbau und Grenzen gespeicherter Ergebnisse erklärt die Reportübersicht.

Passende nächste Themen