Why This Confuses Almost Everyone

Most developers learn each piece of web infrastructure in isolation. You bought a domain once. You set up hosting another time. Email "just worked" because someone else configured it. Then one day you change hosting providers and email stops working — and you suddenly realize you never understood how these pieces fit together.

The truth is that a domain like bluehorizon.dev doesn't live in one place. It's actually five separate concerns, and you can split each one across a different provider:

1. Domain registration — who owns the name
2. DNS management — where the name points
3. Website hosting — where your site's files live
4. Email hosting (mailboxes) — where you@yourdomain.com receives mail
5. Transactional email — how your app sends automated mail like signups, password resets, and invoices

This article walks through each layer with a single running example, the fictional domain bluehorizon.dev, and shows how to wire it across ResellerClub, Hostinger, Amazon SES, and Brevo. By the end, you will be able to draw the full diagram on a whiteboard and debug it when things break.

We will also talk about cost. If you are running a mid-level agency with ten client sites, the difference between a "premium everything" stack and a "smart split" stack can be ₹2,00,000+ per year.

The Mental Model

Before we touch any control panel, lock this picture in your head:

┌─────────────────────────────────────────────────────────────┐
│                     bluehorizon.dev                          │
│                                                              │
│  ┌──────────────┐    "Who owns this name?"                   │
│  │  REGISTRAR   │    →  ResellerClub                         │
│  └──────┬───────┘                                            │
│         │ points to                                          │
│         ▼                                                    │
│  ┌──────────────┐    "Where does this name resolve?"         │
│  │  DNS ZONE    │    →  ResellerClub Premium DNS             │
│  └──────┬───────┘                                            │
│         │ contains records that route to                     │
│         ▼                                                    │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐        │
│  │  WEB SERVER  │  │ MAIL SERVER  │  │ SMTP RELAY   │        │
│  │  Hostinger   │  │ cPanel on    │  │ Amazon SES   │        │
│  │              │  │ ResellerClub │  │ or Brevo     │        │
│  └──────────────┘  └──────────────┘  └──────────────┘        │
│   (A record)        (MX records)      (SPF/DKIM TXT)         │
└─────────────────────────────────────────────────────────────┘

Three things to internalize:

1. The registrar holds the name, but does not have to host anything.
2. DNS is just a phonebook. It maps names to servers. Whoever runs your DNS controls where every type of traffic goes.
3. Each record type is a different door. A records route web traffic. MX records route email. They are independent — you can change one without affecting the other.

This independence is the whole reason cost-splitting works. You can put each piece on the provider that is cheapest for that specific job.

Layer 1: Domain Registration (ResellerClub)

What a registrar actually does

A domain registrar is a company accredited by ICANN (or a TLD-specific authority for ccTLDs) to sell domain names and write records to the central registry. When you buy bluehorizon.dev, the registrar reserves the name in the .dev registry, stores your contact info in WHOIS, and lets you set the authoritative nameservers for the domain.

That last point is the most important. The registrar does not have to host anything. It just has to know which nameservers to delegate the domain to. That is the only job you cannot outsource.

Why ResellerClub for cost-conscious agencies

ResellerClub is a domain reseller platform owned by Newfold Digital. It is popular with agencies and Indian web hosts for a few reasons. Wholesale pricing brings .com domains down to roughly ₹650 to ₹800 per year, compared to ₹1,200+ at retail elsewhere. White-label resale lets you resell to your own clients under your own brand. WHOIS privacy is free on most TLDs. And the bulk management panel handles 50+ client domains comfortably.

If you are managing client domains, the reseller account model lets you mark up domains for clients while keeping your wholesale price.

The registrar checklist

When you register bluehorizon.dev on ResellerClub, do four things on day one. Enable WHOIS privacy, which is free, to keep your personal data out of public records. Enable the registrar lock to prevent unauthorized transfers. Note where the EPP (auth) code lives in the panel — you will need it if you ever transfer the domain out. And turn on auto-renew. Losing a domain because of an expired credit card is a brutal way to learn this lesson.

