Email sending domains

When an agent follows up with a lead, that mail goes out from Erdo’s own address by default. The recipient sees a sender they have never heard of, on a domain that has nothing to do with the business they enquired with — which is bad for replies and worse for the spam filter, because nothing about the message lines up with the site they just filled a form on. A sending domain fixes that at the source: verify a domain you own, and outreach leaves as hello@acme.com, signed off in your brand’s name. Verification is entirely DNS — a few records at whichever host runs your domain, the same motion you already went through for a custom pages domain. No mail server to run, no mailbox to hand over, no credentials to give Erdo.

Only outreach moves to your domain: the mail agents and automations send on your behalf — lead follow-ups, replies to enquiries, alerts an automation sends out. Erdo’s own product mail — team invites, account notifications — keeps coming from Erdo, because that mail is from Erdo and dressing it up as your brand would be misleading rather than helpful.

Choose the name to send from

You can verify an apex domain (acme.com) or any subdomain (hello.acme.com, news.acme.com) — Erdo does not require the name to match your pages domain, and does not care whether you host anything on it. An organization has one sending domain: everything Erdo sends on your behalf leaves from one identity, so which domain that is should never be ambiguous. To switch domains, remove the current one (sends fall back to Erdo’s address) and register the new one — so the name is worth choosing deliberately. A subdomain is usually the better choice, for one reason worth understanding before you pick. Once you verify a domain, the reputation of everything Erdo sends attaches to that name. Send from the apex and automated outreach shares a reputation with the mail your team sends by hand from their own mailboxes; a bad week for one is a bad week for the other. A subdomain keeps them separate, so a deliverability problem on outreach never touches your everyday business mail. We suggest hello. — it reads like a place a person writes from, which is the point of sending as your own business. Anything warm works (team., contact.); avoid names that read as bulk mail (marketing., promo.), and avoid send., which collides with the name Erdo’s return-path records already use. If you pick hello., give the mailbox a different name — sales@hello.acme.com reads well, hello@hello.acme.com does not. There is also a hard constraint if you want Erdo to receive at the name — which is what brings replies back in, so an agent can read what a lead wrote and act on it rather than only your team seeing it. Receiving needs an MX record on the name itself, and a name can only have one set of MX records — if acme.com already points its MX at Google Workspace or Microsoft 365, it cannot also deliver to Erdo. Erdo checks for existing MX records when you register a domain, and a name that already routes mail somewhere is registered sending-only: no MX record appears among the ones to add, so nothing you (or the DNS admin you email the instructions to) could paste would take your mailbox down. In that setup a forwarding mailbox is required, since replies need somewhere real to land. To also receive through Erdo, verify a subdomain such as hello.acme.com instead, which has no mailbox MX of its own to displace. The same constraint cuts the other way when a name already serves a website — a landing page published on a custom domain, or anything else the name reaches by CNAME. A CNAME record forbids every other record on the same name, so the MX that receiving needs could never be published there. Erdo checks at registration and refuses to register such a name with receiving on, rather than leave you with a domain that can never finish verifying. Keep the page where it is and put email on a sibling name: the page on go.acme.com, email on acme.com or mail.acme.com. (Sending-only from the page’s name is fine — every record sending needs sits on names beneath it, out of the CNAME’s way.)

Set it up

Open Settings → Domains, go to Email sending, and add the domain you want to send from. Erdo registers it and immediately hands back the DNS records to create.

Create the DNS records

Add them at whatever host answers for your domain — your registrar, Cloudflare, Route 53. Every record is shown with a copy button, and the values must be entered exactly as given. If someone else runs your DNS, email them the instructions straight from the domain’s card — the whole record set arrives in one message, which is safer than pasting values into chat one at a time.

Wait for verification

Erdo re-checks the domain roughly every ten minutes until every record is visible and correct, then marks it active. DNS changes usually surface within minutes, but a host with long TTLs can take a few hours — nothing is wrong until the records are live and Erdo still can’t see them.

