Add, edit, and delete DNS records for a domain managed by Brimble. This guide covers the dashboard UI; for the supported record types and field shapes, see DNS record types.
Prerequisites
- A domain in your Brimble account, with nameservers set to
ns1.brimble.io and ns2.brimble.io. If your domain is using external nameservers, the records you add in the Brimble dashboard won’t take effect, you have to manage records at the external provider instead.
Open the records UI
- In the dashboard, go to Domains and open the domain.
- Click the DNS tab.
The records table shows every record on the domain, with type, host, value, TTL, proxy state, and per-row edit/delete actions.
Add a record
- Click Add record.
- Fill in:
- Type,
A, AAAA, CNAME, MX, TXT, NS, SRV, or CAA.
- Name, the subdomain. Use
@ for the apex (root) domain. Use www, api, etc. for subdomains.
- Value, the record’s answer (IP, hostname, text, etc., depending on type).
- TTL, defaults to Auto (3600 seconds). Pick a shorter value if you’re about to make changes.
- Proxied, only available on
A and CNAME. When on, traffic for the host routes through Brimble’s edge (with TLS, edge rate limits, and the origin IP hidden). When off, the record returns the raw value.
- Click Save.
The record is published to Brimble’s authoritative DNS within seconds, but resolvers cache the previous answer up to its TTL.
Edit a record
Click the pencil icon next to a record. The edit form is identical to the add form, with values pre-filled. Save changes when done.
Delete a record
Click the trash icon next to a record and confirm. There’s no undo, re-add the record if you delete by mistake.
Common patterns
Apex and www pointing at the same project
@ A <edge IP from Add Domain dialog> (proxied: on)
www CNAME gateway.brimble.app (proxied: on)
For DNS providers that support apex CNAME flattening / ALIAS at the apex (Cloudflare, Route 53, DNSimple), you can use @ ALIAS gateway.brimble.app instead of an A record. Brimble’s authoritative DNS handles apex CNAMEs by synthesizing the right A record automatically.
Email through Google Workspace
@ MX 1 ASPMX.L.GOOGLE.COM
@ MX 5 ALT1.ASPMX.L.GOOGLE.COM
@ MX 5 ALT2.ASPMX.L.GOOGLE.COM
@ TXT "v=spf1 include:_spf.google.com ~all"
Don’t proxy MX records, they’re SMTP, not HTTP.
Domain ownership verification
Most third-party services (Google Search Console, Stripe, GitHub) verify with a TXT record on the apex:
@ TXT "google-site-verification=abc123..."
Add the record they give you exactly as written, including the quotes if shown.
Allow Let’s Encrypt to issue certs (CAA record)
Most domains don’t need a CAA record. If you have one and Let’s Encrypt isn’t listed, certificate issuance fails. Either remove the CAA record or add Let’s Encrypt:
@ CAA 0 issue "letsencrypt.org"
SRV record (e.g. for XMPP, SIP, Matrix)
_xmpp-server._tcp SRV 10 5 5269 jabber.example.com
The SRV value format is priority weight port target.
TTL guidance
| TTL | Use when |
|---|
| 300 (5 min) | About to make a change. Lower TTL ahead of time so the change propagates fast. |
| 3600 (1 hour) | Default. Reasonable for most records. |
| 86400 (1 day) | Stable records you don’t expect to change. Reduces DNS load. |
After making a change, raise the TTL back up once you’re confident.
Proxied vs not
| Proxied | Use for |
|---|
| On | Records that point at a Brimble-hosted service (A or CNAME). Gets you free TLS, edge rate limits, and hides the origin IP. |
| Off | Records pointing at non-Brimble services. Mail records (MX, TXT for SPF/DKIM/DMARC), never proxy these. SaaS verification records. |
Only A and CNAME can be proxied. Other types are always served raw.
When records aren’t taking effect
The most common reason is that the domain isn’t actually using Brimble’s nameservers:
dig your-domain.com NS +short
If you don’t see ns1.brimble.io and ns2.brimble.io, your records live at whatever nameservers dig returned, not at Brimble. Either delegate the domain to Brimble’s nameservers, or manage records at the external provider.
If nameservers are correct but a record still seems wrong, check propagation from public resolvers:
dig @1.1.1.1 your-record.example.com +short
dig @8.8.8.8 your-record.example.com +short
If those return the new value, you’re done, local caches will refresh once their TTL expires.
Next steps
Last modified on May 18, 2026