By the end of this layer you should be able to buy a domain, enable privacy and lock, and find the nameserver settings. That is all the registrar layer asks of you.

Layer 2: DNS Management (ResellerClub Premium DNS)

This is the layer that confuses people most, so we will go slow.

Authoritative nameservers vs DNS records

When someone types bluehorizon.dev into a browser, their computer asks one question: who is authoritative for this domain? That answer comes from the registry, and it is the nameservers you configured at the registrar.

So if your nameservers are:

ns1.resellerclub.com
ns2.resellerclub.com

ResellerClub's DNS service is authoritative. Whatever records they serve are the truth, as far as the internet is concerned.

The records themselves are just key-value entries inside a "zone." You do not need to memorize all DNS record types — just six.

Why ResellerClub Premium DNS

ResellerClub gives you basic DNS for free with a domain. Premium DNS, which costs around ₹500 to ₹800 per year, adds anycast routing so DNS is served from the geographically closest node, DDoS protection because premium DNS networks absorb attacks, higher record limits, DNSSEC support for cryptographic signing of DNS responses, and a stronger uptime SLA.

For an agency hosting client sites, premium DNS is cheap insurance. A DNS outage takes down everything — site, email, APIs — at the same time.

TTL and propagation: the real story

Every DNS record has a TTL (Time To Live) in seconds. It tells resolvers how long they can cache the answer before re-asking.

bluehorizon.dev.   3600   IN   A   198.51.100.42
                   ^^^^
                   TTL in seconds (1 hour)

The "DNS propagation takes 48 hours" thing you have heard is mostly nonsense. What actually happens: you change a record, authoritative nameservers update immediately, and resolvers around the world keep serving the old cached value until their TTL expires. Once expired, they fetch the new value.

So if your TTL is 3600 (1 hour), the change propagates fully in 1 hour. The "48 hours" advice comes from old systems with 48-hour TTLs. Lower your TTL to 300 seconds the day before a planned change and your transitions will complete in 5 minutes.

A handy command: dig +short bluehorizon.dev @8.8.8.8 queries Google's resolver directly, useful for checking if your records have propagated globally.

By the end of this layer you should be comfortable adding an A record, finding your nameservers, lowering a TTL before a change, and using dig to verify a record is live.

Layer 3: Website Hosting (Hostinger)

What hosting actually is

A web host is a server (or a bunch of servers) that responds when someone's browser requests bluehorizon.dev. The server reads files from disk (or generates them dynamically) and sends back HTML, CSS, JS, and images.

Hosting comes in flavors. Shared hosting puts your site on a server with hundreds of others — the cheapest option, fine for small sites. VPS gives you a slice of a server with dedicated CPU and RAM, more control and more responsibility. Managed hosting is shared with a friendlier control panel and auto-updates. Serverless and static (Vercel, Netlify) means no server to manage — you just push code.

Why Hostinger for cost-effective sites

Hostinger hits a sweet spot for agencies. Shared plans start around ₹150 per month with unlimited bandwidth and free SSL via Let's Encrypt that auto-renews. One-click WordPress installers and other CMS setups are built in. Plans include a free domain, but skip that since you already have a registrar. The servers run LiteSpeed, which is faster than Apache on shared hosting. And hPanel — Hostinger's control panel — is cleaner and less bloated than traditional cPanel.

For a brochure site, agency landing page, or small WordPress site, Hostinger's $2 to $4 per month shared plan is hard to beat.

Connecting Hostinger to your domain

Hostinger gives you two ways to do this.

Option A: Point nameservers to Hostinger. Change your nameservers at the registrar to ns1.dns-parking.com and ns2.dns-parking.com. Hostinger now manages DNS. The downside: you lose control of advanced DNS records. If you want SES, cPanel email, or anything custom, you have to add records inside Hostinger's panel — workable, but you have moved your DNS away from Premium DNS.

