Domain, Hosting und geschäftliche E-Mail: Wem gehört was, und wie richtet man es ein?

Die Agentur, die Ihre Website gebaut hat, ist seit Jahren nicht mehr für Sie tätig. Das neue Team braucht Zugriff auf die Domain, aber niemand kennt das Passwort. In den Inhaberdaten steht noch die alte Agentur, und die Verlängerungshinweise gehen an das Postfach einer Mitarbeiterin, die vor drei Jahren gegangen ist. Das ist häufiger, als man denkt, und fällt meist im ungünstigsten Moment auf: wenn die Domain ausläuft oder keine E-Mails mehr ankommen.

Dieser Leitfaden behandelt Domain, Hosting und geschäftliche E-Mail als eine zusammenhängende Infrastruktur: wem was gehören sollte, wo es verwaltet wird, wie Sie zwischen Hosting-Arten wählen und warum Ihre Mails im Spam landen. Das Ziel ist einfach: Egal, wer Ihre Website künftig betreut, die Schlüssel bleiben im Unternehmen.

Wem gehört Ihre Domain wirklich?

Bei einer Domain gibt es zwei Ebenen. Die erste ist der Domaininhaber: die Person oder Organisation, die bei der Registrierungsstelle als Inhaber eingetragen ist, für .de also bei der DENIC. Die zweite ist das Konto, über das die Domain verwaltet wird, also wer das Passwort, den Transfercode und den Verlängerungsknopf in der Hand hat.

Beides sollte Ihrem Unternehmen gehören. Steht als Inhaber die Agentur oder ein Mitarbeiter im Eintrag, gehört Ihr Markenname formal jemand anderem. Liegt das Konto im Reseller-Panel einer Agentur, hängt jede DNS-Änderung an ihr, und selbst eine freundliche Übergabe bedeutet wochenlange Abstimmung.

Agenturen bündeln Kundendomains meist aus Bequemlichkeit, nicht aus Kalkül. Das kann in Ordnung sein, solange Ihr Unternehmen als Inhaber eingetragen ist und im Vertrag steht, dass Sie die Domain jederzeit in Ihr eigenes Konto übernehmen können.

• Tragen Sie als Inhaber die Firma mit vollständiger Bezeichnung ein, nicht eine Person.
• Legen Sie das Konto beim Domainanbieter mit einer Rollenadresse wie domains@ oder it@ an, nie mit einem persönlichen Postfach.
• Aktivieren Sie die Zwei-Faktor-Authentifizierung und geben Sie mindestens zwei Personen Zugriff.
• Zahlen Sie mit einer Firmenkarte. Die private Karte eines Mitarbeiters ist an dessen letztem Arbeitstag Geschichte.

Domainanbieter und DNS-Verwaltung sind nicht dasselbe

Der Anbieter, bei dem Sie die Domain registriert haben, und der Ort, an dem die DNS-Einträge gepflegt werden, sind oft identisch, müssen es aber nicht sein. Die Domain kann bei einem Registrar liegen, die Nameserver bei Cloudflare, die Website bei einem Hoster und die E-Mail bei Microsoft. Vier Orte, vier Zugänge, vier getrennte Risiken.

Das DNS ist das Adressbuch Ihrer Domain. A- und AAAA-Einträge sagen, auf welchem Server die Website liegt, MX-Einträge, wohin E-Mails zugestellt werden, und TXT-Einträge enthalten SPF, DKIM, DMARC und diverse Verifizierungen. Wer nicht weiß, warum welcher Eintrag existiert, kann mit einer gut gemeinten Änderung Website und E-Mail gleichzeitig lahmlegen.

Der klassische Unfall: Der neue Hoster bittet Sie, die Nameserver auf ihn umzustellen, und in der neuen Zone steht nur der Eintrag für die Website. MX- und DKIM-Einträge sind in der alten Zone geblieben, also kommen ab sofort keine E-Mails mehr an. Ausgehende Mails funktionieren weiter, also merkt es niemand, bis ein Kunde anruft und fragt, warum keiner antwortet.

