E-Mail mit eigener Domain: Anbieter und DNS

E-Mail mit eigener Domain heißt: Die Adresse zieht mit, wenn du den Anbieter wechselst. Das ist wichtiger, als es klingt, denn in deinem Postfach landet jeder Link zum Zurücksetzen eines Passworts. Wer die Adresse kontrolliert, hat den Zweitschlüssel zu deinen Konten.

Kurz gesagt

Wie richtest du E-Mail mit eigener Domain ein? Du brauchst eine Domain und einen Mailanbieter, der eigene Domains unterstützt. Dann trägst du vier Arten von DNS-Einträgen ein: MX sagt, wohin Mail für deine Domain zugestellt wird, SPF nennt die Server, die für sie senden dürfen, DKIM lässt Empfänger eine Signatur an jeder Nachricht prüfen, und DMARC sagt Empfängern, was bei fehlgeschlagenen Prüfungen passieren soll und wohin Berichte gehen. Den Anbieter wählst du danach, wo er deine Mails speichert, wie du sie wieder herausbekommst und was er pro Nutzer und Monat kostet. Ein Mailserver am Heimanschluss klappt selten, weil Empfänger Heim-IP-Adressen misstrauen. Auch wir mailen von unserer eigenen Domain. Unten vergleichen wir fünf Anbieter nur anhand ihrer eigenen Angaben, Stand 25. Okt. 2026, ohne Rangfolge und ohne Partnerlinks.

So funktioniert’s

