Warum Ihre Firmen-E-Mails im Spam landen

Der Anruf klingt fast immer gleich. Eine Offerte ist vor zehn Tagen rausgegangen, der Kunde hat sich nicht gemeldet, man hakt nach — und hört: „Von Ihnen ist nie etwas gekommen." Dann sucht jemand im Spam-Ordner, und dort liegt sie. Ungelesen, aber zugestellt.

Das ist der harmlose Fall. Der unangenehme ist der andere: Die Nachricht wurde gar nicht erst angenommen, sondern vom Empfängerserver abgewiesen, und die Fehlermeldung ist in einem Postfach gelandet, das niemand liest. Dann fehlt nicht nur die Antwort, sondern auch der Hinweis darauf, dass etwas fehlt.

In beiden Fällen liegt es selten am Text und fast nie an einzelnen Wörtern. Es liegt daran, dass Ihre Domain gegenüber den grossen Mailanbietern nicht belegen kann, dass die Nachricht wirklich von Ihnen stammt. Dieser Beitrag erklärt, wie das funktioniert, welcher Fehler bei Websites von KMU am häufigsten ist, und wie Sie den Zustand Ihrer Domain in etwa zehn Minuten selbst prüfen.

Zwei Probleme, die gern verwechselt werden

Bevor es technisch wird, eine Trennung, die viel Sucherei erspart. Es gibt zwei völlig verschiedene Störungen, die sich für den Betrieb identisch anfühlen — „es kommt nichts an":

Erstens: Die Website verschickt gar nichts. Das Kontaktformular meldet „Vielen Dank", aber der Server hat die Nachricht nie abgesendet, weil der Mailversand falsch konfiguriert ist oder ein Passwort abgelaufen ist. Diese Störung ist von aussen unsichtbar, weil die Dankesseite trotzdem erscheint. Sie prüfen sie, indem Sie das eigene Formular einmal im Monat ausfüllen — mit einer Adresse ausserhalb Ihrer eigenen Domain, etwa einem privaten Postfach.

Zweitens: Die Website verschickt, aber niemand nimmt es an. Darum geht es hier. Die Nachricht ist unterwegs, wird aber unterwegs als verdächtig eingestuft, weil sie sich nicht ausweisen kann.

Warum eine E-Mail sich überhaupt ausweisen muss

Das Protokoll, über das E-Mail läuft, stammt aus einer Zeit, in der sich alle Beteiligten kannten. Es hat eine Eigenschaft, die heute das Grundproblem ist: Der Absender ist frei behauptbar. Jeder Server der Welt kann eine Nachricht verschicken, in der als Absender „info@ihre-firma.ch" steht. Nichts im Protokoll hindert ihn daran. Genau das tun Betrüger, wenn sie im Namen einer Treuhandfirma eine gefälschte Zahlungsaufforderung an deren Kunden schicken.

Weil der Absender allein also nichts wert ist, prüfen die Empfängerserver etwas anderes: Kann die Domain, die im Absender steht, unabhängig bestätigen, dass diese Nachricht legitim ist? Diese Bestätigung geben Sie über drei Einträge im DNS Ihrer Domain — dem öffentlichen Verzeichnis, in dem steht, welcher Server für Ihre Domain wofür zuständig ist. Die drei heissen SPF, DKIM und DMARC. Sie kosten nichts, sie sind in Minuten gesetzt, und sie fehlen bei erstaunlich vielen Betrieben.

SPF: wer in Ihrem Namen senden darf

SPF ist eine Liste. In Ihrem DNS steht ein Eintrag, der sinngemäss sagt: „Für meine Domain dürfen diese Server senden — und sonst niemand." Empfängt ein Mailserver eine Nachricht, die angeblich von Ihnen kommt, schaut er nach, ob der tatsächlich sendende Server auf dieser Liste steht.