• Exportieren Sie vor jedem Nameserver-Wechsel die komplette Zonendatei und archivieren Sie sie.
• Senken Sie ein bis zwei Tage vorher die TTL wichtiger Einträge, damit Änderungen schneller greifen.
• Notieren Sie, zu welchem Dienst jeder TXT-Eintrag gehört, löschen Sie verwaiste Einträge und testen Sie nach jedem Umzug Website, eingehende und ausgehende Mail getrennt.

Verlängerung, Transfersperre und Länderdomains

Verlängerung nicht dem Zufall überlassen

Eine Domain ist keine einmalige Anschaffung, sondern eine Registrierung auf Zeit. Schalten Sie die automatische Verlängerung ein, tragen Sie das Ablaufdatum der Karte in den Kalender ein und verlängern Sie die Hauptdomain Ihrer Marke, wo möglich, gleich für mehrere Jahre. Die Hinweise gehen an die Adresse des Kontos; stimmt die nicht, verpufft auch der Hinweis.

Bei den meisten generischen Endungen wird eine abgelaufene Domain nicht sofort gelöscht: Es folgt eine Schonfrist, danach eine teurere und mühsamere Wiederherstellungsphase, je nach Endung unterschiedlich lang. Automatisierte Dienste registrieren wertvolle Domains sofort nach der Freigabe. Die eigene Domain zu halten, ist immer leichter, als sie zurückzuholen.

Transfersperre und Auth-Code

Bei .com und den meisten generischen Endungen setzt der Registrar eine Transfersperre (in technischen Abfragen als clientTransferProhibited sichtbar). Solange sie aktiv ist, kann die Domain nicht zu einem anderen Anbieter umziehen. Für den Transfer heben Sie die Sperre auf und fordern den Auth-Code an, der im Konto angezeigt oder an dessen Adresse geschickt wird. Wer das Konto kontrolliert, kontrolliert also den Transfer.

Lassen Sie die Sperre aktiv und lösen Sie sie nur für einen Transfer, den Sie selbst angestoßen haben. Hängt Ihr ganzes Geschäft an einer Domain, fragen Sie Ihren Anbieter nach einem Registry Lock, sofern die Endung ihn anbietet; kritische Änderungen werden dann erst nach manueller Prüfung ausgeführt.

Länderdomains: .de, .at, .ch

Länderdomains folgen den Regeln ihrer jeweiligen Registrierungsstelle. Für .de ist das die DENIC, für .at nic.at und für .ch SWITCH. Auch bei .de läuft ein Providerwechsel über einen AuthInfo-Code, den Ihr bisheriger Anbieter erzeugt; ohne Zugang zum Konto bleibt Ihnen nur der mühsame Weg über den Nachweis, dass Sie der eingetragene Inhaber sind. Spätestens hier zeigt sich, wer wirklich Inhaber ist.

Sichern Sie die .de-Domain, die .com und die Länderendungen der Märkte, in denen Sie aktiv verkaufen. Hat jemand Ihren Namen bösgläubig registriert, gibt es für .com das UDRP-Verfahren der ICANN; bei .de kann ein Dispute-Eintrag bei der DENIC verhindern, dass die Domain während einer gerichtlichen Klärung weiterübertragen wird. Ob Ihr Anspruch trägt, klären Sie mit Ihrer Rechtsberatung.

Hosting-Arten: Shared, VPS, Managed und Cloud

Die eigentliche Frage beim Hosting lautet: Was leistet Ihre Website, und wer kümmert sich um den Server? Eine fünfseitige Firmenwebsite und ein Shop mit Tausenden Bestellungen am Tag haben nicht denselben Bedarf.

Shared Hosting

Sie teilen sich einen Server, seine IP-Adresse und oft auch den E-Mail-Ruf mit Hunderten anderer Websites. Für eine Visitenkarten-Website mit wenig Traffic reicht das. Der Haken: Wird ein Nachbar gehackt oder verschickt Spam, spüren Sie das mit.

VPS

Ein virtueller Server bringt eigene CPU, eigenen Arbeitsspeicher und Speicherplatz, macht Updates, Firewall und Backups aber zu Ihrer Aufgabe. Ein unverwalteter VPS, den jemand eingerichtet und vergessen hat, ist ein Server, der seit Jahren ungepatcht am Netz hängt. Kümmert sich niemand regelmäßig darum, ist er die falsche Wahl.

Managed Hosting

