# Domains and Aliases

> Primary domains, domain aliases and addon domains — what each one serves, what mail identity it gets, and how to choose between them.

Source: https://www.corepanel.net/docs/accounts/domains/
Last updated: 2026-08-03
Part of the CorePanel documentation — https://www.corepanel.net/docs

---

An account always has one **primary domain**. On top of it you can add two kinds of
secondary domain, and the difference between them is the single most useful thing to
understand about hosting several domains in one account.

| Type | Document root | DNS zone | Mail |
|---|---|---|---|
| **Primary** | `~/public_html` | Its own | Full: mailboxes, DKIM, sending and receiving |
| **Alias** (parked) | The site it republishes — the primary's `~/public_html` by default | Its own | None of its own — mail is redirected to the site it republishes |
| **Addon** | `~/domains/<domain>` | Its own | Full: its own mailboxes and DKIM |

In one sentence: **an alias is another name for the same site; an addon domain is a
different site inside the same account.**

## Domain aliases (parked domains)

Use an alias when a domain must lead to a site you already host:

- `example.net` and `example.org` protecting the brand of `example.com`
- an old domain kept alive after a rename
- a shorter domain used in print or advertising

The alias gets its own DNS zone pointing at this server and its own certificate, but it
serves the primary's document root. There is nothing extra to upload.

**Its mail is redirected to the domain it republishes.** An alias has no mailboxes of its
own — when it is added, CorePanel installs a whole-domain redirect so that
`anything@example.net` is delivered to `anything@example.com` and nothing bounces.

### Parking an alias on an addon

By default an alias republishes the account's **primary** domain. It can republish an
**addon** instead — "parking a domain on top of an addon", which is exactly what cPanel
lets you do and what a [migration](https://www.corepanel.net/docs/cpanel-import) brings over. Pick the site under
**Serves the site of** in the add dialog, or pass `--alias-for`:

```bash
corepanel domain add <accountId> otherbrand.com --alias-for otherproject.com
```

The alias then serves that addon's document root and its mail is redirected there. Two
consequences worth knowing:

- The target must be a **primary or addon domain of the same account**. An alias of an
  alias is refused — it would chain two redirects onto the same site.
- Deleting an addon deletes the aliases parked on it. They serve its document root, so
  leaving them behind would mean a live vhost, DNS zone and certificate pointing at a
  directory that no longer exists.

> **Aliases should usually redirect, not duplicate**
>
> By default a new alias serves a full copy of the primary's site under two more hostnames,
> which search engines see as duplicate content. Set its canonical host to **primary** and
> every request to the alias answers a single-hop 301 to the primary's canonical hostname
> instead. See [Canonical hostnames](#canonical-hostnames-www-or-not) below.
## Addon domains

Use an addon domain when the domain is a **different website** that you want to keep
inside the same account — the same customer, the same FTP login, the same quota:

- a second project of the same client
- a separate landing page or campaign site
- a site with its own mailboxes

An addon gets its own document root at `~/domains/<domain>`, its own DNS zone, its own
certificate, and a full mail identity with its own DKIM key. Mailboxes on an addon
domain work exactly like mailboxes on the primary.

That document root sits **beside** the primary's `public_html`, not inside it, so the
addon is reachable only under its own domain — never as a path under the primary. See
[Files and FTP access](https://www.corepanel.net/docs/accounts/files/) for the full home-directory layout.

> **Existing content is never destroyed**
>
> If the document root of an addon already exists — content uploaded by FTP before the
> domain was added, for instance — CorePanel reuses it. And if adding the domain then
> fails for another reason, the rollback only removes a document root that CorePanel itself
> created, never one that was already there.
## Adding a domain

From the account workspace, open **Account domains → Add domain**, enter the domain, and
pick its type (alias or addon). From the CLI:

```bash
corepanel domain add <accountId> example.net --type alias
corepanel domain add <accountId> otherproject.com --type addon
corepanel domain add <accountId> otherbrand.com --alias-for otherproject.com
```

CorePanel provisions the vhost, the DNS zone and the certificate, then records the domain
against the account.

### Rules and limits

- A domain name can belong to **only one account** on the server. Adding one that already
  exists anywhere is rejected.
- Aliases and addons consume **separate** limits (*Domain aliases* and *Addon domains*).
  `0` means unlimited.
- An addon also consumes one of the server's
  [websites](https://www.corepanel.net/docs/accounts/#the-server-wide-website-limit) — 20 on the free Personal
  edition, unlimited on Pro and Business. An **alias does not**: it republishes a
  document root that is already counted, so parking a domain keeps working at the cap.
- Every domain also gets its `www.` name automatically. You do not add `www` yourself.
- The primary domain cannot be deleted while the account exists.

## Canonical hostnames: www or not

CorePanel serves every domain under both `example.com` and `www.example.com`. Unless one
of them redirects to the other, the same site answers `200` under two names — bad for
SEO and confusing in analytics.

The **canonical host** setting decides which name is the real one:

| Setting | Behaviour |
|---|---|
| `www` | `www.example.com` is canonical; `example.com` answers 301 to it. **Default for new domains.** |
| `nonwww` | `example.com` is canonical; `www.example.com` answers 301 to it. |
| `none` | Both names serve the site directly, no redirect. |
| `primary` | *Aliases only.* Every hostname of the alias redirects, in one hop, to the canonical hostname of the site it republishes. |

Redirects preserve the path and the query string, so a deep link keeps working.

> **Existing domains were left alone**
>
> Domains that existed before this setting was introduced keep `none` — changing how a live
> site answers is an operator decision, not an upgrade side effect. New domains are created
> with `www` canonical.
## Serving mode

Each domain also has a **serving mode** (`plain`, `cms`, `spa`) that controls how the web
server handles a request for a path that is not a file on disk. New domains get `plain`,
where a missing path is a 404. Change it — on a domain or a subdomain — with the edit
button on its row in the account workspace. See
[Serving Modes](https://www.corepanel.net/docs/web/serving-modes).

## Force HTTPS

Each domain also decides whether plain HTTP answers a redirect to HTTPS. New domains are
created with it **on**; domains that arrive through an import or a restore are created
with it **off**, because a migrated site usually still has `http://` integrations pointing
at it.

The redirect only fires while the hostname has a valid certificate, so enabling it early
is harmless and a failed renewal cannot take the site offline. Same edit button, **HTTPS**
section. See [Force HTTPS](https://www.corepanel.net/docs/web/https-redirect).

## Deleting a domain

Deleting a secondary domain removes its vhost, its DNS zone, its certificate and — for
an addon — its DKIM key and, optionally, its document root. Any subdomains under it go
with it.

The account's usage counter is released, so the slot becomes available again.

## Which one should I use?

```
Does the domain need to show a different website?
├── No  → alias, canonical host "primary"      (redirects to the main site)
├── No, but it must serve the same content
│        under its own name → alias, canonical host "www"/"nonwww"
└── Yes → does it need its own mailboxes or its own DNS-level identity?
          ├── Yes → addon domain
          └── No, and it belongs to another customer → a separate account
```

When in doubt between an addon domain and a new account: an addon shares the quota, the
FTP user and the fate of the account it lives in. Different customers get different
accounts.