1. Trenn Domain und Postfach. Die Domain mietest du bei einem Registrar, das Postfach liegt bei einem Mailanbieter, und die DNS-Zone kann bei einem von beiden liegen. Genau diese Trennung ist der Sinn: Passt der Anbieter nicht mehr, änderst du ein paar DNS-Einträge und behältst jede Adresse. Lass die Domain automatisch verlängern und hinterlege beim Registrar eine Kontaktadresse außerhalb dieser Domain, damit Erinnerungen nicht in dem Postfach landen, das du gerade verlierst. Für generische Endungen wie .com verlangt ICANN von Registraren Erinnerungen etwa einen Monat und eine Woche vor Ablauf, weist darauf hin, dass E-Mail nicht mehr funktioniert, während der DNS-Dienst nach Ablauf unterbrochen ist, und verlangt von Registries nach der Löschung eine Redemption Grace Period von 30 Tagen [33]. Länderendungen wie .de folgen den Regeln ihrer eigenen Registry. Nach unserer Einschätzung gilt: Ist ein verfallener Name wieder frei, bekommt der nächste Inhaber deine Mails, Links zum Zurücksetzen von Passwörtern eingeschlossen.
2. Wähl den Anbieter nach Speicherort, Exportweg und Preis. Lies, wo der Anbieter selbst deine Mails speichert, prüf, ob Standardprotokolle wie IMAP funktionieren oder nur seine eigenen Apps, und vergleich den Preis pro Nutzer und Monat mit Mehrwertsteuer und Abrechnungszeitraum. Die Tabelle nach dieser Liste vergleicht fünf Anbieter. Der Exportweg zählt vor allem an dem Tag, an dem du gehst. Proton verbindet E-Mail-Programme am Desktop per IMAP und SMTP nur über seine App Proton Mail Bridge, und die braucht einen bezahlten Tarif [16]. Tuta unterstützt IMAP gar nicht und verweist auf den Export aus seinen Desktop-Clients [24]. mailbox.org dokumentiert ganz normale IMAP-, POP3- und SMTP-Server [22]. Brauchst du einen Speicherort in Europa, prüf die Edition: Google nennt Datenregionen unter anderem für Business Standard, Business Plus und die Enterprise-Editionen; Business Starter steht nicht auf dieser Liste [30]. Microsoft ordnet Microsoft-365-Kunden mit einem Anmeldeort in der EU oder EFTA seiner EU-Datengrenze zu, mit begrenzten Ausnahmen [27].
3. Richte die MX-Einträge auf den Anbieter. Ein MX-Eintrag nennt einen Server, der Mail für deine Domain annimmt, zusammen mit einer Präferenzzahl; niedrigere Werte werden bevorzugt [1]. Trag genau die Hosts ein, die dein Anbieter nennt, und lösch MX-Einträge, die woandershin zeigen. mailbox.org verlangt zum Beispiel vier MX-Einträge, mxext1 bis mxext4.mailbox.org, alle mit Priorität 10 [19]. Leg jede Adresse und jeden Alias beim neuen Anbieter an, bevor du umstellst. Proton warnt, dass Mail an Adressen, die in Proton Mail nicht existieren, nach der Umstellung nicht zugestellt wird [14].
4. Veröffentliche genau einen SPF-Eintrag. SPF ist ein TXT-Eintrag direkt an der Domain. Er beginnt mit v=spf1 und nennt die Server, die mit deiner Domain im Umschlag-Absender senden dürfen, meist über ein include:, das dein Anbieter vorgibt [2]. RFC 7208 erlaubt einen solchen Eintrag pro Name; zwei führen zu einem Fehlerergebnis [2]. Die Auswertung endet auch dann mit einem Fehler, wenn sie mehr als 10 Begriffe braucht, die DNS-Abfragen auslösen, etwa include, a, mx oder redirect, und Begriffe in eingebundenen Einträgen zählen mit [2]. Der letzte Begriff regelt alle anderen: -all heißt Fehlschlag (fail), ~all weicher Fehlschlag (softfail) [2]. Nimm den Qualifier, den dein Anbieter dokumentiert, und ergänze neue Dienste im bestehenden Eintrag, statt einen zweiten anzulegen.
5. Schalte DKIM ein. Mit DKIM signiert der Anbieter jede ausgehende Nachricht, und Empfänger prüfen die Signatur gegen einen öffentlichen Schlüssel, den du unter einem Selektor veröffentlichst, zum Beispiel sel1._domainkey.example.com [3]. Manche Anbieter geben dir einen TXT-Eintrag mit dem Schlüssel, andere CNAME-Einträge, damit sie den Schlüssel selbst wechseln können. Microsoft 365 nutzt zwei CNAMEs, selector1._domainkey und selector2._domainkey [13]; Proton verlangt drei DKIM-Einträge [14]. RFC 8301 schreibt RSA-Schlüssel mit mindestens 1.024 Bit vor und empfiehlt mindestens 2.048 [4]. Google verlangt für Mail an private Gmail-Konten mindestens 1.024 Bit und empfiehlt 2.048 [10]. Lässt dein Anbieter dich wählen, nimm 2.048.
6. Fang mit DMARC behutsam an. DMARC steht in einem TXT-Eintrag unter _dmarc.example.com. Es prüft, ob die Domain in der sichtbaren Absenderadresse zu einer bestandenen SPF- oder DKIM-Prüfung passt, sagt Empfängern, was mit durchgefallener Mail geschehen soll, und fordert Berichte an. Seit Mai 2026 definiert RFC 9989 DMARC und ersetzt RFC 7489; die Sammelberichte haben jetzt ein eigenes RFC 9990 [5][6]. Der Eintrag muss mit v=DMARC1 beginnen; p= nimmt none, quarantine oder reject; rua= nennt die Adresse für Sammelberichte [5]. RFC 9989 streicht das alte Feld pct und führt t=y ein, einen Testmodus, in dem Empfänger die nächstmildere Richtlinie anwenden, sodass quarantine wie none behandelt wird [5]. Starte mit p=none und einer Berichtsadresse, lies die Berichte und zieh danach an. Proton empfiehlt für die meisten Domains p=quarantine [14]. RFC 9989 ergänzt zwei Warnungen: Domains, deren Nutzer an Mailinglisten schreiben könnten, sollen kein p=reject veröffentlichen, und eine Domain mit p=reject darf sich nicht allein auf SPF verlassen, sondern muss ihre Mails mit DKIM signieren [5].
7. Kenn die Regeln der großen Postfächer. Seit dem 1. Feb. 2024 verlangt Google von jedem Absender SPF oder DKIM, gültige Vorwärts- und Rückwärtsauflösung für sendende Server, TLS und eine Spamrate unter 0,3 Prozent [10]. Wer mehr als 5.000 Nachrichten am Tag an Gmail-Konten schickt, braucht zusätzlich SPF und DKIM, DMARC mit mindestens p=none, eine Absenderdomain, die zu SPF oder DKIM passt, und Abmelden mit einem Klick bei Werbemails [10]. Yahoo hat vergleichbare Regeln für alle Absender und für Massenversender; die Durchsetzung begann im Februar 2024 [11]. Seit dem 5. Mai 2025 verlangt Microsoft von Domains, die mehr als 5.000 Nachrichten am Tag an Outlook.com schicken, SPF, DKIM und DMARC mit mindestens p=none; durchgefallene Mail landet im Junk-Ordner und kann später mit dem Fehler 550 5.7.515 abgewiesen werden [12]. Bei einem Mailanbieter sind Server, Rückwärtsauflösung und TLS seine Aufgabe. Deine Aufgabe sind die DNS-Einträge.
8. Zieh um, ohne Mails zu verlieren. Senk die TTL deiner MX-Einträge rechtzeitig vor dem Wechsel, warte mindestens eine alte TTL ab, ändere sie dann und erhöhe die TTL danach wieder (siehe die Seite zur DNS-TTL). Proton schlägt beim Bestätigen der Domain eine TTL von 300 Sekunden vor, damit Änderungen innerhalb von fünf Minuten greifen [14]. Lass das alte Postfach noch eine Weile erreichbar, denn Server mit zwischengespeicherten Antworten liefern womöglich noch dorthin. Kopier deine alten Mails mit dem Import-Werkzeug des neuen Anbieters oder einem IMAP-Programm; Protons Easy Switch etwa importiert von jedem Anbieter, der IMAP anbietet [18]. Ersetz danach den alten Anbieter in deinem SPF-Eintrag, ergänze die neuen DKIM-Einträge und lass DMARC auf p=none, bis die Berichte nur noch den neuen Anbieter zeigen.
9. Leite mit Bedacht weiter. Leitet eine alte Adresse an die neue weiter, hilft SPF nicht mehr. Es schlägt am Ziel fehl, sofern der Weiterleiter nicht zur autorisierten Infrastruktur des ursprünglichen Absenders gehört, und schreibt der Weiterleiter den Umschlag-Absender um, kann SPF nur für seine eigene Domain bestehen, die nicht zur sichtbaren Absenderadresse passt [7]. DKIM-Signaturen können überleben, wenn die Weiterleitung weder den Inhalt noch wichtige Kopfzeilen ändert [7]. Mailinglisten ergänzen oft eine Markierung im Betreff oder eine Fußzeile und brechen damit DKIM [7]. Deshalb braucht deine eigene Mail eine DKIM-Signatur, und deshalb ist ein einmaliger Import alter Mails oft sauberer als eine Weiterleitung für immer.
10. Lass den Mailserver zu Hause weg. Spamhaus führt in seiner Policy Blocklist Adressbereiche, die keine Mail direkt ins Internet schicken sollen, oft Bereiche, die Provider an Breitbandkunden vergeben, und betont, dass ein Eintrag nicht durch das Verhalten der Nutzer entsteht [32]. Außerdem schreibt Spamhaus, dass ausgehender Port 25 auf Mailserver beschränkt sein sollte [32]. Google erwartet gültige Rückwärtsauflösung für sendende Server [10], und am Heimanschluss setzt dein Provider diesen PTR-Eintrag (siehe die Seite zu Reverse DNS). Nach unserer Einschätzung kann Mailempfang zu Hause funktionieren, zuverlässiges Senden klappt selten. Willst du trotzdem einen eigenen Server, miete einen mit fester Adresse und einem PTR-Eintrag, den du selbst setzen kannst.

