An alert from your app.A delivery you can follow.

A contact form needs to tell you that someone wrote in. A background task needs to tell your team that a report is ready. A Worker with a send_email binding can send those notifications from a domain your account verified to addresses that confirmed they want the mail. The sending domain, allowed recipients and delivery activity belong to the same account as the projects using them.

This is outbound email. Fortly does not currently receive incoming email, provision inboxes, forward arbitrary mail or call a Worker’s email() handler. It is also not a general transactional email service for sending to every new customer address. Confirmed destinations make it useful for contact-form notifications, internal alerts and messages to your own verified recipients. Choose a separate mail service if your workflow needs arbitrary recipient delivery.

The distinction is visible in setup rather than hidden in a failed delivery. Open Email in the console to see the sending-domain, destination and connected-Worker checklist. A binding declaration connects code to the feature; it does not by itself verify DNS, confirm a recipient or make the mail provider available.

Add a sending domain and publish the records Fortly shows. Ownership and DKIM are required; SPF is recommended and shown separately. A dedicated subdomain such as mail.example.com can keep sending configuration apart from your existing mail setup. Fortly rechecks pending domains, and you can ask it to check again. Verified records remain inspectable and copyable after setup is complete.

Add the destination address next. Fortly sends it a confirmation link, and a person explicitly confirms the address on that page. A pending destination is not ready to receive application mail. Removing a domain or destination asks for confirmation because connected Workers can lose sending access. Check the affected bindings before changing a shared account-level setting.

Deploy the Worker with its send_email config. The connected-Worker view evaluates its actual restrictions: a different confirmed address does not satisfy a binding limited to one recipient, and a verified domain must match any allowed sender addresses. Provider configuration and remaining allowance also affect readiness. The next action stays close to the state that needs attention.

Worker code can send a structured message with from, to, cc, bcc, replyTo, subject, text, html and headers, or use a raw EmailMessage from cloudflare:email. Every recipient must be confirmed and permitted by the binding. The destination_address, allowed_destination_addresses and allowed_sender_addresses restrictions still apply. A message accepts up to 50 recipients.

Email Activity shows sent, refused and failed messages with the reason. Search by subject, recipient or project, filter the outcome and refresh the list when investigating a specific send. A sent result means the provider accepted the message; it is not a promise of inbox placement or a recipient read receipt. Handle errors from send() in your application and inspect the documented error code before retrying.

Free includes 100 messages per account each UTC calendar month, Pro includes 1,000 and Max includes 5,000. Only sent messages consume the allowance. The docs describe DNS verification, destination confirmation, binding restrictions, activity fields and refusal codes. That gives your team a concrete route from a missing notification to the setting or application error that caused it.

Open the detailed guide for configuration examples, access requirements, limits and troubleshooting. Then use your own project to verify the full flow before depending on it in production.

Read the email guide · Explore the full platform