DNS Setup and Management Service

What DNS actually does

Every domain name needs to be translated into a server address before a browser or email client can reach it. DNS, the Domain Name System, handles that translation. Think of it as the phone book for the internet: when someone types your domain into a browser, DNS tells their device exactly where to find your website. Whether you've just chosen a domain name for your business or you're moving an established one, DNS is the foundation. When someone sends you an email, DNS tells the sending server where to deliver it.

Without correctly configured DNS, your website won't load and your email won't arrive. It doesn't matter how good your hosting or email provider is, if the DNS records are wrong or missing, nothing works.

We configure, verify and maintain DNS for businesses that need their domains working reliably from day one, whether that's a brand-new launch, a migration from an old provider, or ongoing management as services change. If you are still in the domain negotiation stage, we can handle DNS immediately after transfer completes.

Key DNS records explained

DNS is made up of individual records, each with a specific job. Here are the ones that matter most:

Record type	What it does	When you need it
A / AAAA	Points your domain to the IP address of your web server. A is for IPv4, AAAA is for IPv6.	Every website needs at least an A record. AAAA is increasingly expected.
MX	Tells sending servers where to deliver email for your domain.	Required if you use email on your domain. Google Workspace, Microsoft 365, or any other provider.
CNAME	Creates an alias that points one name to another. Often used for subdomains like `www` or `blog`.	When you need a subdomain to resolve to a service hosted elsewhere, such as a CDN or a landing-page platform.
TXT	Holds text data used for verification and security policies, including email authentication.	Domain ownership verification (Google, Microsoft), SPF, DKIM and DMARC records.
NS	Specifies which nameservers are authoritative for your domain, effectively which DNS provider controls your records.	Set at your registrar. Changing NS records is how you move DNS management to a different provider.

Email authentication: SPF, DKIM and DMARC

If your domain sends email, even just automated receipts or contact-form replies, you need email authentication records in your DNS. Without them, three things happen:

Your legitimate emails land in spam. Mail servers use SPF and DKIM to decide whether an email is genuine. Missing records make your messages look suspicious.
Some recipients reject your emails entirely. Stricter providers (including Google and Microsoft) increasingly require authentication. No records, no delivery.
Scammers can send email pretending to be you. Without DMARC, there's no policy telling mail servers to reject spoofed messages that use your domain name. This is a real brand protection and security risk.

In practical terms:

SPF lists which servers are allowed to send email on behalf of your domain.
DKIM adds a cryptographic signature that proves the email hasn't been tampered with in transit.
DMARC ties SPF and DKIM together with a policy, telling receiving servers what to do when authentication fails (report it, quarantine the message, or reject it outright).

We configure all three as part of any DNS setup that involves email, and we verify them with external tools before sign-off.

How a domain launch or migration works

Whether you're going live with a new domain or moving an existing one to new hosting, the process follows the same disciplined sequence:

Audit existing records. We export and review every DNS record currently in place, website routing, email, subdomains, verification entries, everything. This prevents records being lost in the move.
Lower TTL values. TTL (time to live) controls how long DNS resolvers cache your records. We reduce it to a short interval, typically five minutes, a day or two before making changes. This means updates propagate quickly once we switch.
Make changes in a controlled window. Records are updated methodically, usually starting with the lowest-risk entries. For migrations, we often run old and new configurations in parallel briefly.
Verify externally. We check every record from outside your network using independent DNS lookup tools, email authentication testers and browser checks. Internal testing alone isn't enough, your local resolver may still have cached the old records.
Monitor after cutover. We watch for delivery failures, resolution errors and certificate issues for at least 48 hours after changes go live.
Restore TTL. Once everything is confirmed working, we raise TTL values back to their normal levels (typically one to four hours) for better caching performance.

What can go wrong, and how to avoid it

Email stops working. This is the most common DNS failure. Changing nameservers or hosting without recreating MX records means email silently stops arriving. We audit email records before any migration.
Website goes down during migration. If A records point to the old server before the new one is ready, or if SSL certificates haven't been provisioned on the new host, visitors see errors. We stage changes and verify before cutting over.
High TTL means changes take hours or days. If your current TTL is set to 24 hours, every resolver in the world will keep serving the old address for up to a full day after you update. Lowering TTL in advance avoids this.
Missing DMARC means spoofed emails. Without a DMARC policy, anyone can send email that appears to come from your domain. This can damage your reputation and is a common vector for phishing attacks targeting your customers or staff.
No rollback plan. If something goes wrong and you haven't saved a snapshot of the original records, recovering cleanly is difficult and slow. We always keep a full export before making changes.

When you need professional help vs DIY

Not every DNS change requires outside help. Here's a practical guide:

Simple hosting with one provider: If your registrar also hosts your website and email (e.g. Squarespace, Wix), DNS is usually handled automatically. You probably don't need us.
Multiple services or providers: If your website is on one platform, email on another, and you're using a CDN or multiple domains with redirects. DNS gets more complex. Conflicting records and missing entries are common. This is where professional setup saves time and prevents outages.
Migration from an old provider: Moving a domain that's been running for years, including domains acquired from previous owners with accumulated records, subdomains and email configurations, is where things most often break. We recommend getting help for any migration involving live email or business-critical services.
Email authentication setup: If your emails are landing in spam or you've never configured SPF, DKIM and DMARC, getting this right the first time avoids weeks of deliverability problems.

Common mistakes we see

Changing nameservers without copying records first. The new nameserver starts empty. Every record that existed on the old one, website, email, subdomains, needs to be recreated manually. Forgetting this is the number-one cause of post-migration outages.
Forgetting email records. Website A records get updated, but MX, SPF, DKIM and DMARC entries are left behind on the old provider. Email breaks silently, you won't know until someone tells you they haven't heard back.
Not lowering TTL before migration. Making changes while TTL is set to 24 hours means some visitors and email servers will keep using the old address for a full day. A five-minute TTL set 24-48 hours before migration avoids this.
No rollback plan. If you don't have a saved copy of the original DNS zone, undoing a bad change means reconstructing records from memory or support tickets. We always export the full zone before touching anything.
Setting up DMARC at p=reject immediately. DMARC should be rolled out gradually, start with p=none to collect reports, then move to quarantine, then reject, otherwise you risk blocking your own legitimate email.

Frequently asked questions

How long does DNS propagation take?

It depends on the TTL (time to live) of the records being changed. If TTL is set to five minutes, most resolvers will pick up the new value within minutes. If TTL is 24 hours, it can take up to a full day. By lowering TTL in advance, changes propagate quickly when it matters.

Can a domain migration avoid downtime entirely?

In most cases, yes. With staged cutovers, where we verify the new configuration is working before switching traffic, downtime is avoidable. The key is preparation: auditing records, lowering TTL, and testing everything before making the final change.

Do you set up SPF, DKIM and DMARC?

Yes. Email authentication is part of every DNS setup that involves email. We configure all three records, verify them with external testing tools, and provide documentation so you know exactly what's in place.

What if I already have DNS records and just need them checked?

We offer DNS audits as a standalone service. We'll review your current records, flag anything missing or misconfigured (especially email authentication), and provide a clear report with recommended changes.

Can you manage DNS on an ongoing basis?

Yes. For businesses that regularly add services, subdomains or email configurations, we offer ongoing DNS management. Changes are documented, tested and monitored, so nothing breaks silently.

What DNS providers do you work with?

We work with all major DNS providers and registrars, including Cloudflare, AWS Route 53, Google Domains, Namecheap, GoDaddy and others. If you're not sure where your DNS is currently managed, we can help you find out.

DNS setup and management service