SMTP

Webflow's form notification email is more configurable than most people assume, and it still cannot do the one thing a customer-facing message needs. You can set the recipients, the sender name, the reply to address, the subject and the body, and the reply to, subject and body all accept form variables such as {{siteName}}, {{formName}} and {{formData}}. What you cannot change is the address the mail comes from. It is one of Webflow's own addresses, no-reply-forms@webflow.com by default and no-reply@webforms.io on a Growth Workspace, never your own domain. The recipient list is fixed too: the To field takes addresses, not form variables, so the person who just filled in the form is never one of the people it emails.

SMTP.com is a transactional relay that sits behind the form and sends a second message under your own domain. A form_submission webhook, a Zap, or a server-side function hands each submission to SMTP.com, which authenticates the message against your SPF record and signs it with your DKIM key. Webflow carries on storing the submission and carries on sending its own notification unless you deliberately remove that destination, so the relay adds a message rather than replacing one.

Agencies running several client sites can give each client its own SMTP.com sender, with separate credentials and its own reporting. Store owners get a branded receipt that goes out beside Webflow's order email rather than instead of it, and developers deploying on Webflow Cloud can call the SMTP.com API directly with the key held in an environment variable.

How to integrate SMTP.com with Webflow

What is SMTP.com? SMTP.com is a transactional email delivery and relay service operated by J2 Global Canada, part of Ziff Davis. It accepts mail either over a standard SMTP connection using per sender credentials or through a RESTful JSON API, signs outgoing messages with DKIM, and pushes delivery, bounce, open, click, complaint and unsubscribe events to a URL you control.

Teams pair the two when a Webflow site has to send mail that inbox providers will trust under the brand's own domain, which is really a DMARC question. SMTP.com DKIM signs everything with one of its own shared domains by default, so until you add a custom key for your domain the signature does not match the address in the From header. Whichever route you take, something outside Webflow has to hold the SMTP.com credentials, because Webflow has no field for them.

This integration has three shapes. Webflow form destinations hand submission data to a webhook, a connected App or a custom action with no code inside Webflow. Zapier pairs Webflow's form and order triggers with SMTP.com's Send Email action, and Make or n8n can do the same job through a generic email module. The Webflow and SMTP.com APIs give you the message payload, the delivery callbacks and CMS writeback, at the cost of running a server. Most builds combine two of them.

Configure Webflow form destinations for SMTP.com

Every route to SMTP.com starts in the form's destination settings, since Site settings has no SMTP server field of its own. A form can send its data to Webflow storage, to email notifications, to a webhook, to a connected App, or to a custom action, and Webflow's forms guide walks through all five. Webhooks and connected Apps run alongside normal processing, so submissions still land in your dashboard and the native notification still goes out. Removing the email notification destination silences Webflow's own message while keeping storage and the webhook. A Code Embed or site-wide custom code cannot hold SMTP.com credentials, because everything in page code is readable by every visitor.

Add a form_submission webhook

A form_submission webhook posts each submission as JSON to a URL you control, and that URL then calls SMTP.com. This trigger accepts a filter parameter naming a single form, which matters on a site carrying several. Each site can register up to 75 webhooks per trigger type, per Webflow's webhook guide.

To add the webhook:

1. Go to Site settings > Apps & integrations > Webhooks and click Add webhook.
2. Choose the form submission trigger type, select API version v2, and enter the HTTPS URL of your relay function.
3. Copy the signing key Webflow shows you and store it immediately. Webhooks created this way each get their own secret, it is displayed only once, and you need it to validate incoming requests.
4. Return HTTP 200 from that URL promptly. A non-200 response, a redirect, a failed SSL negotiation, or a slow reply all count as failures, and the request then retries three more times at 10 minute intervals before it is discarded.

The form_submission payload carries payload.name, payload.siteId, payload.formId, payload.submittedAt, payload.data with the submitted fields, and payload.schema naming each field and its type. That is everything your function needs to compose the SMTP.com message without hard-coding field names.

