Tilda stores run on Tilda's infrastructure. Forms submit to Tilda, Tilda runs the integration, and email notifications go out via Tilda's sending stack. The merchant does not choose the SMTP relay, does not see logs, does not configure DKIM on the sender domain.
For a Russian-market store targeting customers on Mail.ru and Yandex, that introduces a specific deliverability concern: Tilda's shared sender reputation is one of several layers between you and the customer inbox. The best path is to configure email delivery to route through your own ESP — which Tilda supports via Webhook and ESP integrations.
Route form submissions and store orders to your own ESP (Unisender, SendPulse, Mailchimp) via Tilda integrations. Tilda handles the form capture; the ESP handles the send. You control DKIM and DMARC on your domain.
Tilda's native email delivery
When a customer submits an order on a Tilda store, Tilda can:
- Email the admin via Tilda's own relay from a
noreply@tildacdn.com-style envelope. Useful for getting the order detail to you. - Email the customer — Tilda does this for some scenarios but not all. For Store blocks, the customer confirmation is optional and simple.
- Forward to a webhook or ESP integration: Mailchimp, Unisender, SendPulse, getResponse, custom webhook.
The customer-facing confirmation is where Tilda's limits bite. The default template is minimal and the sender is Tilda-branded. For a real store, you want the confirmation sent from your domain via your ESP.
Route orders to your ESP
Example: Tilda + Unisender
- In Tilda project settings: Site Settings → Forms → Connect integration → Unisender.
- Paste the Unisender API key. Choose the list to add contacts to (or create one).
- In Unisender, set up an automation triggered on list join: send a transactional template with order details.
- Or skip the list and use Unisender's transactional API via a Tilda Webhook integration.
Alternative: Tilda Webhook to your backend
# Tilda posts form submissions as multipart/form-data
# to your webhook URL. Example Node.js receiver that
# forwards to a transactional ESP.
POST /tilda-webhook
Content-Type: multipart/form-data
name: Aleksandr
email: customer@example.ru
phone: +7...
payment:amount: 4990
payment:products: [{name: "Order #1234", price: 4990}]
formid: form123456
formname: CheckoutTilda does not sign webhook payloads. Add basic protections: only accept from Tilda's IP ranges (published in their docs), rate-limit per form, and validate theformid against a whitelist.
DNS for your ESP sender domain
Once your ESP (Unisender, SendPulse, Mailchimp) handles the customer confirmation, publish SPF, DKIM and DMARC for the sender domain. Tilda's own envelope is irrelevant at that point — the email the customer sees comes fromorders@yourstore.ru via your ESP.
; example: yourstore.ru apex, Unisender as relay
yourstore.ru. TXT "v=spf1 include:unisender.com -all"
us._domainkey.yourstore.ru CNAME us._domainkey.unisender.com.
_dmarc.yourstore.ru TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourstore.ru"What you cannot do on Tilda
- Configure SMTP for Tilda's own admin notifications.
- Sign DKIM on mail Tilda sends from its own envelope.
- Get bounce logs for Tilda-sent notifications.
- Change the Reply-To on Tilda's native confirmation (limited — some blocks expose it).
Testing Tilda order flow
- Submit a real test order with a seed email address in the customer field.
- Check which emails actually fire: admin notification (Tilda), customer confirmation (Tilda or your ESP), integration-triggered messages.
- For the ESP-routed customer confirmation, run a seed test across Mail.ru, Yandex, Gmail, Outlook to see placement.
Place a test order, watch placement across 20+ seed mailboxes covering RU (Mail.ru, Yandex) and global (Gmail, Outlook) providers.