Das Kontaktformular auf der Website meldet: Vielen Dank, Ihre Nachricht wurde versendet. Im Postfach des Unternehmens kommt sie trotzdem nicht an, oder sie liegt unbemerkt im Spam-Ordner. Diese Lücke zwischen technischer Erfolgsmeldung und tatsächlicher Zustellung ist einer der teuersten blinden Flecken auf Firmenwebsites, denn niemand beschwert sich über eine Nachricht, die er nicht gesehen hat. Die Ursache liegt selten im Formular selbst, sondern in der E-Mail-Authentifizierung: Empfangende Mailserver prüfen heute sehr genau, ob eine Nachricht wirklich von der Domain stammt, die im Absender steht. Drei Verfahren entscheiden darüber: SPF, DKIM und DMARC. Wie stark sich diese Prüfungen inzwischen auswirken, zeigt eine Zahl des größten Postfachanbieters: Nach Einführung verbindlicher Absenderregeln ging die Zahl unauthentifizierter Nachrichten in den Postfächern um 75 Prozent (Google) zurück. Dieser Beitrag erklärt, wie eine Formular-Mail technisch entsteht, was die drei Verfahren tun, welche Fehler in der Praxis am häufigsten Zustellung kosten und in welcher Reihenfolge kleine und mittlere Unternehmen das sauber einrichten.
Das Wichtigste in Kürze
- Beim Absenden eines Formulars verschickt der Webserver selbst eine E-Mail — und genau dieser Absender ist es, den Postfachanbieter prüfen.
- SPF, DKIM und DMARC sind offene Standards der IETF; jeder löst ein anderes Teilproblem, erst zusammen ergeben sie ein belastbares Bild.
- Seit Februar 2024 verlangen große Postfachanbieter Authentifizierung von Absendern — für Formular-Mails ist das keine Kür mehr.
- Der häufigste Fehler ist der Start in der Mitte: irgendwo einen SPF-Eintrag setzen und auf Besserung hoffen, statt erst alle Versandwege zu erfassen.
- DMARC ist kein Rundumschutz gegen Betrug: Es prüft die Absenderdomain, nicht den Inhalt — täuschend ähnliche Domains fängt es nicht.
- Eingerichtet ist nicht überprüft: Reports auswerten, Testversand und ein regelmäßiger Blick verhindern, dass eine funktionierende Konfiguration unbemerkt zerfällt.
Wie eine Kontaktformular-Mail entsteht
Wenn eine Besucherin auf Absenden klickt, passiert technisch mehr, als die Erfolgsmeldung vermuten lässt. Das Formular schickt die Eingaben an ein Skript auf dem Webserver. Dieses Skript baut daraus eine E-Mail und übergibt sie an einen Mailserver, der sie an das Postfach des Unternehmens ausliefert. Entscheidend ist dabei ein Detail, das im Alltag kaum jemand sieht: Die Domain im Absender und der Server, der die Nachricht tatsächlich verschickt, sind zwei verschiedene Dinge. Die Domain gehört Ihnen, der sendende Server gehört häufig dem Hoster der Website, während die Postfächer bei einem dritten Anbieter liegen. Für den empfangenden Mailserver lautet die Frage deshalb nicht, ob die Nachricht echt aussieht, sondern ob dieser konkrete Server für diese konkrete Domain senden darf.
Erschwerend kommt hinzu, dass jede E-Mail zwei Absenderangaben trägt. Beim Transport nennt der sendende Server eine Adresse im sogenannten Envelope-From, technisch RFC5321.MailFrom; an sie gehen Unzustellbarkeitsmeldungen zurück. Im Postfach sichtbar ist dagegen der From-Header, technisch RFC5322.From, und nur diesen liest der Empfänger. Beide können völlig unterschiedliche Domains enthalten, ohne dass es auffällt. SPF prüft die Transportadresse, DKIM prüft die signierende Domain, und erst DMARC verlangt, dass mindestens eine davon zur sichtbaren Absenderdomain passt (IETF RFC 7489). Genau an dieser Stelle scheitert die Authentifizierung bei Website-Formularen besonders häufig.
Kurz erklärt: zwei Absender in jeder E-Mail
Hinzu kommt, dass eine Website selten das einzige System ist, das unter Ihrer Domain Nachrichten verschickt. Newsletter, Rechnungsversand aus der Buchhaltung, Terminbestätigungen aus einer Buchungsstrecke und das normale Postfach senden häufig über völlig verschiedene Server. Wer nur an die Website denkt und die übrigen Systeme vergisst, sperrt sich beim späteren Verschärfen der Regeln die eigenen Nachrichten aus. Wie viel an solchen automatischen Benachrichtigungen hängt, zeigt sich besonders deutlich bei einer Online-Terminbuchung auf der Website, bei der jede Bestätigung und jede Erinnerung eine eigene E-Mail ist.
- Kontaktformular, Rückrufwunsch und Bewerbungsformular auf der Website
- Bestell- und Versandbestätigungen aus einem Onlineshop
- Termin- und Erinnerungsmails aus einer Buchungsstrecke
- Rechnungen, Mahnungen und Belege aus der Buchhaltung
- Newsletter und regelmäßige Kundeninformationen
- Das tägliche Postfach der Mitarbeitenden
Wo die Website liegt, entscheidet also mit darüber, welcher Server im Namen Ihrer Domain auftritt. Ein Umzug auf einen anderen Server oder ein Wechsel des Formular-Backends verändert diese Absenderkette, ohne dass sich am sichtbaren Formular etwas ändert. Warum Betrieb und Mailversand zusammen gedacht gehören, zeigt auch unser Beitrag zu den Vorteilen von Webhosting in Deutschland.
SPF, DKIM und DMARC: die drei Bausteine
Alle drei Verfahren sind offene Internetstandards der Internet Engineering Task Force. Sie lösen jeweils ein anderes Teilproblem, und erst zusammen ergeben sie ein belastbares Bild. Wer nur eines davon einrichtet, hat die halbe Strecke geschafft, aber selten das Ergebnis, auf das er gehofft hat.
SPF: wer senden darf
Das Sender Policy Framework, standardisiert in RFC 7208 aus dem Jahr 2014, ist ein DNS-Eintrag, in dem Sie festlegen, welche Server im Namen Ihrer Domain E-Mails verschicken dürfen (IETF RFC 7208). Der empfangende Server schlägt den Eintrag nach und vergleicht ihn mit der IP-Adresse, von der die Nachricht kam. Pro Domain darf es nur einen SPF-Eintrag geben; findet die Prüfung mehrere, endet sie mit einem permanenten Fehler (IETF RFC 7208).
DKIM: kryptografische Signatur
DomainKeys Identified Mail, standardisiert in RFC 6376 aus dem Jahr 2011, versieht jede ausgehende Nachricht mit einer Signatur über ausgewählte Kopfzeilen und den Nachrichtentext (IETF RFC 6376). Der passende öffentliche Schlüssel liegt im DNS unter einem Selektor. Für langlebige Schlüssel verlangt der Standard mindestens 1024 Bit (IETF RFC 6376); in der Praxis sind längere Schlüssel üblich. Anders als SPF übersteht eine DKIM-Signatur eine Weiterleitung, solange die Nachricht unverändert bleibt.
DMARC: Regel und Rückmeldung
DMARC, beschrieben in RFC 7489 aus dem Jahr 2015, verbindet beide Verfahren mit zwei Ideen: Alignment und Policy (IETF RFC 7489). Alignment verlangt, dass die per SPF oder DKIM bestätigte Domain zur sichtbaren Absenderdomain passt. Die Policy sagt dem Empfänger, was mit durchgefallenen Nachrichten geschehen soll: none, quarantine oder reject. Über den rua-Eintrag kommen zusätzlich tägliche Sammelberichte zurück.
Alignment gibt es in zwei Schärfegraden. Im entspannten Modus genügt es, wenn beide Domains zur selben organisatorischen Domain gehören, eine Subdomain also zur Hauptdomain passt. Im strengen Modus müssen die Namen exakt übereinstimmen (IETF RFC 7489). Für den Anfang ist der entspannte Modus praxistauglicher, weil viele Systeme mit Subdomains arbeiten. Wichtig ist außerdem die Reihenfolge: DMARC ist bereits bestanden, wenn eine der beiden Prüfungen erfolgreich und ausgerichtet ist. Eine korrekte DKIM-Signatur ist deshalb der stabilere Anker, während SPF an jeder Weiterleitung zerbrechen kann.
Warum ein Verfahren allein selten reicht
Warum das 2026 keine Kür mehr ist
Lange galt E-Mail-Authentifizierung als Thema für große Versender. Das hat sich geändert. Seit Februar 2024 verlangt der größte Postfachanbieter von Absendern, die mehr als 5.000 Nachrichten (Google) pro Tag an seine Nutzer schicken, SPF und DKIM, eine veröffentlichte DMARC-Richtlinie und ein Alignment zwischen sichtbarer Absenderdomain und geprüfter Domain. Gleichzeitig gilt eine Obergrenze für gemeldete Spam-Beschwerden von 0,30 Prozent (Google), empfohlen wird ein Wert unter 0,10 Prozent (Google). Ein weiterer großer Anbieter hat für seine Privatkundenpostfächer vergleichbare Anforderungen an Versender mit hohem Volumen veröffentlicht (Microsoft).
Die Wirkung dieser Regeln lässt sich beziffern: Nach Angaben des Anbieters sank die Zahl unauthentifizierter Nachrichten in den Postfächern um 75 Prozent (Google), und die Filter blockieren nach derselben Darstellung täglich rund 15 Milliarden unerwünschte Nachrichten (Google). Für kleine Unternehmen heißt das: Die Schwelle von 5.000 Nachrichten mag weit entfernt wirken, doch dieselben Filter bewerten auch einzelne Nachrichten. Eine Domain ohne Authentifizierung fällt in dieser Umgebung negativ auf, unabhängig vom Volumen.
Auch auf nationaler Ebene ist das Thema aus der Nische heraus. Das Bundesamt für Sicherheit in der Informationstechnik hat mit der Technischen Richtlinie TR-03182 Email Authentication prüfbare Anforderungen an E-Mail-Diensteanbieter veröffentlicht und begründet sie damit, dass E-Mail-Authentifizierung vor Angriffen schützt, bei denen die Identität vertrauenswürdiger Sender vorgetäuscht wird, etwa Spoofing und Phishing (BSI, Technische Richtlinie TR-03182). Ergänzt wird sie durch die Richtlinie zum sicheren E-Mail-Transport (BSI, Technische Richtlinie TR-03108). Für einen mittelständischen Betrieb sind diese Richtlinien keine unmittelbare Pflicht, aber sie zeigen deutlich, in welche Richtung sich die Erwartungen bewegen.
Mailbox-Anbieter sprechen regelmäßig von einer möglichen Zukunft der E-Mail-Authentifizierung mit dem Schlagwort: keine Authentifizierung, kein Zutritt.
Auch unterhalb der 5.000-Grenze zählt Authentifizierung
Schritt für Schritt zur sauberen Einrichtung
Der häufigste Fehler bei der Einrichtung ist der Start in der Mitte: irgendwo einen SPF-Eintrag setzen und auf Besserung hoffen. Sinnvoll ist die umgekehrte Reihenfolge, weil jeder spätere Schritt auf einer vollständigen Bestandsaufnahme aufbaut. Für ein kleines Unternehmen ist das eine überschaubare Aufgabe, wenn sie einmal geordnet abgearbeitet wird.
- Bestandsaufnahme: Alle Systeme erfassen, die unter der Domain senden. Website, Onlineshop, Buchungsstrecke, Newsletter, Buchhaltung, Ticketsystem und klassisches Postfach. Erfahrungsgemäß tauchen bei dieser Übung in kleinen Betrieben regelmäßig zwei bis drei vergessene Absender auf (Projekterfahrung).
- SPF veröffentlichen: Genau ein Eintrag pro Domain, der ausschließlich die tatsächlich benötigten Server oder Netzblöcke freigibt. M3AAWG empfiehlt, SPF-Einträge mit einem weichen Fehlschlag abzuschließen und nicht mehr Adressen freizugeben als nötig (M3AAWG).
- DKIM je System einrichten: Für jedes sendende System ein eigenes Schlüsselpaar mit eigenem Selektor. So lässt sich später nachvollziehen, welches System welche Nachricht signiert hat, und ein Schlüsselwechsel betrifft nur ein System.
- DMARC mit p=none starten: Zunächst nur beobachten und über den rua-Eintrag Sammelberichte anfordern. Ohne die Möglichkeit, Berichte zu empfangen und auszuwerten, kann ein Domaininhaber nicht wissen, ob eine strengere Richtlinie gefahrlos möglich ist (M3AAWG).
- Auswerten und nachziehen: Berichte über mehrere Wochen sichten, unbekannte Absender klären, fehlende Signaturen ergänzen. Erst danach auf p=quarantine wechseln.
- Auf p=reject verschärfen: M3AAWG empfiehlt p=reject, wo es betrieblich möglich ist, sonst p=quarantine; p=none, sp=none und ein pct-Wert unter 100 sollten nur als Übergangszustände gelten (M3AAWG).
- Nicht sendende Domains absichern: Für Domains und Schreibvarianten, über die keine E-Mail verschickt wird, empfiehlt M3AAWG einen SPF-Eintrag, der jeden Versand ausschließt (M3AAWG).
Beim SPF-Eintrag lauern zwei Fallen, die in der Praxis wiederholt Zustellung kosten. Die erste ist der doppelte Eintrag: Wird für einen neuen Dienst einfach ein zweiter SPF-Record angelegt, statt den bestehenden zu erweitern, endet die Prüfung mit einem permanenten Fehler, und zwar für alle Systeme gleichzeitig (IETF RFC 7208). Die zweite ist das Lookup-Limit: Der Standard schreibt vor, dass eine SPF-Auswertung höchstens 10 DNS-Abfragen (IETF RFC 7208) auslösen darf, um die Last auf das DNS zu begrenzen. Jeder Verweis auf einen Dienstleister verbraucht davon mindestens eine. Zusätzlich sollen Abfragen ohne Ergebnis, im Standard void lookups genannt, auf zwei (IETF RFC 7208) begrenzt werden. Wer vier oder fünf Dienste einbindet, reißt diese Grenze schneller als gedacht.
Beim DMARC-Eintrag ist der Weg wichtiger als das Ziel. p=none verändert nichts an der Zustellung und dient ausschließlich der Beobachtung. p=quarantine weist den Empfänger an, durchgefallene Nachrichten als verdächtig zu behandeln, was in der Praxis meist den Spam-Ordner bedeutet. p=reject verlangt die Abweisung (IETF RFC 7489). Zwei Stellschrauben helfen beim Übergang: Der pct-Wert legt fest, auf welchen Anteil des Nachrichtenstroms die Richtlinie angewendet wird, und der sp-Eintrag regelt Subdomains getrennt von der Hauptdomain (IETF RFC 7489).
| Einstellung | Was der Empfänger tut | Wann sie passt |
|---|---|---|
| p=none | Zustellung unverändert, es kommen nur Berichte zurück | Einstieg und Bestandsaufnahme, solange nicht alle Absender bekannt sind |
| p=quarantine | Durchgefallene Nachrichten gelten als verdächtig | Wenn alle bekannten Systeme sauber signieren, aber ein Restrisiko bleibt |
| p=reject | Durchgefallene Nachrichten werden abgewiesen | Wenn die Berichte über mehrere Wochen unauffällig geblieben sind |
| sp= | Eigene Regel für Subdomains | Wenn Subdomains von anderen Systemen bespielt werden |
| pct= | Richtlinie gilt nur für einen Anteil der Nachrichten | Für einen kontrollierten Übergang zwischen zwei Stufen |
| rua= | Empfänger schicken tägliche Sammelberichte | In jeder Stufe, weil ohne Berichte jede Verschärfung ein Ratespiel bleibt |
Alle Einträge liegen im DNS Ihrer Domain und wirken sich auf jeden Versand aus, auch auf den aus der Buchhaltung. Deshalb gehören sie in dieselbe geordnete Planung wie ein Serverumzug, bei dem ebenfalls Reihenfolge und Wartezeiten entscheidend sind. Welche Fehler bei solchen Umstellungen typischerweise passieren, beschreibt unser Beitrag zum Website-Relaunch ohne Ranking-Verlust. Welche Aufgaben rund um Technik und Betrieb wir übernehmen, zeigt die Übersicht unserer Leistungen für Website und Onlineshop.
Typische Fehlerbilder aus der Praxis
Wenn Formular-Mails im Spam landen oder gar nicht ankommen, sind es meist dieselben sechs Ursachen. Fast alle lassen sich beheben, ohne das Formular neu zu bauen.
Kundenadresse als Absender
Das Formular trägt die Adresse der anfragenden Person als Absender ein, damit die Antwort per Klick funktioniert. Damit steht im sichtbaren From-Header eine fremde Domain, für die Ihr Server nicht senden darf. Richtig ist eine feste Absenderadresse Ihrer eigenen Domain und die Kundenadresse im Antwort-an-Feld.
Weiterleitungen brechen SPF
Wird eine Nachricht an ein anderes Postfach weitergeleitet, verschickt sie der weiterleitende Server, und die SPF-Prüfung schlägt am Ziel fehl. Eine gültige DKIM-Signatur übersteht diesen Schritt in der Regel, solange der Inhalt unverändert bleibt. M3AAWG ruft Zwischenstationen deshalb auf, Änderungen an Nachrichten so gering wie möglich zu halten (M3AAWG).
Subdomain vergessen
Die Hauptdomain ist sauber eingerichtet, der Versand läuft aber über eine Subdomain, etwa für Shop oder Newsletter. Ohne eigene Einträge oder eine passende sp-Regel bleibt diese Lücke offen und lässt sich für Missbrauch nutzen (IETF RFC 7489).
Versand über fremde IP
Nach einem Hosting- oder Systemwechsel verschickt plötzlich ein anderer Server die Formular-Mails. Der SPF-Eintrag kennt diesen Server nicht, die Nachrichten fallen durch. Solche Wechsel fallen oft erst auf, wenn jemand eine erwartete Anfrage vermisst.
Zwei SPF-Einträge
Ein weiterer Dienst wird eingebunden und legt seinen eigenen SPF-Eintrag an. Ab diesem Moment liefert die Prüfung einen permanenten Fehler für die gesamte Domain (IETF RFC 7208). Richtig ist ein einziger Eintrag, in dem alle Dienste zusammengeführt sind.
Pflichtangaben fehlen
Geschäftliche E-Mails gelten als Geschäftsbriefe und brauchen dieselben Pflichtangaben wie das Impressum der Website. Fehlen sie, ist das kein Zustellproblem, aber ein rechtliches. Welche Angaben dazugehören, klärt unser Beitrag zur Impressumspflicht und den Pflichtangaben.
Der stille Ausfall ist der teuerste
Was DMARC leistet und was nicht
DMARC wird gerne als Rundumschutz gegen Betrug dargestellt. Das ist es nicht, und die Unterscheidung ist wichtig, weil sonst falsche Erwartungen entstehen. Zunächst das, was die Richtlinie tatsächlich bewirkt:
- Sie erschwert es erheblich, dass Dritte Nachrichten mit exakt Ihrer Domain im sichtbaren Absender verschicken, soweit die empfangenden Systeme die Richtlinie beachten.
- Sie macht sichtbar, welche Systeme unter Ihrer Domain senden, auch jene, von denen im Unternehmen niemand mehr wusste.
- Sie verbessert die Chance, dass legitime Nachrichten den Posteingang erreichen, weil das Authentifizierungsergebnis in die Bewertung einfließt.
- Sie liefert über die Sammelberichte eine belastbare Grundlage, statt Zustellprobleme zu raten (M3AAWG).
Ebenso wichtig sind die Grenzen, die man kennen sollte, bevor man sich in Sicherheit wiegt:
- DMARC schützt nicht vor ähnlich aussehenden Domains. Eine Nachricht von einer verwechselbaren Schreibweise Ihres Namens ist technisch korrekt authentifiziert, nur eben für die falsche Domain.
- DMARC prüft keine Inhalte. Eine authentifizierte Nachricht kann trotzdem Schadsoftware oder eine gefälschte Rechnung enthalten.
- DMARC ersetzt weder die Verschlüsselung des Transports noch den Virenschutz; dafür sind andere Verfahren zuständig (BSI, Technische Richtlinie TR-03108).
- DMARC wirkt nur, soweit empfangende Systeme die Richtlinie auswerten und beachten (IETF RFC 7489).
Beim verbreiteten Rechnungsbetrug hilft DMARC dort, wo Angreifer die echte Firmendomain missbrauchen, um eine geänderte Bankverbindung glaubwürdig erscheinen zu lassen. Es hilft nicht, wenn jemand eine eigene, ähnlich klingende Domain registriert und von dort schreibt. Zu einer durchdachten Absenderstrategie gehört deshalb auch, naheliegende Schreibvarianten der eigenen Domain zu sichern und für diese einen SPF-Eintrag zu veröffentlichen, der jeden Versand ausschließt (M3AAWG). Der zweite Baustein ist Aufmerksamkeit im Team, denn eine geänderte Kontoverbindung sollte grundsätzlich telefonisch bestätigt werden.
Ein häufiger Einwand betrifft die Sammelberichte: Enthalten sie personenbezogene Daten? Die Berichte fassen Zustellergebnisse statistisch nach sendender IP-Adresse zusammen und enthalten keine Nachrichteninhalte (IETF RFC 7489). Die Certified Senders Alliance im eco Verband der Internetwirtschaft hat die Vereinbarkeit von DMARC mit der Datenschutz-Grundverordnung in einem eigenen Gutachten untersucht (eco Verband der Internetwirtschaft, Certified Senders Alliance). Bei Einzelfallberichten über den ruf-Eintrag ist mehr Zurückhaltung angebracht; M3AAWG hält deren Einbindung ausdrücklich für optional (M3AAWG). Wie Datenschutz auf der Website insgesamt sauber umgesetzt wird, fasst unsere DSGVO-Checkliste für Websites zusammen.
Kontrolle: Reports, Testversand und Monitoring
Eingerichtet ist nicht dasselbe wie überprüft. Fünf einfache Routinen verhindern, dass eine funktionierende Konfiguration unbemerkt zerfällt.
- Sammelberichte lesen: Die täglichen rua-Berichte zeigen, welche Server unter Ihrer Domain gesendet haben und ob SPF und DKIM bestanden wurden. Ohne diese Auswertung bleibt jede Verschärfung ein Ratespiel (M3AAWG).
- Testversand nach jeder Änderung: Nach Anpassungen an DNS, Hosting oder Formular eine echte Anfrage abschicken und im Zielpostfach die Kopfzeilen prüfen, ob für SPF, DKIM und DMARC jeweils ein Bestanden vermerkt ist.
- Alle Absender einzeln testen: Nicht nur das Kontaktformular, sondern auch Bestellbestätigung, Rechnungsversand und Newsletter, weil jedes System eine eigene Signatur braucht.
- Nach Umzügen erneut prüfen: Hosting-Wechsel, ein neues Formular-Backend oder ein Wechsel des Postfachanbieters verändern die sendenden Server. Solche Änderungen sind der häufigste Grund dafür, dass eine vorher saubere Konfiguration plötzlich durchfällt (Projekterfahrung).
- Schlüsselwechsel planen: Ein DKIM-Schlüssel, dessen öffentlicher Teil zu früh aus dem DNS entfernt wird, macht alle noch unterwegs befindlichen Nachrichten unprüfbar (IETF RFC 6376).
Der Aufwand bleibt überschaubar, wenn er Teil der laufenden Betreuung ist, statt einmal im Jahr in Eile nachgeholt zu werden. In unseren Projekten dauert die Ersteinrichtung für ein kleines Unternehmen mit drei bis vier sendenden Systemen wenige Stunden, die anschließende Beobachtungsphase bis zur strengeren Richtlinie dagegen mehrere Wochen (Projekterfahrung). Warum sich regelmäßige Pflege auch sonst auszahlt, beschreibt unser Beitrag zur Website-Wartung; den laufenden Rahmen dafür bietet unsere Website-Betreuung.
Der Moment, in dem es am häufigsten bricht
Was das für Ihre Website bedeutet
Für die meisten kleinen und mittleren Unternehmen ist E-Mail-Authentifizierung eine einmalige Aufräumaktion mit dauerhafter Wirkung. Sie kostet keine Lizenzgebühren, sondern Sorgfalt: eine vollständige Liste der sendenden Systeme, einen sauberen SPF-Eintrag, je System einen DKIM-Schlüssel und eine DMARC-Richtlinie, die schrittweise schärfer wird. Der Nutzen zeigt sich doppelt, bei der Zustellung eigener Nachrichten und beim Schutz der eigenen Marke vor Missbrauch. Wer zusätzlich messen möchte, wie viele Anfragen tatsächlich ankommen, findet die passenden Kennzahlen in unserem Beitrag zum Messen des Website-Erfolgs.
Wir richten Website-Versand, DNS-Einträge und die Auswertung der Sammelberichte im Rahmen unseres Webhosting-Angebots ein und prüfen die Zustellung nach jedem Umzug erneut. Wenn Sie nicht einschätzen können, wie Ihre Domain aktuell dasteht, ist ein Zustellbarkeits-Check der bestehenden Domain der schnellste Einstieg: Wir sehen uns SPF, DKIM und DMARC an, benennen die offenen Punkte und ordnen ein, was davon dringend ist und was warten kann. Für Fragen zum konkreten Vorgehen erreichen Sie uns über das Kontaktformular, das bei uns übrigens authentifiziert versendet.
Quellen und Studien