Verify your sending domain

A verified sending domain is the one task you do before anything else in Brixus365. Once it’s done, every email feature unlocks: Spark campaigns, the Dev API, Workflows, transactional analytics, and Send Test. Brixus365’s One thing before you dive in modal points you here on first login for a reason. It takes about 5 minutes of clicks plus DNS propagation time.

---

Why you need a verified domain

Brixus365 sends email through your own domain, not from a generic platform address. That matters for two reasons:

1. Deliverability. Mailbox providers — Gmail, Outlook, Apple Mail, Yahoo — trust mail authenticated by the sending domain’s owner, not by the platform. DKIM signs each email with a key published in your DNS; SPF tells receivers which servers are allowed to send for your domain; DMARC ties them together. Without all three, your campaigns land in the Promotions tab — or the Spam folder.

2. It’s the gate. Until you have at least one verified domain, every send-side feature in the dashboard shows a Domain verification required banner. Spark’s New-Campaign wizard surfaces an alert at step 1. The Dev API rejects calls. The Welcome modal won’t dismiss. Domain verification is the first task for a reason.

---

Open Settings → Email Setup

1. Sign in to app.brixus365.com.
2. Click your account menu (top-right) → Settings, then Email Setup in the Email section of the sidebar (envelope icon).
3. The page has two cards stacked: Custom Email Domains on top, Sender Addresses below. On a brand-new workspace both are empty.

Click Add Your First Domain to open the Add Custom Email Domain dialog.

---

Add a domain

The dialog asks for one thing: the domain you want to send from.

Why a subdomain instead of your apex (example.com)? Three reasons:

• SPF apex collisions. The SPF record Brixus365 generates uses the apex of whatever domain you enter. If you already publish an SPF record on your apex (for Google Workspace, Microsoft 365, or another sending platform), the two collide — receivers see two competing records and reject all your outbound mail. Using a subdomain gives you a dedicated SPF record without disturbing your existing setup.
• Reputation isolation. If a campaign causes a sudden bounce spike, only the subdomain takes the reputation hit. Your apex (where employee email lives) is unaffected.
• Convention. mail.example.com, email.example.com, notifications.example.com are widely-recognised sending subdomains.

Set as default sending domain — check this if you only have one domain (or want this one to be the default for new campaigns and API calls). At most one domain can be the default; checking it here unsets any other.

Click Add Domain. The next dialog — Authenticate your domain — opens automatically with the message Domain added successfully!

---

Authenticate: automatically or yourself

Two cards side by side: one path lets Brixus365 set up DNS for you, the other lets you do it manually.

• Authenticate the domain automatically (Recommended badge) — Brixus365 talks directly to your DNS provider via the open Domain Connect protocol. Records are added in your provider for you; you confirm in a popup window; verification runs automatically. Works with Cloudflare, GoDaddy, IONOS, and many other providers that support Domain Connect. Takes about a minute end-to-end.
• Authenticate the domain yourself — Brixus365 shows you the 6 DNS records to add. You copy them into your DNS provider’s control panel manually, then click Verify Domain on the row. The path the rest of this guide walks. If you’re using a DNS-as-code workflow (Terraform, Pulumi, repo-managed zones), this is the option you want.

If you pick Automatically, follow the popup to your provider, sign in, approve. When you return, Brixus365 runs verification on the now-published records and flips the row’s status to Verified.

If you pick Yourself, the DNS Configuration dialog opens with all 6 records to copy.

---

The DNS records you’ll add

The DNS Configuration dialog lists 6 records. All values are pre-filled — Brixus365 generates the DKIM tokens and ownership verification code for you, so they’re unique to your domain. Use the Copy Configuration button (top-right of the dialog) to grab everything at once, or copy each record individually.

What each record does:

Record	Required?	What it does
DKIM × 3 (CNAME)	Yes	Cryptographic signature verification. Receivers fetch the public key from these CNAMEs and verify each email was signed by you. Three slots are provided so the key can rotate without downtime.
SPF (TXT, name @)	Yes	Authorises Brixus365’s mail servers to send for your domain. The ~all at the end is the standard “soft fail” recommendation.
DMARC (TXT, name _dmarc)	Optional but recommended	Tells receivers what to do when DKIM/SPF fail (p=none = report only) and where to send the daily authentication reports.
Domain Ownership (TXT, name _brixus-verify)	Yes	Proves you control the domain. Brixus365 generates a unique token per domain — the verifier checks this TXT record exists with the matching value before allowing verification to succeed.

