Send From a Domain You Do Not Host

Some domains should never move. A client runs their business on Google Workspace or Microsoft 365, everyone is used to it, and nobody wants a migration. You still want your team to answer that client's mail from TrekMail, from the client's own address, without anyone on the outside noticing a difference.

That is what a sending-only domain is for. TrekMail confirms you control the domain and sends from its addresses. Incoming mail keeps arriving exactly where it does today, because you never touch the MX record.

When to use this

Use a sending-only domain when all of these are true:

• The domain's mail is hosted somewhere else and is staying there.
• You can add TXT records to the domain's DNS.
• You want replies to leave with that domain's address, not yours.

If you want TrekMail to actually receive the mail — real mailboxes, storage, search — set the domain up the normal way instead and point its MX at us.

How the mail flows

Nothing about the client's incoming mail changes. Their provider receives it as always. A copy is forwarded into a TrekMail mailbox, usually a shared one your team already works in.

When someone answers from that shared mailbox, they pick the client's branded address in the From field. The reply leaves through TrekMail — or through a saved SMTP service if you use one — and lands in the shared mailbox's Sent folder, where the whole team can see it.

So the inbox, the visible address, and the delivery route are three separate choices. That is the whole idea.

Before you start

You need:

• Access to the domain's DNS, enough to add three TXT records.
• A TrekMail mailbox or shared mailbox where the forwarded copies will land. It can live on any of your domains.
• Forwarding set up at the client's provider. TrekMail does not create that for you — it is a rule in Google Workspace, Microsoft 365, or whatever they use.

You do not need to change the MX record, and you should not.

Set it up

1. Add the domain. Go to Domains → Add a domain and enter the client's domain as usual.

2. Tell us the mail lives elsewhere. Open the domain and use the Incoming mail chip under its name. Choose Incoming mail stays with your current provider and save. The DNS tab immediately stops asking for an MX record.

The chip is the only place this setting lives, and it sits under the domain name on every tab, so you do not have to hunt through settings for it. One thing worth knowing while the domain is still on the normal setup: if you open the list of DNS conflicts, an MX record belonging to another provider is reported as something to consider, never as something to delete.

3. Publish three TXT records. The DNS tab now lists SPF, DKIM and DMARC, and nothing else. Add them at the domain's DNS provider.

The DKIM record is also how we confirm you control the domain: its value is a key generated for this domain alone, so publishing it proves the point without a separate verification record to add and then delete.

About the DKIM row. A domain that already sends through another service usually has a key published under the common name dkim._domainkey, and that record belongs to the other service — replacing it would stop that service signing its mail. You do not have to check for this or work around it: when we generate the key we look first, and if the usual name is taken we publish under a different one. The DNS tab always shows the exact name for this domain, so copy what it says rather than what you remember. Both keys then live side by side and both services keep signing.

If the domain already has a long SPF record, read the warning on that tab before editing. SPF allows ten DNS lookups in total, and a domain that already lists Google Workspace, a CRM and a newsletter tool can be one entry away from the limit. Going over it breaks SPF for all of that domain's mail, not just the part we send.

4. Add the branded addresses. Go to the mailbox that receives the forwarded copies, open its Aliases, and add the client's address — for example admin@clientdomain.com — choosing the client domain. Turn on sending for it.

The address then appears on the domain's Sending addresses tab, and in the From list of that mailbox.

5. Choose the sending route. By default every address on the domain follows the domain's own setting on the SMTP tab: TrekMail's managed service, or a saved SMTP profile such as Mailjet, Brevo or SMTP2Go. Change it once and every address on that domain follows.

If one address needs a different provider, an account owner can override the route for that single address when adding it.

Make replies use the right address

Open the shared mailbox in webmail, go to Settings → Sending addresses, and pick how replies should start:

• Address that received the message — good when several branded addresses arrive in the same mailbox and each conversation should answer itself.
• Default address for new messages — good when copies arrive at one collection address but every reply should go out as the client's public address.

The second one is what most forwarded-copy setups want, because the address the copy was delivered to is your collection mailbox, not the address the customer wrote to.

What a sending-only domain cannot do

• It cannot hold mailboxes. There is nowhere for mail to be delivered, because we are not the mail host.
• It cannot use a catch-all or forwarding addresses, for the same reason.
• It does not appear in autodiscover or mail-client setup. Those settings belong to the provider that actually holds the mail, and publishing ours would pull the client's Outlook onto an account they do not have here.
• It does not create the forwarding rule at the client's provider.

Doing this from the API or an AI agent

Everything above is available without the dashboard.

POST /api/v1/domains takes mail_hosting: "external", so a domain can be added as sending-only from the start. PATCH /api/v1/domains/{id}/mail-hosting moves an existing one, and GET /api/v1/domains reports which kind each domain is. Moving a domain that still holds mailboxes is refused until you resend with confirm_mailboxes_stop_receiving: true — the same deliberate act the dashboard asks for by typing the domain name.

The MCP tools are create_domain, set_domain_mail_hosting and list_domains, all under the domains:write scope. Adding the branded address afterwards uses create_identity with kind=send_as and no external_account_id.

Switching later

You can move a domain in either direction from the same Incoming mail chip.

Turning a normal domain into a sending-only one stops its mailboxes receiving, so we ask you to type the domain name first. Nothing is deleted, and switching back restores delivery once the MX record points at us again.