Ask for domain names, a bounce explanation or a capacity plan and the copilot pulls your actual domains, DNS records and delivery logs first. Nothing it proposes touches the fleet until you approve it.
- 0s
- Median response time on a fleet question
- 0%
- Changes require explicit confirmation before applying
- 0+
- Fleet actions the copilot can propose
Start with what it is not allowed to do
No. Provisioning, DNS edits and policy changes all ship as proposals with the exact before-and-after shown, and nothing applies until you approve it. There is no autonomous mode waiting to be switched on.
From your setup. Every answer reads your live domains, DNS records, delivery logs and reputation history, and then lists which of them it checked.
As long as the delivery log for that send is inside your plan's retention window, yes, including which record was implicated and whether reputation actually moved.
Dismiss it. Nothing queues, nothing half-applies, and the conversation carries on from where it was.
It checks availability live and drafts the registration, but the purchase is a confirmation you give. The copilot does not spend money on its own.
Grounded in your fleet. Not in a best-practice article.
Four jobs it does well, all of them against your live records rather than against a general model of how email is supposed to work.
Ask why a mailbox bounced
It reads the DNS, the DKIM history and the delivery log for that specific send, then names the cause, not a checklist of things that could theoretically be wrong.
Hand it a volume target
Give it a send volume and it works backward to the domain count, mailbox count and ramp that reach it, as a proposal you approve, never as a change it makes.
Name ideas that are actually available
Availability is checked live while it drafts, so a name you like is one you can register in the next click instead of one taken in 2011.
A 550 in words that mean something
Hard and soft bounces become an explanation: what the receiver objected to, whether reputation moved, and whether it needs an action from you at all.
It drafts. You approve. Nothing applies silently.
The copilot reads live fleet data to answer a question or draft a change, but a DNS edit, a policy tightening or a new mailbox batch sits as a proposal with an explicit diff until you approve it.
Live data, not a canned script
Answers come from your domains, DNS records, delivery logs and reputation history at the moment you ask, rather than from a pre-written response.
Every proposal shows the diff
A suggested DNS change displays the exact record before and after, so approval means approving a specific string rather than an intention.
Approval is required, every time
Provisioning, zone edits and policy changes all wait. There is no setting that lets the copilot act on your fleet unattended.
It shows its work
A bounce or reputation explanation names the records and logs it reviewed, so you can check the reasoning instead of trusting the tone.
Ask, verify, decide.
Three stages, and the third one is always yours.
Step 1: Ask in plain language
Type a question about a domain, a mailbox or a bounce. There is no query syntax to learn and no dashboard to find first.
Step 2: It goes and looks
It pulls the relevant DNS records, delivery logs and reputation history before it forms an answer at all.
Step 3: You approve, or you do not
If the answer carries a proposed fix, review the exact change and apply it, or dismiss it and keep asking.
The boundaries, precisely.
Exactly what it reads on every query, and exactly where its authority stops.
Data read on each query
- Detail
- DNS records, delivery logs, reputation history, mailbox roster
Change confirmation
- Detail
- Required for every provisioning or DNS action
Response grounding
- Detail
- Cites which records or logs were checked
Availability checks
- Detail
- Live domain availability lookups on suggestion
| Capability | Detail |
|---|---|
| Data read on each query | DNS records, delivery logs, reputation history, mailbox roster |
| Change confirmation | Required for every provisioning or DNS action |
| Response grounding | Cites which records or logs were checked |
| Availability checks | Live domain availability lookups on suggestion |
The copilot never sends mail, never changes a DMARC policy and never registers a domain on its own. Every action leaves it as a proposal.
Ask the fleet instead of grepping the logs.
The copilot ships in the console from the day you sign up: nothing to install, nothing to configure first.