Warum Formular-Mails im Spam landen

Eine Anfrage, die im Spam-Ordner liegt, ist teurer als eine Anfrage, die nie geschrieben wurde. Der Besucher hat sich Mühe gegeben, er wartet auf Antwort, und er hört nichts. Beim nächsten Mal schreibt er jemand anderem.

Der häufigste Grund dafür steckt in einer einzigen Zeile in der Formularkonfiguration. Danach kommen drei Einträge im DNS, die jede Domain haben sollte. Der Reihe nach.

Der Fehler, der am meisten kostet

Viele Kontaktformulare verschicken die Benachrichtigung so:

Von:  besucher@gmail.com
An:   info@deine-domain.de

Das wirkt praktisch, weil sich im Postfach direkt antworten lässt. Für den empfangenden Server sieht es so aus: Ein Server, der zu deine-domain.de gehört, behauptet, Post im Namen von gmail.com zu verschicken. Genau diese Behauptung prüfen Mailserver seit Jahren, und Google hat für seine eigene Domain eine strenge Richtlinie hinterlegt. Das Ergebnis reicht von der Einstufung als Spam bis zur Ablehnung.

Richtig ist die Trennung von Absender und Rückadresse:

Von:        hola@primero.link
Antwort an: besucher@gmail.com

Der Absender bleibt die eigene Domain, für die der eigene Server senden darf. Die Adresse des Besuchers steht im Feld Antwort an, und der Klick auf Antworten geht trotzdem an die richtige Stelle. Bei uns steht das so im Seitenkopf der Kontaktseite:

email:
  subject: 'Anfrage über primero.link: '
  reply_to: ''

Wer ein fertiges Formular-Plugin einsetzt, findet die Einstellung meist unter „Absender" und „Antwort an". Steht dort eine Platzhalterangabe wie {email} als Absender, ist die Zeile gefunden, die deine Anfragen kostet.

Die drei Einträge

Zwei Begriffe dazu, die in jeder Anleitung vorkommen:

Ausrichtung heißt, dass die Domain in der sichtbaren Absenderzeile zu der Domain passt, die SPF oder DKIM geprüft haben. Ein technisch einwandfrei unterschriebener Versand über einen Dienstleister fällt bei DMARC durch, solange die sichtbare Absenderadresse auf eine andere Domain zeigt.

Richtlinie ist das, was DMARC dem Empfänger empfiehlt: p=none beobachten, p=quarantine in den Spam-Ordner, p=reject abweisen. Der übliche Weg beginnt bei none, wertet ein paar Wochen die Berichte aus und zieht dann an.

Was die großen Postfächer verlangen

Bei Microsoft ging es im Mai 2025 zunächst in den Spam-Ordner. Inzwischen werden solche Nachrichten abgewiesen, mit einer Meldung, die man sich merken kann:

550 5.7.515 Access denied, sending domain does not meet
the required authentication level

Die Fünftausend-Grenze klingt weit weg, wenn ein Formular fünf Anfragen im Monat auslöst. Sie ist auch die falsche Zahl, auf die man schauen sollte: Für kleine Absender entscheidet der Ruf der Domain, und der entsteht zu einem guten Teil aus bestandenen Prüfungen.

Neu seit Mai 2026

DMARC hat eine neue Fassung bekommen. Die RFCs 9989, 9990 und 9991 vom Mai 2026 lösen den bisherigen RFC 7489 ab und teilen die Spezifikation in drei Dokumente auf. Drei Änderungen wirken sich auf bestehende Einträge aus:

Der Befund an unserer eigenen Domain

Nachgesehen am 19. September 2026, mit denselben drei Abfragen, die unten stehen.

Die letzte Zeile ist der Grund, warum dieser Beitrag entstanden ist. Eine Domain mit p=quarantine und ohne DKIM hängt vollständig an SPF. Solange die Post den eigenen Server nimmt, geht das gut. Sie fällt in dem Moment aus, in dem eine Nachricht weitergeleitet wird, denn eine Weiterleitung bricht SPF und lässt DKIM unberührt. Bei uns steht deshalb als Nächstes an, DKIM in der Serververwaltung einzuschalten und den Eintrag zu prüfen. Der Selektor lässt sich danach im Kopf einer tatsächlich versendeten Nachricht ablesen.

Der Befund ist typisch. Bei Hosting-Paketen ist SPF meist voreingestellt, DMARC setzt man selbst, und DKIM liegt als Schalter in der Verwaltungsoberfläche, den niemand umgelegt hat.

Prüfen in fünf Minuten

dig +short TXT deine-domain.de          # SPF steht in der Zeile mit v=spf1
dig +short TXT _dmarc.deine-domain.de   # DMARC
dig +short TXT default._domainkey.deine-domain.de   # DKIM, Selektor variiert

Der Selektor bei DKIM ist der einzige Stolperstein: Er wird beim Einrichten vergeben und heißt je nach Anbieter default, dkim, s1 oder anders. Wo er steht, verrät der Kopf einer echten Nachricht. In Gmail öffnet man dazu „Original anzeigen" und sucht nach DKIM-Signature, das s= darin ist der Selektor.

Zum Gegenprüfen der Zustellbarkeit selbst genügt eine Testnachricht an eine Adresse bei Gmail und eine bei Outlook. Was dort im Spam landet, landet bei deinen Kunden auch im Spam.

Was du heute tun kannst

1. Sieh in deinem Formular nach, was als Absender eingestellt ist. Steht dort die Adresse des Besuchers, ändere sie auf deine eigene und trag die Besucheradresse als Antwort an ein.
2. Lass das Formular zusätzlich speichern. Eine Ablage auf dem Server ist die zweite Spur, an der ein Ausfall auffällt. Bei uns liegt jede Anfrage als Datei, unabhängig von der Mail.
3. Prüf die drei Einträge mit den Abfragen oben.
4. Setz DMARC auf p=none mit einer Berichtsadresse, wenn noch nichts da ist, und sieh dir die Berichte zwei Wochen an, bevor du auf quarantine gehst.
5. Schick eine Testanfrage über dein eigenes Formular und sieh nach, wo sie ankommt. Am besten einmal im Quartal.

Wenn du wissen willst, ob die Anfragen von deiner Seite zuverlässig ankommen: Schreib uns kurz, mit deiner Domain. Wir sehen uns die drei Einträge an und sagen dir, was fehlt.

Quellen

• Google: Richtlinien für E-Mail-Absender
• Microsoft: Fehler 550 5.7.515 in Outlook.com beheben
• RFC 9989: DMARC, Kernspezifikation, Mai 2026
• RFC 9990: DMARC Aggregate Reporting
• RFC 9991: DMARC Failure Reporting