Option B: Keep DNS at ResellerClub Premium, point an A record at Hostinger. This is the recommended path for the split stack we are building. In ResellerClub's DNS panel, add:

bluehorizon.dev.       300   IN   A      <Hostinger server IP>
www.bluehorizon.dev.   300   IN   CNAME  bluehorizon.dev.

Hostinger gives you the IP in their hPanel under "Hosting Account Details." This way your DNS stays on Premium DNS, and only web traffic goes to Hostinger.

The apex vs www gotcha

bluehorizon.dev (the apex or root) and www.bluehorizon.dev are two different names in DNS. You should always point both to your site, otherwise users typing one or the other will get errors.

Most setups use an A record at the apex pointing to the server IP, and a CNAME at www pointing to the apex. Some hosts (notably Vercel) want CNAME for both — but DNS forbids CNAME at the apex, so they get around it with a synthetic ALIAS or ANAME record. ResellerClub Premium DNS supports these. With Hostinger you usually just use a plain A record at the apex.

SSL and HTTPS

Hostinger auto-provisions SSL via Let's Encrypt as soon as your A record points to their IP. The certificate auto-renews every 90 days. Two things break this. First, a wrong A record: Let's Encrypt validates by hitting your domain over HTTP, so if your DNS does not resolve to Hostinger, validation fails. Second, restrictive CAA records: if you have a CAA record only authorizing other CAs, LE cannot issue. Either remove the CAA or add letsencrypt.org to it.

By the end of this layer you should be able to point a domain at Hostinger via an A record while keeping DNS elsewhere, and verify SSL issued correctly.

Layer 4: Email Mailboxes via cPanel on ResellerClub Linux Shared Hosting

This is the layer where most agencies get burned, so I will say it once, plainly:

Switching your web host does not break email. Switching your nameservers (or DNS records) does.

If you remember nothing else from this article, remember that.

Why cPanel email is the most cost-effective option

When you buy a Linux Shared Hosting plan from ResellerClub, you do not just get web hosting. The plan includes cPanel — a full hosting control panel — and cPanel comes with a built-in email server. That means you can create mailboxes like you@bluehorizon.dev without paying for any separate email service.

For agencies running cost-sensitive client sites, this is one of the biggest savings on the table. A typical Linux Shared Hosting plan at ResellerClub runs ₹150 to ₹400 per month and includes either unlimited or 100+ email accounts depending on the plan tier.

A common pattern in our split stack: you keep the actual website on Hostinger (faster LiteSpeed servers), but you also keep a small ResellerClub Linux Shared Hosting plan purely as the email host. Because MX records are independent of A records, your DNS can route web traffic to Hostinger and mail traffic to ResellerClub at the same time. If you would rather consolidate, you can also run the website on the same ResellerClub plan and skip Hostinger entirely.

Creating a mailbox in cPanel

After logging into cPanel from the ResellerClub panel:

1. Open the "Email Accounts" section
2. Click "Create"
3. Enter the username (the part before the @) and a strong password
4. Set a mailbox quota — 1 to 5 GB is typical for shared plans
5. Save

Within seconds the mailbox is live. Repeat for info@, support@, hello@, or any address you need.

Accessing email through a web browser (webmail)

cPanel ships with Roundcube as its default webmail client. On older servers you may also see Horde or SquirrelMail, but Roundcube is the modern default. You can reach it three ways:

https://webmail.bluehorizon.dev
https://bluehorizon.dev/webmail
https://yourserver.example.com:2096

The first option works because cPanel auto-creates a webmail subdomain that resolves to the same IP as your hosting account. If the auto-created entry is missing for some reason, add a CNAME yourself:

webmail.bluehorizon.dev.   3600   CNAME   bluehorizon.dev.

Roundcube's UI is functional but dated. It supports folders, IMAP search, contacts, basic filters, and HTML composing. It will not feel like Gmail. For most internal mail and small-business clients, that is fine.

