With the Custom domain add-on, your agency workspace and your clients' portal answer on a subdomain of yours, such as app.youragency.com. You add the subdomain under Settings, publish one CNAME record at your domain provider and, as soon as it points here, the certificate issues itself and the app answers there. Never on the root domain.
What changes when the app lives on your domain
Until now your team and your clients came in through the product's own address. With the Custom domain add-on the same app answers on a subdomain of yours: the team signs in at app.youragency.com, the client opens their portal at app.youragency.com, and the links that go out by email, such as a quote or an invoice to review, are built on that address too. It is the same app, with the same permissions and the same data, behind a name that belongs to you.
It is worth being clear about what this is and what it is not before touching anything. It is an add-on for agency workspaces, because the client portal is what gives it a point and the portal only exists there. It is separate from the Branding pack, which dresses the workspace in your palette, your logo and your name: the pack is the clothing and the domain is the address, and they are bought separately. And it is separate from the Email domain add-on, which makes your emails leave from an address of yours; that one uses a different subdomain, different records and has a guide of its own. You can take one, the other or both.
There is one technical condition that is not up for discussion: it has to be a subdomain. The screen says it in its own words, "app.youragency.com, not youragency.com", and the reason is practical. Pointing the root domain would send your whole website at the app and, on the way, touch the email that hangs off that domain. A subdomain is a new record that brushes against nothing you already have running.
The DNS records, in one table
The process starts under Settings, on the Custom domain screen. You type the subdomain, press "Add domain", and the screen hands you a table of records with a type, a host, a value and a copy button on each. Almost always it is a single line.
| Record | Host | Type | Value | When it appears |
|---|---|---|---|---|
| CNAME | app.youragency.com | CNAME | cname.vercel-dns.com | Always |
| Verification | The host the screen shows | TXT | The value the screen shows | Only if the name is already in use on another account at the provider |
The CNAME is what points the subdomain here; without it, nothing answers. Leave the TTL at your provider's default, which the table calls "Auto". If your provider forces you to type a number, any of the usual ones will do: it only changes how long a later change takes to be noticed.
The TXT record is the exception, and it is worth understanding so you do not go looking for it when it is not there. It appears only when that same name is already registered on another account at the hosting provider, which is what happens when an agency tried another tool on the same subdomain and never released it. The TXT proves the domain is yours; once checked, the screen says so and you can delete it. If the table shows only the CNAME, there is nothing else to publish.
Write the host exactly the way your provider asks for it. Some panels want only the left hand part, "app", and append the domain themselves; others want the full name. If you publish "app.youragency.com" in a panel that already appends the domain, you end up with app.youragency.com.youragency.com, which points nowhere.
Where the CNAME field is at each provider
Every panel names things its own way, but the operation is the same everywhere: a new record of type CNAME, with the subdomain in the name field and the value from the table in the target field.
- Cloudflare. Inside the domain, open DNS and add a record of type CNAME. "Name" takes "app" and "Target" takes the value. The detail that breaks half of all setups is the orange cloud: the proxy status has to be left at "DNS only", with the grey cloud. With the proxy switched on, the certificate cannot be issued and the check stays pending.
- IONOS. Inside the domain, open the DNS management and add a CNAME record. The name field takes "app" and the target field takes the value from the table.
- GoDaddy. In the domain's DNS management, add a record of type CNAME with "app" as the name and the value as the target. The default TTL is fine.
- Namecheap. Under "Advanced DNS", add a "CNAME Record" with "app" as the host and the value from the table under "Value". If the domain uses another provider's nameservers, the record goes in that other panel, not here.
- Squarespace Domains. In the domain's DNS settings, add a custom record of type CNAME with "app" as the host and the value as the target.
A separate case is the domain whose DNS is run by a company other than the one that registered it, which is common when a studio built the website and still maintains it. The rule is simple: the record is published wherever the domain's nameservers live, not where the domain was paid for. If you do not know which that is, ask whoever runs the website to add the line from the table, and leave it there.
What happens after you press "Add domain"
As soon as you add the subdomain, the app starts checking on its own whether the record points here yet. The first checks are dense, at one minute, at two, at five, at ten, at fifteen and at half an hour, and from the first hour onwards they become hourly. That rhythm exists because most providers propagate a CNAME in minutes and a few take hours; the screen warns you with that same sentence.
In the meantime you will see one of these states:
| State | What it means | What you do |
|---|---|---|
| Added | The provider has not accepted the name yet; the app retries on its own | Nothing |
| TXT pending | The name is in use on another account and the TXT record is missing | Publish the TXT from the table |
| DNS pending | The domain is yours but the CNAME does not point here yet | Publish or review the CNAME |
| Live | The app answers on your subdomain | Open it and sign in |
| Failed | The provider refused the name | Read the reason and change or remove the domain |
If you have just published the record and do not want to wait for the next turn, press "Check now". It does the same read the automatic process does, right then, and accepts one press every fifteen seconds; press it sooner and the screen asks you for a breather. When the state turns to Live, the screen shows "Your app answers at" with the link, and at that point the certificate is already issued: there is nothing to request, upload or renew, because the hosting provider manages it the moment the DNS resolves.
The automatic checks run for two days. If they pass without the record pointing here, the screen says so and stops, and not because the domain is lost: a CNAME is one line, and whoever has not published it in two days is not waiting on propagation. You review the DNS, press "Check now" and the cycle starts again. A domain that is already Live never goes backwards on its own. If the record stops pointing here later on, you will see a warning, but the app keeps answering while the provider keeps the certificate.
Everything in this article happens in one place in GoFeed.
Try it freeHow the team and the clients get in
Once live, every address in the app also exists on your subdomain, with the same paths. The team signs in at app.youragency.com and lands in its workspace; the client opens app.youragency.com and sees their portal, which is exactly what the client portal page describes. The links the app emails from that workspace, such as a quote to accept or a password reset, are written on your domain as soon as it is live.
There are two details about access worth knowing before somebody asks. The first: the subdomain belongs to one workspace. If a member of your team also belongs to another agency and follows a link from that other one while on your domain, the app sends them to the product's address, where that other workspace lives. A foreign workspace is never rendered under your brand.
The second is the "Continue with Google" button. Google only returns a sign-in to a registered address, which is the product's, so when somebody presses that button on your subdomain the app takes them for an instant to app.gofeedapp.com, Google answers there, and a single-use, five-minute ticket brings them back to your domain with the session already open. It is the same session in both places, not two: signing out on one signs out on the other. For the person it is two redirects they never get to read. Creating a new account and creating a workspace still live at the product's address; what does stay on your domain is the sign-up of somebody you have invited, to the team or to the portal.
Changing, removing, and what happens if the add-on lapses
The screen has two more actions. "Change domain" puts a different subdomain in the same place: the current one stops answering as soon as you confirm, and the new one has to be verified from scratch, with a CNAME of its own. "Remove domain" sends the app back to the product's address; if you add one again later, you verify it again.
If the add-on leaves your plan, the app stops answering on your domain almost at once, within about a minute. The subdomain is not deleted at that moment: the screen tells you the date it is kept until, which is thirty days out, and if you take the add-on out again before that date it comes back without verifying again and without touching the DNS. After the thirty days the name is released and disappears from your workspace, and using it again means starting the whole process over. What the add-on includes and what it costs is on the pricing page, which reads the live catalogue.
What the domain does with the Bio pages deserves a sentence too. As soon as the domain
is live, every Bio page in the workspace also answers at your address,
app.youragency.com/t/ followed by the code, and that is the address the panel shows
and copies from then on. The address on the product's domain keeps working, so a link
already placed in a profile does not break.
What the domain does not do deserves a sentence too. It does not make your email leave from your domain; that is the Email domain add-on, with its own subdomain and its own signing records. And it does not include the Branding pack, which is what puts your palette and your logo on what the client sees when they sign in. Each of the three is taken on its own, and the three together are what makes a client open app.youragency.com and find not one sign that there is another product underneath.