Der Anbieter übernimmt Wartung, Updates, Backups und meist auch Caching und Malware-Scans. Für Unternehmen mit WordPress oder einem ähnlichen CMS und ohne eigene Technik ist das oft der vernünftigste Kompromiss, auf Kosten mancher Freiheit bei den Servereinstellungen.

Cloud

AWS, Google Cloud und Microsoft Azure skalieren mit Ihrem Verbrauch; Plattformen wie Vercel oder Netlify verteilen Websites, die auf modernen Frameworks basieren, über ein weltweites Netz. Das ist leistungsfähig, aber die Zahl der Einstellungen ist groß und abgerechnet wird nach Nutzung. Lassen Sie bei der Einrichtung auch Budgetwarnungen und Zugriffsrechte konfigurieren.

Viele Unternehmen im DACH-Raum setzen auf Anbieter mit Rechenzentren in Deutschland oder der EU, etwa Hetzner, IONOS, Strato oder all-inkl. Unabhängig vom Anbieter sollten Sie diese Fragen vor Vertragsschluss schriftlich beantwortet haben:

• Wo steht das Rechenzentrum, und wie nah ist es an Ihren Kunden?
• Wer erstellt Backups, wie oft, wo werden sie gespeichert, und wann wurde zuletzt eine Wiederherstellung getestet?
• Zu welchen Zeiten und über welche Kanäle gibt es Support, und was passiert, wenn die zugesagte Verfügbarkeit (SLA) nicht eingehalten wird?
• In welchem Format und wie schnell bekommen Sie Dateien und Datenbank, wenn Sie wechseln?

SSL, CDN und Backups: automatisiert und im eigenen Konto

Über SSL (genauer: TLS) muss man nicht mehr diskutieren, jede Seite gehört auf HTTPS. Die Frage ist die Verlängerung. Nach einem Beschluss des CA/Browser Forum aus dem Jahr 2025 sinkt die maximale Laufzeit öffentlicher Zertifikate schrittweise: seit dem 15. März 2026 auf 200 Tage, bis 2029 auf 47 Tage. Die jährliche Verlängerung von Hand ist vorbei; sie muss automatisch laufen.

Let's Encrypt und die meisten Hosting-Oberflächen erledigen das bereits über das ACME-Protokoll. Prüfen Sie, ob die Automatik tatsächlich funktioniert, ob Fehlermeldungen bei einem Menschen ankommen und ob www und alle genutzten Subdomains abgedeckt sind.

Ein CDN (Content Delivery Network) liefert statische Dateien von Servern nahe beim Besucher aus und filtert einen Teil schädlichen Traffics; wer über Ländergrenzen verkauft, merkt den Unterschied. Beachten Sie: Der Wechsel zu einem Dienst wie Cloudflare bedeutet meist auch den Umzug der Nameserver. Ihr DNS liegt dann in diesem Konto, und das gehört in die Inventarliste des Unternehmens.

Unsere einzige feste Regel zu Backups: Die Backups Ihres Hosters sind nicht Ihre Backups. Sie liegen auf derselben Infrastruktur und verschwinden mit ihr, wenn das Konto gesperrt wird oder der Anbieter aufgibt. Die bekannte 3-2-1-Regel ist ein guter Ausgangspunkt: drei Kopien, zwei verschiedene Speichermedien, eine Kopie außer Haus.

• Sichern Sie Dateien und Datenbank automatisch und getrennt.
• Halten Sie mindestens eine Kopie bei einem Speicher, der vom Hoster unabhängig ist.
• Testen Sie mindestens einmal im Jahr eine echte Wiederherstellung. Ein ungetestetes Backup ist eine Annahme.
• Geschäftliche E-Mail-Plattformen schützen ihre Infrastruktur, bewahren aber das Postfach eines gelöschten Nutzers nicht ewig auf. Legen Sie Aufbewahrung und Offboarding bewusst fest.

Geschäftliche E-Mail: Google Workspace oder Microsoft 365?

Postfächer aus dem Hosting-Paket wirken verlockend, aber der Spamfilter ist schwach, der Speicher begrenzt, Ihr Versandruf hängt an allen Websites auf dem Server, und beim Hoster-Wechsel zieht die E-Mail mit um. Ab einer Handvoll Mitarbeitenden empfehlen wir, E-Mail und Website zu trennen.