Two notes on the DMARC record:

• The reports mailbox is generated as postmaster@<your-domain>. Make sure that mailbox actually exists — if it doesn’t, the daily reports your DNS provider sends will bounce back. You can route reports somewhere else by editing the rua= value before pasting; the verifier doesn’t check what’s there.
• p=none is a permissive starting policy. After a week or two of clean reports, harden to p=quarantine or p=reject. That’s a separate hardening exercise outside this guide.

A note on the Domain Ownership record:

The _brixus-verify TXT record is a one-time ownership proof. Brixus365 generates a unique token when you add the domain — you’ll see it pre-filled in the DNS Configuration dialog.

---

Click Verify Domain

DNS changes don’t reach receivers instantly. After you’ve added the records:

• Wait at least 10–30 minutes for typical propagation.
• For some providers and TTL settings, full global propagation can take several hours up to 24. If your first verify fails, give it an hour and retry.

In the Custom Email Domains card, your domain row shows status Pending Verification with a clock icon, plus two buttons: Verify Domain and View DNS Records. Click Verify Domain to run the check. Status flips to Verifying… while the DNS query runs (about 30 seconds), then to one of:

• Verified (cyan check) — you’re done. The status badge turns green.
• Verification Failed (red ×) — see the next section.
• Pending Verification again, with the message DNS records published, our provider is still verifying — your DNS is correct but our upstream provider hasn’t fully picked it up yet. Wait 5–10 minutes and click Verify Domain again.

Verification is manual only — there’s no background poller. Click Verify Domain each time you want to re-check. The button stays available until status is Verified.

---

If verification fails

The most common reasons, in rough frequency order:

• DNS hasn’t propagated yet. The verifier shows DNS record not found or value mismatch but the record is in your DNS provider’s control panel. Likely correct but global DNS hasn’t caught up. Wait 30–60 minutes and retry. If it’s been 24+ hours, something else is wrong.
• Wrong record type. Double-check the Type column for each record — DKIM is CNAME (not TXT), SPF and DMARC are TXT. A common mix-up: pasting the DKIM CNAME value into a TXT record. The receiver expects to follow a CNAME chain, so DKIM signature verification will fail.
• Trailing-dot oddity in CNAME values. Some DNS providers add a trailing dot to fully-qualify CNAME values, some don’t. Brixus365 normalises both, so this usually doesn’t fail — but if you see a near-match in the verifier output, copy the record fresh from the dialog and replace.
• SPF apex collision. If you already publish an SPF record on the apex of the domain you entered (e.g. for Google Workspace, Microsoft 365, or another sending platform), receivers see two competing records and fail SPF authentication. Solution: use a subdomain instead, OR merge the records into one — for example: v=spf1 include:_spf.google.com include:amazonses.com ~all.
• DMARC rua= mailbox doesn’t exist. Verification passes even if the mailbox is missing (the verifier doesn’t check), but you’ll get bounce notifications from your DNS provider’s reports. Either create postmaster@<your-domain> (forwarding to your real inbox is fine) or edit the record to point rua= at a mailbox you control.

---

What unlocks once verified

The moment your domain shows Verified, every email-side feature in the dashboard turns on:

• Sender addresses. The Sender Addresses card on the same page can now create senders on this domain (e.g. hello@mail.example.com).
• Spark campaigns. The Domain verification required alert banner disappears from the New-Campaign wizard. Send Test fires. Campaigns can launch.
• The Dev API. POST /v1/emails accepts your sender; the Send emails (transactional) scope on API keys becomes selectable. Transactional sends start working.
• Workflows. Enrolment and step-execution can dispatch.
• Transactional analytics. Inside Connect → Send History and Transactional analytics, dev-API sends start populating the dashboards.
• The Welcome modal stops appearing. The One thing before you dive in prompt on first login goes away.

---

What’s next

You want to…	Go to
Send your first email campaign	Send your first email campaign
Send a transactional email from code	Quickstart
Pick a starting template	Pick a sample template
Send a test email before going live	Send a test email