Ghost Custom Domain Setup: DNS, SSL and Email

Quick answer: Point your domain at Ghost with two DNS records at your domain provider, then tell Ghost the address. On Ghost(Pro) that means the Domain screen in admin, and SSL is automatic. On a self-hosted site it means the site URL in your config plus a certificate, and the www redirect is your job, because Ghost only redirects http to https.

You have a Ghost site and a domain name, and you want readers to reach the site at that name. The steps are short, but two of them trip people up: which version of the domain to use, www or not, and what happens to the other version. This guide covers Ghost(Pro) first, then self-hosted installs, then the email sending domain. Where the answer differs between the two, it says so.

We checked every path against Ghost’s documentation in September 2026 and tested the redirect behaviour on one of our own self-hosted sites.

www or root: decide before you add records

A domain has two front doors: the root, example.com, and the www subdomain. Readers will type both, links will use both, and search engines treat them as two sites unless one redirects to the other. So the first decision is which one is the real address. The other one should redirect to it.

Ghost’s own guidance is that www is simpler. A CNAME record, the kind that points at another hostname, works on a subdomain everywhere, but not every DNS provider supports it on the root. On the root it can also conflict with the domain’s email records. If your provider supports CNAME, ALIAS or ANAME records on the root, the root works just as well. Either is fine for search. What matters is that you pick one and the redirect for the other exists.

Ghost(Pro): the Domain screen and two records

Every Ghost(Pro) plan includes a custom domain. In Ghost admin, open the Ghost(Pro) section, then Domain, click Setup, and enter your domain. Only the owner account of the site can activate it.

Ghost then shows the records to add at your domain provider. For a www address:

For a root address the two swap roles: the CNAME goes on @ and the A record on www. In both layouts the A record is not your site. It points at a redirect service Ghost runs, and it is what sends the other version of the domain to the right one. Ghost’s help page puts it plainly: however a reader types the address, they land on the correct site. Skip the A record and one version of your domain fails.

DNS changes usually take effect within an hour, and occasionally a day. Once they have, Ghost issues an SSL certificate on its own. There is nothing to configure and nothing to renew.

If your DNS is on Cloudflare, set every Ghost record to DNS only, the grey cloud, not the orange proxied one. Ghost’s Cloudflare guide is explicit about this, and it is a common reason a Ghost(Pro) domain “doesn’t work” after the records look right.

Self-hosted: DNS, the site URL, and a certificate

On a self-hosted site there is no redirect service and no automatic certificate. Three things have to line up: DNS pointing at your server, Ghost knowing its own public address, and a certificate for that address.

DNS. Add an A record from your domain to the server’s IP address. If you want www to work as well, add a second A record for www, or a CNAME from www to the root. Where Ghost actually runs matters for the next steps, and the Ghost hosting guide explains how each kind of host handles domains.

The site URL. Ghost builds every link, image path and login redirect from one setting, the site URL. It has to be the full public address including https://. If it is wrong, the site loads but images point at the wrong place. The admin refuses to log in, with errors about an incorrect origin or access denied from a URL. On an install made with Ghost-CLI, the command is:

ghost config url https://example.com
ghost setup nginx ssl
ghost restart

The second line rewrites the web server configuration for the new address and requests a certificate for it. The certificate comes from Let’s Encrypt, it is free, and Ghost-CLI renews it on a schedule. The one requirement is that port 80 on your server is reachable from the internet, because that is how Let’s Encrypt checks you control the domain.

On the official Docker Compose setup, the address lives in the .env file as DOMAIN, with an optional ADMIN_DOMAIN if you want the admin on a separate hostname. Caddy, the web server in that setup, obtains and renews the certificate by itself. When you change the domain later, the Caddy container has to be recreated, not just restarted.

Behind a reverse proxy. Many hosts, control panels and Docker setups put a proxy in front of Ghost that terminates SSL. Ghost then sees plain http requests, and unless the proxy tells it otherwise it will keep redirecting to https and never settle. The proxy has to forward the original protocol in the standard header, and the site URL still has to be the public https address. For the technical reader: the header is X-Forwarded-Proto: https, and Ghost trusts it from the proxy.

