Webflow SPF and DKIM setup

What you are setting up

Webflow is a website builder and host, and the only mail it sends on your behalf is the form notification: the message that tells you someone submitted a form on your site. Webflow's documentation is direct about where that message comes from. On Starter, Core, and Freelancer Workspaces it is sent from no-reply-forms@webflow.com with the sender name Webflow Forms; on a Growth Workspace it comes from the unbranded no-reply@webforms.io instead. Webflow's troubleshooting page adds a third address it may use, no-reply@webflow.com. None of them is on your domain, and Webflow offers no custom sending domain, SMTP setting, or DNS records to publish on any plan. Webflow Logic, which had its own “Send email notification” block, was sunset on June 27, 2025, and any form that was wired to a Logic flow is now a standard Webflow form. So the honest answer to “how do I set up SPF and DKIM for Webflow” is that you do not, and this guide is about what you do instead.

Publish SPF and DKIM

There is nothing to publish. Do not add a Webflow entry to your SPF record: no Webflow message uses your domain as its Return-Path, so an include would spend one of your ten lookups and authorize nothing. What Webflow does let you set lives on the form itself. Select the form on the canvas or in the Navigator, open the Settings panel, and under Send to click Email Notifications (if it is not listed, click the add icon and choose it). The fields are:

To:           comma-separated recipients (name-based addresses, not info@ or admin@)
Sender name:  a display label only, e.g. "Acme Studio" (the address stays Webflow's)
Reply to:     where replies go; form variables allowed, e.g. {{Name}} <{{Email}}>
Subject:      variables such as {{siteName}} and {{formName}}
Body:         variables such as {{formData}} and {{formDashboardUrl}}

Click Apply and republish the site. The resulting message reads, in the recipient's mailbox, as "Acme Studio" <no-reply-forms@webflow.com> with a Reply-To of whatever the visitor typed into the email field. Set site-level defaults for new forms under Site settings > Forms, where each form's Reset to defaults button also points. Two limits from the same page: the free Starter Site plan allows five recipients, all of whom must be Workspace members, and the Reply to field accepts ASCII characters only.

If a form has to produce mail from your own domain, for example a confirmation to the visitor with your address in the From line, Webflow's route is to hand the submission to another service. Connect an App to the form or use a workflow tool such as Zapier or Make (the two Webflow recommends since the Logic sunset), and have that service send through an authenticated sender you control. That sender then has real SPF and DKIM records to publish; our guides for Resend, Postmark, and SendGrid cover them. One caution from Webflow's own docs: pointing the form at a custom form action URL bypasses Webflow's processing entirely, so submissions stop appearing in Site settings and Webflow sends no notification at all.

Add DMARC

Your domain still needs a DMARC record; it just has nothing to do with Webflow. Because every form notification carries a Webflow From address, receivers evaluate it against Webflow's DMARC record, not yours. When we checked on the date below, webflow.com published p=reject and webforms.io published p=none, with its SPF delegated to Mailjet. Webflow owns those outcomes. Publish the standard record for the mail you do send as yourself:

Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Build it with our DMARC builder and progress past p=none once your reports are clean. Webflow notifications will never show up in those reports as your domain, and moving your policy to p=reject cannot break them, which is one less sender to worry about on the way to enforcement. If you route submissions through a sender of your own, as described above, that sender is what appears in the reports, under its own name.

The Webflow gotcha

“Sender name” is a label, not an address. It is the most common misreading of this screen: a studio sets the sender name to its brand, sees the brand in the inbox, and assumes the mail is coming from its domain. It is not. Outlook prints no-reply-forms@webflow.com right beside the brand, Gmail reveals it one click into the sender details, and a forwarded notification is a Webflow message end to end. Nothing you type into Sender name touches SPF, DKIM, or alignment, and the Reply-To carrying the visitor's address does not change who sent the message either. The one thing you can improve is that the notification looks like it came from Webflow at all: the unbranded webforms.io address is gated to the Growth Workspace, and even there the address is Webflow's.

Your own mailbox can quietly stop receiving them. Webflow lists the reasons, and they are on your side of the fence. Role-based recipients such as info@ or admin@ are more likely to be filtered, so use a person's address. Every notification carries an unsubscribe link, and if anyone clicks it the recipient field is blanked without a warning; re-add the address to resume. And if your mail server has ever rejected a Webflow notification, for spam scoring or a full mailbox, Webflow puts the address on a blocklist and stops trying until its support team clears it. Allowlisting all three Webflow addresses before that happens is cheaper than the support ticket after.

Confirm it worked

• Submit the published form and check Site settings. The submission should appear under Site settings > Forms with the fields you expect. If it is there and no email arrived, the problem is delivery of the notification, not the form.
• Read the notification's headers. The From address will be one of the three Webflow addresses, and the Authentication-Results line will name Webflow's domain, not yours. That is the expected result, not a failure. Our header analyzer shows which domain was authenticated in plain English.
• Watch your own reports. Webflow should be absent from your DMARC aggregate reports, because it never sends as your domain. If a Webflow-hosted form feeds a sender of your own, that sender is the row to check for dmarc=pass. trustyourinbox labels it by the service that actually delivered the message.