One MX record, and your agent can receive

One MX record on a verified AgentiSend domain is what lets an agent receive mail there. Mail to that name is stored on the account, and each message fires email.received with the reply already separated from the quoted history.

The record

Turn receiving on for a domain you have already verified. Its DNS records then include one MX. Publish that record with the lowest priority number of any MX on the same name. A name whose mail is read somewhere else already should not get it. Use a subdomain such as inbound.example.com when the apex belongs to another inbox. Publishing the record on the apex would take that name's mail away from the inbox that already reads it.

The host name and the exact record are in Receiving and replying. Publish the record, then send one message from an account you control and read it back before you point a customer's reply address at it. Mail for a domain that is not verified, or has receiving off, is refused at the door and never stored. Nothing from that refusal appears in the list.

If the name already has an MX, the one with the lowest priority number is where mail is delivered. A record you add at a higher number does not receive while the lower one answers. That is why a name you still read somewhere else should get a subdomain, and why the record you publish for AgentiSend has to be the lowest number on that name. After it is published, the status page shows receiving as accepting mail.

What arrives

email.received carries the sender, the recipients, the subject, the message id, and extracted_text. Add that webhook if the agent should wake up on arrival. Polling the list works when you do not want a public webhook URL. The event is the signal. The body you act on is the read below, not a guess from the subject.

GET /emails/receiving lists received mail, newest first. Filter by recipient, sender, or a date range. list_received_emails is the same list over MCP. Both need a full-access key. A key minted as sending_access can send and can read the mail it sent itself. It cannot read mail that arrived at your domains. Handing the agent's sending key to this list returns the refusal for a key that can only send.

GET /emails/receiving/{id} returns one message: headers, text, HTML, and the attachments it carried. extracted_text is the reply with quoted history, a signature block, a phone signature line, an unsubscribe footer, and a legal disclaimer removed. extracted_html is that same cut in HTML. Either field is null when it could not be produced, and an empty result is null too. Read text, then html.

The list does not include the extracted fields. Read each message on its own. A forwarded message often arrives as a short note plus the original. The extracted fields then keep the note and drop the forwarded message. Read text when you need what was forwarded. A delivery-failure notice is kept whole, including the copy of the message that failed, because the notice is the message.

A message over 256 KB is not judged. The size cap is on the label, not on storage. The stored message is still the one GET /emails/receiving/{id} returns. The label itself, and what a review message waits on, is Mail an agent reads is where it gets hurt.

Threads, a reply, and the sender rules are separate calls on the same stored message. They are written in Receiving and replying. A domain holds 1,000 of those sender rules.

Read next

• Receiving and replying
• Mail an agent reads is where it gets hurt
• How do I stop prompt injection in email my agent reads?