Domain setup troubleshooting¶
You followed the walkthrough, saved the records, clicked Re-check… and something says "missing" or "mismatch" or just sits on "pending" forever. This page is for those moments.
If reading isn't helping, skip to Ask for help — the in-app modal sends us your exact DNS state so we can diagnose without back-and-forth.
Verdict badges, decoded¶
After Re-check DNS (the button at the top of the Domain Setup page), each record gets one of four badges:
| Badge | What it means | What to do |
|---|---|---|
| VERIFIED | All three public resolvers (Google, Cloudflare, Quad9) returned the expected value. | Nothing — you're done with this record. |
| MISMATCH | The record exists, but the value doesn't match what we expect. | Re-paste the value from the Mission Broadcast table; check for accidental quotes, trailing spaces, or copy from the wrong row. |
| PROPAGATING | Some resolvers see the record, others don't. | Wait 5-15 minutes. This usually clears on its own. |
| MISSING | None of the three resolvers found the record at all. | The record probably wasn't saved at the registrar. Re-check the panel at your registrar; common causes below. |
Vendor 'Pending' vs our 'Verified' can disagree
Brevo and SendGrid have their own caches that refresh every 5-30 minutes. If our resolver check says verified but the vendor card still says Pending, trust ours — the vendor will catch up. The opposite (vendor green, our check red) is rarer and usually means a resolver hiccup.
Common reasons records say "missing"¶
You typed the host wrong¶
Different registrars want the host field in different forms:
- GoDaddy, Squarespace Domains want
@for the apex and bare labels for subdomains (em123, notem123.elderpehrson.com). - Namecheap wants the host field blank for A/MX at the apex but
@for CNAMEs (you can't blank a CNAME host). - Cloudflare accepts both
@and the full FQDN; in their UI, the host gets rewritten to the FQDN after save. - Porkbun, Name.com, Hover mostly tolerate either form.
If you picked your registrar from the dropdown in the Domain Setup page, the Host column in each table is already showing the registrar's preferred form. Use that exactly.
You pasted into the wrong field¶
Especially for TXT records, the long value (with quotes, semicolons, commas) is fragile:
- Don't include surrounding quotes — the registrar adds them.
- Don't trim trailing periods on subdomains.
- Don't trim whitespace inside the value if it's part of the spec (some DKIM keys break on it).
The safest path: click the value cell in the Mission Broadcast table (it copies the canonical literal to your clipboard), then paste into the registrar's value field without retyping.
Your registrar has a cache¶
Some registrars (Bluehost is the worst offender) take 10-15 minutes even after "save" before the records actually appear in DNS. Click Re-check DNS every few minutes; if a record stays MISSING for an hour, something else is wrong.
TTL is too high¶
If you had an old A record with a 24-hour TTL and you replaced it with the new Firebase Hosting one, some resolvers may still serve the old value until that 24-hour cache expires. During setup, use TTL 300 (5 minutes). You can raise it after everything verifies.
Common reasons records say "mismatch"¶
Your registrar appended quotes to a TXT record¶
Some registrar UIs (older ones especially) wrap TXT values in extra
quotes automatically — so what you saved as v=DMARC1; p=quarantine
becomes "v=DMARC1; p=quarantine" in DNS. Most resolvers handle this
fine, but some don't. Re-save the value without the quotes if you can,
or contact your registrar's support.
You have an existing SPF record¶
A domain can only have one SPF TXT record (v=spf1 ...). If your
domain is already used for outbound mail elsewhere (a parent's Google
Workspace at the apex, for example), saving Mission Broadcast's SPF
makes a second one — and DNS validators reject the whole pair.
The fix: merge them. The combined record looks like:
Replace _spf.google.com with whatever your existing service uses;
keep include:spf.sendinblue.com (that's Brevo) from the Mission
Broadcast table. Save one merged record. If you're not sure how to
merge, ask for help and we'll write it for you.
Your MX record points somewhere else¶
If MX @ ... says MISMATCH and the value we see is something like
smtp.google.com or mail.bluehost.com, your registrar shipped a
default MX or you have another email service on the same domain.
Inbound mail to letters@<your-domain> will bounce until this is
resolved. Options:
- Delete the existing MX and use SendGrid's exclusively (best if you don't use the domain for human-readable email).
- Use a subdomain for inbound (
letters@mail.yourdomain.com). This isn't currently a one-click option — contact us if you need it.
When setup is taking forever¶
After 30 minutes without progress, the Domain Setup page shows an amber "Still pending after 30 minutes" banner with a one-click link to ask for help. The escape hatch is right there — use it.
If you'd rather try a bit longer:
- Click Re-check DNS explicitly (don't trust auto-poll if the tab was backgrounded — we pause polling on hidden tabs to save query budget).
- Verify your registrar actually saved the records. Some panels show unsaved drafts that haven't actually been published.
- Check whether your IT department or VPN forces a different DNS server. The auto-poll uses public resolvers; your browser uses whatever DNS your network sets.
DNS drift alerts¶
Once your domain is fully verified, Mission Broadcast runs a daily health check at 0:00 UTC. It re-queries the public resolvers for every record we expect and tracks per-record state.
If a record that used to be verified stops resolving for two consecutive days, you'll get an email titled:
Heads up: a DNS record for
<your-domain>isn't resolving anymore
The email tells you:
- Which record (type, host, expected value)
- What it powers (outbound, inbound MX, hosting, etc.)
- The likely impact (e.g., for MX: "letters@ will bounce")
- A link to the Domain Setup page to fix it
One email per record per 7 days, so a long outage doesn't become spam. The Dashboard and Domain Setup pages also show a persistent red banner until the record returns to verified.
Why two consecutive bad runs?
Public DNS resolvers occasionally fail to answer for a few minutes (cache evictions, network blips, the resolver's own hiccups). A single bad-run threshold would email you every time one of those happens. Two consecutive 24-hour runs almost always means a real problem — typically a registrar dashboard glitch, an expired domain, or someone in the family edited DNS by mistake.
Ask for help¶
The Domain Setup page has a Stuck? Ask for help button at the bottom. The button opens a modal that:
- Pre-fills a snapshot of your current DNS state — which records are verified, which are missing/mismatching, your selected registrar, how long you've been at it.
- Asks one free-text question: "What have you tried?"
When you submit, the email lands in a real human's inbox and includes the full DNS dump grouped by vendor. We reply within two business days (often within a few hours).
Use it generously. It exists precisely because some DNS fights aren't worth solo time — a quick look from someone who's seen the specific gotcha before saves you an evening.
What we can't see
The help request doesn't include your registrar credentials, your domain's WHOIS info, or anything else from outside the Mission Broadcast app. We only see what's already in your missionary doc: the domain, the selected registrar slug, and the DNS verdicts from our resolver check.
Still stuck?¶
If the in-app help doesn't resolve it, email us directly at support@missionbroadcast.com. Reply within two business days.