Bottom line

Treat the agent as a planner behind a strict control plane. Keep registration and DNS ownership clear, make inbound and failure signals first-class, and ensure an operator—not the model—can stop the system.

The six layers

The six layers
LayerResponsibilitiesFailure you must detect
Identity and DNSDomain custody, SPF, DKIM, DMARC, MX, PTR, return pathMisalignment, expired domain, stale selector, wrong nameserver
Mailbox and inboundAddresses, credentials, storage, IMAP, role mailboxesReply missed, credential leak, mailbox unavailable
Submission and MTATLS, queues, retries, pacing, per-MX behaviorBacklog, deferral storm, provider block
Event pipelineDelivery, bounce, complaint, reply, unsubscribeDropped, duplicated, delayed, or unauthenticated event
Control planePlans, policy, approvals, limits, audit, reconciliationUnapproved action or split-brain state
OperationsMonitoring, reputation, abuse response, recoveryUnsafe sending continues during incident

Identity begins before the first message

Record who owns the registration, who controls authoritative DNS, and who can move or renew the domain. Authentication records are necessary, but operational custody determines whether you can rotate keys, recover from a vendor failure, or prove which system was authorized.

Google requires authentication for mail sent to Gmail and calls for valid forward and reverse DNS, TLS, RFC-conformant messages, and low spam rates. Higher-volume senders face additional SPF, DKIM, DMARC, alignment, and unsubscribe requirements. Build to the stricter baseline rather than waiting to cross a threshold. [2][3]

Inbound events are part of sending infrastructure

A platform that can send but cannot reliably observe a reply is incomplete. Replies, permanent bounces, complaints, and opt-outs are state changes. Give them stable event IDs, authenticate their origin, store raw evidence, retry delivery, and process them idempotently.

Do not collapse every negative event into “unsubscribed.” Operators need to distinguish a human request, hard bounce, feedback-loop complaint, provider rejection, and internal policy stop. They have different causes even when all prevent another message.

Shared versus dedicated is not a one-word decision

A shared provider can offer mature operations and enough volume diversity for a small program. A dedicated IP offers clearer reputation isolation but gives a low-volume sender less positive history and more operational responsibility. “Dedicated server” may still hide a shared IP, shared return path, shared warm-up pool, or shared complaint handling.

Ask for the exact mapping among customer, domain, mailbox, MTA, public IP, PTR hostname, DKIM identity, and feedback-loop enrollment. Also ask whether automatic failover can move traffic onto shared infrastructure. Architecture diagrams are more useful than a dedicated-infrastructure badge.

Buy, build, or manage a hybrid?

Buy a managed platform when speed and provider operations matter more than fine control. Build only when mail operations are a core competency and you can staff queue monitoring, blocklist response, backups, abuse handling, DNS rotation, security updates, and provider relationships. A managed-MTA hybrid can preserve control while outsourcing specialized operations.

Actually Agentic is designed around a managed model in which the campaign plan and infrastructure are reconciled together. It is currently prelaunch; the broader lesson is to model infrastructure as durable campaign state instead of a pile of setup tasks outside the product. [1]

Questions, answered plainly

Does an AI email agent need its own mail server?

Usually not. It needs a well-defined control plane and a permitted, observable sending service. Self-hosting adds significant operational work.

Is a dedicated IP always better?

No. It improves isolation but requires sufficient legitimate volume and active reputation management. Verify what “dedicated” includes.

What events are mandatory?

At minimum: inbound replies, permanent and temporary failures, complaints where available, unsubscribes, and provider-level rejections, all tied back to the original message.

Sources and methodology

Product capabilities were checked against first-party documentation available on September 9, 2026. Policies, plans, and prices can change; verify them before buying. General guidance is educational and is not legal advice.

  1. Actually Agentic product overview Actually Agentic. Product scope and operating model.
  2. Email sender guidelines Google. Authentication, DNS, spam-rate, formatting, unsubscribe, and volume guidance for Gmail.
  3. Email sender guidelines FAQ Google. Bulk-sender definitions and DMARC alignment details.
  4. DMARC overview DMARC.org. How DMARC builds on SPF and DKIM to add alignment, policy, and reporting.

Your agent can do the thinking.
The infrastructure still needs a grown-up.

See how Actually Agentic works