Setting up the mailbox in a local email client

This is where most people stumble. cPanel offers "auto-config" links, but they fail half the time across modern clients. The reliable path is to plug the manual settings into any client yourself.

For incoming mail (use IMAP, not POP3, so messages stay on the server and sync across devices):

For outgoing mail (SMTP):

These settings work identically across:

• Outlook (Account Settings → Manual setup → IMAP)
• Thunderbird (Account Setup → enter address → "Configure manually")
• Apple Mail (Mail → Add Account → Other → Mail Account)
• iOS Mail (Settings → Mail → Add Account → Other)
• Android Gmail or Outlook app (Add account → Other or IMAP)

The single biggest cause of "it will not connect" on shared hosting is using just the username instead of the full email address. cPanel servers route mailboxes by the full address.

DNS records you still need

cPanel-hosted email uses the same four DNS records as any other email setup. You do not skip them just because the email server runs on the same machine as your website. The records below assume the cPanel server is at mail.bluehorizon.dev, which cPanel sets up for you automatically.

; MX — where mail is delivered
bluehorizon.dev.   3600   IN   MX   0   bluehorizon.dev.

; SPF — which servers are allowed to send as your domain
bluehorizon.dev.   3600   IN   TXT  "v=spf1 +a +mx ~all"

; DKIM — public key generated by cPanel under "Email Deliverability"
default._domainkey.bluehorizon.dev.   3600   IN   TXT   "v=DKIM1; k=rsa; p=<cpanel-generated-public-key>"

; DMARC — policy for what to do when SPF/DKIM fail
_dmarc.bluehorizon.dev.   3600   IN   TXT   "v=DMARC1; p=quarantine; rua=mailto:postmaster@bluehorizon.dev"

cPanel auto-generates the DKIM record under "Email Deliverability" — copy the value from there into your DNS zone. The SPF record above uses +a +mx, which authorizes the server's own IP (because web and mail share the same machine) plus any servers listed in your MX record. We will extend this SPF record in the next layer when we add transactional senders.

The cons — what you give up for the savings

cPanel email on shared hosting is genuinely good for many use cases, but you need to be honest about the tradeoffs.

Shared IP reputation. Your outgoing mail goes through an IP shared with hundreds of other tenants. If a neighbor spams, your domain can suffer collateral damage. Major providers (Gmail, Outlook) may flag legitimate mail.

Lower sending limits. Shared hosting typically caps you at 200 to 500 outgoing emails per hour. If you are running anything that sends bulk — newsletters, even moderate transactional volume — you will hit the wall. This is exactly why we put transactional mail on SES or Brevo in Layer 5.

Smaller mailboxes. 1 to 5 GB per mailbox is normal. Compared to Google Workspace's 30 GB starting tier, you will need to archive often.

Basic spam filtering. cPanel uses SpamAssassin, which is fine but not at the level of Gmail's ML-based filtering. Phishing detection is rudimentary.

Dated webmail. Roundcube works, but it will not impress clients used to Gmail or Outlook 365. There is no built-in calendar invitations, video conferencing, or shared drive.

No native calendar and contacts sync. You can bolt on CalDAV and CardDAV with extra cPanel addons, but it is not seamless.

Mailbox is tied to the hosting account. If you cancel the hosting, you lose the mailbox unless you migrate first. Always export to .mbox or via IMAP before any host change.

Backups depend on the host. ResellerClub keeps periodic backups, but you should pull your own copies regularly. Mail is irreplaceable.

When cPanel email is enough — and when to upgrade

cPanel email on shared hosting is an excellent fit when you have one to ten mailboxes, your volume is under a few hundred outgoing emails per day, your clients are small businesses rather than enterprises, you are already paying for the hosting plan anyway (so email is effectively free), and you do not need calendar, video, or collaboration features baked in.

