Between owning a domain and being able to send from it sits a dozen DNS records. Infrabox closes that gap inside the same job that buys the domain, for one domain or for fifty.
- 0+
- TLDs available to search and register
- 0 min
- Median purchase to fully published zone
- 0.0%
- Domains passing SPF and DKIM on first check
Search bar to resolving records.
Four stages, and three of them finish before a registrar dashboard would have loaded.
Step 1: Search or attach
Search across 40+ TLDs, or hand over a domain you already own by repointing its nameservers or dropping in a verification record.
Step 2: The zone is drafted
SPF, DKIM, DMARC, MTA-STS and BIMI are written for that specific domain the moment it attaches: nothing hand-typed, no selector copied wrong.
Step 3: Records go live
Infrabox writes them straight into the zone when it holds DNS, or hands you an exact copy-paste list when your registrar stays external.
Step 4: Then queried back, forever
Every record is re-resolved on a schedule, so a failed lookup becomes an alert instead of becoming a bounce.
One zone-writing path, whatever the domain came from.
A domain you bought here and a domain you have owned for six years run through the same job: same records, same checks, same rollup.
Bought here or owned for years: same pipeline
Attach a domain you already run or register new ones across dozens of TLDs. From the first record onward, neither one is a special case.
DNS you never hand-edit
Records, forwarding with tagging and masked redirects change across hundreds of domains in a single action: seconds, not a support ticket.
Fifty domains move as one job
Queue a batch and watch each domain cross from purchase to verified in the same run, with anything that stalls named individually.
A bad domain cannot hide in a long list
DNS, authentication and blocklist state for every domain roll into one grid, so the row that is failing is the row you see first.
Client domains never share a namespace
Domains group by workspace, each with its own DNS, billing and access, so nothing bleeds from one client portfolio into another.
Attach the domain. The zone writes itself.
Attaching or registering a domain generates SPF, DKIM, DMARC, MTA-STS and BIMI in one pass, publishes them, then queries them back on a schedule, because the record that breaks you is the one somebody edited two quarters ago.
One include, one lookup
A single TXT record at the root authorizes Infrabox senders (v=spf1 include:_spf.infrabox.software ~all), which costs one lookup and leaves you nowhere near the ten-lookup SPF ceiling.
A key pair per domain, never shared
Each domain gets its own DKIM key pair; the public half publishes at a dedicated selector, such as ibx1._domainkey.yourdomain.com.
DMARC starts at p=none and tightens
Published at _dmarc, it stays observational while alignment is watched, then moves to p=quarantine or p=reject once the domain has clean history behind it.
MTA-STS and BIMI re-checked, not set and forgotten
A policy file and a matching _mta-sts TXT record enforce transport security; BIMI publishes a logo reference once DMARC is enforced. Both are re-queried every six hours.
What buyers ask about the domain layer
Yes. Repoint the nameservers at Infrabox and we write the zone, or leave DNS where it is and publish the records we generate. Verification and monitoring are identical either way; only the write step differs.
Fifty per job, so a large run stays reviewable line by line. Queue as many jobs as you need; they run in parallel rather than one after another.
Re-verification runs every six hours. A missing or altered record raises an alert in the console and, if you have enabled it, a signed webhook to your own systems.
Yes. A subdomain carries its own SPF, DKIM and DMARC and builds reputation independently of the parent, which is how you keep outbound away from the domain your invoices go out on.
They stay yours. Every domain is registered to your legal entity, transfer locks come off on request, there is no exit fee, and the zone we wrote travels with the domain.
What lands in your zone.
The exact rows, the exact hosts, and the TTLs we set them to.
SPF
- Type
- TXT
- Location
- domain root (@)
- Typical TTL
- 3,600s
DKIM
- Type
- TXT
- Location
- <selector>._domainkey
- Typical TTL
- 3,600s
DMARC
- Type
- TXT
- Location
- _dmarc
- Typical TTL
- 3,600s
MTA-STS policy
- Type
- HTTPS + TXT
- Location
- _mta-sts + policy file
- Typical TTL
- 86,400s (policy max_age)
BIMI
- Type
- TXT
- Location
- default._bimi
- Typical TTL
- 3,600s
| Record | Type | Location | Typical TTL |
|---|---|---|---|
| SPF | TXT | domain root (@) | 3,600s |
| DKIM | TXT | <selector>._domainkey | 3,600s |
| DMARC | TXT | _dmarc | 3,600s |
| MTA-STS policy | HTTPS + TXT | _mta-sts + policy file | 86,400s (policy max_age) |
| BIMI | TXT | default._bimi | 3,600s |
TTLs shown are Infrabox defaults. A domain left at an external DNS host propagates on that host's schedule, not ours.
Stop treating DNS as a manual step.
Attach or register your first domains and watch every record publish and resolve inside the same run.