Why this area exists
The Domain section lets your organization connect a branded public subdomain such as donate.yourorg.ca or events.yourorg.ca so supporters see your organization's domain instead of only the default Altrinum URL structure.
What the setting is for
The custom domain affects public and member-facing routing in the codebase for:
- donation pages
- event pages and registration routes
- program pages and checkout routes
- member portal routes
It also feeds the workspace email sender preview so admins can see how branded sending is expected to look.
What changes after configuration
When a tenant domain is present and resolves correctly:
- public routes can be generated on the branded domain
- member portal links can also use the tenant domain
- sender previews can switch to a
mail@your-domainstyle sender with a matching bounce-domain preview when the current sending mode allows it
When the custom domain is not yet live:
- the default Altrinum route still works
- the platform can continue serving the public experience from the default route until the branded domain is ready
Subdomain requirement
The settings UI is explicit about this:
- use a subdomain
- do not use your root domain
- do not enter
https:// - do not enter a path
Examples shown in the UI include:
events.yourorg.cadonate.yourorg.caengage.yourorg.ca
DNS process confirmed in the UI
Workspace Settings instruct admins to create NS records for the chosen subdomain and delegate them to the listed AWS nameservers.
The page also explains:
- propagation can take time
- the default Altrinum link continues working while the custom domain is being connected
- admins may need to work with IT, a web team, or the domain registrar provider
Sender preview and branded sender implications
The domain page includes Email Sender Preview.
That preview shows:
- the current
Fromname and address the workspace would use - whether the bounce domain is tenant-branded or still platform-managed
This is important because email sender behavior is not just a visual choice. It affects the identity supporters will see in mailboxes and helps teams catch misalignment before launching a campaign.
Treat the preview as the current truth. Do not assume that entering a domain automatically means every email path is fully branded until the preview confirms it.
Operational notes
- If you change the workspace name after setting the domain, recheck the sender preview and any copied callback instructions.
- Public assets still come from the central storage origin, so a branded domain does not mean every asset URL moves to that domain.
- Stripe webhooks remain on the secure hooks domain even when public pages use your branded domain.
Common mistakes
- entering the full URL instead of the subdomain only
- trying to use a root domain
- switching public promotions to the branded domain before DNS propagation finishes
- forgetting to test both the branded route and the default Altrinum route after setup
- assuming a branded domain automatically guarantees a branded bounce domain for email without checking the preview
What to test afterward
After DNS changes, test:
- the branded donation URL
- the branded event URL
- the branded program URL
- one member portal link if your team uses it
- the default Altrinum fallback URL
- the email sender preview
If your team is preparing a launch, also test:
- QR codes
- copied links in email campaigns
- any saved browser bookmarks or website buttons that previously used the default route
Troubleshooting
- If the domain does not resolve, confirm the NS delegation exactly matches the nameservers shown in the settings page.
- If the page resolves but the wrong tenant appears, stop and have the domain mapping reviewed before going further.
- If links still generate on the default route, confirm you are actually accessing the workspace from the tenant domain path being tested.