MX-Infrastruktur: MX-Records korrekt konfigurieren

Email Security · Fundament

Was ist ein MX-Record? Das DNS-Fundament der E-Mail-Zustellung

Ein MX-Record (Mail Exchange Record, RFC 5321 § 5) ist ein DNS-Eintrag, der den sendenden Mailservern signalisiert, welche Hosts eingehende E-Mails für eine Domain annehmen. Ohne MX-Record kann keine E-Mail zugestellt werden — der sendende Server bekommt einen NXDOMAIN-Fehler und bounct die Nachricht. Im Wolf-Agents Email Security Check sind MX-Records mit 5 Punkten bewertet, und ohne MX-Record wird die Gesamtnote per Grade-Cap auf F begrenzt.

MX-Records sind die Basis jeder weiteren E-Mail-Sicherheitsmaßnahme. SPF, DKIM und DMARC bauen auf einer korrekten MX-Konfiguration auf. Manipulierte oder ungeschützte MX-Records (ohne DNSSEC) öffnen direkt die Tür für Domain-Spoofing und SubdoMailing-Angriffe — die NIS2-Richtlinie (Art. 21 Abs. 2 lit. h) fordert deshalb explizit Konzepte für Kryptografie und Verschlüsselung, inklusive DNSSEC für die DNS-Zonen mit MX-Records.

Grade-Cap F Ohne MX-Record begrenzt der Wolf-Agents Scanner die Gesamtnote auf F — keine Zustellung, keine Authentifizierung Wolf-Agents Email Security Check

RFC 5321 SMTP-Standard seit 2008 — Priority-Mechanik, 4-5-Tage-Retry und FQDN-Pflicht IETF RFC 5321 § 5

5 Punkte MX + PTR/FCrDNS + Redundanz im Wolf-Agents Email Security Check (165 Punkte gesamt) Wolf-Agents Scanner

Aufbau eines MX-Records (RFC 1035 + RFC 5321)

ihre-domain.de.   IN  MX  10  mx1.ihre-domain.de.
ihre-domain.de.   IN  MX  20  mx2.ihre-domain.de.
mx1.ihre-domain.de.  IN  A     203.0.113.10
mx1.ihre-domain.de.  IN  AAAA  2001:db8::10
mx2.ihre-domain.de.  IN  A     203.0.113.20
mx2.ihre-domain.de.  IN  AAAA  2001:db8::20

Vier Felder: Domain (für welche die Records gelten), Typ (MX), Priorität (numerisch, niedriger = wichtiger) und Exchange (FQDN mit abschließendem Punkt). Der Hostname im Exchange-Feld muss per A- oder AAAA-Record auflösbar sein — CNAMEs sind laut RFC 2181 § 10.3 als MX-Ziel ausdrücklich verboten und führen bei strikten Resolvern zu Zustellfehlern.

Priority & Backup-MX

MX-Priority + Multi-MX-Setup: Wie Priorität, Fallback und Round-Robin zusammenspielen

Niedrigere Prioritätszahl = höhere Priorität. Der sendende Mailserver versucht zuerst den MX mit der niedrigsten Zahl — bei Erreichbarkeit ist die Zustellung dort abgeschlossen, bei Fehler weiter zum nächsten Wert. Bei gleicher Priorität verteilt der Sender per Round-Robin zufällig zwischen den Hosts. RFC 5321 § 4.5.4.1 fordert, dass nicht erreichbare MX-Server für mindestens 4-5 Tage retried werden, bevor die E-Mail mit Bounce zurückgeht — diese Queue-Garantie ist der Grund, warum Backup-MX-Server für Self-Hosted-Setups oft optional sind.

Ablauf der MX-Auswahl beim sendenden Server

Sendender Mailserver fragt DNS nach MX-Records für example.com

DNS-Antwort:
  10  mx1.example.com.     (primär)
  20  mx2.example.com.     (sekundär / Backup)
  30  mx3.example.com.     (tertiär)

Verbindungsversuch 1 → mx1.example.com  (niedrigste Priorität)
  ├─ Erfolgreich  → E-Mail zustellen, fertig.
  └─ Timeout/451  → Weiter zu mx2

Verbindungsversuch 2 → mx2.example.com
  ├─ Erfolgreich  → E-Mail zustellen, fertig.
  └─ Timeout/451  → Weiter zu mx3