Use a custom form action

A custom action URL posts the form straight to an external endpoint, and it is the one destination that takes Webflow out of the loop entirely. Submissions are not sent to or stored in Webflow, no native notification email goes out, and a form using a custom action cannot also use the Webflow storage or email notification destinations. The built-in reCAPTCHA integration stops working as expected as well. Some third-party form backends accept an SMTP host, port, username and password directly, so relay credentials work there.

To route a form through a custom action:

1. Remove the Webflow storage and email notification destinations from the form.
2. Enter your relay or form backend URL as the form action, following the steps in Webflow's exported-site guide.
3. Turn on site-wide spam protection, since Cloudflare Turnstile applies to every form once enabled and reCAPTCHA does not work with a custom action.

Take this path only when you are willing to give up the submission record inside Webflow. A webhook or a connected App keeps both the record and the SMTP.com message.

Connect with Zapier

Zapier publishes a dedicated SMTP.com app, which pairs its Send Email action with Webflow's form and order triggers. Credentials you enter there live in Zapier's connection settings rather than anywhere in your site's page code. If you use the generic SMTP by Zapier action instead, pair port 2525 with STARTTLS, because SMTPS on 465 is not supported.

To set up the Zapier path:

1. In SMTP.com, open Manage Senders and note the channel's login and password, or copy an API key from the portal's API settings.
2. In Site settings > Forms, add Zapier as a connected App destination for the form.
3. In Zapier, create a Zap with the Webflow New Form Submission trigger and select the form.
4. Add the SMTP.com Send Email action and map name, email address, subject and body from the form fields. From Name and From Address are optional.
5. Test the Zap with a live submission, then turn it on.

The trigger and action pairs available for this combination:

• New Form Submission to Send Email: sends the lead a confirmation from your own domain, or alerts your team without relying on Webflow's fixed sender address.
• New Order to Send Email: adds a branded order notification beside Webflow's own, and needs an Ecommerce plan because the order trigger reads store data.
• Updated Order to Send Email: sends a shipping or status update when the order record changes, on the same Ecommerce plan requirement.
• New Hard Bounce or New Complaint to Update Live Item: flags the contact in a collection. Pick Update Live Item rather than Update Item, because Update Item writes to the staged item and the flag stays invisible on the published site until you publish.
• New Open or New Click to Update Live Item: records engagement against the same collection item, using the identifier you sent with the message.

Zapier's own SMTP.com triggers also cover New Sending Event and New Unsubscribe, so the no-code path can drive suppression handling as well as sending.

Build with the Webflow and SMTP.com APIs

A server-side function that receives Webflow webhooks and calls the SMTP.com API gives you HTML templates, custom tracking arguments and two-way event sync. SMTP.com publishes no official SDK, so plain fetch() calls are the practical route. This path suits developers comfortable validating an HMAC signature, absorbing webhook retries and managing environment variables.

• SMTP.com API v4: a REST JSON service at https://api.smtp.com/v4, authenticated with Authorization: Bearer {apikey} and an Accept: application/json header, per the API documentation.
• Message payload and tracking: a send carries channel, recipients, originator, subject and body.parts, and an X-SMTPAPI custom header holding a top-level unique_args object tags each message with your own identifiers, as SMTP.com's payload example sets out in full.
• Delivery callbacks: delivered, opens, clicks, unsubscribes, bounces and complaints each push JSON to your endpoint, and SMTP.com's trigger list confirms they can be switched on through the API or in Manage Senders.
• Webflow writeback: flag a suppressed address on a published Webflow CMS item through the live update endpoint, which needs the CMS:write scope.

Generate a site token under Site settings > Apps & integrations > API access. Only site administrators can create one, each site holds up to 5, and a token expires after 365 consecutive days of inactivity, per the site token reference.

Send a transactional email from a form_submission webhook