Der typische Fehler ist nicht ein fehlender SPF-Eintrag, sondern ein unvollständiger. Viele Betriebe versenden über mehr Wege, als ihnen bewusst ist: das Postfach beim Hoster, der Newsletter-Dienst, das Buchhaltungsprogramm, das Rechnungen verschickt, das Terminsystem mit seinen Erinnerungen — und die eigene Website. Steht nur der Hoster in der Liste, gilt alles Übrige als nicht legitimiert.

DKIM: die Unterschrift auf der Nachricht

DKIM geht einen Schritt weiter. Der sendende Server hängt an jede Nachricht eine kryptografische Unterschrift. Der zugehörige öffentliche Schlüssel liegt im DNS Ihrer Domain. Der Empfänger holt sich diesen Schlüssel und prüft die Unterschrift. Passt sie, ist zweierlei belegt: Die Nachricht kommt aus Ihrer Domain, und sie wurde unterwegs nicht verändert.

DKIM ist robuster als SPF, weil es eine Weiterleitung übersteht. Wird eine Nachricht an eine andere Adresse weitergeleitet, ändert sich der sendende Server — SPF scheitert dann, die DKIM-Unterschrift bleibt gültig. Deshalb reicht keines von beiden allein.

DMARC: die Regel, was im Zweifelsfall passieren soll

SPF und DKIM liefern Prüfergebnisse. DMARC sagt dem Empfänger, was er damit tun soll — und stellt eine zusätzliche Bedingung, an der die meisten Konfigurationen scheitern: die Ausrichtung. Es genügt nicht, dass irgendeine SPF- oder DKIM-Prüfung aufgeht. Die Domain, die der Empfänger im sichtbaren Absender sieht, muss zu der Domain passen, die die Prüfung bestanden hat.

Zusätzlich legen Sie in DMARC eine Anweisung fest. p=none heisst „nichts tun, aber berichten" — der Einstieg, mit dem Sie zunächst nur Auswertungen erhalten, wer alles in Ihrem Namen sendet. p=quarantine heisst „in den Spam" und p=reject heisst „gar nicht erst annehmen". Der vernünftige Weg ist, mit none zu starten, die Berichte einige Wochen anzuschauen, alle eigenen Versandwege sauber einzutragen — und erst dann zu verschärfen. Wer sofort auf reject stellt, blockiert unter Umständen die eigene Buchhaltungssoftware.

Der häufigste Fehler bei KMU-Websites

Und damit zum Punkt, der uns in der Praxis am meisten begegnet — er hat direkt mit der Website zu tun.

Sehr viele Kontaktformulare sind so gebaut, dass die Benachrichtigung an den Betrieb im Namen des Interessenten verschickt wird. Im Absender steht dann die private Adresse der Person, die das Formular ausgefüllt hat, damit man bequem auf „Antworten" klicken kann. Technisch bedeutet das: Ihr Webserver verschickt eine Nachricht, die vorgibt, von einer fremden Domain zu stammen. Für diese fremde Domain ist Ihr Server selbstverständlich nicht legitimiert. Die Prüfung scheitert — und je strenger die fremde Domain ihre eigene DMARC-Regel gesetzt hat, desto zuverlässiger landet Ihre eigene Formularmeldung im Spam oder wird abgewiesen.

Die Lösung ist unspektakulär und in fast jedem Formular in zwei Zeilen erledigt: Als Absender steht immer Ihre eigene Domain — etwa „website@ihre-firma.ch". Die Adresse des Interessenten kommt in das Feld Reply-To. Der Antworten-Knopf funktioniert dann genau wie vorher, die Nachricht ist aber sauber legitimiert. Wenn Sie nur eine einzige Sache aus diesem Beitrag mitnehmen, dann diese.

Was die grossen Anbieter inzwischen verlangen

Bis vor wenigen Jahren waren diese Einträge eine Empfehlung. Das hat sich geändert.