Fünf Anbieter im Vergleich (Stand 25. Okt. 2026)

So liest du das: Das sind die eigenen Angaben der Anbieter vom 25. Okt. 2026, keine Messungen, und die Reihenfolge bedeutet nichts. Preise und Tarife ändern sich, achte also aufs Datum. Für Google Workspace nennen wir keinen Preis, weil uns die Preisseite nur Beträge in US-Dollar zeigte; prüf dort den Preis für dein Land [29]. Für diesen Guide haben wir keinen der Dienste getestet. Bytearium setzt später möglicherweise Partnerlinks zu einigen Anbietern. Wenn wir das tun, sind sie gekennzeichnet, und die Kriterien oben bleiben dieselben.

Die DNS-Einträge auf einen Blick

Alle Namen und Werte unten sind Platzhalter. Ersetz example.com durch deine Domain und die Hosts unter mail-provider.example durch die Werte deines Anbieters.

example.com.                  3600 IN MX    10 mx1.mail-provider.example.
example.com.                  3600 IN MX    20 mx2.mail-provider.example.
example.com.                  3600 IN TXT   "v=spf1 include:_spf.mail-provider.example ~all"
sel1._domainkey.example.com.  3600 IN CNAME sel1.dkim.mail-provider.example.
_dmarc.example.com.           3600 IN TXT   "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Im Webformular deines DNS-Anbieters trägst du meist nur den Namensteil ein: @ oder ein leeres Feld für die Domain selbst [14] und für die anderen den Teil vor deiner Domain, hier _dmarc oder sel1._domainkey. Sehen die Berichte sauber aus, zieh die Richtlinie auf v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com an. Eine Domain, die weder sendet noch empfängt, bekommt einen Null-MX, example.net. 3600 IN MX 0 ., und dazu den SPF-Eintrag v=spf1 -all, der erklärt, dass kein Server für sie Mail verschickt [8].

