This guide is focused on DNS record hygiene inside the HostBible Zone Editor:
detecting and removing duplicates
resolving CNAME conflicts
fixing incorrect hostnames / formatting mistakes
cleaning up mis-set or inconsistent TTLs
Not covered in this article: changing nameservers at your registrar, propagation/caching behavior, or DNSSEC DS updates.
When should you do a DNS cleanup?
Use this workflow when:
you imported a zone (zone file, copy/paste, bulk add) and now see repeated or messy entries
your site/email/verification worked before, but the HostBible zone now contains “extra” records you don’t recognize
you see obvious formatting oddities like
www.example.com.example.comyou want a more consistent, maintainable TTL strategy (without chasing one-off values)
Before you start: define what “correct” looks like
A cleanup goes fastest if you know which services the domain should support. Make a simple checklist like:
Website: root (
@) and/orwwwEmail: MX + SPF/DKIM/DMARC (if used)
App/verification: TXT records (ownership checks, app verification)
Special subdomains:
api,app,blog,mail, etc.
Safety tip: Before editing, copy the current record list somewhere safe (notes doc). If your HostBible Zone Editor has an export/copy feature, use it.
Open the HostBible Zone Editor
Log in to HostBible
Go to your domain’s management page
Open DNS → Zone Editor (wording may vary slightly)
You should see a list of records with columns like:
Name/Host
Type (A, AAAA, CNAME, MX, TXT, etc.)
Value/Target
TTL
Actions (Edit/Delete)
Step-by-step cleanup workflow
1) Start with the “money records”: root and www
These two names are where conflicts and duplicates show up most often.
What to look for
Multiple records at
@(root) that you didn’t intendwwwhaving both a CNAME and an A/AAAA recordwwwpointing somewhere unexpected (old IP, old hostname)
Why it matters
If @ or www contains conflicting or duplicated data, users may land on the wrong destination (or get inconsistent results depending on which answer is returned).
2) Detect duplicates (true duplicates vs intentional multiples)
A “true duplicate” looks like:
Same Name + Type + Value repeated, often with different TTLs.
Example (duplicate A record):
@— A —192.0.2.10— TTL 60@— A —192.0.2.10— TTL 3600
Fix: Keep one and delete the extra. Pick the TTL you want to standardize on (see TTL section below).
A “conflicting duplicate” looks like:
Same Name + Type, but different values that don’t match your intent.
Example (conflicting A records):
@— A —192.0.2.10@— A —198.51.100.25
Fix:
If you intentionally use multiple A/AAAA records (rare for simple setups), confirm they are correct.
If not intentional, remove the outdated destination.
Special note: multiple records can be valid
Some record types commonly have “multiple” entries on purpose:
MX: multiple priorities for failover
TXT: several unrelated TXT records can exist at the same name (but duplicates are still bad)
A/AAAA: can be multiple, but should be deliberate
Quick duplicate cleanup rule
If you can’t explain why a record exists, treat it as suspicious and verify it before keeping it.
3) Fix CNAME conflicts (a very common zone-breaker)
The rule
A CNAME record should be the only record at that exact name.
If a hostname has a CNAME and also has another record type (A/AAAA/TXT/MX/etc.), that’s a conflict. Many DNS systems will ignore one of them or behave unpredictably.
Common conflict pattern: www
Problem example:
www— CNAME —@www— A —192.0.2.10
Why it’s a problem: www is trying to be both an alias (CNAME) and a direct address (A).
Fix (choose one approach):
Keep www CNAME → @ or
Keep www A/AAAA → your destination
…and delete the other record(s).
Another conflict pattern: “verification TXT” on a CNAME name
Problem example:
shop— CNAME —some-target.example.netshop— TXT —verification=...
Fix: Verification TXT usually needs its own compatible name. Either:
move verification to a different hostname that does not use CNAME, or
replace the CNAME approach if the TXT is required at that exact name
(If you’re unsure which one your service needs, check the instructions from the service you’re integrating with.)
4) Correct common hostname formatting mistakes
Formatting mistakes usually show up after imports or when records were copied from a different format.
Mistake A: Double-appended domains
Problem you might see in the record list or preview:
www.example.com.example.com
Why it happens: The editor is treating what you typed as a relative name and appending the zone name again.
Fix: Use the short host label:
Use
www(notwww.example.com)Use
@(or the zone’s “root” option) for the apex/root record
Mistake B: Putting http:// or https:// into record values
DNS records never include URL schemes.
Wrong: https://app.example.com
Right: app.example.com (for CNAME targets) or an IP address (for A/AAAA)
Mistake C: Trailing dots handled inconsistently
Some DNS inputs use a trailing dot to indicate a fully-qualified name (FQDN), like target.example.com.
Hygiene tip: Whatever HostBible accepts, keep it consistent. If you notice some CNAME targets have a trailing dot and others don’t, standardize to one style so you avoid accidental mismatches during future edits.
Mistake D: Underscore records typed incorrectly (very common for email/security)
Records like these must be exact:
_dmarcselector1._domainkey_acme-challenge
Common errors:
missing underscore (
dmarcinstead of_dmarc)placing it under the wrong name (e.g., adding
_dmarc.example.comin a field that already appends the domain)adding extra dots
Fix: Match the hostname exactly as provided by the service, then confirm the final rendered name in HostBible’s record list.
5) Audit email records for collisions (MX / SPF / DKIM / DMARC)
Even if your website loads fine, messy email records can cause silent failures.
MX record hygiene
Ensure MX records exist only where intended (usually at root
@)Remove old MX hosts you no longer use
Keep priorities sensible (lower number = higher priority)
SPF (TXT) hygiene
SPF is typically a TXT record at the root.
Duplicate SPF is a common problem:
@— TXT —v=spf1 ... -all@— TXT —v=spf1 ... ~all
Why it matters: Multiple SPF TXT records can break SPF evaluation.
Fix: Combine into one SPF policy record (only if you know what you’re doing), or remove the incorrect/old one and keep the intended single record.
DKIM hygiene
DKIM records are usually TXT at a selector name like:
selector1._domainkey
Cleanup targets:
remove unused selectors (only if you’re sure they’re no longer used)
remove duplicates of the same selector TXT record
DMARC hygiene
DMARC is TXT at:
_dmarc
Cleanup targets:
remove duplicates
ensure the policy record starts with
v=DMARC1;
6) TTL cleanup (keep this about record hygiene)
TTL isn’t just a performance knob—messy TTLs make DNS harder to maintain.
What “bad TTL hygiene” looks like
Mixed TTLs for records that should be treated similarly (some 60s, some 3600s, some 86400s)
Very low TTLs left behind from troubleshooting (e.g., 30–60 seconds) on stable, long-lived records
Inconsistent TTL strategy where no one can tell which values are intentional
Practical TTL hygiene guidelines
Pick a default TTL that fits your normal change cadence (many teams use something like 1 hour as a baseline, but your standard may differ)
Use exceptions intentionally (e.g., only a specific record needs a different TTL)
If you see multiple identical records with different TTLs, keep one record and set the TTL to your chosen standard
Goal: Consistency and clarity—so future edits don’t turn into guesswork.
7) Remove stale records you no longer use
Imports often bring in old “temporary” records that should not live forever:
old verification TXT tokens
deprecated subdomains (old
app,dev,staging)legacy mail hosts
records for services you no longer run
Safe approach: If you’re unsure, remove in small batches and document what you changed (name/type/value), so it’s easy to reverse.
Before/After example: cleaning a messy zone
Before (common post-import mess)
@— A —192.0.2.10— TTL 60@— A —192.0.2.10— TTL 3600 (duplicate)www— A —192.0.2.10— TTL 3600www— CNAME —@— TTL 3600 (conflict)_dmarc— TXT —v=DMARC1; p=none; ...— TTL 3600_dmarc— TXT —v=DMARC1; p=none; ...— TTL 3600 (duplicate)ftp.example.com— CNAME —@(name formatting likely wrong if the editor appends the domain)
After (clean + predictable)
@— A —192.0.2.10— TTL 3600 (kept one, standardized TTL)www— CNAME —@— TTL 3600 (removed the conflicting A record)_dmarc— TXT —v=DMARC1; p=none; ...— TTL 3600 (kept one)ftp— CNAME —@— TTL 3600 (fixed hostname formatting)
Quick checklist: “Zone looks wrong” cleanup
Root (
@) andwwwpoint where you expectNo exact duplicates (same Name/Type/Value repeated)
No CNAME conflicts (CNAME is not sharing a name with other record types)
Hostnames are formatted correctly (no double domain, no
https://, correct underscores)Email records are coherent (MX, SPF, DKIM, DMARC—no duplicates where they shouldn’t be)
TTLs follow a consistent strategy (no leftover ultra-low TTLs unless intentional)
Need help validating what to keep?
If you’re unsure which record is correct, the safest move is to gather:
the list of records you want reviewed (or a screenshot of the HostBible Zone Editor list)
what services the domain should run (website, email provider, verification needs)
Then contact HostBible support with that info so we can help you identify what’s safe to remove and what must remain.