Sending domains

To send email from your own address (hello@yourcompany.com, noreply@app.example.com, …) you have to prove to the receiving mail servers that Runsite is allowed to send on your domain’s behalf. That proof lives in three DNS records: SPF, DKIM and DMARC.

The dashboard generates the exact records to add at your registrar; you copy them in, click Verify, and once they pass you can use any From: address on that domain.

Add a domain

1. Open your email service → Domains tab → Add Domain.
2. Enter the domain you want to send from (e.g. yourcompany.com, mail.yourcompany.com).
3. The dashboard shows the DNS records to add. The domain appears as Pending.

You can use either the apex (yourcompany.com) or a subdomain (mail.yourcompany.com) — using a dedicated subdomain keeps your transactional and marketing reputation isolated.

DNS records to add

The exact host names and values come from the dashboard — paste each row into your DNS provider verbatim. The shape looks like this:

Record	Type	Purpose
SPF	TXT on the apex / send-from host	Authorizes Runsite to send on behalf of your domain.
DKIM	TXT on dedicated subdomains (usually two)	Cryptographic signature on every outgoing message — recipients use it to verify the message wasn’t forged or tampered with.
DMARC	TXT on _dmarc.yourdomain.com	Tells receivers how to handle messages that fail SPF / DKIM (none, quarantine, reject) and where to send aggregate reports.
Return-Path (optional)	CNAME	Aligns the bounce-handling address with your domain so receivers see consistent identity.

Two important rules:

• Don’t add SPF twice. A domain can only have one SPF record. If you already have one (for example for Google Workspace), edit it to include Runsite’s send host alongside your existing entries.
• TTL low while testing. Set the TTL on these records to 300–600 seconds while you’re verifying — that way edits take effect within minutes instead of hours.

DNS changes typically propagate in a few minutes; some providers can take up to a few hours.

Verify

Once you’ve added the records:

1. Return to the Domains tab.
2. Find the pending domain in the list.
3. Click Verify.

The dashboard checks the live DNS against what it expects:

• ✅ All records found and correct → status flips to Verified, badge turns green.
• ⚠️ One or more records missing or wrong → status stays Pending (or moves to Failed after repeated misses). The error message tells you which record didn’t match — fix it and verify again.

You can re-run Verify as many times as you need.

Going from sandbox to production

A new email service starts in sandbox mode — it can only send to recipients you’ve explicitly verified, from a shared sandbox sender (onboarding@runsite.app). Verifying your first sending domain on a service is what unlocks production mode: real From: addresses on your domain, deliverable to anyone.

The transition is automatic — once a domain on the service reaches Verified status, the service header switches from a yellow Sandbox badge to a green Production badge.

See Sandbox mode for the development flow before that switch.

Sending after verification

With the domain verified, set from in your API request to any address on it:

curl https://api.runsite.app/emails \
  -H "Api-Key: rs_eml_…" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "Acme Support <support@yourcompany.com>",
    "to": ["user@example.com"],
    "subject": "Welcome",
    "message": "<p>Thanks for signing up!</p>"
  }'

Both forms are accepted: a bare address (user@example.com) and the display-name form (Acme Support <support@yourcompany.com>).

If you send from a domain that isn’t verified on the service, the request doesn’t fail — Runsite transparently falls back to the sandbox sender so you don’t drop messages mid-deploy. The response will tell you mode: "sandbox_fallback" so you know to fix it.

Multiple domains

You can attach as many domains as you like to one service — useful if you operate multiple brands or want a clean split between transactional and product subdomains. The from address picks which domain’s keys sign the message.

Removing a domain

Open the domain → Delete. This stops Runsite from signing for it (the upstream key is rotated out automatically). Remove the DNS records at your registrar afterwards if you don’t plan to use the domain again.

DMARC: start in monitor mode

Set the initial DMARC policy to p=none with a reporting address you control. Watch the aggregate reports for a couple of weeks to make sure all your legitimate senders (Runsite and anything else like Google Workspace, your CRM, etc.) align — only then ramp to p=quarantine and finally p=reject. Going straight to reject can silently lose mail until everything is aligned.