Einträge prüfen

dig +short MX example.com
dig +short TXT example.com
dig +short CNAME sel1._domainkey.example.com
dig +short TXT _dmarc.example.com

dig fragt einen Nameserver nach einem Eintragstyp, und +short gibt nur die Antwort aus [34]. Veröffentlicht dein Anbieter DKIM als TXT-Eintrag, frag nach TXT statt CNAME. Schick dann eine Nachricht an ein Konto bei einem anderen Anbieter und öffne den vollständigen Header: In Gmail öffnest du die Nachricht und wählst neben „Antworten“ das Menü für mehr Optionen und dort die Originalansicht (englische Oberfläche: More, Show original) [31]. Such nach dem Feld Authentication-Results, das RFC 8601 dafür definiert, dass Empfänger ihre Ergebnisse festhalten, etwa spf=pass, dkim=pass und dmarc=pass [9].

Praxisbeispiel

Das ist erfunden und kein Test. Mara besitzt example.org und hat bisher die Postfächer eines Webhosting-Pakets genutzt. Sie will zu einem Mailanbieter mit Unterstützung für eigene Domains. Am Montag senkt sie die TTL ihrer MX-Einträge von 3.600 auf 300 Sekunden und legt ihre zwei Adressen beim neuen Anbieter an. Am Dienstag, mehr als eine Stunde später, ersetzt sie die MX-Einträge, ergänzt die DKIM-Einträge des Anbieters, schreibt ihren SPF-Eintrag so um, dass er nur noch den neuen Anbieter einbindet, und veröffentlicht DMARC mit p=none und einer Berichtsadresse. dig zeigt die neuen Werte. Eine Testnachricht an ein Gmail-Konto zeigt im Header spf=pass, dkim=pass und dmarc=pass. Sie importiert ihre alten Mails per IMAP, behält das alte Paket noch einen Monat und stellt DMARC auf p=quarantine, sobald die Berichte nur noch den neuen Anbieter zeigen. Nichts in diesem Beispiel wurde gemessen.

Prüfliste

• Prüfe, ob deine Domain sich automatisch verlängert und ob das Registrar-Konto eine Adresse außerhalb dieser Domain nutzt.
• Vergleiche Anbieter nach Speicherort, IMAP- oder Exportweg und Preis pro Nutzer mit Mehrwertsteuer und Abrechnungszeitraum.
• Leg jede Adresse beim neuen Anbieter an, bevor du die MX-Einträge änderst.
• Senk die TTL mindestens eine alte TTL vor dem Wechsel und erhöhe sie danach wieder.
• Behalte genau einen SPF-Eintrag und halte die Begriffe mit DNS-Abfragen bei höchstens 10, eingebundene Einträge mitgezählt.
• Schalte DKIM ein, mit 2.048-Bit-Schlüsseln, wenn dein Anbieter sie anbietet.
• Veröffentliche DMARC zuerst mit p=none und einer Berichtsadresse und zieh dann auf quarantine an.
• Schick eine Testnachricht und lies das Feld Authentication-Results.
• Sichere das Postfach selbst mit Passkeys oder Zwei-Faktor-Anmeldung, denn darüber lassen sich deine anderen Konten zurücksetzen.
• Gib Domains, die keine Mail verschicken, einen Null-MX und v=spf1 -all.

Datenschutz, kurz

Nutzt du die Adresse geschäftlich, stellen sich Fragen zu Datenschutz und Aufbewahrung, etwa welche Verträge ein Anbieter für die Verarbeitung deiner Daten anbietet. Das sind Rechtsfragen. Wir beantworten sie hier nicht; frag Fachleute.

Passt dazu: DNS / Namensauflösung; Reverse DNS (PTR): von der IP zum Namen; DNS-TTL (Gültigkeitsdauer); Konto gehackt: was in der ersten Stunde zählt; Passkeys und 2FA: Konten richtig absichern.