Set how it signs

Choose the display name, the local part of the address (hello unless you change it), and the mailbox replies should reach. These are editable at any time and take effect on the next send.

The records, and what each one is for

Erdo generates the exact values for your domain; there is nothing to compose yourself. What they do:

Record	Where it goes	Why it’s needed
DKIM public key (TXT)	A selector Erdo names, on your domain	Lets receiving servers verify that a message signed with Erdo’s key really was authorised by your domain. This is the record that makes the mail yours.
Return path (MX)	A `send.` subdomain of the name you verified	Routes bounces and delivery reports back through a name inside your domain, which is what makes SPF align with the address in the From header.
SPF (TXT)	The same `send.` subdomain	Names the servers allowed to send with that return path.
DMARC policy (TXT)	`_dmarc` on your domain	Offered only when your domain has no DMARC policy at all. Erdo suggests a monitoring-only policy (`v=DMARC1; p=none;`) — it changes nothing about how your mail is handled and starts the reports you’d need before tightening it later.

Because the return path sits on a send. subdomain rather than on the name itself, these records do not touch your existing mail routing: adding them cannot divert mail to your team’s mailboxes. Once the domain is active, DMARC alignment is automatic. Every message is sent from an address on the verified domain, signed with a DKIM key published by that domain, with a return path inside it — so both the DKIM and SPF checks align with the visible From address, which is what a DMARC policy actually asks for. You get this by construction; there is no setting to enable.

What changes once it’s active

Outreach switches to <local-part>@<your-domain> with your display name, and the sign-off at the bottom of composed messages changes from Erdo’s to your brand’s, so nothing in the message contradicts the sender. What happens when someone replies depends on whether you turned receiving on, because that is the difference between the reply going somewhere Erdo can see and going somewhere it cannot. With receiving on, the mail goes out with Reply-To set to the sending address itself — which is a name that now delivers to Erdo — so a reply comes back to Erdo and is stored against the domain, where an agent can read it and act on it. When the reply is a lead answering your auto-reply, Erdo keeps the whole conversation. The lead’s message is passed on to the mailbox you nominated as “Jane Smith via Your Brand”, from your sending address, in the same email thread. Hit reply in your own mailbox as you normally would: your answer comes back to Erdo, is stored against the lead, and is passed on to the lead as “Your Name · Your Brand”. The lead replies, and so on. Nobody has to press Reply All and nobody has to log in anywhere — every message in the thread goes through Erdo, so the full back-and-forth appears on the lead’s timeline. A few messages are kept in Erdo and not passed on: automatic replies such as an out-of-office, delivery failures, and an email your mailbox sends to the sending address that is not a reply in a lead’s thread — Erdo cannot tell which lead it was meant for. An email you write to a lead from scratch, outside the thread, goes straight to them and Erdo does not see it. Any other mail that arrives at the domain is forwarded to your nominated mailbox with Reply-To set to the person who wrote, so answering it goes straight to them from your real address. With receiving off — which is the right choice when the name already routes mail to Google Workspace or Microsoft 365 — nothing changes about where mail lands. Outreach carries a Reply-To pointing at the mailbox you nominated, so someone who hits reply reaches a real person at your company directly. That reply never passes through Erdo, so Erdo has no record of it and no agent can act on it. Delete a sending domain and outreach falls straight back to Erdo’s default sender, hello@mail.erdo.ai, on the next send. Its Reply-To is hello@erdo.ai, not the mailbox you nominated for the removed domain. An automation whose copy asks the recipient to reply must therefore stay disabled until its sending domain and reply route are active; the fallback is suitable only for messages that do not promise a client reply path.

Your brand in the message, not just on the envelope