Google Workspace oder Microsoft 365 ist eher eine Frage der Gewohnheit als der Technik. Ein Team, das im Browser arbeitet und Gmail mag, kommt mit Workspace gut zurecht; arbeitet die Buchhaltung mit Excel auf dem Desktop und bestimmen Teams und Outlook den Arbeitstag, erzeugt 365 weniger Reibung. Beide sind zuverlässig. Falsch ist nur das Werkzeug, das Ihr Team nicht nutzen wird.

Ausgelassene Schritte bei der Einrichtung rächen sich später. Die Mindest-Checkliste:

1. Bestätigen Sie die Domain beim Anbieter über einen TXT-Eintrag.
2. Ersetzen Sie die MX-Einträge durch die Werte des Anbieters und entfernen Sie die alten.
3. Legen Sie einen einzigen SPF-Eintrag an oder ergänzen Sie den bestehenden.
4. Erzeugen Sie einen DKIM-Schlüssel und veröffentlichen Sie ihn im DNS. In Google Workspace finden Sie das in der Admin-Konsole unter Apps, Google Workspace, Gmail, E-Mails authentifizieren; Google empfiehlt einen 2048-Bit-Schlüssel. Bei Microsoft 365 liegt die Einstellung im Defender-Portal bei den E-Mail-Authentifizierungseinstellungen.
5. Veröffentlichen Sie einen DMARC-Eintrag im Beobachtungsmodus (p=none) mit einer Adresse für die Berichte.
6. Halten Sie das Offboarding schriftlich fest: Konto sperren und Daten übertragen statt löschen.

SPF, DKIM, DMARC und die Absenderregeln von Gmail und Yahoo

Diese drei Einträge beweisen dem empfangenden Server, dass eine Mail wirklich von Ihnen stammt. SPF listet die Server, die im Namen Ihrer Domain senden dürfen. Eine Domain darf nur einen SPF-Eintrag haben, und dieser darf höchstens 10 DNS-Abfragen auslösen; für jedes neue Tool einen zweiten SPF-Eintrag anzulegen, ist der häufigste und unauffälligste Fehler. Ein typischer Eintrag für Google Workspace lautet v=spf1 include:_spf.google.com ~all, bei Microsoft 365 heißt der include-Wert spf.protection.outlook.com.

DKIM versieht jede Mail mit einer digitalen Signatur Ihrer Domain; jeder Dienst, der in Ihrem Namen versendet (Postfach, Newsletter-Tool, Rechnungssystem), braucht einen eigenen Schlüssel. DMARC sitzt darüber. Es verlangt, dass die Domain in der sichtbaren Absenderadresse mit der per SPF oder DKIM bestätigten Domain übereinstimmt (Alignment), und legt fest, was mit Mails passiert, die das nicht schaffen: beobachten (p=none), in den Spam (p=quarantine) oder abweisen (p=reject).

Starten Sie im Beobachtungsmodus und lesen Sie die Berichte einige Wochen lang. Sie zeigen vergessene Absender: ein altes CRM, ein Umfrage-Tool, die Rechnungssoftware des Steuerbüros. Wenn alles übereinstimmt, verschärfen Sie die Richtlinie Schritt für Schritt.

Die Regeln seit Februar 2024

Gmail und Yahoo haben ihre Absenderanforderungen im Februar 2024 verschärft. Laut Googles Richtlinien muss jeder, der an private Gmail-Adressen sendet, SPF oder DKIM nutzen, gültige Forward- und Reverse-DNS-Einträge (PTR) haben, über TLS senden und die Spam-Beschwerderate unter 0,3 Prozent halten. Massenabsender, also wer 5.000 oder mehr Nachrichten pro Tag verschickt, brauchen SPF, DKIM und DMARC; die DMARC-Richtlinie darf p=none sein, aber die Absenderdomain muss mit SPF oder DKIM übereinstimmen. Werbemails müssen eine Abmeldung mit einem Klick unterstützen und einen sichtbaren Abmeldelink enthalten, und Google erwartet, dass Abmeldungen innerhalb von zwei Tagen umgesetzt werden.