This flow replaces the native notification with a branded message signed by your own domain, once you remove the form's email notification destination. The Webflow webhook lands on your function, the function validates the signature, and then it posts to SMTP.com.

To implement this:

1. Remove the form's native email notification destination if the SMTP.com message is meant to replace it, and keep Webflow storage and the webhook.
2. Validate every request before you act on it. Take the x-webflow-timestamp header, join it to the stringified request body with a colon, compute an HMAC SHA256 over that string with the webhook's signing key, and compare the result to x-webflow-signature. Reject a mismatch, or a timestamp older than 5 minutes. Webflow ships a verification helper in its SDK and recommends using it, since the implementation can change.
3. Read the recipient and message fields from payload.data, using payload.schema to map field names.
4. Post the message to the SMTP.com API with your key in the Authorization header, and add an X-SMTPAPI custom header carrying the form or item ID inside unique_args so later callbacks bring it back to you.
5. Return 200 to Webflow.

On Webflow Cloud, store the SMTP.com key as an environment variable and mark it as a secret. Keep it out of any name a framework inlines during the build, such as a NEXT_PUBLIC_ or PUBLIC_ prefixed variable, because anything inlined that way ends up in the JavaScript the browser downloads.

Write SMTP.com delivery events back to the Webflow CMS

SMTP.com pushes each event as JSON to an HTTPS endpoint you register. Every payload carries an id, a tracking_id, a sender_id, an event_label, an event_code, the rcpt_to address and the subject. Delivery and bounce events add a status letter, while complaint and unsubscribe events carry a feedback_type in its place, and SMTP.com documents each shape field by field. The callback identifies the recipient by rcpt_to only, so carry a Webflow item ID through unique_args if you want to update a specific item. Protect the endpoint with IP allowlisting or authentication at the infrastructure level, because SMTP.com's callback pages describe no signature or shared secret to verify.

Update a single item with PATCH /v2/collections/{collection_id}/items/{item_id}/live. For a batch, chunk the events into groups of 100 or fewer and call PATCH /v2/collections/{collection_id}/items/live, since a bulk update accepts at most 100 items per request.

SMTP.com already adds hard-bounced addresses to its own suppression database and blocks later sends with reason code 13, Recipient was internally suppressed. A CMS flag exists for your own records and your unsubscribe processing rather than to duplicate that suppression.

What you can build with the SMTP.com Webflow integration

Pairing SMTP.com with Webflow lets you send form, order and account email from your own authenticated domain without running a mail server, while Webflow keeps handling storage and its own notifications.

• Branded lead confirmations: a contact form fires a form_submission webhook to a small function, which sends the prospect a confirmation from the agency's own domain with SPF and DKIM both authenticating under that domain.
• Custom order confirmation emails: a store listens for ecomm_new_order, assembles an HTML receipt with line items and shipping detail, and sends it through SMTP.com beside Webflow's own order email, whose branding, labels and dynamic fields are edited separately in Ecommerce email settings.
• Release-note notifications from the CMS: a SaaS site publishes a release note, a collection_item_published webhook fires, and the middleware mails the customer list with the collection and item IDs tagged in unique_args for later reporting.
• Per-client agency sending: an agency gives every client its own SMTP.com channel with a separate login and quota, routes each client site's form webhooks to the matching channel, and pulls per-channel statistics for monthly reports.

Password reset and account email from membership tools such as Memberstack or Outseta fit the same pattern, since they all come down to a webhook and a send. If your actual goal is to change how Webflow's own message reads rather than to add a second one, read customizing form notifications first.

Almost all of the Webflow side of this build is CMS and form plumbing, which is what Webflow's MCP server handles well: it can create the suppression collection and its fields, read a form's schema so your middleware uses the right field names, and publish CMS items, all inside your existing permissions and roles. It cannot send mail or hold your SMTP.com key, so the relay stays exactly where it is. Connect the MCP server to your agent, let it build the Webflow half, and wire up the sending half yourself.