An AI agent with its own email address is great, but it’s useless if it can only talk to other agents on the same server. The gateway system in @agenticmail/enterprise connects your agents to the real internet email system. There are two ways to do it, and the right choice depends on your situation.
Relay mode: quick and simple
Relay mode uses an existing Gmail or Outlook account as a bridge. Your agents send outbound email through the relay account’s SMTP server, and inbound email arrives at the relay account using sub addressing (the + trick).
Here’s how it works. Say your relay account is company@gmail.com and your agent’s address is researcher@agents.internal. When someone external sends a message to your agent, the gateway maps it to company+researcher@gmail.com. Gmail delivers it to the company inbox. The gateway’s IMAP poller picks it up, strips the sub address to figure out which agent it’s for, and delivers it internally.
Outbound works in reverse. The agent sends a message through AgenticMail, the gateway relays it through Gmail’s SMTP, and the recipient sees it from company@gmail.com (with a reply to header pointing back to the sub address).
The advantages: zero DNS configuration, works in five minutes, leverages Gmail/Outlook’s deliverability reputation. The tradeoffs: your agents share a single external identity, you’re subject to the relay provider’s sending limits, and the sub addressing pattern is visible to recipients.
Relay mode is perfect for development, testing, and small deployments where you don’t want to manage DNS records.
Domain mode: full control
Domain mode gives each agent a real email address on a domain you control. researcher@agents.yourdomain.com is a real address that the internet email system treats as legitimate. This requires DNS configuration, but AgenticMail automates most of it through the Cloudflare API.
The setup configures:
MX records pointing your agent domain to Cloudflare’s email routing, which forwards inbound messages to your AgenticMail instance via a Cloudflare Email Worker.
SPF records that authorize your server and Cloudflare to send email on behalf of your domain. Without SPF, most recipients would reject your agents’ messages as potential forgeries.
DKIM signing so every outgoing message carries a cryptographic signature proving it actually came from your domain. The gateway generates the DKIM key pair and publishes the public key as a DNS TXT record.
DMARC policy that tells receiving servers what to do if SPF or DKIM checks fail. This is the layer that prevents spoofing of your agent domain.
Cloudflare Tunnel for routing inbound traffic to your server without exposing ports to the internet. The tunnel connects your AgenticMail instance to Cloudflare’s edge network.
Cloudflare Email Worker that receives inbound email at Cloudflare’s edge and forwards it to your instance through the tunnel. This handles the connection between Cloudflare’s email routing and your actual mail server.
The whole setup runs through a single configuration flow. You provide your Cloudflare API token and domain, and the gateway handles the rest.
Credential encryption
Both modes require storing credentials: IMAP/SMTP passwords for relay mode, API tokens for domain mode. These get encrypted at rest using AES 256 GCM.
Each credential is encrypted with a unique initialization vector, and the encryption key is derived from a master secret that you provide at startup. The encrypted credentials are stored in the database alongside their IV and auth tag, so decryption is only possible with the original master secret.
This matters because gateway credentials are high value targets. Your relay account password gives access to all agent email. Your Cloudflare API token can modify DNS records. Neither should ever be stored in plaintext.
Which mode to choose
Relay mode if you want to get started fast, don’t have DNS access, or are running a development environment.
Domain mode if you want agents with their own real email addresses, need high deliverability, care about professional appearance, or are running a production deployment.
Source Code
The GatewayManager is the orchestration layer that ties relay mode and domain mode together. It imports the relay gateway, Cloudflare integration, domain purchasing, DNS configuration, and tunnel management. The options interface shows the key dependencies: a database, Stalwart admin connection, account manager, inbound mail callback, and the master encryption key for credential storage.
import { RelayGateway } from './relay.js';
import { CloudflareClient } from './cloudflare.js';
import { DomainPurchaser } from './domain-purchase.js';
import { DNSConfigurator } from './dns-setup.js';
import { TunnelManager } from './tunnel.js';
export interface GatewayManagerOptions {
db: Database.Database;
stalwart: StalwartAdmin;
accountManager?: AccountManager;
onInboundMail?: (agentName: string, mail: InboundEmail) => void | Promise<void>;
encryptionKey?: string; // Master key for AES 256 GCM at rest
}View the full source on GitHub
You can also run both simultaneously, using relay mode for some agents and domain mode for others. The gateway handles the routing transparently.