Published by SoftHire Systems 2026 edition — covers Google Workspace 2023 MX consolidation, Squarespace/Google Domains migration aftermath, and the modern multi-sender SPF problem

---

About this guide

You bought a domain. You set up a website. Then you tried to add email. Somewhere between MX records and DKIM selectors, something snapped. Your email goes to spam. Your support ticket got closed with "please wait 48 hours for propagation." Three days later you opened a second ticket. A different rep told you to wait another 48 hours.

You are not the problem. The system is genuinely confusing — three different companies each control one piece (your domain registrar, your DNS host, your email host), and none of them will tell you which one is broken. Each one points at the others. Most small business owners give up and either pay an IT consultant $400 to fix it in an hour, or live with broken email for months.

This guide is the IT consultant's hour, written down. It explains DNS in plain English, walks you through the six most common setup scenarios with exact record values, and gives you a troubleshooting flowchart for the twelve most common failures.

Who this is for: solo founders, freelancers, agencies, and small service businesses (1-15 people) who run their own domain + email setup. If you have an IT department, you don't need this. If you're running anything involving Active Directory, Microsoft Exchange on-premise, or HIPAA-bound mail flow, you should hire a specialist — and the closing section tells you when.

What this guide is not: it is not professional IT advice. DNS changes affect production systems. Test in a staging environment when possible. SoftHire Systems is not liable for downtime or delivery failures from following this guide — the responsibility for production DNS changes always sits with the person clicking save.

What you should expect: after reading Part 1, you'll understand the mental model. Part 2 explains the eight concepts that trip people up. Part 3 is six end-to-end setup scenarios with copy-paste record values. Part 4 is the troubleshooting flowchart for when something is already broken. Part 5 is the monthly 15-minute deliverability check.

The whole point is that the next time you change a CNAME and your email stops working, you spend 30 minutes diagnosing instead of three days.

---

How to use it

Read Part 1 once. It's about 15 minutes. You'll have the mental model after that.

Use Part 3 (setup walkthroughs) for your specific scenario. Each walkthrough is end-to-end — domain registrar through verification.

Bookmark Part 4 (troubleshooting). When something breaks, start at the symptom and follow the diagnosis tree.

Part 5 is a monthly checklist. Fifteen minutes once a month catches deliverability problems before your customers tell you about them.

Appendix A has copy-paste record templates for five common stacks. Appendix B is the vendor support cheat sheet — what to actually say to GoDaddy / Squarespace / Google support to get past tier-1. Appendix C is the glossary.

---

Part 1 — DNS in plain English

Three companies are usually involved in your domain and email setup. Most owners think one company is doing everything, and that's the source of 80% of confusion.

1.1 The three roles — and why they get conflated

Your domain registrar is the company you bought the domain from. They are the legal owner of the lease on your domain (which is technically rented from ICANN through the TLD operator). GoDaddy, Namecheap, Squarespace (formerly Google Domains), Porkbun, Cloudflare Registrar — these are registrars.

The registrar's only required job is to keep your domain registered and tell the internet which nameservers are authoritative for it. That's it. They don't run your website. They don't deliver your email. They just tell the internet "for this domain, ask these nameservers."

Your DNS host is the company running the nameservers your registrar points at. The DNS host is the company you go to when you want to add, change, or delete a DNS record (MX, A, CNAME, TXT, etc.). By default, your registrar is also your DNS host — but you can change this. Many people point GoDaddy domains at Cloudflare DNS, for example, because Cloudflare's DNS is faster and free.

Your email host is the company actually receiving and storing your email. Google Workspace, Microsoft 365, Fastmail, ProtonMail, ImprovMX (forwarding only), Cloudflare Email Routing (forwarding only). The email host gives you MX, SPF, and DKIM record values that have to be configured at your DNS host.

You can have three different companies for these three roles. The most common small business stack:

• Registrar: GoDaddy (where you bought the domain)
• DNS host: Cloudflare (because it's faster and free)
• Email host: Google Workspace (because your team likes Gmail)

When email breaks, the first question is: which of these three is broken? Most support reps won't tell you. GoDaddy support will say "your nameservers are pointing to Cloudflare, contact them." Cloudflare will say "your MX records are for Google, contact them." Google will say "your DNS doesn't resolve to us yet, contact your DNS host." This is the loop. We'll show you how to break out of it.

1.2 The seven DNS record types small businesses encounter

DNS has many record types, but you only need to understand seven.

A record. Maps a name to an IPv4 address. The most basic record. softhireapp.com A 76.76.21.21 says "when someone asks for softhireapp.com, give them 76.76.21.21." Used for website hosting.

AAAA record. Same as A but for IPv6. Most small business sites don't strictly need AAAA. Modern hosts add them automatically when you set up the A.

CNAME record. Maps a name to another name. www.softhireapp.com CNAME softhireapp.com says "when someone asks for www, send them to the same place as the root domain." Used for subdomains pointing at services (like app.yourdomain.com CNAME cname.vercel-dns.com). Important rule: a CNAME cannot coexist with any other record at the same name, which is why you cannot put a CNAME at the apex (root) of your domain — the apex has to have NS and SOA records by definition.

MX record. Mail Exchanger. Tells the internet where to deliver email for your domain. MX records have a priority number — lower priority is preferred. Multiple MX records is normal (it's a failover list). For Google Workspace, you have either one MX (smtp.google.com) on new setups, or five MX records on older setups (ASPMX.L.GOOGLE.COM and four ALT variants).

TXT record. Free-text record. Used for three main things: domain verification (proving you own the domain to Google, Stripe, Apple, etc.), SPF records (which servers are authorized to send email for your domain), and DMARC records (your email authentication policy). DKIM records are also TXT records.

SRV record. Service record. Mostly used for VoIP phones, Microsoft 365 services like Skype for Business / Teams, and a few specialized protocols. You'll rarely touch SRV records on a small business site — when you do, the vendor gives you the exact values.

NS record. Nameserver record. Tells the internet which DNS hosts are authoritative for your domain (or a subdomain). When you change nameservers at your registrar, you're updating the NS records that the TLD operator stores about your domain. You can also use NS records to delegate a subdomain to a different DNS host (e.g., app.yourdomain.com could be delegated to a completely separate DNS host while the rest of the domain stays where it is).

That's it. Seven types cover 99% of what you'll touch.

1.3 Propagation and TTL — why "wait 24-48 hours" is real

DNS is cached. Everywhere. Your ISP caches DNS. Your operating system caches DNS. Your browser caches DNS. When you change a record, the new value has to reach all those caches before everyone in the world sees it. This is propagation.

Each DNS record has a TTL (time to live), measured in seconds, that tells caches how long they're allowed to remember the old value. A typical TTL is 3600 seconds (1 hour) or 14400 (4 hours). When you make a change, the worst case is the longest TTL — caches that pulled the old record just before your change get to hold it until the TTL expires.

In practice, most propagation happens within 1-4 hours. Some stragglers (ISPs with aggressive caching, mobile carrier DNS) can hold an old value for 24-72 hours. This is real and unavoidable. The "wait 48 hours" advice is correct, even though it feels like a cop-out.

Pro tip: before making a planned change, lower the TTL on the record to 300 (5 minutes) about 24 hours ahead of time. After the 24 hours, propagation has happened on the low TTL value, so the actual change will roll out in 5 minutes. After the change is stable, raise TTL back to 3600 for performance.

Diagnostic tools that ignore caches:

• mxtoolbox.com/SuperTool.aspx — type dig:yourdomain.com or mx:yourdomain.com to query authoritative DNS directly
• Google's Dig tool in the Admin Toolbox (toolbox.googleapps.com/apps/dig/)
• The command dig +trace yourdomain.com MX from a terminal walks from root nameservers down

These bypass cache and show you what's actually published, not what your laptop happens to remember.

1.4 The handoff problem — who controls what

Here is the question that 90% of broken DNS situations come down to: which company is your DNS host right now?

To answer:

1. Go to whatsmydns.net or use mxtoolbox.com/SuperTool.aspx
2. Look up your domain's NS records
3. The result tells you the nameservers

Example: NS records of ns-cloud-a1.googledomains.com means your DNS host is Google Cloud DNS (likely a legacy Google Domains setup or migrated to Squarespace). NS records of harry.ns.cloudflare.com means Cloudflare. NS records of ns1.namecheaphosting.com means Namecheap. NS records ending in domaincontrol.com means GoDaddy.

Whichever company runs those nameservers is where you go to add MX records or any other DNS record. Adding records anywhere else doesn't work — those records will be ignored.

The migration trap. Many small businesses moved domains from Google Domains to Squarespace in late 2023 / mid 2024. After migration, domains that used Google's DNS continued using it — but you cannot edit DNS records in the Squarespace dashboard if the domain is still on Google's DNS. You have to either move DNS hosting to Squarespace's own DNS, or move it to a third party like Cloudflare. Multiple users reported being trapped in support loops because Squarespace and Google each claimed the other was responsible. This is the migration trap. If you have a domain that came from Google Domains, check your NS records first.

The same applies to anyone who set up Cloudflare in front of their domain at some point and forgot. Cloudflare's free tier silently changes you to its nameservers when you "add a site." If your nameservers point at Cloudflare, anything you change at your registrar's DNS panel is ignored.

Rule: edit records at the company whose nameservers are listed in your NS records. Nowhere else.

---