A verified domain changes the sender and the sign-off. It also changes what the message looks like: composed mail from your domain renders in your brand — your accent color on the button and links, your text color, your page and card backgrounds, your logo above the first line, and your typeface where the recipient’s mail client loads web fonts. Mail from Erdo’s default address keeps Erdo’s look, for the same reason it keeps Erdo’s sign-off: a message in your colors under an Erdo sender would read as two different companies. You do not set this up. The look is derived from your Brand Style record — the Knowledge record your agent team builds when it captures your brand, and the same record your landing pages are built from. A model reads the record’s color tokens, typography table and logo attachments once and Erdo validates what it picked before using any of it: a color has to appear in the record verbatim, backgrounds have to be light (email on a dark ground is a deliverability problem), text has to read against the card it sits on, and the logo has to be one of the record’s own published images that actually shows on the email’s background — a light logo variant made for dark pages is skipped in favour of one that reads, or left out. The accent is worn as it is on the button, with the button text chosen to read on it; links take the accent darkened only as far as legibility needs, so a pale brand color stays the brand’s rather than falling back. A token that fails falls back to the default on its own; the rest still apply. When the Brand Style record changes, the next send notices and re-derives the theme in the background — that send goes out in the previous look, the one after in the new. To see the result immediately instead, refresh the theme (below) right after the record is updated. Two things follow from this being derived rather than authored:

To change the theme, change the Brand Style record. Ask your agent team in chat; there is nothing to edit here. If a color is wrong in the email, it is wrong in the record, and fixing it there fixes the pages too.
The logo appears once it is published. A record’s images become public when a page built from it is published, which is the normal order of events for a development with landing pages. An organization whose brand has never been used on a live page sends branded mail without a logo until one is.

Fonts are best-effort by nature: Apple Mail and iOS Mail load the Google Fonts family the record names; Gmail and Outlook ignore web fonts and show the system fallback. Colors and the logo render everywhere.

Deliverability is now your domain’s

This is the trade you are making, and it is worth being explicit about. On Erdo’s shared sending domain your mail inherits a reputation that already exists. On your own domain you start from nothing, and everything Erdo sends builds — or damages — the reputation of a name you also use for everything else. Practically, that means:

Warm up gradually. A domain that has never sent automated mail and then emits a few hundred messages in a day looks exactly like a compromised domain to a spam filter. Start with the follow-ups you’d send anyway and let volume grow over days, not in one afternoon.
Keep the volume modest. Erdo caps an organization at 50 distinct recipients per day across all its outbound mail, and verifying a domain does not raise that cap. It is a deliberate guard: outreach from an agent is meant to be a handful of relevant follow-ups, not a campaign send.
Mail people who asked to hear from you. Follow-ups to leads who filled in your form perform well and get few complaints. Cold lists on a freshly verified domain are the fastest way to teach the receiving side to distrust your name.
Leave DMARC on p=none for a while. If Erdo offered you the DMARC record, it deliberately suggests monitoring rather than enforcement, so that a misconfiguration somewhere else in your mail setup doesn’t start bouncing legitimate mail the day you add it.

API

Sending domains are org-scoped and require an org admin, like custom domains. A domain is addressed by its name — the natural identifier — and a name registered to another organization answers 404 with no hint that it exists. List the org’s sending domains with their live status and DNS records:

curl https://api.erdo.ai/v1/sending-domains \
  -H "Authorization: Bearer $ERDO_API_KEY"

curl -X POST https://api.erdo.ai/v1/sending-domains \
  -H "Authorization: Bearer $ERDO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"domain": "hello.acme.com"}'

Read one back while you wait for DNS to propagate:

curl https://api.erdo.ai/v1/sending-domains/hello.acme.com \
  -H "Authorization: Bearer $ERDO_API_KEY"

This read asks the email provider for the current DNS status. If that live check is temporarily unavailable, the request fails instead of presenting a previously stored status as current; retry the same read to continue polling. Remove a registration — outreach reverts to Erdo’s default sender:

curl -X DELETE https://api.erdo.ai/v1/sending-domains/hello.acme.com \
  -H "Authorization: Bearer $ERDO_API_KEY"