Verbindungsversuch 3 → mx3.example.com
  ├─ Erfolgreich  → E-Mail zustellen, fertig.
  └─ Alle nicht erreichbar:
       In Queue halten → Retry für mindestens 4–5 Tage
       (RFC 5321 § 4.5.4.1)

MX-Bypass: Wie Angreifer den Backup-MX missbrauchen

Falsch konfigurierte Backup-MX-Server sind ein häufig genutzter Angriffsvektor. Wenn Ihr Secure Email Gateway (Proofpoint, Mimecast, Barracuda) auf Priorität 10 läuft und ein hauseigener Mailserver auf Priorität 20 als Backup steht, kann ein Angreifer per gezielter Verbindung direkt an Priorität 20 zustellen — das SEG wird vollständig umgangen, alle Filter, Sandboxing und Anti-Phishing-Regeln greifen nicht. Lösung: Entweder alle MX-Hosts hinter dem SEG, oder der Backup-MX akzeptiert nur Verbindungen vom primären MX (per Firewall-Regel oder SMTP-Whitelist). Der Wolf-Agents Email Security Check erkennt diese Konfiguration und warnt explizit, wenn Backup-MX-Server außerhalb des Gateway-Perimeters liegen.

RFC 7505 · Anti-Spoofing

Null MX (RFC 7505): Domains ohne E-Mail-Empfang sauber kennzeichnen

Null MX (RFC 7505, 2015) ist die Standard-Methode, Domains zu kennzeichnen, die keine E-Mails empfangen sollen — beispielsweise Marketing-Subdomains (campaign.example.com), Asset-Hosts (cdn.example.com) oder reine Web-Domains (status.example.com). Der MX-Record mit Priorität 0 und einem einzelnen Punkt als Hostname signalisiert sendenden Servern, dass die E-Mail sofort mit permanentem Fehler (550 5.1.10) abgelehnt werden soll — kein Queue, kein Retry, keine Backscatter-Bounces.

Null-MX-Konfiguration nach RFC 7505

# Domain soll niemals E-Mails empfangen (Marketing-, Asset-Subdomain etc.)
nicht-mail.example.com.   IN  MX  0  .

# Wirkung beim Sender (RFC 7505 § 3):
#   550 5.1.10 The domain example.com does not accept mail (nullMX)
# → keine Queue, kein Retry, sofortiger permanenter Fehler.

Ohne Null MX würde ein Spoofing-Angriff auf campaign.example.com bei jedem Empfänger zumindest eine Bounce-Schleife produzieren — der sendende Server queued die Nachricht 4-5 Tage und antwortet erst dann mit „domain not found“. Mit Null MX bleibt die Angriffsfläche eliminiert: jede gefälschte Nachricht wird in unter einer Sekunde abgelehnt. Auch Backscatter-Spam (Spam an gefälschte Absender-Adresse mit Bounce-Verstärkung) wird durch Null MX vermieden.

Wo Null MX besonders wirksam ist (Wolf-Agents-Empfehlung)

Setzen Sie Null MX gezielt auf alle Subdomains, die nie E-Mails empfangen sollen: marketing., cdn., assets., img., api., www. (sofern getrennt vom Apex), track., links.. Kombination mit einer strikten DMARC-Policy (p=reject) auf dem Apex schließt zusätzlich Direct-Domain-Spoofing — siehe Cross-Verweis DMARC-Kapitel. Der Wolf-Agents Email Security Check verifiziert Null MX automatisch und vergibt Bonus-Punkte für korrekte Anti-Spoofing-Subdomain-Härtung.

Dual-Stack · IPv6-AAAA

IPv6 + AAAA-MX: Reverse-DNS und Dual-Stack für moderne Zustellung

Seit Februar 2024 verlangen Google und Yahoo für Bulk-Sender (über 5.000 Mails/Tag) explizit funktionierendes IPv6 inklusive PTR/FCrDNS. Auch wenn IPv6-only-Empfang noch selten ist: Eine MX-Konfiguration ohne AAAA-Records signalisiert „veraltete Infrastruktur“ — die Reputations-Scores bei Google Postmaster Tools sinken, Zustellverzögerungen steigen. Wer eine moderne E-Mail-Infrastruktur betreibt, hat den MX-Hostnamen sowohl mit A-Record (IPv4) als auch AAAA-Record (IPv6) und gültigen PTR-Records für beide Adressfamilien.

