Sending and outbound access

Every message that leaves FounderMail, whether sent from the dashboard or submitted by a mail client over SMTP, passes the same set of checks. They are applied in this order, and the first one that fails is the reason you see.

A message that is refused is not sent and is not counted. From the dashboard the reason is shown in the compose window and the draft is kept; from a mail client it is returned as an SMTP error the client shows you. A message that passes is signed with your domain's DKIM key and sent from the mailbox's own address, so replies come back to the same mailbox and thread correctly.

Reply-only mode

Every domain starts in reply-only mode once it is verified for sending. In this mode a mailbox on the domain may send to any address that has written to one of the domain's mailboxes, and the message must be a reply to a message you received: replying from a thread in the dashboard, or replying in a mail client so that the message references the original. A reply may go to the people on the message it answers; adding anyone else makes it a message to a stranger, which reply-only mode refuses. Writing a new message to an address that has never contacted you is refused, even if you have added that address as a contact through the API.

Reply-only is not a plan feature. It applies to the Free plan and the paid plans alike, because it exists to keep the sending reputation your domain shares with everyone else's clean, and paying does not make a sender trustworthy.

Requesting outbound access

Outbound access lets mailboxes on a domain write first, to anyone, within the plan's monthly allowance and its daily limit on new recipients. It is granted per domain, because deliverability and reputation are per domain.

1. Verify the domain for receiving and for sending; the request needs both.
2. Open the domain's Outbound tab and choose Request outbound access.
3. Say what you intend to send and to whom, in a sentence or two (up to 500 characters): "invoices and onboarding mail to customers of our accounting app", for example.

The request is screened automatically and reviewed by a person. Most requests are answered within a day, and you receive an email either way. While it is under review the domain stays reply-only, so nothing you could already do stops working. Outbound access is for correspondence: a request that describes automated or bulk outreach, bought lists, sequences or warm-up is not approved (see What FounderMail is not for).

New recipients per day

A new recipient is an address that has never written to your workspace. Each plan allows a number of them in any 24 hours, across every mailbox and domain in the workspace:

• Replies to people who have written to you never count, however many you send.
• Writing to the same new address twice within 24 hours counts once.
• To, Cc and Bcc all count: each new address on a message is one new recipient.
• Once someone writes back, they are no longer new.

The limit is the line between a person writing and a tool. A founder writing to a few new people a day stays below it; a tool working through a list of strangers does not.

A newly approved domain starts below its plan's number and earns its way up. Its own allowance grows by one for every day without a bounce or a complaint and by one for every few people it wrote to who wrote back, until it reaches the plan's limit; a run of undeliverable addresses or a complaint sets it back for a week. The domain page shows the current figure. Writing to people who have written to you is never counted, so a domain that replies to its customers notices none of this.

Bounces and complaints

Our delivery provider reports every hard bounce (an address that does not exist, or refuses mail permanently) and every complaint (a recipient marking a message as spam). FounderMail records each one against the message that caused it.

• An address that hard-bounces is refused from then on, for every workspace: it would bounce for anyone.
• An address that complains is refused for the workspace it complained about, replies included.
• A delivery that fails only temporarily, such as a full mailbox or a server that is down, is retried by the delivery provider first and does not count.

The bounce message itself still arrives in the sending mailbox, as it always has, so you can see which address failed.

Warnings, limits and pauses

A domain's sending is watched in three steps, and the first two refuse nothing:

• Warn. The account owner is emailed, and the domain's Outbound tab says the same, when a message could not be delivered, when undeliverable addresses are adding up, when the day's new recipients are close to the allowance, or when mail from the domain is starting to look like outreach. Each kind of warning is sent at most once a week.
• Restrict. A run of undeliverable addresses or a complaint sets the domain's allowance of new recipients back to its starting figure for a week, while the cause is fixed. A first run of bounces serious enough to pause the domain pauses it for 24 hours, after which writing to new people resumes on its own at that low figure.
• Pause. Outbound access is withdrawn, without waiting for a reviewer, on any recipient complaint, on the automated-outreach pattern (many messages to new recipients from several mailboxes across unrelated domains, almost nobody answering), on a pause by the delivery provider, or on a second run of bounces within ninety days. The Outbound tab shows the reason and the owner receives an email. Replies keep working. After 7 days the domain can request outbound access again, and a person reviews the request.

These measurements come from delivery metadata: who a message went to, whether they had written before or wrote back, and the bounce and complaint reports above. They never look at what your messages say. We do not publish the exact thresholds; they sit well below the levels at which mailbox providers and our delivery provider start treating a sender as a problem.

Every customer's mail leaves through the same delivery provider, so the service is also watched as a whole. A domain that accounts for most of the bounces across FounderMail on a given day is paused for it; the rest is a matter for us, and never stops another domain's mail.

What FounderMail is not for

FounderMail sends the mail people write: replies, invoices, onboarding notes, proposals. It is not a transactional sending service: an application's automated mail belongs with a service built for it, and the monthly allowances are sized for a company's correspondence.

Writing to many people at once has one door, Campaigns (from the Pro plan): lists of people who wrote to you or confirmed by email, an unsubscribe link on every copy, and an allowance of its own. Doing the same through compose, a mail client or the API, to people who never asked, costs a domain its outbound access.

Nor is it a platform for automated or bulk outreach. Writing to a few new people a day yourself is fine. Sequence and mail-merge tools, automated follow-up cadences, bought or scraped lists, warm-up services and engagement networks, and spreading sending across mailboxes, domains or accounts to stay under a limit all cost a domain its outbound access, whatever the plan; the Terms of Service forbid unsolicited bulk email and leave outbound access to our discretion.

Forwarders and outbound

A forwarder re-sends a received message from the receiving mailbox's own address to the address you configured. It passes the same checks as any other outgoing message and counts toward the monthly send allowance. Junk is never forwarded. See Routing.

Sending from the API and the MCP server

An API key with the mail:send scope can send from any of your mailboxes, and the MCP server's send_email tool does the same for an assistant. Both go through the checks on this page — the domain must be verified for sending, the reply-only rule applies, and every message counts against the plan's allowance and its daily limit on new recipients — because they use the same code path as the dashboard's compose window.

A key scoped to mail:draft alone cannot send: it writes a draft and a person sends it. That is the setting to use for an integration you want to keep a human in front of. See REST API and MCP server.