„Seit Wochen bekommen wir keine Anfragen mehr über das Kontaktformular." Der Anruf kommt von einem langjährigen Kunden, und er klingt vorwurfsvoll. Du testest das Formular – es funktioniert einwandfrei, die Mail wird verschickt. Nur landet sie nie im Postfach. Mal steckt sie im Spam-Ordner, mal kommt sie mit einer kryptischen Fehlermeldung zurück: „550 5.7.15 Access denied". Das Formular ist nicht kaputt. Kaputt ist etwas, das die wenigsten Agenturen auf dem Schirm haben: die E-Mail-Authentifizierung.
Seit die großen Anbieter ihre Regeln verschärft haben, entscheidet nicht mehr allein der Inhalt einer Mail, ob sie ankommt – sondern ob die Domain nachweisen kann, dass sie senden darf. Dieser Beitrag erklärt, warum gerade Kundenprojekte betroffen sind, was Google, Yahoo und Microsoft heute verlangen, und wie du das Thema in vier Schritten sauber löst – und daraus einen wiederkehrenden Service machst.
Warum E-Mail-Zustellbarkeit zum Agentur-Thema wird
Lange war E-Mail-Zustellbarkeit das Problem der großen Newsletter-Versender. Das hat sich geändert. Seit dem 1. Februar 2024 verlangen Google und Yahoo von allen Absendern ein Mindestmaß an Authentifizierung, und für größere Versender wurde daraus eine harte Pflicht. Microsoft zog nach: Seit dem 5. Mai 2025 lehnt Outlook.com E-Mails von Massenversendern ab, die die neuen Anforderungen nicht erfüllen – nicht Spam-Ordner, sondern komplette Zurückweisung mit der Fehlermeldung „550 5.7.15 Access denied".
Für Agenturen ist das relevant, weil die Grenze zwischen „normalem" und „Massen"-Versand fließend ist und die Basisregeln ohnehin für alle gelten. Eine schlecht konfigurierte Domain landet auch bei kleinen Mengen zunehmend im Spam. Und weil die betroffenen Postfächer – Gmail, Yahoo, Outlook, Hotmail – die mit Abstand meistgenutzten sind, trifft es früher oder später fast jedes Kundenprojekt.
Ein verbreiteter Irrtum: HTTPS hat damit nichts zu tun
Bevor es an die Technik geht, ein Missverständnis, das erstaunlich oft auftaucht – auch bei erfahrenen Kollegen. „Die Seite hat doch ein SSL-Zertifikat, dann sind die Mails doch sicher." Das eine hat mit dem anderen nichts zu tun. HTTPS verschlüsselt die Verbindung zwischen Browser und Website; es sagt nichts darüber aus, ob eine E-Mail authentifiziert ist. Eine perfekt per HTTPS ausgelieferte Seite kann Mails verschicken, die bei jedem Empfänger im Spam landen, weil im DNS kein einziger Authentifizierungs-Eintrag steht. E-Mail-Sicherheit und Transportverschlüsselung der Website sind zwei getrennte Baustellen – und die Mail-Baustelle wird deutlich häufiger übersehen.
Die drei Buchstaben-Kürzel, die entscheiden
Hinter der Authentifizierung stehen drei Standards, die zusammenspielen. Wer sie einmal verstanden hat, kann jedem Kunden in zwei Sätzen erklären, worum es geht.
SPF (Sender Policy Framework) ist die Gästeliste: ein DNS-Eintrag, der festlegt, welche Server im Namen deiner Domain E-Mails verschicken dürfen. Kommt eine Mail von einem Server, der nicht auf der Liste steht, ist das ein Warnsignal.
DKIM (DomainKeys Identified Mail) ist das Siegel: Jede Mail bekommt eine kryptografische Signatur, die beweist, dass sie unterwegs nicht verändert wurde und wirklich von der Domain stammt. Der passende öffentliche Schlüssel liegt ebenfalls im DNS.
DMARC (Domain-based Message Authentication) ist die Hausordnung: Es verknüpft SPF und DKIM mit der sichtbaren Absenderadresse („Alignment") und legt fest, was passieren soll, wenn die Prüfung scheitert – nichts tun (p=none), in den Spam verschieben (p=quarantine) oder ablehnen (p=reject). Zusätzlich schickt DMARC Berichte darüber, wer im Namen der Domain sendet.
Was Google, Yahoo und Microsoft konkret verlangen
Die Anforderungen sind gestaffelt. Für alle Absender an Gmail gilt seit Februar 2024: mindestens SPF oder DKIM, gültige Reverse-DNS-Einträge (PTR), Übertragung per TLS, Einhaltung des Standards RFC 5322 und eine in den Postmaster Tools gemeldete Spam-Rate unter 0,3 Prozent. Die sichtbare Absenderadresse im „From"-Header darf nicht gefälscht sein.
Für Massenversender ab 5.000 Nachrichten pro Tag verschärfen sich die Regeln: Jetzt sind SPF und DKIM zwingend, dazu ein gültiger DMARC-Eintrag (mindestens p=none) und – bei Marketing- und Abo-Mails – eine funktionierende Abmeldung mit einem Klick. Microsoft übernahm für Outlook.com, Hotmail und Live dieselbe 5.000er-Schwelle und verlangt seit Mai 2025 bestandenes SPF, DKIM und ein DMARC mit mindestens p=none samt Alignment. Wer das nicht erfüllt, dessen Mails werden nicht aussortiert, sondern rundheraus abgelehnt.
Die 5.000er-Grenze klingt hoch, ist es im Alltag aber nicht immer: Ein Kunde mit einem aktiven Newsletter, automatischen Bestellbestätigungen und Terminerinnerungen kommt schneller dorthin, als er denkt. Und selbst wer klar darunter bleibt, profitiert: Die Basisanforderungen – korrekte DNS-Einträge, TLS, kein gefälschter Absender – gelten unabhängig von der Menge, und eine authentifizierte Domain genießt bei den Spam-Filtern schlicht mehr Vertrauen. Zustellbarkeit ist also keine reine Newsletter-Frage, sondern eine Grundeigenschaft jeder Domain, die überhaupt Mails verschickt.
Warum gerade Kontaktformulare in die Falle tappen
Der häufigste Fehler steckt in einer scheinbar sinnvollen Einstellung. Damit die Formular-Mail so aussieht, als käme sie vom Website-Besucher, tragen viele Formulare dessen Adresse direkt in den „From"-Header ein – also etwa From: max.mustermann@gmx.de. Verschickt wird die Mail aber über den Server des Hosters, der nichts mit gmx.de zu tun hat. Für die Empfänger-Prüfung sieht das aus wie eine Fälschung: Der sendende Server steht nicht im SPF der Absender-Domain, das Alignment scheitert, die Mail wird aussortiert.
Die Lösung ist unspektakulär: Der „From"-Header gehört auf eine Adresse der eigenen, authentifizierten Kundendomain – etwa From: website@kundendomain.de. Die Adresse des Besuchers wandert in den „Reply-To"-Header, damit der Kunde weiterhin direkt antworten kann. So bleibt die Zustellung sauber, ohne dass die Bedienung leidet. Noch robuster ist der Versand über einen authentifizierten SMTP-Zugang oder einen transaktionalen Mail-Dienst statt über die simple mail()-Funktion von PHP.
In vier Schritten sauber aufsetzen
Zuerst der SPF-Eintrag: Er listet alle Server und Dienste, die für die Domain senden – den Hoster, den Newsletter-Dienst, gegebenenfalls das CRM. Zweitens DKIM: Fast jeder seriöse Hoster und E-Mail-Dienst bietet die Aktivierung an; die erzeugten Schlüssel kommen in den DNS. Drittens DMARC: Starte defensiv mit p=none und einer Report-Adresse (rua), beobachte einige Wochen, wer wirklich in deinem Namen sendet, und ziehe die Richtlinie dann schrittweise auf p=quarantine und p=reject an. Viertens das Formular: „From" auf die eigene Domain, „Reply-To" auf den Absender, Versand idealerweise über authentifiziertes SMTP.
Zum Prüfen genügen kostenlose Werkzeuge: mail-tester.com bewertet eine Testmail mit Punkten und benennt fehlende Einträge, MXToolbox prüft SPF-, DKIM- und DMARC-Records, und die Google Postmaster Tools zeigen Spam-Rate und Authentifizierungsquote im Zeitverlauf.
Ein Wort zur Reihenfolge: Springe nicht sofort auf p=reject. Wer die DMARC-Richtlinie verschärft, bevor alle legitimen Sende-Dienste sauber erfasst sind, blockiert womöglich die eigenen Rechnungen aus dem Buchhaltungstool oder die Bestätigungen aus dem Shop. Deshalb der Umweg über p=none mit Reporting: Erst wenn die Berichte über mehrere Wochen zeigen, dass wirklich nur die vorgesehenen Server senden, ist die scharfe Stufe gefahrlos. Diese Geduld ist kein Zeichen von Unsicherheit, sondern der Grund, warum eine saubere Umstellung nie versehentlich echte Kundenpost verschluckt.
Aus dem Ärgernis ein Standbein machen
Für Agenturen steckt hier ein sauberer, wiederkehrender Service. Ein einmaliges „Zustellbarkeits-Setup" pro Kundendomain – SPF, DKIM, DMARC und die richtige Formular-Konfiguration – ist in überschaubarer Zeit erledigt und verhindert genau den Anruf vom Anfang. Der laufende Teil ist das Auswerten der DMARC-Berichte: Sie zeigen nicht nur Konfigurationsfehler, sondern auch, wenn Dritte versuchen, im Namen deines Kunden Phishing-Mails zu verschicken. Dieser Schutz vor Identitätsmissbrauch ist zugleich ein Sicherheitsargument, das gut zu den steigenden Anforderungen an die Lieferketten-Sicherheit nach NIS2 passt.
Am besten bündelst du das mit einem bestehenden Wartungsvertrag: Domains ändern sich, Dienste kommen hinzu, und ein DMARC-Report will regelmäßig gelesen werden. Aus einer Fehlermeldung, die niemand versteht, wird so ein Baustein, den du über deinen ganzen Kundenstamm hinweg anbieten kannst – bevor das Telefon klingelt.
- Seit Februar 2024 (Google/Yahoo) und Mai 2025 (Microsoft Outlook) entscheidet die E-Mail-Authentifizierung darüber, ob Mails ankommen – Outlook lehnt nicht-konforme Massenmails komplett ab (Fehler 550 5.7.15).
- SPF, DKIM und DMARC arbeiten zusammen: SPF legt erlaubte Sende-Server fest, DKIM signiert die Mail, DMARC verknüpft beides mit der Absenderadresse und definiert die Richtlinie.
- Kontaktformulare tappen in die Falle, wenn sie die Besucheradresse als Absender eintragen – richtig ist: From auf die eigene Domain, die Besucheradresse in Reply-To.
- Ab 5.000 Mails pro Tag sind SPF, DKIM und DMARC bei Gmail und Outlook Pflicht; ein Kunde mit Newsletter, Bestätigungen und Erinnerungen erreicht diese Schwelle schneller als gedacht.
- Ein einmaliges Zustellbarkeits-Setup plus laufendes Auswerten der DMARC-Reports ist ein wiederkehrender Agentur-Service, der zugleich vor Phishing im Kundennamen schützt.