Roadmap

Site email

Send and receive email on your site's own domain, with shared and personal mailboxes you read in webmail using your studio login.

Planned. Not available yet. Details may change before it ships, and we'll announce it on What's new when it's ready.

Goal

Give every site that has its own domain real email on that domain, managed from the studio: send from your forms, flows and the assistant, receive mail into the site's mailboxes, and read and answer it in a webmail interface you open with your studio login. No separate mail account, password or mail server to look after.

Scope

• Your own domain only. Email is available only to sites with their own custom domain (see Domains & mail). Nothing is ever sent from Sherman Web Design's or the studio's own domains, and built-in site addresses don't get email.
• Transactional and everyday mail. Form notifications, replies, receipts, messages from your flows, and one-to-one mail you write yourself.
• Sending and receiving. Mail sent to your addresses lands in the site's mailboxes: shared mailboxes for the team, or a personal mailbox for the one person an address is assigned to.
• Your existing options stay. Mail forwarding and a site's own SMTP account for sending email from flows keep working as they do today.

How it works

Sending

• Mail is sent through Amazon SES in its us-east-1 (N. Virginia) region.
• Each client domain gets its own SES tenant: its own sending identity, settings, reputation tracking and suppression list. One site's bounces or complaints don't affect another site's sending.
• Every message is signed with your domain's DKIM key, so it's authenticated as coming from your domain.
• Forms and flows send through the existing send_email flow step. A site with its own SMTP setting can keep using it; otherwise mail goes out through the site's verified domain.
• Form notifications go to you with Reply-To set to the visitor, so you can reply straight from your inbox.

Receiving and mailboxes

• Mail to your addresses is received by Amazon SES. Admins and above manage inbound routing: which addresses exist and where each one's mail goes.
• Shared mailboxes. Every address that isn't assigned to a specific person is a shared mailbox. Editors and above can read it.
• Personal mailboxes. An address assigned to a specific person is a personal mailbox, and only that person can read it.
• Replying. Anyone who can read a mailbox can reply from it. Starting a new message from an address is for Admins and above.
• When someone leaves the site. Their address stops receiving mail. An Admin can reassign it to another person or turn it into a shared address. The mail already in it stays private to the person who left until then. If the address is reassigned, that mail goes to the new person; if it becomes shared, it moves into the shared mailbox.
• Message bodies and attachments are stored in R2 object storage; each message's details (sender, subject, date, spam verdict) are kept in the site's records.
• Received mail is kept until someone deletes it, like any mailbox. The sent-mail log keeps its current 90 days.
• A flow can also run when mail arrives at an address, for example to save a request as a record.

Webmail

• A webmail interface for the site's mail: read, search and reply, and (for Admins and above) start new messages from your verified addresses.
• Access comes from your studio login. There are no separate mailbox passwords. You see the shared mailboxes if you're an Editor or above, plus any personal mailbox assigned to you.

Spam handling

Incoming mail goes through these steps, in order:

1. Sender checks. SPF, DKIM and DMARC are checked. Clearly spoofed mail (a DMARC fail) is rejected outright and never stored.
2. SES verdicts. Amazon SES marks each message with a spam verdict and a virus verdict. Mail flagged as a virus is rejected outright and never stored.
3. Your site's rules. Allow or block senders and domains, match keywords, and choose how strict the site should be. You set these in the studio.
4. Optional API forward. Sites that want their own filtering can have each message sent to a URL of their own, which answers with a verdict.
5. Spam folder. Mail that fails the spam check is held in that mailbox's Spam folder. Anyone who can read the mailbox can see it, release a message or always allow its sender. Held mail never starts a flow and is never forwarded. Released mail goes through the address's normal routing as if it had just arrived. Held spam is deleted automatically after 30 days.

A paid spam-filtering or AI check may come later as an optional add-on, billed in credits.

DNS setup

• To verify a domain, the studio shows you the exact DNS records to add: DKIM, a custom MAIL FROM record, DMARC, and an MX record for receiving.
• Add them at your DNS provider yourself, or ask us and we'll help. The studio checks the records and turns sending on only once the domain is verified.
• We encourage managing your domain's DNS through us. For domains registered with or transferred to Sherman Web Design (through name.com), the studio can add the records for you. See Domains & mail.

Limits and protection

• Send caps per plan. Each plan has daily and monthly sending limits, based on the per-tenant limits Amazon SES allows. A send over the cap is refused rather than queued.
• Recipients per message are capped too, and there are no list uploads.
• Automatic pause. Bounces and complaints are counted per site. If either rate gets too high, the site's sending is paused automatically, and Sherman Web Design reviews it before it resumes. A site owner can also pause the site's own sending at any time.
• Suppression list. Addresses that hard-bounce or complain aren't mailed again from that site.
• Receiving limits. Messages per hour and message size are limited per site, so a flood of spam can't fill your mailboxes or run up usage.

Who can do what

For your AI assistant (MCP)

If you connect your AI to the studio, email has two tools:

• mail reads: domain status, the mailboxes you're allowed to read (the same access as webmail), sent mail and delivery events, spam rules, suppressions and usage. It never changes anything.
• run_mail_action makes every change: set up a domain, send a message, add or assign a receiving address, change spam rules, pause sending. It also takes over today's forwarding, mail DNS and SMTP actions.
• help explains each one in a man-page style: help {topic:"run_mail_action"} lists every action, and help {topic:"run_mail_action.send"} shows one in full.

Your assistant can read a personal mailbox only when it's connected as the person that mailbox is assigned to. It never sees anyone else's personal mail, whatever your role on the site.

Every send your assistant starts, including replies, needs your Confirm, even with brave mode on. Your assistant never sends mail on its own.

Pricing

Email will be billed in credits, like the rest of your site's usage. Prices aren't set yet.

What's not included

• Bulk mail and newsletters. This is for transactional and everyday mail only. For newsletters and mailing lists, the assistant can help you set up and use a service such as Mailgun or Mailchimp.
• Hosted mailboxes from other providers. We aren't offering third-party mailboxes (IMAP accounts and the like) for now. Your site's mailboxes live in the studio's webmail.

Phases

1. Sending foundation. Amazon SES set up in us-east-1, one tenant per client domain, and bounce and complaint tracking.
2. Domain setup. The studio's DNS instructions and checks, with records added for you when we manage your DNS. Sending stays off until the domain is verified.
3. Guardrails. Send caps, suppression lists and automatic pausing.
4. Receiving. Inbound routing, shared and personal mailboxes with attachments, and flows that run when mail arrives.
5. Spam handling. Sender checks, SES verdicts, your site's rules, the Spam folder and the optional API forward.
6. Webmail. Read and answer your shared and personal mailboxes with your studio login.

The mail and run_mail_action tools grow with each phase, as each part ships.