Read the mail that arrived at the domain, newest first — usually replies to outreach, though anything sent to an address on the domain lands here too. This one needs only org membership rather than an admin, because received mail is correspondence to read and not a registration to change — and domain can be left off, since you have one sending domain and the read resolves it:

curl "https://api.erdo.ai/v1/received-emails?limit=20" \
  -H "Authorization: Bearer $ERDO_API_KEY"

Add lead_ref (and optionally dataset) to read one lead’s email conversation:

curl "https://api.erdo.ai/v1/received-emails?lead_ref=$LEAD_REF" \
  -H "Authorization: Bearer $ERDO_API_KEY"

Each message comes back as

{from_email, from_name, subject, text_preview, received_at, forwarded_at, direction, lead_ref, dataset, lead_email, relayed_email_id, relay_skip_reason}

. direction is lead or desk for a message in a lead’s thread and empty otherwise; relayed_email_id is the copy Erdo passed on, readable in full at /v1/emails/{id}; relay_skip_reason says why a thread message was kept and not passed on (auto_submitted, bounce, unmatched_desk). text_preview is the opening of the message — enough to separate a real answer from an out-of-office without pulling whole bodies. forwarded_at says when the copy went to your nominated mailbox; empty means the message is in Erdo only, so nobody on your side has necessarily seen it yet. A sending-only domain returns an empty list, which is the configuration working as chosen rather than a fault. The theme is read from /v1/sending-theme:

curl -H "Authorization: Bearer $ERDO_API_KEY" https://api.erdo.ai/v1/sending-theme

{
  "found": true,
  "status": "ready",
  "accent": "#0b3d91",
  "text": "#1a1a1a",
  "page_background": "#f4f6fa",
  "card_background": "#ffffff",
  "font_family": "Inter",
  "logo_url": "https://api.erdo.ai/public/knowledge-assets/…",
  "source_title": "Acme — Brand Style",
  "source_slug": "acme-brand-style",
  "source_updated_at": "2026-09-01T10:30:00Z",
  "rationale": "primary #0b3d91 from Visual tokens; Inter from the Typography table",
  "derived_at": "2026-09-01T10:31:04Z"
}

status is ready when the theme above is in use, no_brand_style when the organization has no Brand Style record yet (mail renders in the default look until one exists), or failed when a record exists but yielded nothing usable — error_reason says what it lacked. found: false means no theme has been derived yet, which is what every organization looks like before its first send from a verified domain. On a ready theme, error_reason lists any token that was dropped and why, so a missing logo or a fallen-back color is explained rather than silent. POST /v1/sending-theme/refresh derives the theme from the Brand Style record now and returns the same shape. It is for the moment right after the record changed; it needs the org admin role, because it replaces what every future send renders in.

CLI

The CLI does the whole setup, which is the shape most of this work actually has: register the domain, hand the printed records to whoever runs the DNS, then check back until it says active.

erdo email domains add hello.acme.com --from-name "Acme Sales"
erdo email domains list                              # domain, status, from, receiving, last checked
erdo email domains get hello.acme.com                # while DNS propagates
erdo email domains update hello.acme.com --from-local-part sales
erdo email domains remove hello.acme.com             # outreach reverts to Erdo's address

add and get print the status first and then the DNS records, one per line as type, name, value — the records go to stdout so they pipe and paste cleanly, while the surrounding notes go to stderr. Those notes are worth reading: a domain that is not yet active says so outright, because until it is, every send still leaves from Erdo’s address. A domain Erdo registered sending-only says that too, so “receiving is off” is never mistaken for something a flag can fix. --receiving true|false and --forward-to <mailbox> set receiving and the forwarding mailbox on either verb; update changes only the flags you pass. Read what has come back with:

erdo email received                 # newest first, across the org's sending domain
erdo email received --limit 20
erdo email received --lead-ref <ref>  # one lead's conversation with the desk