Dual-Stack-Konfiguration für MX-Hosts

# Dual-Stack-Setup für Mailserver (Pflicht ab 2026 für Bulk-Sender Google/Yahoo)
mx1.ihre-domain.de.   IN  A     203.0.113.10
mx1.ihre-domain.de.   IN  AAAA  2001:db8:42::10

# Reverse-DNS (PTR): bei IP-Provider eintragen
10.113.0.203.in-addr.arpa.            IN  PTR  mx1.ihre-domain.de.
0.1.0.0.0.0.0.0.0.0.0.0.2.4.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR mx1.ihre-domain.de.

# FCrDNS-Prüfung beim Sender (Google, Microsoft):
# 1. PTR → mx1.ihre-domain.de
# 2. A/AAAA von mx1.ihre-domain.de → muss zur ursprünglichen IP zurückzeigen.

FCrDNS (Forward-Confirmed Reverse DNS) verlangt, dass PTR-Record und A/AAAA-Record bidirektional konsistent sind. Google Gmail lehnt eingehende E-Mails ohne gültigen PTR-Record häufig als Spam ab — und für die MX-Seite gilt sinngemäß dasselbe: Mailserver mit generischen PTR-Records wie vps12345.provider.com werden als unprofessionell eingestuft. Bei Cloud-Providern (Hetzner Cloud, Netcup vServer, AWS) wird der PTR-Record im Provider-Panel gesetzt, nicht in der eigenen DNS-Zone.

RFC 4033 · NIS2 lit. h

DNSSEC für MX-Records: Kryptografische Bindung gegen DNS-Hijacking

Ohne DNSSEC kann ein Angreifer im Netzwerkpfad oder via Cache-Poisoning den MX-Record manipulieren und eingehende E-Mails auf einen feindlichen Server umleiten — ein Angriff, der für die Domain-Inhaber zunächst unsichtbar bleibt, weil ausgehende E-Mails normal funktionieren. DNSSEC signiert die DNS-Antworten kryptografisch (RRSIG-Records), sodass der sendende Mailserver Manipulation erkennt. Für MX-Records ist DNSSEC die zentrale Schutzschicht gegen DNS-basierte Übernahme und damit eine direkte NIS2-Anforderung (Art. 21 Abs. 2 lit. h Kryptografie und Verschlüsselung).

DNSSEC-Validierung sichtbar machen

# DNSSEC-Validierung der MX-Records sichtbar machen
dig +dnssec MX ihre-domain.de

# Erwartete Antwort (gekürzt):
;; ANSWER SECTION:
ihre-domain.de.   3600  IN  MX     10 mx1.ihre-domain.de.
ihre-domain.de.   3600  IN  RRSIG  MX 13 2 3600 20260615... (Signatur)

;; flags: qr rd ra ad;        ← "ad" = Authenticated Data
                              ← Resolver hat DNSSEC validiert.

Das Flag ad (Authenticated Data) in der Antwort zeigt, dass der Resolver die DNSSEC-Kette bis zur Root-Zone validieren konnte. Fehlt das Flag, ist die DNSSEC-Validierung unvollständig (typisches Symptom: DS-Record fehlt bei der Registrar-Stelle oder die Zone ist nicht signiert). Aufbauend auf DNSSEC bringt MTA-STS und DANE (RFC 7672) die kryptografische Bindung auch zur TLS-Schicht — DANE verlangt zwingend DNSSEC, MTA-STS funktioniert auch ohne. Beide Standards werden im DNS-Sicherheits-Kapitel vertieft.

DNS-Provider · Apex-CNAME

MX-Flattening & CNAME-Probleme: Wie DNS-Provider helfen