Google verlangt seit Februar 2024 von Versendern, die 5'000 oder mehr Nachrichten pro Tag an private Gmail-Konten schicken, sowohl SPF als auch DKIM, dazu einen DMARC-Eintrag mit mindestens der Anweisung p=none, eine Ausrichtung des sichtbaren Absenders auf eine der beiden Prüfungen, gültige Vorwärts- und Rückwärtseinträge im DNS, Versand über eine verschlüsselte Verbindung und eine Beschwerderate unter 0,3 Prozent. Seit November 2025 setzt Google diese Anforderungen härter durch: Nachrichten, die sie nicht erfüllen, werden temporär oder dauerhaft abgewiesen — mit eigenen Fehlercodes je Ursache, etwa 5.7.27 für gescheitertes SPF oder 5.7.32 für fehlende Ausrichtung des Absenders. Microsoft hat für Outlook.com, Hotmail.com und Live.com per 5. Mai 2025 im Kern dieselben Anforderungen für Versender ab 5'000 Nachrichten pro Tag eingeführt.

Nun wird ein Treuhandbüro in Baar keine 5'000 Nachrichten pro Tag verschicken. Der Punkt ist ein anderer: Diese Regeln haben festgelegt, was gute Praxis ist, und die Filter richten sich zunehmend danach — auch unterhalb der Schwelle. Eine Domain ohne SPF, ohne DKIM und ohne DMARC ist heute nicht neutral, sondern auffällig.

Der Zehn-Minuten-Check

1. Schicken Sie sich selbst eine Nachricht — über einen Umweg. Senden Sie von Ihrer Firmenadresse an ein privates Konto bei einem grossen Anbieter. Kommt sie an? In welchem Ordner?

2. Schauen Sie in die Kopfzeilen. In den meisten Programmen finden Sie unter „Original anzeigen" oder „Details" eine Zeile Authentication-Results. Dort steht für spf, dkim und dmarc jeweils pass oder fail. Drei Mal pass ist das Ziel. Das ist der ehrlichste Test überhaupt, weil er das echte Ergebnis eines echten Empfängers zeigt.

3. Füllen Sie Ihr eigenes Kontaktformular aus — mit einer privaten Adresse, nicht mit einer Ihrer Firmenadressen. Prüfen Sie danach im Postfach des Betriebs, ob die Meldung angekommen ist, wie schnell, und welche Adresse im Absender steht. Steht dort die Adresse, die Sie ins Formular getippt haben, haben Sie den oben beschriebenen Fehler.

4. Zählen Sie Ihre Versandwege auf. Postfach, Website, Newsletter, Buchhaltung, Termin- oder Kassensystem, Branchensoftware. Jeder dieser Wege muss legitimiert sein. Die Liste dauert fünf Minuten und ist die Grundlage für alles Weitere.

5. Fragen Sie Ihren Hoster nach dem Ist-Zustand. Die Frage lautet wörtlich: „Sind für unsere Domain SPF, DKIM und DMARC gesetzt, und deckt der SPF-Eintrag alle Dienste ab, über die wir versenden?" Bei einer klaren Antwort ist die Sache meist schnell erledigt; bei einer ausweichenden wissen Sie ebenfalls Bescheid.

6. Prüfen Sie, wo Fehlermeldungen landen. Wenn Ihre Website Nachrichten an eine Adresse schickt, deren Postfach niemand öffnet, bekommen Sie von Ausfällen nichts mit. Legen Sie fest, wer dieses Postfach wöchentlich anschaut.

Was das kostet

Die drei DNS-Einträge selbst kosten nichts. Der Aufwand liegt darin, alle Versandwege zu erfassen und danach die DMARC-Berichte auszuwerten, bevor man die Regel verschärft. Für einen typischen Betrieb mit Postfach, Website und einem Newsletter-Dienst ist das eine überschaubare, einmalige Arbeit — und danach Ruhe, solange kein neuer Dienst dazukommt.

