Email from your domain: transactional sending included in your plan

How many emails each plan brings

Plan	Emails per day	Per month, roughly
Nébula	50	1,500
Órbita	100	3,000
Galaxia	300	9,000
Cosmos	1,000	30,000

For a sense of what that is worth: the free tier at SendGrid and Mailgun is 100 emails a day, and their first paid plan runs $15 to $20 a month. Here it is included and already configured.

So there is no confusion: what these are and what they are not

They are the emails your site writes to your customers on its own. “We got your order,” “here is your invoice,” “reset your password,” “your shipment is on its way.” They go out under your own domain, signed, and land in the inbox instead of the spam folder — we set that configuration up for you, because your DNS already lives here.

They are not a mailbox you log into to read. There is no webmail and no you@yourdomain.com account to check messages; your Gmail or whatever you already use still covers that. What we solve is the other half: letting your site talk to your customers without you contracting or configuring a separate sending service, which on its own runs $15 to $20 a month.

In one line: this is not your email, it is your website's email.

What your plan includes

Every paid plan comes with daily emails included, sent from your own domain: order confirmations, invoices, notices, password resets. They go out DKIM-signed with SPF and DMARC configured — we write those records for you, because your DNS already lives with us. You copy nothing, you verify nothing.

The free Preview plan does not include email: it is the showcase for your page, not the business operation.

Turning it on: one button

1. Go to your dashboard → My domains → your domain.
2. On the "Email from your domain" card, press Activate my domain's email.
3. Done. The signup and the DNS records are in place within seconds.

Sending from your app

Your code calls our endpoint with your site token (the same one from the database console, "View token" button in your dashboard):

POST https://yapanel.yadominios.com/api/hosting/correo/enviar
Content-Type: application/json

{
  "sitio": "my-site",
  "token": "your site token",
  "from": { "address": "notices@yourdomain.com", "name": "Your Business" },
  "to": [{ "address": "customer@example.com" }],
  "subject": "Your order is confirmed",
  "text": "Plain-text version (always include it)",
  "html": "<p>HTML version</p>"
}

Successful response:

{
  "success": true,
  "message_id": "<…@yourdomain.com>",
  "enviados_hoy": 12,
  "incluidos_por_dia": 100,
  "es_extra": false
}

The rules

• The sender (from) must belong to a domain connected to your site. Any mailbox works: notices@, orders@, billing@.
• Always include text along with html: it improves deliverability.
• Transactional email only. No newsletters or bulk campaigns.
• The token goes in an environment variable of your site, never in code.

If you're an AI integrating sending: read this whole section before writing code

This section exists because an AI already lost an hour guessing formats. Everything below is verified with real sends — and other docs (including the Workers binding's) use formats that DO NOT APPLY here.

The exact shape that works

POST https://yapanel.yadominios.com/api/hosting/correo/enviar
Content-Type: application/json

{
  "sitio": "site-name",
  "token": "the site token (environment variable, never in code)",
  "from": { "address": "notices@yourdomain.com", "name": "Your Business" },
  "to": [{ "address": "customer@example.com" }],
  "reply_to": "support@yourdomain.com",
  "subject": "…",
  "text": "plain-text version (ALWAYS)",
  "html": "<p>HTML version (optional)</p>"
}

What NOT to do (each item already broke someone)

Mistake	What happens	The right way
Using replyTo in camelCase	invalid_request_schema — cost a real AI an hour	reply_to, snake_case, as PLAIN TEXT
reply_to as a list of objects	invalid_request_schema	Plain text: "reply_to": "support@…"
Sender from a domain that isn't the site's	403 from_ajeno — a security lock, not a bug	The from must belong to YOUR site's connected domain
Calling Cloudflare directly with an account key	That key can send as ANY domain on the platform; it is never handed out	Use this endpoint with your site token
Sending only html without text	Worse deliverability; some clients won't render it	Always include both
Retrying an error in a loop	Burns the day's quota and fixes nothing	Read the error code table below and act once

The endpoint's errors, with the way out

HTTP	Code	Meaning	What you do
401	token_invalido / sin_token	The token isn't this site's or doesn't exist	Generate one with "View token" in the dashboard and put it in the env variable
403	plan_sin_correo	The site is on the free Preview plan	The owner must move to a paid plan
403	from_ajeno	The sender isn't from a site domain	Change the from to the connected domain
429	limite_alcanzado	The day's 100 went out and extras aren't authorized	Do NOT retry: wait for tomorrow or have the owner authorize extras
502	proveedor	The provider rejected the message	Read the error detail: it's usually the message format

The success response always carries enviados_hoy: use it so you never hit the limit blind.

What if I go past the daily 100?

You decide, and the default is the safe one:

Situation	What happens
Extra emails not authorized (the default)	At email 101 sending pauses until the next day. Zero surprise charges.
"Extra emails" authorized (⋮ menu on your site)	Sending continues uninterrupted and the excess bills at $1 per 1,000 emails.

The endpoint response always tells you today's count (enviados_hoy) so your app can show it if it wants.

Where you see your emails: the “Emails” button on your site

In the dashboard, on your site's card, there is an Emails button. Everything you need is there, without asking anyone:

• Today's numbers: how many went out, how many failed, how many are left of your 100 included, and your total for the last 30 days. The bar turns amber at 80% — you find out you are running short before you run short, not after.
• Every email, with its content. Subject, who it went to, what time, and one tap opens it so you can read the message exactly as it was sent. It answers the question people actually ask: “did this customer get the notice, and what did it say?”
• The failed ones, with the reason in plain words. They sit in the same list, in clock order, marked in red. The send that did not go out is precisely the one you need to be able to look at.

Messages are kept for 30 days; the sent and failed counts never expire. Very large bodies are stored trimmed (the email itself goes out complete).