RFC 2181 § 10.3 verbietet CNAMEs als MX-Ziel — sendende Mailserver dürfen einen CNAME im Exchange-Feld nicht folgen. In der Praxis nutzen viele Domain-Inhaber Cloud-Mailserver wie Microsoft 365 oder Google Workspace, deren MX-Hostnamen ohnehin auf Apex-Cluster zeigen, aber wenn der eigene Apex-A-Record per ALIAS/ANAME auf einen externen Hostnamen verweist, kann das mit dem MX-Lookup-Verhalten kollidieren. MX-Flattening bei DNS-Providern (Cloudflare DNS) löst die externe Resolution Server-seitig auf und liefert IP-Adressen direkt aus — der Sender sieht nur saubere A/AAAA-Records.

Wo MX-Flattening relevant wird

Cloudflare DNS bietet das integrierte Email Routing zusätzlich zum eigenen MX-Hosting an — der Apex-Domain wird ein Cloudflare-MX-Cluster zugewiesen (route1.mx.cloudflare.net, route2.mx.cloudflare.net, route3.mx.cloudflare.net), Cloudflare Workers können benutzerdefinierte Routing-Regeln in JavaScript ausführen. Hetzner DNS hostet MX-Records via DNS Console und Robot-API, ohne eigenes Email-Routing — der MX zeigt direkt auf den Mailserver Ihrer Wahl. Beide DNS-Provider unterstützen DNSSEC mit 1-Click-Aktivierung und automatischer DS-Record-Synchronisation zum Registrar.

DNS-Provider-Wahl + DNSSEC-Algorithmen-Vergleich (Information-Gain R3-Mehrwert)