It is time to move to a dedicated email host (Google Workspace, Microsoft 365, Zoho Mail) when you have 20+ mailboxes, you need shared calendars and team drives, deliverability is mission-critical (legal, finance, healthcare), you are sending more than a few hundred manual emails per day, or your clients expect a polished webmail experience.

The beauty of the layered model is that you can move only the mailbox layer when the time comes. The website, DNS, and transactional email all stay where they are.

By the end of this layer you should be able to create a mailbox in cPanel, configure it in any local email client over IMAP/SMTP, log into Roundcube webmail, and add the four DNS records (MX, SPF, DKIM, DMARC) that make the mailbox actually work.

Layer 5: Transactional Email (Amazon SES or Brevo)

Why transactional is its own thing

Mailbox email is for humans typing replies. Transactional email is for applications sending automated mail — order confirmations, password resets, signup welcomes, invoices, notifications.

The two have completely different needs:

You can send transactional mail from a cPanel mailbox. You should not. cPanel mailboxes have low daily sending limits, one spam complaint can blacklist the whole shared IP, you do not get bounce or complaint webhooks, and your team's regular email reputation gets damaged when transactional mail fails.

Amazon SES — the cheapest at scale

Amazon SES is the budget king for transactional email. It costs $0.10 per 1,000 emails (roughly ₹8 per 1,000), with a free tier of 62,000 emails per month if you send from EC2. Deliverability is excellent thanks to AWS-grade IP reputation. Bounce and complaint webhooks come through SNS. And it is region-based, so you can pick the AWS region closest to your users.

The catch: SES starts in "sandbox mode." You can only send to verified email addresses, max 200 per day. To leave sandbox, you submit a request explaining your use case. Approval usually takes one to two business days.

To set up SES with bluehorizon.dev, verify your domain in SES (it asks for a TXT record), then add the three DKIM CNAMEs SES generates:

abc123._domainkey.bluehorizon.dev.   IN   CNAME   abc123.dkim.amazonses.com.
def456._domainkey.bluehorizon.dev.   IN   CNAME   def456.dkim.amazonses.com.
ghi789._domainkey.bluehorizon.dev.   IN   CNAME   ghi789.dkim.amazonses.com.

Then add include:amazonses.com to your SPF record. Combine it with your existing SPF — do not add a second TXT record:

"v=spf1 +a +mx include:amazonses.com ~all"

Finally, request production access from the SES console and start sending via the AWS SDK or SMTP credentials.

Brevo — easier, slightly pricier

Brevo (formerly Sendinblue) trades some cost for ease of use. The free tier covers 300 emails per day. Paid plans start around ₹1,500 per month for 20,000 emails. The web dashboard has solid analytics, and there is a built-in template editor. There is no sandbox approval gate — you can send to anyone after domain verification. And if you ever need it, marketing email features (campaigns, contact lists) are included.

For a small SaaS sending under 10,000 emails per month, Brevo is simpler. For higher volume, SES wins on cost.

In this very codebase, the YugaMatix site uses Brevo's transactional API (@getbrevo/brevo) for contact form, project inquiry, and newsletter emails. See lib/brevo-email.ts for the implementation pattern.

Should you use both?

Yes, often. A reasonable setup is cPanel mailboxes for you@yourdomain.com, Brevo for low-volume transactional and occasional marketing, and SES for high-volume transactional once you grow past 10,000 emails per month.

All three coexist on one domain — they are just different SPF and DKIM entries:

"v=spf1 +a +mx include:amazonses.com include:sendinblue.com ~all"

By the end of this layer you should be able to verify a domain in SES, add the DKIM records, merge SPF entries, and send a test email programmatically.

Putting It All Together

Here is the complete annotated DNS zone for bluehorizon.dev running the full split stack. Read it top to bottom and notice that every line is doing exactly one job — and you can change any line without affecting the others. That is the point.