The www redirect on a self-hosted site is your job

This is the part most guides, and an earlier version of this one, get wrong. Ghost does not redirect www to the root, or the root to www. We tested it on one of our own sites by sending requests straight to Ghost with different hostnames:

Host: www.example.com   ->  301 https://www.example.com/
Host: example.com       ->  301 https://example.com/
Host: anything.else     ->  301 https://anything.else/

Ghost upgrades http to https and keeps whatever hostname it was given. Ghost’s own code does the same thing on purpose: the public site only checks the protocol, and only the admin checks the hostname. So if both versions of your domain point at the server, both will serve the site, and search engines will see two copies.

The redirect belongs one layer up, in whatever receives the request first:

• Ghost-CLI install with nginx. Add a server block for the version you don’t want, returning a permanent redirect to the one you do. It needs a certificate that covers that hostname, or the https redirect will show a certificate warning. Ghost-CLI’s documented route is to run its nginx and SSL setup once for the extra hostname, then point that server block at the main domain.
• Docker Compose. The Caddyfile that ships with the setup has two commented blocks, one redirecting www to the root and one the other way. Uncomment the one you want and make sure DNS exists for both names. Ghost notes this is also required for ActivityPub to work on a www domain.
• Cloudflare in front. A redirect rule at the edge does it without touching the server. Use the Full (strict) encryption mode, or at least Full. The Flexible mode sends plain http to your server, Ghost redirects it back to https, and the two loop forever.
• A managed host. The redirect is a setting in the host’s panel or a request to their support. It is not something you can fix from inside Ghost.

For the technical reader, the nginx block looks like this:

server {
    listen 80;
    listen 443 ssl http2;
    server_name www.example.com;
    ssl_certificate     /etc/letsencrypt/www.example.com/fullchain.cer;
    ssl_certificate_key /etc/letsencrypt/www.example.com/www.example.com.key;
    return 301 https://example.com$request_uri;
}

A custom sending domain for newsletters

By default, newsletters from a Ghost(Pro) site are sent from a ghost.io address. A custom sending domain lets them come from your own domain instead, which readers recognise and which mail providers treat better once it has a reputation. It is available on the Publisher plan and above.

It is set up on the same Ghost(Pro) → Domain screen, under Custom sending domain. Ghost lists the DNS records to copy into your provider. It also requires a DMARC record on the domain, the policy that tells receiving mail servers what to do with mail that fails authentication. Ghost’s sending domain guide recommends starting with the least strict policy so nothing is rejected while you learn. Two things worth knowing before you switch it on:

• The custom domain is warmed up over about six weeks. During that time only a growing share of readers receive newsletters from the new domain, and the rest still get them from ghost.io. Sign-in links and other one-to-one emails use the new domain straight away.
• DNS for these records can take a day to be detected. A red mark next to a record in admin means Ghost cannot see it yet, not that you did it wrong.

On a self-hosted site there is no such screen, because newsletters go out through a sending service you connect yourself, and the sending domain is verified there. Our guide to Ghost newsletters without Mailgun covers the options and their domain setup.

When something doesn’t work

One case that is easy to mistake for a domain problem: Ghost on a subpath such as example.com/blog/. Ghost(Pro) offers it as a paid add-on on the Business plan, and it needs a reverse proxy you run yourself. On a self-hosted site it is a matter of setting the site URL to the full path and routing that path at your proxy. If you are choosing a setup from scratch, a subdomain such as blog.example.com avoids all of that. The exception is a blog that already has years of search history on the root domain, or a brand that needs it under the main site. Then the subpath is worth the proxy work.

Where this leaves you

Your domain now resolves to the site, one version redirects to the other, and the certificate renews itself. If you are self-hosting and the redirect or the certificate is the part still open, the self-hosting guide covers the server side in more depth. If the next thing on your list is email, the Ghost newsletter guide picks up from here.