Zum Inhalt springen 
MX-Records legen fest, wohin E-Mails für deine Domain zugestellt werden – ich zeige dir, wie du eine email eigene domain korrekt einrichtest, prüfst und absicherst. Dabei erkläre ich die nötigen DNS-Einträge, sinnvolle Tools und typische Fehler, die du vermeidest.
Zentrale Punkte
- MX-Records: Zuständige Mailserver pro Domain festlegen
- SPF/DKIM/DMARC: Versandautorisierung, Signatur, Richtlinien
- Priorität/TTL: Zustellreihenfolge und DNS-Update-Tempo
- Tools: Setup prüfen, Fehler sichtbar machen
- Providerwahl: Passendes Paket, guter Support
Was sind MX-Records?
Ich definiere mit MX-Records, welcher Mailserver E-Mails für meine Domain annimmt. Sobald jemand an meine Adresse schreibt, fragt der sendende Server im DNS die zuständigen Einträge ab. Der zuständige Eintrag zeigt auf den Zielserver, der die Annahme übernimmt und weiterleitet. Ohne korrekte MX-Einträge riskierst du Zustellfehler oder Ablehnungen. Ich halte diese Einträge klar, eindeutig und frei von widersprüchlichen Angaben für eine verlässliche Zustellung.
Vorteile einer E-Mail mit eigener Domain
Mit einer eigenen Adresse wirke ich professionell und stärke meine Marke. Ich halte die Hoheit über Providerwechsel, da ich die MX-Records selbst pflege. Neue Postfächer für Team, Projekte oder Dienste füge ich zügig hinzu. Die Wiedererkennung steigt, weil Empfänger meine Domain sofort zuordnen. Ich sichere mir so Vertrauen und erhöhe die Kontrolle über meinen Mailverkehr.
Voraussetzungen schaffen
Ich starte mit einer eigenen Domain und Zugang zur DNS-Verwaltung beim Registrar oder Hoster. Ein aktiver E-Mail-Dienst wie Google Workspace, Microsoft 365, Proton Mail oder ein Hosting-Paket muss bereitstehen. Die Anbieter zeigen mir später die genauen MX-Ziele, Hostnamen und Prioritäten. Bei IONOS oder ähnlichen Registraren hilft mir eine kompakte IONOS-DNS Anleitung beim Auffinden der DNS-Zone. Ich notiere alle Daten des Mailanbieters, damit ich sie im nächsten Schritt korrekt in die Zone eintrage.
MX-Records einrichten Schritt für Schritt
Ich melde mich beim Registrar an, öffne die DNS-Einstellungen und schaue zuerst, ob alte MX-Einträge existieren. Veraltete Angaben entferne ich, damit keine konkurrierenden Server zuständig bleiben. Danach übernehme ich die MX-Daten meines Anbieters exakt, zum Beispiel bei Google Workspace häufig „smtp.google.com“ mit einer niedrigen Priorität wie 1 sowie Host „@“. Ich achte darauf, den TTL-Wert moderat zu wählen, damit Änderungen schneller wirksam werden. Zum Abschluss speichere ich die DNS-Zone und plane eine Wartezeit ein, da die Verteilung global etwas dauert.
Priorität, Host und TTL verstehen
Die Priorität steuert, welcher MX-Server zuerst kontaktiert wird: kleinere Zahl bedeutet Vorrang. Zusätzliche MX-Einträge mit höherer Zahl dienen als Fallback bei Ausfällen. Als Host verwende ich meist „@“, damit der Eintrag für die Wurzel der Domain gilt; Subdomains benötigen eigene MX-Einträge. Beim TTL-Wert greife ich häufig zu einer eher kurzen Zeit, damit Anpassungen schneller sichtbar werden. Ich halte die Angaben konsistent und vermeide Mischungen verschiedener Anbieter mit gleicher Priorität, weil das die Zustellung verwirrt.
Wichtige DNS-Regeln für MX-Records
Ich beachte ein paar Grundregeln, damit meine MX-Einträge technisch sauber sind:
- MX zeigt auf Hostnamen, nicht auf IP-Adressen. Der Zielhost braucht gültige A- bzw. AAAA-Records.
- Kein CNAME als MX-Ziel: Ein MX darf nicht auf einen CNAME verweisen. Ich nutze immer einen kanonischen Host.
- Kein CNAME am selben Owner: Wo ein CNAME steht, dürfen keine anderen Recordtypen existieren. Für die Root-Domain setze ich deshalb kein CNAME, wenn ich MX, TXT (SPF) oder andere Einträge brauche.
- Subdomains separat: Für sub.example.de gilt der MX der Subdomain, nicht automatisch der der Root. Ich trage für jede Subdomain eigene MX ein, falls dort Mail empfangen werden soll.
- Fallbacks sinnvoll wählen: Mehrere MX-Einträge kommen aus derselben Plattform oder sind abgestimmt, damit Failover wirklich funktioniert.
Provider-spezifische MX-Beispiele
Ich übernehme immer die Angaben aus dem Adminbereich meines Anbieters. Typische Beispiele helfen mir beim Verständnis (können sich ändern):
- Google Workspace: Üblich sind Hosts wie ASPMX.L.GOOGLE.COM (Priorität 1) und weitere Backups ALT1.ASPMX.L.GOOGLE.COM usw. Ich richte alle vorgeschlagenen Einträge ein.
- Microsoft 365: Meist domain-key.mail.protection.outlook.com (individuell je Domain) mit Priorität 0 oder 10.
- Proton Mail: Häufig mail.protonmail.ch (Priorität 10) und mailsec.protonmail.ch (Priorität 20).
- Webhoster: Oft ein kundenindividueller MX wie mxX.provider.tld. Ich sorge dafür, dass entsprechende A/AAAA-Records existieren.
Ich verlasse mich nicht auf generische Beispiele, sondern trage exakt die Werte aus meinem Setup ein.
SPF, DKIM und DMARC ergänzen
Ich richte neben MX immer SPF ein, damit nur autorisierte Server in meinem Namen senden. Zusätzlich aktiviere ich DKIM, damit jede ausgehende Nachricht eine kryptografische Signatur trägt. Mit DMARC formuliere ich klare Regeln, was Empfänger mit nicht authentifizierten E-Mails tun sollen. Diese Kombination erhöht die Zustellrate und senkt das Risiko von Phishing über meine Domain. Ich prüfe regelmäßig, ob meine Richtlinien aktuell sind, vor allem nach Providerwechseln.
SPF/DKIM/DMARC in der Praxis vertiefen
Bei SPF achte ich auf eine schlanke Policy: Ich limitiere die Anzahl von include:-Mechanismen, um DNS-Lookups gering zu halten, und vermeide doppelte Einträge. Steht ein Wechsel an, teste ich zuerst mit ~all (Softfail) und gehe später auf -all (Hardfail), wenn alle Sender sauber abgedeckt sind. Für DKIM nutze ich Selector-Namen (z. B. s1, s2), damit ich Schlüssel rotieren kann, ohne Mails zu unterbrechen. Bei DMARC starte ich mit p=none und sammle Auswertungen über rua-Aggregate-Reports. Wenn alles stabil ist, erhöhe ich schrittweise auf quarantine und reject, optional mit pct=, um nur einen Prozentsatz zu verschärfen. So finde ich ein stabiles Gleichgewicht aus Sicherheit und Zustellbarkeit.
Tools für Tests und Monitoring
Ich kontrolliere meine Einrichtung mit Prüfwerkzeugen und reagiere sofort auf Warnungen. Dienste wie MX-Checks oder Admin-Toolboxen zeigen mir falsche Hostnamen, fehlerhafte Prioritäten oder fehlende TXT-Einträge. Für tiefergehende Analysen nutze ich Hinweise zu DNS-Fehler erkennen, um Ursachen sauber zu trennen. Ich teste nach jeder Änderung die Erreichbarkeit, den Versand und die Authentifizierung. So halte ich meine MX-Records dauerhaft funktionsfähig und nachvollziehbar.
Typische Fehler vermeiden
Ich lasse keine widersprüchlichen MX-Einträge mit gleicher Priorität stehen, wenn sie auf verschiedene Anbieter zeigen. Ich setze den Host korrekt auf „@“ oder auf die gewünschte Subdomain, damit E-Mails nicht ins Leere laufen. Ich verzichte auf überlange TTLs, denn sie verlangsamen spätere Umstellungen. Ich vergesse nie SPF, DKIM und DMARC, sonst beeinträchtigt das die Zustellung spürbar. Nach Änderungen führe ich immer einen Test durch, damit ich Probleme direkt erkenne.
Migration ohne Ausfälle planen
Vor einem Providerwechsel senke ich den TTL meiner MX- und relevanten TXT-Einträge auf wenige Minuten – idealerweise 24–48 Stunden vor dem Stichtag. Ich richte beim neuen Anbieter bereits Postfächer und Aliasse ein und lasse, wenn möglich, eine parallele Annahme laufen (Dual Delivery oder Weiterleitung), damit während der DNS-Umstellung keine Mails verloren gehen. Ich beobachte eingehende Nachrichten auf beiden Systemen und schalte alte MX erst ab, wenn die Mehrzahl der Absender die neuen Records nutzt. Für einen sauberen Rückfallplan notiere ich mir die alten Werte, um bei Bedarf schnell zurückzuwechseln.
Weiterleitungen, Aliasse und Catch-All
Ich unterscheide zwischen Alias (weitere Adresse auf demselben Postfach) und Weiterleitung (Zustellung an ein anderes Ziel). Weiterleitungen können SPF-Checks brechen, weil der weiterleitende Server nicht autorisiert ist. Ich halte daher DKIM stabil und nutze, wo möglich, SRS (Sender Rewriting Scheme) beim weiterleitenden Server. Ein Catch-All kann praktisch sein, erhöht aber Spam – ich aktiviere ihn nur gezielt und mit guten Filtern. Für Rollenadressen wie info@ oder support@ setze ich klare Zuständigkeiten, damit nichts liegen bleibt.
E-Mail-Anbieter vergleichen
Ich wähle meinen Anbieter nach DNS-Bedienbarkeit, Sicherheit, Funktionsumfang und Support. Für Unternehmen zählt eine klare Verwaltung der DNS-Einträge ebenso wie Monitoring und gute Hilfetexte. Ich achte auf transparente MX-Vorgaben und zusätzliche Records, die der Anbieter bereitstellt. Ein schneller Support spart mir Zeit, falls Zustellfragen auftauchen. Die folgende Tabelle hilft mir bei der Einordnung beliebter Lösungen.
| Anbieter | E-Mail-Integration | DNS-Management | Support |
|---|---|---|---|
| webhoster.de | Sehr gut | Sehr einfach | Exzellent |
| Google Workspace | Sehr gut | Einfach | Sehr gut |
| Microsoft 365 | Sehr gut | Mittel | Gut |
| Proton Mail | Sehr gut | Mittel | Gut |
Anleitung: Proton Mail einrichten
Ich verbinde meine Domain im Proton-Adminbereich und bestätige die Inhaberschaft. Dann trage ich die angezeigten MX-, SPF-, DKIM- und DMARC-Einträge in meiner DNS-Zone ein. Proton zeigt mir, ob alle Schlüssel korrekt hinterlegt sind und ob die Signatur aktiv ist. Nach der DNS-Verteilung teste ich die Annahme und den Versand mit einer Testmail. Ich richte anschließend Postfächer, Aliasse und Weiterleitungen direkt im Proton-Panel ein, damit mein Setup vollständig wirkt.
Google Workspace und Microsoft 365
Ich aktiviere Google Workspace oder Microsoft 365 für meine Domain und folge den Einrichtungsassistenten. Für Google übernehme ich die aktuelle MX-Vorgabe, zum Beispiel „smtp.google.com“ mit Priorität 1, sowie die ergänzenden TXT-Einträge. In Microsoft 365 erzeuge ich die geforderten Einträge im Admincenter und prüfe, ob die Bestätigung durchläuft. Anschließend teste ich Empfang, Versand, SPF-Validierung und DKIM-Signatur. Bleiben Tests fehlerfrei, nutze ich die Plattform produktiv und plane regelmäßige Überprüfungen.
Eigene Nameserver und DNS-Delegation
Ich betreibe bei Bedarf eigene Nameserver und delegiere meine Domain dorthin. Dabei setze ich auf saubere Zonenpflege, korrekte NS-Einträge und passende Glue-Records beim Registrar. Eine strukturierte Delegation schafft Klarheit über Zuständigkeiten und verkürzt Wege beim Ändern von MX, SPF, DKIM und DMARC. Für einen kompakten Start nutze ich die Anleitung zu eigene Nameserver einrichten. So halte ich die Verwaltung unter voller Kontrolle und kann schneller reagieren.
Sicherheit beim Transport: TLS, MTA-STS, DANE
Ich stelle sicher, dass mein Anbieter TLS für eingehende und ausgehende Mails erzwingt oder bevorzugt. Mit MTA-STS kann ich Empfängern mitteilen, welche Mailserver für meine Domain gültig sind und dass TLS erwartet wird; TLS-RPT liefert mir Berichte zu TLS-Problemen. Falls meine Domain mit DNSSEC signiert ist und mein Anbieter TLSA-Records unterstützt, nutze ich optional DANE als zusätzliche Absicherung. So senke ich das Risiko von Downgrade-Angriffen und halte die Transportverschlüsselung konsistent.
Subdomains, Transaktionsmails und Trennung
Ich arbeite gern mit Subdomains, um unterschiedliche Mailflüsse zu trennen: Beispielsweise nutze ich mail.example.de für Team-Postfächer und eine eigene Sende-Subdomain wie mg.example.de für Newsletter oder Systemmails. Dadurch separiere ich Authentifizierung (eigene SPF-/DKIM-Records), vereinfache das Monitoring und verhindere, dass Fehler im Massenversand die Hauptdomain betreffen. Ich sorge auch dafür, dass die MX- und A/AAAA-Records der betroffenen Subdomains vollständig und konsistent sind.
Blocklists, Bounces und Zustellhürden
Ich beobachte, ob mein ausgehender Versand oder die MX-Ziele auf Blocklists (RBLs) auftauchen. Treten vermehrt Softbounces (4xx) auf, warte ich ab oder versuche eine spätere Zustellung; bei Hardbounces (5xx) prüfe ich Fehlertexte (z. B. „SPF fail“, „DKIM bad signature“, „Mailbox full“, „User unknown“). Bei Greylisting sende ich erneut, ohne Einstellungen zu verschärfen. Ich halte meine Listen sauber, pflege Abmeldungen und entferne unzustellbare Adressen, um Reputationsschäden zu vermeiden.
Postfächer, Protokolle und Zugriff
Ich lege IMAP/POP3/SMTP-Zugänge mit starken Passwörtern an und aktiviere 2FA, sofern möglich. Ich dokumentiere Servernamen, Ports, TLS/STARTTLS-Vorgaben und richte App-Passwörter für ältere Clients ein. Ich plane Quotas (Speicherkontingente) realistisch, damit Postfächer nicht voll laufen, und setze Regeln, um große Anhänge auszulagern oder automatisch zu archivieren. So bleiben Clients stabil und Mails erreichbar.
Self-Hosting vs. Cloud-Anbieter
Wenn ich selbst einen Mailserver betreibe, brauche ich eine feste IP, korrekte PTR-Einträge (Reverse DNS), einen konsistenten HELO/EHLO-Hostnamen, starke Spamfilter und ein sauberes Patch-Management. Ich konfiguriere Ratenbegrenzungen, Backpressure und Monitoring, damit die Queue stabil bleibt. Für viele Organisationen ist ein Cloud-Anbieter mit gepflegter Infrastruktur, Support und Reputation effizienter – ich entscheide nach Teamressourcen, Compliance-Anforderungen und Budget.
DNSSEC und Zonenhygiene
Ich signiere meine Zone mit DNSSEC, wenn mein Registrar und mein DNS-Provider das unterstützen, und hinterlege den DS-Record korrekt. Ich halte die Zone übersichtlich: keine veralteten Einträge, keine widersprüchlichen CNAMEs, keine mehrfachen SPF-Einträge (ich kombiniere Inhalte in einem TXT-Record für SPF). Vor größeren Änderungen erstelle ich eine Backup-Kopie der Zone, um notfalls schnell zurückzugehen.
Checkliste für die finale Abnahme
- MX-Records zeigen auf gültige Hostnamen mit A/AAAA, Prioritäten korrekt gesetzt
- SPF-TXT vorhanden, Lookup-Limit eingehalten, keine Duplikate
- DKIM-Selector veröffentlicht, Signatur aktiv und gültig
- DMARC-Policy definiert (p=none/quarantine/reject), Berichte zugestellt
- Optional: MTA-STS/TLS-RPT veröffentlicht, DNSSEC aktiv
- Weiterleitungen/aliases getestet, Catch-All bewusst konfiguriert
- TTL-Strategie dokumentiert, Migrationstests erfolgreich
- Postfächer in Clients eingebunden, 2FA/App-Passwörter eingerichtet
- Monitoring für Zustellung, Bounces und Blocklists aktiv
Kurz zusammengefasst
Ich richte meine eigene Adresse mit korrekten MX-Records ein, ergänze SPF, DKIM und DMARC und teste alles gründlich. Die Prioritäten steuern die Zustellreihenfolge, eine sinnvolle TTL beschleunigt Änderungen. Tools helfen mir, Fehler sofort zu sehen und gezielt zu beheben. Mit einer passenden Plattform und gutem Support halte ich meinen Mailbetrieb zuverlässig am Laufen. So bleibt meine Kommunikation professionell, nachvollziehbar und langfristig sicher.
