Transactional Email Overview

Forge Email lets an application send transactional messages from a domain owned by its project. Typical uses include verification codes, password resets, receipts and account notifications.

Supported Customer Surface

The current customer surface includes:

• project-owned email domains and DNS ownership verification;
• multiple sender identities on a verified domain;
• a unique DKIM key and verification record for each sender;
• project-scoped and sender-scoped API keys;
• transactional sends with required idempotency;
• recipient suppression after a permanent failure or complaint;
• paginated send history and final delivery status when the delivery route reports it;
• protected SMTP credential rotation for identities using external SMTP authentication.

Email automations, bulk broadcasts, inbound mailboxes, forwarding, IMAP, POP and webmail are not part of the currently supported customer surface.

Ownership And Isolation

Domains, senders, API keys and send history belong to one project. A project-scoped key can use verified senders only from that project. A sender-scoped key can use only its selected sender. Workspace and project permissions control who can manage domains, credentials and send history.

Forge Cloud account and security messages use a separate platform delivery system. Platform delivery configuration never grants a project access to another project’s domains, API keys or SMTP credentials.

Delivery Meaning

Forge distinguishes submission from final delivery:

• queued means the configured delivery route accepted responsibility for the message;
• delivered means the recipient’s SMTP server accepted it;
• deferred means delivery may be retried;
• bounced means the final delivery attempt failed permanently;
• submission_failed means Forge could not submit it to the configured route;
• suppressed means Forge deliberately did not submit it because of a recorded permanent failure, complaint or provider incident.

Neither queued nor delivered proves inbox placement or that a person opened the message.

Quick Start

1. Add and verify a project email domain.
2. Create a sender identity.
3. Publish and verify the exact DKIM TXT record shown by Forge.
4. Create a project-scoped or sender-scoped API key.
5. Store the key as a secret in the application service that needs it.
6. Send a transactional message with a unique idempotency key.
7. Review Send History for the final outcome.

Use only domains you control and send only messages recipients expect. Forge may pause a recipient or mailbox provider after a permanent rejection or complaint.