; Authoritative nameservers — set at registrar (ResellerClub)
; pointing to ResellerClub Premium DNS
bluehorizon.dev.    NS    ns1.resellerclub.com.
bluehorizon.dev.    NS    ns2.resellerclub.com.

; ─── Website (Hostinger) ─────────────────────────────────
bluehorizon.dev.        300   A      198.51.100.42
www.bluehorizon.dev.    300   CNAME  bluehorizon.dev.

; ─── Mailboxes (cPanel on ResellerClub Linux Shared Hosting) ──
bluehorizon.dev.        3600  MX     0  bluehorizon.dev.

; webmail subdomain (auto-created by cPanel; add manually if missing)
webmail.bluehorizon.dev.   3600  CNAME  bluehorizon.dev.

; ─── SPF — combined for cPanel + SES + Brevo ─────────────
bluehorizon.dev.        3600  TXT  "v=spf1 +a +mx include:amazonses.com include:sendinblue.com ~all"

; ─── DKIM — cPanel (from "Email Deliverability" page) ────
default._domainkey.bluehorizon.dev.   3600  TXT    "v=DKIM1; k=rsa; p=<cpanel-public-key>"

; ─── DKIM — Amazon SES (3 CNAMEs from SES console) ──────
abc123._domainkey.bluehorizon.dev.    3600  CNAME  abc123.dkim.amazonses.com.
def456._domainkey.bluehorizon.dev.    3600  CNAME  def456.dkim.amazonses.com.
ghi789._domainkey.bluehorizon.dev.    3600  CNAME  ghi789.dkim.amazonses.com.

; ─── DKIM — Brevo (from Brevo dashboard) ─────────────────
mail._domainkey.bluehorizon.dev.      3600  TXT    "v=DKIM1; k=rsa; p=<brevo-public-key>"

; ─── DMARC ───────────────────────────────────────────────
_dmarc.bluehorizon.dev.   3600   TXT   "v=DMARC1; p=quarantine; rua=mailto:postmaster@bluehorizon.dev; pct=100"

Cost Breakdown for a Mid-Level Agency

Let's price out a realistic agency scenario: ten client sites, five internal mailboxes, and around 5,000 transactional emails per month.

"Premium everything" stack (what most people start with)

Cost-smart split stack (this guide)

That is roughly ₹17,900 saved every month, or about ₹2,15,000 per year. For an agency, that is the cost of an additional employee, a marketing budget, or a healthy buffer for unpaid invoices.

Tradeoffs to be honest about

cPanel webmail (Roundcube) is clunkier than Gmail. Hostinger shared hosting will not handle 100K+ daily visitors. SES requires more devops effort (sandbox approval, bounce handling). And ResellerClub's panel is less polished than premium alternatives.

The split stack works well for agencies serving small-to-medium clients. It starts to creak when individual clients grow past mid-size — and at that point you migrate just that client up the stack, not everyone.

Troubleshooting Cheat Sheet

Commands every developer should know

# What's the A record?
dig +short bluehorizon.dev

# What MX servers handle mail?
dig +short MX bluehorizon.dev

# What's the SPF record?
dig +short TXT bluehorizon.dev | grep spf1

# Query a specific resolver (handy for propagation testing)
dig bluehorizon.dev @1.1.1.1
dig bluehorizon.dev @8.8.8.8

# Authoritative-only (skip cache)
dig +trace bluehorizon.dev

# DKIM
dig +short TXT default._domainkey.bluehorizon.dev

# DMARC
dig +short TXT _dmarc.bluehorizon.dev

Quick Reference Card

Provider roles

DNS record cheat sheet

Final Mental Model

If you internalize one thing, make it this: a domain is a routing decision, not a place. The registrar holds the name. The DNS zone routes each kind of traffic — web, email, transactional — to whichever provider does that job best. Change one line at a time, lower TTLs before you do, and verify with dig.

Once you see infrastructure this way, the next time a client says "the site moved but email broke," you will know exactly where to look — and you will fix it in five minutes instead of five hours.

Happy routing.