How to Verify DNS Settings for a Domain Acquired on Seda or Afternic
Verifying DNS settings after acquiring a domain on platforms like Afternic or Seda ensures your new digital asset points correctly to your web hosting, email servers, and other infrastructure. When you purchase an aftermarket domain, the previous owner's name servers, IP addresses, and routing records often remain active, which can cause downtime or misdirection of traffic. To prevent this, you need to systematically check every DNS record using command-line tools and online utilities before launching your site.
Before you begin making updates at your new registrar, you should run a comprehensive check using the DNS Lookup tool on XiaTools to instantly see which name servers and IP addresses are currently responding to global queries. This diagnostic step helps you establish a baseline and confirms whether the domain is still pointing to the marketplace's parking servers or an old hosting provider.
Understanding Aftermarket DNS States
When you buy a domain on Afternic, Seda, or similar broker networks, the domain goes through an ownership transfer process. During this transfer, the domain usually sits on a placeholder name server managed by the registrar or the marketplace. Until you update these settings and verify them globally, visitors will see a landing page instead of your content.
Marketplace settings often include specific TXT records used for domain ownership verification during the sale. Once the transfer is complete, you must remove these temporary records and replace them with production records for your website and mail exchangers (MX).
Step-by-Step Verification Workflow
Follow this structured workflow to audit and verify every aspect of your newly acquired domain's DNS configuration.
Step 1: Check Global Name Server Propagation
Name servers dictate where the authoritative records for your domain live. If these are incorrect, no other DNS changes will matter.
Open your terminal and query the start of authority (SOA) or name servers using dig:
dig NS example.com +short
Sample output:
ns1.registrar-dns.com.
ns2.registrar-dns.com.
If the output still shows the marketplace's default name servers, you need to log into your registrar account, update the name servers to your preferred hosting provider, and wait for public propagation.
Step 2: Verify A and AAAA Records for Root and Subdomains
Your root domain and www subdomain must point to your server's IP addresses. Test the IPv4 (A record) and IPv6 (AAAA record) responses.
dig A example.com +short
dig AAAA example.com +short
Sample output for documentation ranges:
192.0.2.50
2001:db8::50
Ensure these IP addresses match the server configuration provided by your web host.
Step 3: Inspect Mail Exchange (MX) and Security Records
Email delivery depends on correct MX records, alongside Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) records.
Check MX records with:
dig MX example.com +short
Sample output:
10 mail.example.com.
Check your SPF TXT record to ensure unauthorized servers cannot send email on behalf of your acquired domain:
dig TXT example.com +short
Look for a string starting with v=spf1. Missing security records are a common vulnerability for newly purchased domains.
Comparing DNS Testing Methods
| Method | Best Used For | Speed | Global Perspective |
|---|---|---|---|
| Command Line (dig/nslookup) | Quick local checks, automation | Instant | Local resolver cache only |
| Online Tools (XiaTools) | Checking global propagation, visual debugging | Instant | Worldwide recursive resolvers |
| PowerShell (Resolve-DnsName) | Windows environments, scripting | Instant | Local OS resolver cache |
Fixing Common Acquisition DNS Mistakes
Mistake 1: Ignoring TTL Caching
If you recently updated your records at the registrar but still see old Afternic parking pages, your local machine or ISP has cached the old Time-To-Live (TTL).
Fix: Flush your local DNS cache. On Windows PowerShell, run:
Clear-DnsClientCache
On macOS terminal, run:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Mistake 2: Leaving Marketplace TXT Records
Marketplaces often require verification TXT strings in your DNS zone during the escrow process. Leaving these behind clutters your zone file.
Fix: Audit your TXT records and remove any strings containing marketplace identifiers once the domain transfer is fully finalized and secured.
Mistake 3: Missing CNAME Flattening for Root Domains
Many modern hosting platforms require your root domain to point to a CNAME target, but standard DNS specifications do not allow CNAME records on root domains.
Fix: Ensure your DNS provider supports CNAME flattening or Alias records if your host requires a hostname instead of a raw IP address (192.0.2.1).
Domain DNS Verification Checklist
- Update name servers away from marketplace defaults to your host.
- Verify A records point to your current server IPv4 address.
- Verify AAAA records point to your server IPv6 address.
- Confirm MX records route mail to your active email provider.
- Implement and test SPF, DKIM, and DMARC TXT records.
- Flush local resolver caches to test live public resolution.
- Perform a final global lookup test to ensure zero propagation errors.