DNS Records Report
brex.com
We don't have a stored DNS snapshot for brex.com yet. Run a live lookup — we resolve A and AAAA addresses, MX mail routing, NS authoritatives, the SOA record, TXT entries (SPF, DMARC, BIMI, verification tokens) and check whether the zone is DNSSEC-signed.
Reading brex.com's DNS configuration
com into the IP addresses mail servers and verification metadata your browser mail client and SaaS integrations actually need. This report is a point-in-time snapshot from CheckFast's runtime recursive resolver. It does not prove authoritative answers or worldwide propagation and another resolver may retain a different cached value until its TTL expires.
The A record maps this domain to the IPv4 address where your server accepts connections. No AAAA (IPv6) record is currently published which means native IPv6 clients fall back to IPv4 transparently but miss the lower-latency native routing path. No MX record is published — intentional for send-only domains a misconfiguration for domains that need to receive mail.
The delegated nameservers hold the authoritative copy of the zone. The TXT layer carries everything else a domain advertises about itself: SPF for mail-sender authorisation DMARC reporting addresses Google and Microsoft verification tokens for Search Console and Entra ID BIMI logo references and any SaaS platform tokens accumulated over time.
We surface all of these alongside the core A AAAA and MX records so you can read the full DNS posture in a single view and spot conflicts duplicate entries or leftover tokens from services you no longer use.
Redundancy IPv6 TTLs and the things people forget
A common pattern on small and medium sites is one A record one MX host and two nameservers on the same provider — technically functional but dangerously fragile. Best practice is at minimum two A records pointing to hosts in different availability zones or a CDN-fronted anycast entry that sheds load across regions.
At least two MX hosts in different priority classes — for example priority 10 and a backup at priority 20 — give inbound mail somewhere to queue if the primary is unreachable. com from resolving at all. com becomes invisible to dual-stack health monitors misses native IPv6 routing for roughly half of EU and US client traffic and fails outright for the small but growing set of IPv6-only networks.
TTL strategy matters more than most teams realise: a TTL of 300 seconds means DNS changes propagate globally in five minutes — ideal during a migration or incident response — but generates roughly twelve times more recursive resolver queries per hour than a 3600-second TTL.
The disciplined pattern is to lower TTLs to 300 before any planned change then raise them back to 3600–86400 once the change is stable so resolvers cache efficiently without locking you in during the next migration.
DNSSEC and zone integrity for brex.com
com is not yet DNSSEC-signed meaning the zone's answers cannot be cryptographically verified by resolvers. Without DNSSEC a sophisticated attacker positioned between a resolver and your nameserver can substitute forged DNS answers redirecting users or automated services to a lookalike host with no visible browser warning.
If you operate a high-trust workload — financial services government healthcare or anything that settles transactions — DNSSEC moves from a best-practice to a compliance baseline; FedRAMP PCI-DSS and NIST SP 800-81r2 all reference it explicitly.
We also surface the SOA record so you can monitor zone integrity: the SOA serial should increment on every zone change and a secondary nameserver with a stale serial means its AXFR or IXFR replication pipeline is broken causing it to serve outdated records to every resolver that reaches it.
Use the Run live again button any time you publish a new TXT verification token add or change an MX host switch hosting providers or complete a DNSSEC key rollover — the snapshot here will capture the new state and surface propagation gaps across the authoritative nameserver set.
How brex.com's DNS compares — and what to fix first
Most domains we audit run the bare minimum: a single DNS provider two nameservers on the same network one A record pointing at one server no IPv6 and no DNSSEC. com disappears from the internet entirely because a name that won't resolve has nothing to fail over to. Users see a server not found error bots return a crawl error and search engines log the URL as temporarily unreachable.
The domains at the top of the reliability distribution look different: they run anycast nameservers from two independent providers on separate autonomous systems (for example Route 53 paired with NS1 or Cloudflare paired with a secondary zone service) publish AAAA records so IPv6-native clients get native routing sign the zone with DNSSEC end-to-end and set long TTLs on stable records so the resolver cache absorbs most queries without hitting the authoritative nameservers at all.
com: (1) add a second nameserver provider on a different autonomous system so no single provider outage can black-hole the domain; (2) add AAAA records — most cloud providers and hosting platforms support IPv6 with a single configuration change; (3) right-size TTLs — 300 seconds while actively changing records 3600 or higher once stable; (4) enable DNSSEC at the registrar last once the zone is stable and verify the DS record chain propagates correctly up to the TLD registry.
Re-run this report after each change and consider a DNS monitor to alert when the scheduled DNS audit becomes degraded or unavailable. Review the stored result to identify the specific record or DNSSEC issue.
Related reports for brex.com
Each tool runs an independent check. Combine them into a single dashboard at /check/brex.com.