Die Wahl des DNS-Providers entscheidet implizit auch über den DNSSEC-Algorithmus, der für die MX-Signatur verwendet wird. Cloudflare DNS bevorzugt ECDSAP256SHA256 (Algorithmus 13, RFC 6605, modernste Empfehlung — direkt bestätigt auf developers.cloudflare.com/dns/dnssec: „Algorithm 13 - Cloudflare's preferred cipher choice“). Hetzner DNS: Die letzte explizit datierte Hetzner-Dokumentation zu DNSSEC stammt vom Oktober 2018 (publiziert 25. März 2020) und beschreibt DNSSEC dort als nicht unterstützt — den aktuellen Status der Hetzner DNS Console sollten Sie pro Zone selbst im Panel verifizieren (Cross-Welle-Konsistenz mit DNS-Sicherheit für Hetzner DNS); Alternative: deSEC.io oder Cloudflare DNS. Bei einem Wechsel zwischen DNS-Providern muss der DS-Record beim Registrar exakt zum neuen Algorithmus passen — Mischbetrieb führt zu Validierungs-Fehlern. Multi-Provider-DNSSEC nach RFC 8901 ermöglicht parallel signierende Provider (Primary + Secondary mit eigenen Schlüsseln, alle DNSKEYs im gemeinsamen RRset) — Cloudflare unterstützt das per dnssec_multi_signer-Flag. Pattern-Detail im DNS-Sicherheit-Kapitel-Sektion 6 „DNS-Provider-Wahl“. Wolf-Agents-Scanner erkennt den Algorithmus automatisch und warnt bei DS-Record-Asymmetrie.

Backup-MX-Services + kostenlose Email-Forwarder (Wettbewerber-Übersicht)

Wer einen externen Backup-MX-Service braucht, hat 2026 mehrere Optionen: DuoCircle Secondary MX (kommerzielles Backup-MX-Spooling für bestehende Mailserver, Preismodell laut Wolf-Agents-Recherche 2026-05-14 — Direkt-Verifikation eingeschränkt durch nicht erreichbare Pricing-URL), Cloudflare Email Routing (kostenlos, integriert in Cloudflare DNS, Hostnamen route1-3.mx.cloudflare.net mit pseudo-zufälligen Prio 1-99), ImprovMX (Email-Forwarding-Service, MX-Server mx1.improvmx.com + mx2.improvmx.com, kostenloser Plan ohne Kreditkarte; Hostnamen direkt via improvmx.com 2026-05-16 verifiziert, Gründungsjahr nicht offiziell dokumentiert) und Forward Email (Open-Source, Zero-Knowledge-Architektur direkt auf forwardemail.net bestätigt 2026-05-16, Free-Tier mit 50 MB Attachment-Limit, kostenpflichtige Enhanced-Protection-Stufe mit SMTP-Versand). Wichtig: Jeder externe Backup-MX bringt das klassische MX-Bypass-Risiko — Angreifer können den primären Filter umgehen, wenn der Backup nicht dieselben Filter durchsetzt. Quellen verifiziert: improvmx.com + forwardemail.net (abgerufen 2026-05-16, Direkt-WebFetch).

MX-Lookup-Budget und SMTP-SRV-Fallback (Information-Gain Welle 2, R3-Verifikation)

RFC 7208 (SPF) gibt für die SPF-Auswertung beim Empfänger ein hartes Budget von 10 DNS-Lookups vor — der mx-Mechanismus selbst kostet einen Lookup, jeder MX-Hostname-A/AAAA-Resolve einen weiteren. Wer für eine Domain mit zwei MX-Hostnamen v=spf1 mx include:spf-provider.example -all nutzt, verbraucht bereits 3 von 10 Lookups vor jedem zusätzlichen Include — und überschreitet das Limit oft mit verschachtelten Anbieter-Includes (Microsoft + Sendgrid + Mailchimp summieren typisch auf 12-14 Lookups). Lösung: Bei mehreren Sendern mx häufig durch explizite ip4:/ip6:-Listen ersetzen — der Wolf-Agents Email Security Check zählt das Budget rekursiv und warnt bei permerror-Risiko. Ergänzend: SMTP-SRV (RFC 6186) als Submission-Auto-Discovery (_submission._tcp.<domain> + _imap._tcp.<domain>) ergänzt MX-Records für die Mail-Client-Auto-Konfiguration — die Adoption ist 2026 weiterhin niedrig (primär Self-Hosted-Setups + Apple Mail / Thunderbird-Autodiscovery), aber der Standard ist für Hybrid-Mail-Architekturen relevant. Quelle: RFC 7208 § 4.6.4 + RFC 6186.

Privacy-Mail-Custom-Domain-Vergleich (DACH-Wettbewerber)

Wer Datenschutz-fokussierte Mail-Provider mit Custom-Domain sucht, vergleicht 2026 vier Alternativen zu Microsoft 365 / Google Workspace: Proton Mail (CH, ab Mail-Plus mit 1 Custom-Domain, Mail-Unlimited mit 3 + unlimitierte Aliases, MX mail.protonmail.ch Prio 10 + mailsec.protonmail.ch Prio 20, anti-CLOUD-Act). Tuta / Tutanota (juristisch Tutao GmbH, Hannover, DE, alle bezahlten Pläne mit unbegrenzten Custom-Email-Adressen + unbegrenzten Aliases, Business-Unlimited mit mehreren Domains, proprietäre quantum-safe Encryption ohne PGP). Mailbox.org (juristisch Heinlein Hosting GmbH, Berlin, 100 %-Tochter der Heinlein Support GmbH seit Spinoff am 1. Januar 2021, HRB 220010 B Amtsgericht Berlin-Charlottenburg, DE, deutsche Rechenzentren, BSI C5 Type 1 + ISO/IEC 27001:2022, PGP-Webmail, Custom-Domain mit Aliases nach Tarif). Posteo (juristisch Posteo e.K., Berlin, DE, eingetragener Kaufmann) bietet keine Custom-Domain — nur @posteo.de-Adressen. Diese Asymmetrie ist relevant für Proton-Bewertungen. Quellen verifiziert: proton.me/support/custom-domain + tuta.com/support/use-your-custom-domain (abgerufen 2026-05-16).

Compliance · NIS2 · BSI · DSGVO

MX-Infrastruktur als Compliance-Nachweis: NIS2, BSI TR-03108 und DSGVO Art. 32

Eine korrekt konfigurierte MX-Infrastruktur ist der prüfbare Nachweis, dass Ihre Organisation die Grundlage für sichere E-Mail-Zustellung gelegt hat. Die NIS2-Richtlinie (EU 2022/2555, Art. 21 Abs. 2 lit. h) fordert Konzepte und Verfahren für den Einsatz von Kryptografie und Verschlüsselung — DNSSEC für MX-Records erfüllt diese Anforderung direkt. Die BSI TR-03108 verlangt MX-Redundanz und Reverse-DNS-Konsistenz, die DSGVO Art. 32 fordert technische Maßnahmen für Verfügbarkeit und Integrität personenbezogener Daten.

NIS2 Art. 21 Abs. 2 lit. h

Kryptografie und Verschlüsselung. DNSSEC für MX-Records bindet die E-Mail-Empfangsadresse kryptografisch an die DNS-Zone — eine direkt prüfbare technische Maßnahme. Ergänzend lit. c (Aufrechterhaltung des Betriebs) bei Backup-MX-Konzepten für Krisenmanagement.

BSI TR-03108

Die BSI Technische Richtlinie für sicheren E-Mail-Transport verlangt Verfügbarkeit (Redundanz oder Provider-interne Multi-Site-Architektur), FCrDNS-konsistente PTR-Records und DNSSEC für die Mail-relevanten DNS-Records. Audit-fest dokumentierbar mit dem Wolf-Agents Monitoring.

DSGVO Art. 32 Abs. 1 lit. b

Verfügbarkeit personenbezogener Daten bei der E-Mail-Übermittlung. MX-Redundanz und korrekte PTR-Records verhindern, dass legitime Geschäfts-E-Mails (mit personenbezogenen Inhalten) im Spam-Filter oder in der Sender-Queue verschwinden — direkt prüfbar durch das Wolf-Agents Monitoring.

MX-Infrastruktur adressiert konkrete Bedrohungen: Direct-Domain-Spoofing auf nicht-Null-MX-Subdomains und SubdoMailing-Angriffe über verwaiste Subdomains mit gültigen MX-Records (T1584.001). FBI IC3 2024: 21.442 BEC-Beschwerden, 2,77 Mrd. USD Schaden — ein erheblicher Teil davon nutzt MX-Fehlkonfigurationen oder fehlende Null-MX-Härtung auf Marketing-Subdomains.

NIS2 Art. 23 Meldepflichten: Ein erfolgreicher DNS-Hijacking-Angriff auf einen MX-Record mit Klartext-Mitlesen von Geschäfts-E-Mails kann als „erheblicher Sicherheitsvorfall“ qualifizieren — es greifen 24-Stunden-Frühwarnung, 72-Stunden-Vorfallsmeldung und Abschlussbericht innerhalb eines Monats. DNSSEC-validierte MX-Records und Wolf-Agents Monitoring-Logs sind im Forensik-Prozess die zentrale Beweis-Grundlage.

Der Wolf-Agents Email Security Check prüft alle 165 Kriterien — inklusive MX-Hostname-Auflösung, PTR/FCrDNS-Konsistenz, DNSSEC-Validierung, Null-MX-Härtung und MX-Bypass-Risiken. Das Monitoring überwacht die MX-Konfiguration alle 6 Stunden, erkennt unautorisierte Änderungen und alarmiert über Toast-Notifications, E-Mail oder Slack/Teams-Webhook. Ergänzend nutzt das Attack-Surface-Monitoring CT-Log-Monitoring via Certstream-Integration, das neu ausgestellte TLS-Zertifikate für Ihre MX-Hosts (mx*.ihre-domain.de) erkennt — Frühwarn-Signal für nicht-autorisierte Cert-Ausstellungen, die einen Spoofing-Angriff vorbereiten.

MX-Anleitung für Ihren Provider:

Microsoft 365 Google Workspace IONOS Strato All-Inkl Hetzner Netcup Hostpoint Infomaniak World4You Proton Mail Postfix Exim Mailcow Cloudflare DNS Hetzner DNS

Wie steht Ihre Domain bei MX-Infrastruktur?

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

E-Mail Security Check starten

Häufig gestellte Fragen

Was ist ein MX-Record und wozu brauche ich ihn?

Ein MX-Record (Mail Exchange Record, RFC 5321 § 5) ist ein DNS-Eintrag, der festlegt, welche Server eingehende E-Mails für eine Domain entgegennehmen. Ohne MX-Record kann der sendende Mailserver nicht ermitteln, an welchen Host er die E-Mail zustellen soll — die E-Mail bleibt unzustellbar. Ein MX-Record kombiniert eine Priorität (niedrigere Zahl = höhere Priorität) mit einem Hostnamen. Im Wolf-Agents Email Security Check ist die MX-Infrastruktur mit 5 Punkten bewertet, und ohne MX-Record wird die Gesamtnote auf F begrenzt (Grade-Cap).

Wie funktioniert die MX-Priorität?

Der sendende Mailserver versucht zuerst den MX-Record mit der niedrigsten Prioritätszahl. Beispiel: MX 10 mx1.example.com + MX 20 mx2.example.com — der Sender versucht erst mx1, dann mx2 bei Fehler. Bei gleicher Priorität (z.B. zwei Records mit Prio 10) verteilt der Sender per Round-Robin zufällig. RFC 5321 § 5.1 fordert, dass nicht erreichbare Empfänger-MX-Server für mindestens 4-5 Tage retried werden, bevor die E-Mail mit Bounce zurückgeht.

Was ist Null MX (RFC 7505)?

Null MX (RFC 7505) ist eine spezielle MX-Konfiguration für Domains, die keine E-Mails empfangen sollen — etwa Marketing-Subdomains oder reine Web-Domains. Der Record lautet IN MX 0 "." (mit Punkt als Hostname und Priorität 0). Sendende Mailserver, die RFC 7505 implementieren, verwerfen die E-Mail sofort mit einem permanenten Fehler (550 5.1.10) statt sie zu queuen. Das verhindert Spoofing-Versuche und bounce-basierte Backscatter-Spam-Kampagnen.

Brauche ich einen Backup-MX und wie konfiguriere ich ihn?

Cloud-Anbieter wie Microsoft 365 oder Google Workspace stellen interne Redundanz hinter einem einzigen MX-Hostnamen bereit — ein eigener Backup-MX ist hier nicht nötig. Bei Self-Hosted-Setups (Postfix, Exim, Mailcow) verhindert ein zweiter MX-Server (Prio 20 oder höher) Bounce-Mails bei Server-Wartung. Achtung: Ein falsch konfigurierter Backup-MX kann das Secure Email Gateway (SEG) umgehen — Angreifer senden direkt an den schwächer gesicherten Backup-MX und überspringen alle Filter. Backup-MX-Konfigurationen müssen entweder das gleiche Filter-Niveau bieten oder so eingeschränkt sein, dass sie nur vom primären MX akzeptiert werden.

Warum ist DNSSEC für MX-Records wichtig?

Ohne DNSSEC kann ein Angreifer per DNS-Spoofing oder Cache-Poisoning den MX-Record manipulieren und eingehende E-Mails auf seinen Server umleiten — ein Angriff, der für Außenstehende kaum sichtbar ist. DNSSEC signiert die DNS-Antworten kryptografisch, sodass der sendende Mailserver Manipulation erkennt. NIS2 Art. 21 Abs. 2 lit. h fordert explizit Konzepte für Kryptografie und Verschlüsselung — DNSSEC für MX-Records ist eine prüfbare Maßnahme. DANE (RFC 7672) baut auf DNSSEC auf und ergänzt eine kryptografisch gebundene TLS-Validierung für die MX-Hosts.

Müssen MX-Records IPv6-AAAA-Records haben?

Ja, sofern Sie IPv6-only-Sender (zunehmend bei mobilen Netzwerken und IoT-Infrastrukturen) bedienen wollen. Der MX-Hostname selbst hat einen A-Record für IPv4 und einen AAAA-Record für IPv6. Bei IPv6-Zustellung verlangt Google Postmaster Tools zusätzlich einen gültigen Reverse-DNS-Eintrag (PTR-Record) für die IPv6-Adresse, der per FCrDNS auf den MX-Hostnamen zurückverweist. Fehlende AAAA-Records führen nicht zu Bounce, aber zu zunehmenden Zustellverzögerungen.

Wie prüfe ich meine MX-Konfiguration?

Drei Schritte: Erstens MX-Records mit dig MX ihre-domain.de +short prüfen — Priorität und Hostname müssen sichtbar sein. Zweitens IPv4/IPv6-Auflösung mit dig A bzw. dig AAAA <MX-Hostname>. Drittens DNSSEC-Validierung mit dig +dnssec MX ihre-domain.de — RRSIG-Records müssen vorhanden sein. Der Wolf-Agents Email Security Check prüft alle drei Komponenten automatisch, validiert PTR/FCrDNS, erkennt Null MX, prüft Backup-MX-Bypass-Risiken und scannt die DNSSEC-Kette bis zur Root-Zone.

MX-Infrastruktur: Mail-Exchange-Records korrekt konfigurieren