Der Korrektur am Kontaktformular ist noch kleiner: zwei geänderte Zeilen. Bei den Websites, die wir bauen, ist der Formularversand von Beginn weg so eingerichtet, und die Zustellung gehört zur Abnahme, bevor eine Seite live geht. Wenn Sie eine bestehende Seite haben, die anderswo gebaut wurde, ist das trotzdem der erste Punkt, den wir anschauen würden — vor jedem Gedanken an neues Design. Eine Website, die schön aussieht und deren Anfragen im Nichts landen, ist teurer als eine hässliche, die zustellt.

Verwandt und ebenfalls lesenswert: unser Beitrag dazu, wer eine Website nach dem Launch pflegt — die stille Störung im Formular ist dort einer der fünf Punkte.

Häufige Fragen

Was bedeutet es, wenn eine E-Mail im Spam landet, obwohl der Text harmlos ist?

Der Text ist selten die Ursache. Empfängerserver prüfen zuerst, ob sich die Nachricht ausweisen kann: ob der sendende Server für die Absenderdomain legitimiert ist (SPF), ob eine gültige kryptografische Unterschrift vorliegt (DKIM) und ob die sichtbare Absenderdomain zu einer bestandenen Prüfung passt (DMARC-Ausrichtung). Fehlt eines davon, ist die Nachricht auffällig, unabhängig vom Inhalt. Deshalb bringt Umformulieren fast nichts, das Setzen der drei DNS-Einträge dagegen sehr viel.

Warum kommen ausgerechnet die Meldungen aus dem Kontaktformular nicht an?

Weil viele Formulare die Benachrichtigung im Namen der Person verschicken, die das Formular ausgefüllt hat. Im Absender steht dann eine fremde Domain, für die Ihr Webserver nicht legitimiert ist — die Prüfung scheitert zwangsläufig. Richtig ist, als Absender immer die eigene Domain zu verwenden, etwa website@ihre-firma.ch, und die Adresse des Interessenten in das Feld Reply-To zu setzen. Der Antworten-Knopf funktioniert dann unverändert, die Nachricht ist aber sauber ausgewiesen.

Gelten die Anforderungen von Google und Microsoft auch für kleine Betriebe?

Die ausdrücklichen Vorgaben richten sich an Versender ab rund 5'000 Nachrichten pro Tag an private Konten — Google seit Februar 2024, Microsoft für Outlook.com, Hotmail.com und Live.com seit dem 5. Mai 2025. Ein KMU erreicht diese Schwelle nicht. Massgeblich ist trotzdem, dass diese Regeln den heutigen Massstab gesetzt haben: Eine Domain ohne SPF, DKIM und DMARC gilt bei den Filtern nicht mehr als unauffällig. Der Aufwand ist gering, der Nutzen liegt bei jeder einzelnen Offerte.

Stand und Fundstellen: September 2026. Anforderungen für Versender an private Gmail-Konten (SPF und DKIM, DMARC mindestens p=none, Ausrichtung des From-Headers, gültige Vorwärts- und Rückwärts-DNS-Einträge, TLS, Spam-Rate unter 0,3 Prozent, Schwelle 5'000 Nachrichten pro Tag, verschärfte Durchsetzung ab November 2025, Fehlercodes 4.7.23 bis 5.7.32): Google, „Email sender guidelines" und „Email sender guidelines FAQ", Gmail-Hilfe. Anforderungen für Versender ab 5'000 Nachrichten pro Tag an Outlook.com, Hotmail.com und Live.com ab 5. Mai 2025: Ankündigung des Microsoft-Defender-for-Office-365-Teams vom April 2025. Dieser Beitrag ist keine Rechts- oder Sicherheitsberatung; Richtlinien der Anbieter ändern sich — prüfen Sie den Stand, bevor Sie darauf handeln.

Über uns: LMMeier ist eine Webagentur im Kanton Zug — Websites für KMU zum Festpreis, persönlich von Lisa und Matthias aus Baar. ← Alle Beiträge