Dein Webflow-Formular nimmt Daten an, aber in Outlook/Exchange kommt keine Benachrichtigung an: Das ist fast immer ein Zustellproblem. Wenn du die Einträge im Webflow-Dashboard unter „Submissions“ siehst, wurde das Formular korrekt abgeschickt – danach entscheidet Microsofts Filter, ob die Mail im Posteingang, im Junk-Ordner oder in Quarantäne landet.
Du kommst am schnellsten ans Ziel, wenn du erst Webflow sauber testest und dann in Exchange nachsiehst, was mit der Mail passiert ist. Sobald du Bestätigungen, Auto-Responder oder CRM-Weiterleitungen über deine eigene Domain verschickst, müssen SPF, DKIM und DMARC passen, sonst wirkt das für Outlook wie Spoofing.
Photo by Pixabay on Pexels
Webflow-Basics: Benachrichtigungen, Empfänger und Absender
Prüfe zuerst, ob Webflow überhaupt an die richtige Adresse sendet. Ein Tippfehler oder ein stillgelegtes Postfach reicht, damit „nichts ankommt“. Zusätzlich kann Webflow einzelne Submissions als Spam markieren, wodurch Benachrichtigungen ausbleiben. Wenn du hier sauber bist, sparst du dir unnötige DNS-Arbeit.
Empfängeradresse und Formularstatus kontrollieren
Öffne das Formular in Webflow, gehe in die Form-Settings und kontrolliere die Notification-Empfänger exakt, inklusive Alias und Domain.
Schicke danach eine Test-Submission und prüfe im Submission-Tab, ob der Eintrag sofort auftaucht. Siehst du Hinweise auf Spam-Submissions, kläre erst diese Bewertung und prüfe, ob Custom-Code oder ein Redirect den Submit-Prozess stört.
Verstehen, von welcher Adresse Webflow sendet
Form-Benachrichtigungen kommen in der Regel von einer Webflow-Absenderdomain wie no-reply-forms@webflow.com (abhängig vom Workspace).
Outlook/Exchange bewertet Authentifizierung und Reputation anhand dieser Absenderdomain und der sendenden Infrastruktur. Deine eigenen DNS-Records helfen hier nur indirekt, wenn Microsoft die Webflow-Mail als verdächtig oder „bulk“ einstuft.
Schnelltest mit externem Postfach
Leite Notifications parallel an ein externes Postfach (z. B. Gmail) und an dein Exchange-Postfach. Kommt es extern an, aber intern nicht, ist die Ursache fast sicher eine Exchange-Policy oder Quarantäne. Kommt es nirgends an, geh zurück zu den Webflow-Settings und prüfe Empfänger, Form-Auslösung und ob du wirklich die richtige Form testest.
Outlook/Exchange finden lassen: Quarantäne, Junk und Message Trace
Outlook zeigt dir meist nur „nicht da“, obwohl die Mail verarbeitet wurde. In Microsoft 365 kann sie akzeptiert und trotzdem serverseitig zurückgehalten werden. Je nach Tenant-Setup siehst du sie erst in Quarantäne oder im Defender-Portal. Darum ist die Admin-Sicht der schnellste Weg zur Ursache.
Öffne im Exchange Admin Center die Nachrichtennachverfolgung und suche im Zeitraum deiner Tests nach dem Empfänger. Wenn du die Absenderadresse kennst (z. B. no-reply-forms@webflow.com), filtere damit; sonst nutze Betreff-Details aus einem extern zugestellten Test.
Der Status („zugestellt“, „in Quarantäne“, „abgewiesen“) zeigt dir sofort, ob ein Filter greift oder ob die Mail gar nicht angenommen wurde.
Quarantäne und Policies richtig einordnen
Findest du die Mail in Quarantäne, ist „Safe Sender“ im Outlook-Client oft wirkungslos, weil die Entscheidung serverseitig fiel. Prüfe im Microsoft 365 Defender, welche Policy ausgelöst hat (Anti-Spam, Anti-Phishing, Anti-Spoofing).
Setze gezielte Ausnahmen für die Webflow-Absenderdomain oder einzelne Absender und beobachte danach den Message Trace, statt die Schutzstufe global zu senken.
Regeln und Weiterleitungen als Fehlerquelle
Kontrolliere Postfachregeln, besonders in Shared Mailboxes, weil dort alte Filter unbemerkt bleiben. Auch Weiterleitungen an externe Systeme können Mails „verlieren“, wenn der nächste Hop strenger ist als Exchange. Ein Test an ein frisches Postfach ohne Regeln ist oft der schnellste Beweis.
SPF: Sobald du über deine Domain sendest, zählt es sofort
SPF ist kein Webflow-Schalter, sondern eine DNS-Erlaubnisliste für deine Domain. Er wird relevant, sobald du Bestätigungs-Mails, Auto-Responder oder CRM-Weiterleitungen mit deiner eigenen Absenderadresse sendest. Outlook/Exchange reagiert auf SPF-Fehler schnell mit Spam, Quarantäne oder Ablehnung. Ein sauberer SPF-Record ist die Basis, bevor du DMARC verschärfst.
Einen eindeutigen SPF-Record veröffentlichen
Wichtig ist: genau ein SPF-TXT-Record pro Domain. Für Microsoft 365 ist ein häufiges Grundgerüst:
v=spf1 include:spf.protection.outlook.com -all
Wenn weitere Dienste in deinem Namen senden, ergänzt du deren offizielles include: und entfernst alte Einträge. Mehrere SPF-Records oder ein zu langer Record führen zu PermError – und das mögen Microsoft-Filter gar nicht.
SPF-Probleme in Headern erkennen
In den Headern siehst du spf=pass, spf=fail oder spf=softfail. Ein PermError entsteht typischerweise durch mehrere SPF-Records oder zu viele DNS-Lookups. Bei Weiterleitungen kann SPF kippen, obwohl der Versand korrekt war; genau dann wird DKIM zum Rettungsanker, weil es unabhängig vom Weiterleitungsweg prüft.
Warum SPF-Fail wie Spoofing wirkt
Microsoft bewertet nicht nur SPF, sondern auch, ob die sendende Infrastruktur zur From-Domain passt. Wenn du „From: deine-domain“ nutzt, aber technisch von einem Drittanbieter sendest, sieht ein SPF-Fail nach Identitätsmissbrauch aus. Pflege SPF deshalb dort, wo deine Mails wirklich rausgehen, nicht dort, wo nur das Formular steht.
DMARC: Alignment, Richtlinie und ein Setup, das nicht bricht
DMARC verbindet SPF und DKIM mit einer klaren Policy und verlangt Alignment zur sichtbaren From-Domain.
Genau hier scheitern viele Formular-Workflows, weil „From“ deine Domain zeigt, der technische Versand aber woanders stattfindet. DMARC bringt dir Transparenz und schützt deine Domain, wenn du es schrittweise einführst. Zu aggressive Policies blockieren sonst legitime Form-Mails.
DMARC vorsichtig starten und Reports lesen
Beginne mit Monitoring, damit du zuerst siehst, welche Systeme in deinem Namen senden:
v=DMARC1; p=none; rua=mailto:dmarc@deinedomain.tld; adkim=s; aspf=s
Die Reports zeigen dir, ob Microsoft 365, ein Newsletter-Tool oder ein Automation-Dienst auftaucht. Erst wenn alle legitimen Sender über SPF/DKIM abgedeckt sind, gehst du auf p=quarantine und später auf p=reject.
Alignment sauber herstellen
DMARC besteht, wenn entweder SPF oder DKIM zur From-Domain aligned ist. Wenn du „From: deine-domain“ nutzt, sollte der Versanddienst im SPF stehen und DKIM mit deiner Domain signieren. Eine klare Versand-Subdomain wie mail.deinedomain.tld macht das sauberer, weil du dort Sender bündeln und Policies gezielt setzen kannst.
Wenn es sofort funktionieren muss
Wenn Webflow-Benachrichtigungen akut verloren gehen, setze in Microsoft 365 eine gezielte Ausnahme für die Webflow-Absenderdomain und kontrolliere den Effekt über Message Trace. Für dauerhafte Stabilität ist besser, Benachrichtigungen über einen eigenen, authentifizierten Versandweg zu schicken und Webflow nur die Submission-Daten liefern zu lassen.
Wenn dir dafür Zeit oder Know-how fehlt, kann eine Webagentur in Zurich das Zusammenspiel aus DNS, Microsoft-Policies und Versanddiensten einmal sauber durchziehen, damit nichts mehr stillschweigend verloren geht.
DKIM: Signatur einschalten, damit die Zustellung stabil wird
DKIM signiert deine Mails kryptografisch und gibt Outlook/Exchange ein starkes Vertrauenssignal. Das ist wichtig, weil Relays und Weiterleitungen SPF unzuverlässig machen können. Fehlt DKIM, landet selbst legitimer Formular-Traffic schneller im Spam. Mit DKIM plus konsistentem Absender steigt die Inbox-Quote deutlich.
Für Domains in Microsoft 365 setzt du zwei CNAME-Einträge für DKIM-Selectoren und aktivierst danach DKIM im Admin-Bereich. Sende anschließend eine neue Testmail und prüfe, ob im Header dkim=pass steht. Wenn du mehrere Domains oder Subdomains nutzt, aktiviere DKIM gezielt pro sendender Domain.
DKIM bei Versanddiensten und Automationen
Wenn du über Automationen und einen Maildienst sendest, muss dieser Dienst für deine Domain signieren dürfen. Das passiert meist über zusätzliche DNS-Einträge (CNAME/TXT) und einen „selector“, den der Anbieter vorgibt. Prüfe danach im Header, ob wirklich deine Domain signiert und nicht eine Default-Domain des Dienstes.
Header-Check ohne Extra-Tools
Öffne in Outlook im Web die Nachrichtenheader einer Testmail und suche nach „Authentication-Results“. Dort siehst du SPF, DKIM und DMARC auf einen Blick. Steht DKIM dauerhaft auf none oder fail, stimmt das Setup nicht oder du sendest über einen anderen Dienst als gedacht.
Fazit
Wenn dein Webflow-Formular keine E-Mails „sendet“, ist die Submission oft trotzdem da – nur Outlook/Exchange sortiert die Benachrichtigung aus. Mit externem Testpostfach, Message Trace und Quarantäne-Check findest du den Bruchpunkt sehr schnell.
Sobald du über deine eigene Domain versendest, müssen SPF und DKIM stimmen, damit DMARC später nicht gegen dich arbeitet. Halte den Absender konsistent, signiere sauber und erhöhe DMARC schrittweise, dann kommen Form-Anfragen zuverlässig an.
Neueste Kommentare