Each message prints its arrival time, who wrote, the subject, and the opening of the body — enough to tell a real answer from an out-of-office. Underneath it says when the copy reached your nominated mailbox, or that it did not, which is the line that matters: an unforwarded message is in Erdo only, so nobody on your side has necessarily seen it. --json on any of these prints the raw response instead.

MCP tools

Tool	REST endpoint	Method	CLI
`erdo_create_sending_domain`	`/v1/sending-domains`	POST	`erdo email domains add`
`erdo_list_sending_domains`	`/v1/sending-domains`	GET	`erdo email domains list`
`erdo_get_sending_domain`	`/v1/sending-domains/:domain`	GET	`erdo email domains get`
`erdo_update_sending_domain`	`/v1/sending-domains/:domain`	PATCH	`erdo email domains update`
`erdo_delete_sending_domain`	`/v1/sending-domains/:domain`	DELETE	`erdo email domains remove`
`erdo_list_received_emails`	`/v1/received-emails`	GET	`erdo email received`
`erdo_get_sending_theme`	`/v1/sending-theme` (`refresh: true` → POST `/v1/sending-theme/refresh`)	GET / POST	—

Troubleshooting

You see	What to do
The domain sits waiting for DNS	Confirm the records exist at the host that actually answers for the domain, and that no record name was doubled up (many DNS panels append the domain themselves, so pasting the full name yields `send.acme.com.acme.com`). Erdo re-checks about every ten minutes.
A warning that the domain already has MX records	The name is already receiving mail elsewhere — Google Workspace, Microsoft 365, your own server — so Erdo registered it sending-only and issued no MX record. To also receive replies through Erdo, remove it and register a subdomain like `hello.acme.com` instead.
Registration refused because the name serves a website	The name has a CNAME record (a landing page, most often), and DNS forbids the MX record receiving needs next to a CNAME. Register a sibling name for email — the apex or `mail.acme.com` — or register the page’s name with receiving off and a forwarding mailbox.
Replies aren’t appearing in Erdo	Replies only come back when the domain was registered with receiving on and its MX record is live — check the domain’s records, and remember a name that already routes mail elsewhere cannot also deliver to Erdo. A sending-only domain sends replies straight to your nominated mailbox and Erdo never sees them.
A reply is in Erdo but never reached your mailbox	Forwarding needs a nominated mailbox on the domain; without one, replies are stored in Erdo only. Bounce notifications are deliberately not forwarded.
Verification succeeded but mail still comes from Erdo	Outreach picks up the domain once it is active; a domain still verifying doesn’t change any sender. Product mail — invites, notifications — never switches.
No Email sending section in Settings → Domains	The capability isn’t enabled for your organization yet; ask your Erdo admin.

Custom domains

The same motion for your published pages — serve them from your own hostname.

Sent email

The record of everything Erdo has sent for you, including the address it sent from.

Automations

Where most outreach is sent from.

Inboxes

An address Erdo owns and can receive at, for agents that need to read mail.

Get started

Features

Connect Erdo

Email sending domains

Email sending domains

Choose the name to send from

Set it up

The records, and what each one is for

What changes once it’s active

Your brand in the message, not just on the envelope

Deliverability is now your domain’s

API

CLI

MCP tools

Troubleshooting

Custom domains

Sent email

Automations

Inboxes

​Email sending domains

​Choose the name to send from

​Set it up

​The records, and what each one is for

​What changes once it’s active

​Your brand in the message, not just on the envelope

​Deliverability is now your domain’s

​API

​CLI

​MCP tools

​Troubleshooting

​Related

Custom domains

Sent email

Automations

Inboxes

Email sending domains

Choose the name to send from

Set it up

The records, and what each one is for

What changes once it’s active

Your brand in the message, not just on the envelope

Deliverability is now your domain’s

API

CLI

MCP tools

Troubleshooting

Related