> ## Documentation Index > Fetch the complete documentation index at: https://docs.brilo.ai/llms.txt > Use this file to discover all available pages before exploring further. # Bring your own email domain > Connect a domain you already own (e.g. sales@yourcompany.com) so your agents and campaigns can send email from your own brand. Two gates: confirm the sending address, then authenticate the domain with DNS. To send email from Brilo, you connect a domain your business already owns, so recipients see mail from an address like `sales@yourcompany.com`. It's the email equivalent of importing an existing Twilio number: you bring something you already control. Setup takes about 10 minutes of clicking, plus DNS propagation time (usually minutes, occasionally a few hours) that runs in the background. Connecting a domain is a **two-gate** process, and both gates are required before you can send: 1. **Prove you own the sending address** by clicking a link we email to it. 2. **Authenticate the domain** by adding DNS records that let Brilo sign mail as your domain. You only need to do this once per domain. After that, adding more sending addresses on the same domain only repeats gate 1. *** ## Before you start * **A domain your business owns** and can edit DNS for (e.g. `yourcompany.com`). Public mailboxes like Gmail, Outlook, or Yahoo **cannot** be connected. You can't add DNS records to a domain you don't control, so Brilo blocks them up front with a clear message. * **Access to that domain's DNS**, or a colleague who has it. If the person setting up Brilo isn't the DNS admin, there's a built-in "email the records to your DNS admin" path (Step 3). * **Admin access to your Brilo workspace.** * **The Email channel enabled for your workspace.** If you don't see **Settings → Channels → Email**, it isn't turned on for your workspace yet. Reach out to [support@brilo.ai](mailto:support@brilo.ai). **Your existing email keeps working, untouched.** Brilo authenticates your domain on records that can't collide with your human email: DKIM uses named selectors, and the SPF/MAIL FROM records live on a dedicated `send.` subdomain with its own `MX` and `SPF`. Your **apex** `MX`, `SPF`, and `DMARC` (Google Workspace, Microsoft 365, etc.) are never changed. Brilo also *suggests* a `DMARC` record, but only if you don't already publish one. Replies to your agent's mail land in your normal inbox (see [Reply handling](#reply-handling)). *** ## How it works ``` Settings ▸ Channels ▸ Email ▸ [ + Add domain ] opens the setup wizard Step 1 Enter domain + from-address (no mail-provider call yet; public providers blocked) │ ▼ Brilo emails a single-use link to that exact address (expires in 24h) Step 2 Recipient clicks the link → address VERIFIED │ then Brilo creates the domain identity, ▼ sets a custom MAIL FROM, and generates the records (DKIM + SPF + DMARC) Step 3 Add the records to YOUR DNS, in two groups: │ • Domain Verification — 3 DKIM CNAMEs │ • Enable Sending — MX + SPF on send., suggested DMARC ▼ Brilo polls until DKIM verifies (Check now, or auto re-checks) Step 4 Domain ACTIVE → send a test email → agents & campaigns can send A SEND IS ALLOWED ONLY WHEN: address status = verified AND domain state = active ``` The two gates are deliberate. The email-link step confirms a human controls the mailbox; the DNS step is the real authentication that lets mail pass DMARC and reach the inbox. Skipping either one would either dead-end in spam or let someone claim an address they don't own. *** ## Step 1: Add your domain In your Brilo dashboard, go to **Settings → Channels → Email**. On the **Domains & addresses** tab, click **+ Add domain**. A setup wizard opens in a panel on the right. Fill in the first step (**Add your domain**): | Field | What to enter | | ----------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | **Domain** | The domain you own, e.g. `yourcompany.com`. (Pasting `https://…` or a full email address works too; Brilo normalizes it.) | | **From address** | The local part before the `@`, e.g. `sales`. This becomes `sales@yourcompany.com`. | | **Display name** *(optional)* | The name recipients see in the From line, e.g. `Sales at YourCompany`. Defaults to your workspace name; editable any time. | A live **From** preview shows exactly what recipients will see. When it looks right, click **Verify email**. **Public email providers are rejected.** If you enter `gmail.com`, `outlook.com`, `yahoo.com`, `hotmail.com`, `icloud.com`, `proton.me`, and \~50 other consumer providers, the **Verify email** button stays disabled and you'll see: *"Use a domain your business owns (e.g. yourcompany.com). Public email providers like Gmail, Outlook or Yahoo can't be connected."* Brilo has to authenticate your domain with DNS records, which is only possible on a domain you control. Nothing is sent to the mail provider at this step. Brilo only creates the domain record and emails the confirmation link. The domain identity (and your DNS records) aren't created until you complete Step 2, so an unconfirmed address never touches the mail provider. *** ## Step 2: Confirm you own the address Brilo emails a single-use confirmation link to the exact address you entered (subject: **"Confirm your sending address"**). The wizard moves to **Verify the address** and shows *"We emailed a verification link to [sales@yourcompany.com](mailto:sales@yourcompany.com). Click it to confirm you own this address."* 1. Open the inbox for that address and find the Brilo email. 2. Click **Confirm address**. 3. You land on a confirmation page that reads **"Address confirmed"**. Click **Continue setup** to return to the wizard. The wizard updates on its own, re-checking every few seconds, so once you confirm it advances to the DNS step without you refreshing. If you need it, the **Resend email** button sends a fresh link, and **I'll finish later** closes the wizard while saving your progress. **The confirmation link expires in 24 hours.** If it lapses, the verify page shows *"Link expired"*. Just reopen the wizard and use **Resend email** to get a new one. To prevent abuse, confirmation emails are rate-limited per workspace: **3 per hour and 10 per day**. If you hit the limit, Brilo asks you to try again later. *** ## Step 3: Add the DNS records Confirming the address triggers Brilo to create the domain's sending identity, set up a custom **MAIL FROM** subdomain (`send.yourcompany.com`) for SPF, and generate the full DNS record set. The wizard's **Add DNS records** step lists them in two groups that mirror what each record does. ### Domain Verification (DKIM) Three `CNAME` records that let Brilo sign mail as your domain: | Type | Host | Value | TTL | Priority | | ----- | --------------------- | ----------------------------- | ---- | -------- | | CNAME | `._domainkey` | `.dkim.amazonses.com` | Auto | — | | CNAME | `._domainkey` | `.dkim.amazonses.com` | Auto | — | | CNAME | `._domainkey` | `.dkim.amazonses.com` | Auto | — | ### Enable Sending (SPF & DMARC) **SPF** — an `MX` + `TXT` on the dedicated `send.` subdomain, so SPF authenticates your domain without touching your apex SPF: | Type | Host | Value | TTL | Priority | | ---- | ------ | -------------------------------------- | ---- | -------- | | MX | `send` | `feedback-smtp..amazonses.com` | Auto | 10 | | TXT | `send` | `v=spf1 include:amazonses.com ~all` | Auto | — | **DMARC** *(optional)* — suggested only if you don't already publish a policy: | Type | Host | Value | TTL | Priority | | ---- | -------- | ------------------- | ---- | -------- | | TXT | `_dmarc` | `v=DMARC1; p=none;` | Auto | — | Add every record at your DNS provider (Cloudflare, GoDaddy, Route 53, Google Domains, etc.) with the exact Host and Value shown. The **Host** column is already relative to your domain (`send`, `_dmarc`, `._domainkey`), which is what most providers expect. **Why SPF and DMARC, not just DKIM?** DKIM alone technically passes DMARC, but mailbox providers — Microsoft/Outlook especially — increasingly distrust a brand-new domain that publishes no SPF and no DMARC, and route it to spam or quarantine. Adding the `send.` MAIL FROM (SPF) plus a DMARC record is what gets a cold domain into the inbox. **SPF and DMARC don't block activation.** Your domain goes **Active** as soon as DKIM verifies, so you can send right away. The SPF (MAIL FROM) and DMARC records verify in the background and improve deliverability; a missing or slow-propagating MAIL FROM safely falls back to the default sender rather than stopping mail. The wizard gives you a few ways to get them where they need to go: * **Copy all records:** copies all three at once. * **Per-record copy:** a copy button on each Name and Value. * **Copy link:** copies a shareable link that reopens this exact DNS step (hand it to a teammate). * **"Not the person who manages DNS?":** enter your DNS admin's email and click **Send**. Brilo emails them the same grouped record tables (Domain Verification + Enable Sending), plain-English instructions, and a link back to this step. No secrets travel in that email, since DKIM, SPF, and DMARC records are all public. After the records are in, Brilo verifies them automatically. The wizard shows *"Checking automatically… DNS can take a few minutes · last checked …"*, and you can press **Check now** to poll immediately instead of waiting. When DKIM verifies, the domain flips to **Active**, and the workspace owner gets a *"your domain is verified and ready to send"* email. **Don't double up the domain in the Host.** Many DNS providers automatically append your domain to whatever you type. The Host values shown are already relative (`send`, `_dmarc`, `._domainkey`), so enter them as-is — don't add `.yourcompany.com` yourself, or you'll end up with `send.yourcompany.com.yourcompany.com`. When in doubt, check the provider's preview of the final record name. These records are **purely additive**. DKIM uses named selectors, the MX + SPF sit on the dedicated `send.` subdomain, and DMARC (if you add it) goes on `_dmarc` only when you don't already have one. None of them touch your apex `MX`, `SPF`, or your existing `DMARC`, so human email on the domain is unaffected. *** ## Step 4: You're set Once DKIM verifies, the wizard reaches **All set**, which reads *"Your domain is verified and ready to send."* Before you close it, click **Send test email**. Brilo sends a real message **from your newly verified address to the workspace owner**, so you can confirm end to end that it sends, passes authentication, and renders correctly. Check the owner's inbox (and the spam folder). Then click **Done**. Your agents and campaigns can now send from this domain. Open an agent and set its sending address, or add an email step to a campaign. **Sandbox caveat (test email).** If your mail account is still in sandbox mode, the test send only reaches verified recipients and you'll see a message saying so. That's an account-level provider setting, not a problem with your domain. Production access removes it. *** ## Adding more sending addresses A verified domain can host several addresses (`sales@`, `support@`, `ai@`, …). To add another, open the domain in **Settings → Channels → Email** and click **+ Add address**. Because the domain is already authenticated, you skip the DNS step and only repeat the email-confirmation gate (Step 2) for the new address. Each address is verified independently. *** ## Sharing a domain across workspaces If your company runs more than one Brilo workspace (for example, a separate workspace per country or brand), you don't have to re-authenticate the same domain in each one. A domain is verified once by the workspace that sets it up (the **owner**). Other workspaces can then **request to share** it, and because the domain is already authenticated, a shared workspace **skips the DNS step entirely**. It only confirms a sending address. Sharing is **owner-approved** by design. Proving you control a mailbox on the domain is not enough on its own: the workspace that originally set the domain up has to approve each request. That stops a domain one team set up from being used by another workspace without their knowledge. ``` Workspace B enters a domain another workspace already verified │ ▼ Brilo: "already verified by another workspace" → [ Request access ] Step 1 B enters the from-address it wants (e.g. sales@) and requests access │ ▼ Brilo emails the OWNER of the workspace that set up the domain, Step 2 naming who is asking and from which workspace. Approve / Deny. │ ▼ On Approve: Brilo adds the domain to workspace B already ACTIVE Step 3 (no DNS needed) and emails B's sending address a confirmation link. │ ▼ Step 4 B confirms the sending address (same email-link gate), tests, sends. STILL TRUE FOR THE SHARED WORKSPACE: it can send only once its address is verified AND the domain is active. Owner approval alone does not let it send. ``` ### Requesting access to a shared domain 1. In **Settings → Channels → Email**, click **+ Add domain** and enter the domain. If another workspace already owns it, the wizard recognizes this and offers **Request access** instead of showing an error. 2. Enter the from-address you want (e.g. `sales`), then click **Request access**. Brilo emails the owning workspace's owner to approve. Your domain list shows the request as **Requested** while you wait. 3. When the owner approves, the sending address gets the usual confirmation link (Brilo also emails you that the request was approved, and by whom). Click it to confirm the address. No DNS records are needed, because the domain was already authenticated by its owner. 4. Send a test email and you're done. If the owner denies the request, the list shows **Request denied** and you can request again. ### Approving a request (the workspace that owns the domain) If someone asks to share a domain your workspace set up, the workspace owner gets an email: *"‹Name› from ‹their workspace› wants to send email from yourcompany.com."* It links to a page with **Approve** and **Deny**. * **Approve** lets that workspace send from addresses they verify on your domain. Brilo notifies them, and they finish by confirming their address. * **Deny** rejects the request and lets them know. Under your domain in **Settings → Channels → Email** you'll see a **Shared with** line listing the workspaces you've granted. The approval link is single-use and expires after 7 days. **Two independent checks protect a shared domain.** The owner's approval is one. The requesting workspace still has to prove it controls a mailbox on the domain (the same email-link gate as a first-party setup) before it can send. Neither check on its own is enough. *** ## Requirements, rules & conditions A consolidated reference for everything that governs this flow: #### Sending is gated on two conditions A send only goes out when the **address status is `verified`** *and* the **domain (identity) state is `active`**. Either one missing blocks the send; there are no partial states that send. #### Public providers are blocked Domains on a curated list of \~57 free/consumer providers (Gmail, Outlook, Hotmail, Yahoo, iCloud, Proton, GMX, Zoho, Yandex, QQ, Naver, and regional providers like web.de, orange.fr, libero.it, comcast.net, btinternet.com, …) are rejected at Step 1. You must use a domain you own and can add DNS to. #### One domain has one owner, and can be shared A domain is owned by the **one** workspace that originally authenticated it (the one that added the DNS records). Other workspaces can't claim it as their own, but they can **request to share** it: the owner approves by email, and the shared workspace then skips DNS and just confirms a sending address. See [Sharing a domain across workspaces](#sharing-a-domain-across-workspaces). #### Your existing (human) mail is never touched Brilo's records live where they can't collide with your human email: DKIM uses named selectors, and the MX + SPF live on a dedicated `send.yourcompany.com` MAIL FROM subdomain. Your **apex** `MX`, `SPF`, and existing `DMARC` (Google Workspace, Microsoft 365, etc.) are unchanged. Brilo only *suggests* a DMARC record at `_dmarc` when you don't already publish one, and never overwrites an existing policy. #### What each record is for * **DKIM** (3 CNAMEs) — signs your mail so receivers can verify it came from you. * **SPF** (MX + TXT on `send.`) — authorizes Brilo's sending host for your domain, aligned to your domain rather than `amazonses.com`. * **DMARC** (`_dmarc` TXT, optional) — publishes a policy so strict receivers (Microsoft/Outlook especially) trust you as an accountable sender. DKIM alone passes DMARC alignment, so the domain activates on DKIM. SPF and DMARC are not required to *send*, but a cold domain without them is what gets filtered to spam, so adding all of them is strongly recommended. #### Replies go to your existing inbox Because your domain's `MX` still points at your own mail host, a reply to `sales@yourcompany.com` lands in **your normal inbox**, not back to the agent. In this version, bring-your-own-domain is **send-only**: a human handles replies. Agent-handled inbound replies are a separate, future capability. #### Pick a dedicated address, not a person's Prefer a purpose address like `sales@`, `support@`, or `ai@` over a real employee's exact address (e.g. a human Sarah's `sarah@`). Sending agent mail as a real person mixes the agent's replies with their personal mail. #### Reputation: root vs. subdomain (optional) Sending from your root domain (`sales@yourcompany.com`) is fine for low-volume conversational mail. For higher-volume outreach, consider a dedicated subdomain you also own (`sales@mail.yourcompany.com`) to isolate the agent's sending reputation from your employees' human email. The setup flow is identical either way. #### Limits and timing * Confirmation link: **single-use, expires in 24 hours.** * Confirmation emails: **3 per hour, 10 per day** per workspace. * DNS propagation: typically minutes, sometimes a few hours. Verification runs automatically in the background; **Check now** forces an immediate poll. #### Removing a domain or address Deleting a **domain** removes it from Brilo and tears down its sending identity (including the DKIM records on Brilo's side); your DNS records become inert and can be deleted at your provider. Deleting a single **address** leaves the domain verified. Both can be re-added later. If the domain is **shared** across workspaces: a workspace that was *granted* access can remove it from its own workspace at any time, and that only drops that workspace's access (it never affects the owner or any other workspace, and never touches DNS). The **owner** can't remove a domain while other workspaces still share it, so the shared workspaces stay protected; contact [support@brilo.ai](mailto:support@brilo.ai) if you need to fully retire a shared domain. *** ## Common issues You entered a free/consumer email domain (gmail.com, outlook.com, yahoo.com, etc.). Those can't be authenticated because you don't control their DNS. Use a domain your business owns and can edit DNS for, like `yourcompany.com`. 1. Check the spam/junk folder of the **exact** address you entered. 2. Confirm you typed the address correctly (a typo sends the link to the wrong mailbox). 3. Use **Resend email** in the wizard. Note the limit of 3 per hour / 10 per day per workspace. 4. Links expire after 24 hours, so if it's been longer, resend for a fresh one. The confirmation link is single-use and expires 24 hours after it's sent. Reopen the wizard for that domain and click **Resend email** to get a new link, then click it within 24 hours. Brilo hasn't seen the DKIM records verify yet. Check, in order: 1. **All three** CNAME records are added at your DNS provider, for the right domain. 2. The **Name** isn't doubled up (some providers auto-append your domain; see the warning in Step 3). 3. Each record's **Value** matches exactly (`.dkim.amazonses.com`), with no trailing dots or extra characters added by the provider. 4. Give it time, since propagation can take a few hours, then press **Check now**. Another Brilo workspace already owns this domain. You don't have to start over: click **Request access**, and the owning workspace's owner can approve sharing it with you. Once approved, you skip DNS and just confirm your sending address. See [Sharing a domain across workspaces](#sharing-a-domain-across-workspaces). If you don't know who owns it, contact [support@brilo.ai](mailto:support@brilo.ai). 1. Check the workspace owner's spam folder (the test always goes to the workspace owner, not to you). 2. **If the owner is on Microsoft/Outlook**, also check the organization-level **quarantine** (Microsoft 365 Defender → *Email & collaboration* → *Quarantine*), not just the Junk folder — Microsoft often quarantines a brand-new domain's first messages there silently. Make sure you added the **Enable Sending** records (the `send.` MX + SPF and the `_dmarc` DMARC), not just DKIM, then send again. 3. A brand-new domain has no sending reputation yet, so the first few messages can be filtered even with perfect authentication. It settles after a small volume of real sends. 4. If you saw a message about **sandbox mode**, the account can only send to verified recipients until it has production access. That's a provider-side setting, not your domain. 5. DKIM/SPF may still be propagating; wait a few minutes and press **Send test email** again. Brilo could no longer verify the domain. Usually the DKIM records were changed or removed at your DNS provider, or the mail provider lost verification. Re-add the three CNAME records exactly as shown and press **Check now**. If it persists, contact support. That's expected in this version. Your domain's `MX` still points at your own mail host, so replies land in your normal inbox and a human handles them. Bring-your-own-domain is send-only for now; agent-handled inbound replies are a separate upcoming feature. *** ## Need help? Reach us at [support@brilo.ai](mailto:support@brilo.ai) with your domain and a description of where you got stuck, and we'll get you sending.