> For the complete documentation index, see [llms.txt](https://docs.mdintegrations.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mdintegrations.com/partner/exploring-features/custom-domains.md).

# Custom Domains

For a truly white-label experience, patients shouldn't see MDI's name anywhere in their URLs or inbox. Custom Domains let you point your own domain at the two places MDI-branded links otherwise show up: outbound email and the Patient App itself.

## What you can customize

**Email sending domain** — the domain used for every partner-facing email MDI sends on your behalf (intake links, order updates, notifications, etc.). Once configured, patients see mail coming from your domain instead of MDI's default one.

**Portal domain** — the domain the white-label Patient App is served from, e.g. `patient.yourbrand.com` instead of a generic MDI subdomain. Any link to the Patient App — in an email, a message, or a Voucher's `onboarding_url` — will use this domain once it's verified.

## Setup

{% stepper %}
{% step %}

### Open Custom Domain settings

Open **Custom Domain** settings in the Partner Portal.
{% endstep %}

{% step %}

### Add DNS records

Note the DNS records shown there for the domain(s) you want to configure — one set for email sending, another for the Patient App portal domain.
{% endstep %}

{% step %}

### Configure your DNS provider

Add those records at your DNS provider, using whichever interface it gives you for managing DNS entries.
{% endstep %}

{% step %}

### Wait for verification

Then wait for verification. The Partner Portal will show each domain's status once MDI confirms the records have propagated.
{% endstep %}
{% endstepper %}

Once a domain is verified, MDI switches over automatically — no code changes or redeploys on your end, and no changes needed in how you generate links. A Voucher's `onboarding_url`, for example, will simply resolve on your domain going forward.

{% hint style="warning" %}
DNS changes can take up to 24 hours to propagate, and the portal domain may require additional records for SSL certificate validation. Configure Custom Domains well ahead of a launch date — this is not a same-day setup step.
{% endhint %}

## Setting up your email domain

The email sending domain has its own dedicated screen in the Partner Portal, separate from the general Custom Domain setup above:

{% stepper %}
{% step %}

### Open domain settings

Navigate to `https://partners.mdintegrations.com/partner/{your-company-id}/branding#domain`.
{% endstep %}

{% step %}

### Start setup

Click **Setup**.
{% endstep %}

{% step %}

### Set the sender name

Set a **Sender Name** — the display name recipients see, e.g. your company's name.
{% endstep %}

{% step %}

### Set the sender email

Set a **Sender Email** — the actual from-address MDI sends on your behalf, e.g. `noreply@yourdomain.com`. A subdomain works fine here too.
{% endstep %}

{% step %}

### Save

Review your entries and click **Save**.
{% endstep %}
{% endstepper %}

This covers the email-sending domain specifically. Configuring the Patient Portal domain — the white-label app itself — is a related but separate flow; see the DNS-based setup above for that.

## Recipes

### Fully white-labeled patient experience

Combine a verified portal domain with Theme Settings & Branding so the Patient App is both hosted on your domain and visually indistinguishable from the rest of your product.

### Branded transactional email end-to-end

Pair the email sending domain with the separate **Email Theme** setting (also covered in Theme Settings & Branding) so intake and notification emails both come from your domain and look like your brand, not MDI's default template.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.mdintegrations.com/partner/exploring-features/custom-domains.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.