Case Study — Reading the ayrisglobal Stack

Six lectures of theory, now applied to one real production setup: yours. By the end you’ll be able to read any company’s infrastructure off a few terminal commands — and you’ll understand the email-migration decision from the ground up.

⏱ ~15 min · 🔴 Advanced · Prerequisites: Lectures 1–6

🎯 What you’ll be able to do

• Map a real domain’s registration, DNS, hosting, and email from raw DNS records
• Explain why each piece is where it is
• Reason through an infrastructure migration without breaking things

Step 1 — What we can observe

A few commands reveal the whole stack (you ran versions of these already):

nslookup -type=ns  ayrisglobal.com          # who runs DNS
nslookup -type=mx  ayrisglobal.com           # where email goes
nslookup -type=mx  assure.ayrisglobal.com    # subdomain email
curl -I https://ayrisglobal.com              # who fronts the website

What they told us:

Step 2 — The stack, drawn out

                         ┌─────────────────────────────────────────┐
   Registrar: Hostinger  │  owns the NAME ayrisglobal.com            │
   (just the lease)      └───────────────────┬─────────────────────┘
                                              │ NS records delegate DNS to ↓
                         ┌────────────────────▼─────────────────────┐
   DNS + CDN: Cloudflare │  source of truth for all records          │
                         │  A/CNAME → website   ·   MX → email        │
                         └───────┬───────────────────────┬───────────┘
                                 │ web traffic            │ mail (MX)
                                 ▼                        ▼
                     Cloudflare edge → origin      Hostinger mail servers
                     (static frontend, fast)       (7 mailboxes @assure.)

The key insight this proves

Registration (Hostinger), DNS (Cloudflare), website host (Cloudflare), and email (Hostinger) are four independent choices. That’s not a mess — it’s normal, and it’s why you can change email without touching anything else. The only thing you’ll edit is MX + a few TXT records inside Cloudflare (the authoritative DNS from lecture 3).

Before you read on, prove you can actually read this stack — not just recognize the words:

Step 3 — The actual situation (from the dashboards)

• One registered domain: ayrisglobal.com (auto-renew currently OFF ⚠️ — lecture 2 says fix this).
• All mail lives on the subdomain assure.ayrisglobal.com, on Hostinger’s “Free Business Email” plan expiring 2026-06-29 ⚠️.
• 7 mailboxes, 1 GB each: darshan, kuldeep, jay, support, krishna, shiparajsolutions, sales — all @assure.ayrisglobal.com.

Step 4 — The migration decision, reasoned from first principles

Goal: move email off Hostinger, keep the addresses, stay cheap and low-maintenance.

Constraint (lecture 3): one MX set per domain → one inbound provider. So we pick one provider that does mailboxes and aliases and forwarding for assure.ayrisglobal.com.

Mailbox vs alias (lecture 5): of the 7 addresses, only the real people need paid mailboxes; role addresses (sales@, support@, …) can be free aliases. → confirm who’s who before paying for 7.

The plan:

The safe cutover (lectures 2, 3, 5):

1. Lower MX TTL in Cloudflare (a day ahead)          ← lecture 3
2. Create mailboxes + aliases in Zoho; verify domain (TXT)
3. Migrate old mail (Zoho's IMAP import) — DON'T delete Hostinger yet
4. Switch MX → Zoho in Cloudflare; add SPF + DKIM + DMARC TXT records
5. Test delivery for a few days
6. Only then cancel Hostinger email
7. (Separately) wire Resend for app mail on a send-subdomain
8. While you're here: turn ON auto-renewal for ayrisglobal.com  ← lecture 2

The one rule that prevents disaster

Never delete the old mailboxes until the new MX is verified and mail is flowing. Email in flight during a botched cutover is simply lost. Overlap, verify, then decommission.

✅ Check yourself

📚 Resources

• 🟢 Zoho Mail — setup & MX configuration: zoho.com/mail/help
• 🟢 MXToolbox — verify each step of the cutover: mxtoolbox.com
• 🟡 Resend — domain & DNS setup: resend.com/docs/dashboard/domains/introduction
• 🟡 Cloudflare — managing DNS records: developers.cloudflare.com/dns/manage-dns-records

One-line summary

A real stack is just four independent layers — registrar, DNS, web host, email — that you read off a few dig/curl commands. Knowing they’re independent is exactly what lets you migrate email by editing only MX + TXT records in Cloudflare, safely and cheaply.

Still Unclear?

Paste one of these into Claude to go deeper on your own stack:

I ran these and got this output [paste your nslookup -type=ns, -type=mx,
and curl -I results]. Read my stack back to me layer by layer: registrar,
authoritative DNS, website front, and email. Tell me what each command did
and did NOT prove.

Walk me through a zero-downtime email migration from provider A to provider B
for a domain whose DNS is on Cloudflare. List the exact record changes, in
order, with TTL handling, and tell me the one step where mail could be lost.

Explain the difference between a paid mailbox and a free alias for a small
team, and help me decide which of my addresses [list them] should be which
to minimise cost without losing any mail.

Why AI Can’t Do This For You

AI can recite what MX and NS records are, but it can’t run the commands against your domain, read your dashboards, or know that auto-renew is off and the email plan expires in two weeks. Reading a real stack is detective work on live evidence — and the migration decision is a judgement call that balances cost, risk, and who actually needs a mailbox. Get the reasoning wrong and you lose real mail in flight; AI won’t feel that consequence, you will. The skill is connecting raw record output to a safe plan, and that only forms by doing it on a stack you own.

Module done? Add it to today’s tracker