Zwei Details werden oft übersehen. Die Schwelle von 5.000 zählt Hauptdomain und Subdomains zusammen, und wer einmal als Massenabsender eingestuft ist, bleibt es. Außerdem greifen die Regeln: Seit November 2025 weist Google nicht konforme Mails vorübergehend und dauerhaft ab. Microsoft verlangt seit Mai 2025 Ähnliches von Domains, die täglich mehr als 5.000 Nachrichten an Outlook.com-, Hotmail- und Live-Adressen senden. Google empfiehlt, die Spamrate unter 0,1 Prozent zu halten und 0,3 Prozent nie zu erreichen.

Warum Ihr Webserver keine E-Mails verschicken sollte

Kommen Benachrichtigungen aus dem Kontaktformular nur manchmal an oder landen sie im Spam, liegt es fast immer daran, wie das Formular sie versendet. Viele Websites schicken sie direkt vom Webserver, über die PHP-Funktion mail() oder die Standardeinstellung von WordPress. Diese Mails kommen von einem Server, der nicht im SPF-Eintrag steht, tragen keine DKIM-Signatur und fallen bei DMARC durch.

Noch schlimmer: Manche Formulare verwenden die Adresse des Besuchers als Absender; eine Mail angeblich von [email protected], die von Ihrem Server stammt, scheitert an Gmails DMARC-Richtlinie. Auf Shared Hosting erben Sie womöglich obendrein einen Blocklisten-Eintrag, den der Spam eines Nachbarn verursacht hat.

Die Lösung: Formularbenachrichtigungen und Transaktionsmails wie Bestellbestätigungen oder Passwort-Resets über einen Dienst versenden, der dafür gebaut ist. Verbreitet sind etwa Amazon SES, Postmark, Mailgun, SendGrid und Brevo. Die Website verbindet sich per authentifiziertem SMTP oder API, der Dienst signiert mit DKIM im Namen Ihrer Domain und liefert Zustellprotokolle und Bounce-Berichte.

• Nutzen Sie für Transaktionsmails eine Subdomain wie mail.ihrfirma.de, damit ein Reputationsproblem im Marketing keine Bestellbestätigungen blockiert.
• Senden Sie immer von einer Adresse auf Ihrer eigenen Domain und setzen Sie die Adresse des Besuchers ins Reply-To-Feld.
• Speichern Sie Formulareingaben zusätzlich im Backend oder in der Datenbank, damit keine Anfrage verloren geht, wenn eine Mail hängt.
• Schicken Sie sich selbst eine Testanfrage, öffnen Sie sie in Gmail und wählen Sie Original anzeigen. Bei SPF, DKIM und DMARC sollte jeweils PASS stehen.

Wo fangen Sie an?

Beginnen Sie mit einer Bestandsaufnahme. Halten Sie für jede Zeile der Tabelle fest, auf wen das Konto läuft und wo die Zugangsdaten liegen. Jede leere Zelle ist eine Tür, vor der Sie eines Tages stehen werden.

1. Prüfen Sie im Kundenbereich Ihres Anbieters, wer als Inhaber eingetragen ist, und lassen Sie es korrigieren, falls es nicht die Firma ist.
2. Übertragen Sie alle Zugänge in den Passwortmanager des Unternehmens und aktivieren Sie die Zwei-Faktor-Authentifizierung.
3. Exportieren Sie Ihre DNS-Zone und entfernen Sie Einträge, die niemand erklären kann.
4. Kontrollieren Sie automatische Verlängerung und Transfersperre.
5. Stellen Sie sicher, dass es nur einen SPF-Eintrag gibt und DKIM bei jedem versendenden Dienst aktiv ist, und starten Sie DMARC im Beobachtungsmodus.
6. Binden Sie Ihre Formulare an einen Dienst für Transaktionsmails an und spielen Sie testweise ein Backup zurück.

Wenn AYTE Digital eine neue Website baut oder eine bestehende Umgebung übernimmt, erstellen wir diese Bestandsaufnahme gemeinsam mit Ihnen, führen die Konten auf den Namen Ihres Unternehmens zusammen und testen DNS und E-Mail-Authentifizierung vor der Übergabe. Damit Sie bei einem späteren Teamwechsel keinen einzigen Schlüssel suchen müssen.