> ## Documentation Index > Fetch the complete documentation index at: https://docs.erdo.ai/llms.txt > Use this file to discover all available pages before exploring further. # Email sending domains > Have Erdo send outreach from an address on your own domain — verify the domain with a few DNS records, then every follow-up an agent sends comes from your brand rather than Erdo's. # 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](/custom-domains). 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](/automations) 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. ## 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. 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. 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. 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 `@` 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 lands in two places at once. It is stored against the domain, where an agent can read it and act on it — answer the question, book the meeting, note the objection against the lead — and a copy is forwarded straight to the mailbox you nominated, so your team reads it in the inbox they already live in rather than logging into Erdo to find out someone wrote back. On that forwarded copy the **Reply-To** is set to the person who actually wrote, not to Erdo: hit reply in your own mailbox and your answer goes directly to the lead, from your real address, with Erdo out of the loop entirely. Nothing is trapped in Erdo waiting for you to notice it. 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 nothing breaks: outreach falls straight back to Erdo's default sender on the next send, and replies to the old address stop reaching Erdo. ## 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](/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: ```bash theme={null} curl https://api.erdo.ai/v1/sending-domains \ -H "Authorization: Bearer $ERDO_API_KEY" ``` Register one (the response carries the records to create): ```bash theme={null} 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: ```bash theme={null} curl https://api.erdo.ai/v1/sending-domains/hello.acme.com \ -H "Authorization: Bearer $ERDO_API_KEY" ``` Remove a registration — outreach reverts to Erdo's default sender: ```bash theme={null} 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: ```bash theme={null} curl "https://api.erdo.ai/v1/received-emails?limit=20" \ -H "Authorization: Bearer $ERDO_API_KEY" ``` Each message comes back as `{from_email, from_name, subject, text_preview, received_at, forwarded_at}`. `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. ### MCP tools | Tool | REST endpoint | Method | | ---------------------------- | ----------------------------- | ------ | | `erdo_create_sending_domain` | `/v1/sending-domains` | POST | | `erdo_list_sending_domains` | `/v1/sending-domains` | GET | | `erdo_get_sending_domain` | `/v1/sending-domains/:domain` | GET | | `erdo_update_sending_domain` | `/v1/sending-domains/:domain` | PATCH | | `erdo_delete_sending_domain` | `/v1/sending-domains/:domain` | DELETE | | `erdo_list_received_emails` | `/v1/received-emails` | GET | ## 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. | | 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. | ## Related The same motion for your published pages — serve them from your own hostname. The record of everything Erdo has sent for you, including the address it sent from. Where most outreach is sent from. An address Erdo owns and can receive at, for agents that need to read mail.