Skip to main content
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.
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).

​
How it works

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): 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. 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:

​
Enable Sending (SPF & DMARC)

SPF — an MX + TXT on the dedicated send. subdomain, so SPF authenticates your domain without touching your apex SPF: DMARC (optional) — suggested only if you don’t already publish a policy: 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, <token>._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, <token>._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.

​
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.

​
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 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 (<token>.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. If you don’t know who owns it, contact 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 with your domain and a description of where you got stuck, and we’ll get you sending.