Sending branded emails from your own domain

By default, every White Label Lite transactional email — password resets, mailbox invites, billing notifications to your customers — leaves our servers from noreply@trekmail.net. The visible "from" name is your brand, the body is your brand, but the address itself still says trekmail.net. Recipients who look carefully (or whose Gmail client expands the sender row) see TrekMail.

The Transactional sender setting closes that gap. Once you fill it in, the emails go out from any address you choose on a domain you've already set up with us — noreply@yourbrand.com, hello@yourbrand.com, whatever fits your tone.

Why it works with no extra setup

This is the part that surprises people most: there's no new DNS configuration, no separate DKIM key to publish, no SPF re-alignment to babysit. The reason is what you've already done for your mailboxes.

When you added your domain to TrekMail and created your first mailbox, three things happened in the background:

• We generated a DKIM key for your domain and gave you the TXT record to publish.
• We told you to add an SPF record that includes our sending servers.
• We added a DMARC record lining the two up.

Those records are exactly what an outgoing email from noreply@yourbrand.com needs to be DKIM-signed, SPF-aligned, and DMARC-passing. Our mail server signs every outgoing message by looking up the From-domain — and since that's yourbrand.com, it uses the same key your mailbox emails use. From the recipient's mail server's perspective, an email from noreply@yourbrand.com is indistinguishable from an email Alice on your team sent from alice@yourbrand.com. Same key, same SPF, same alignment.

If you ever moved DNS for that domain, or removed any of those records, your mailbox emails would also have broken — so by the time you're thinking about White Label Lite, the plumbing is already proven.

Turn it on

Open the White Label settings page and find the Transactional sender field. Enter any email on a domain you've already verified on TrekMail — for example noreply@yourbrand.com, team@yourbrand.com, or hello@yourbrand.com. Click Save changes.

From the next email onward, every branded transactional message uses that address as its visible From. The recipient sees:

From: YourBrand <noreply@yourbrand.com>

instead of:

From: YourBrand <noreply@trekmail.net>

The display name (YourBrand in the example) still comes from your Display name setting; the new address just replaces the @trekmail.net part.

What stays unchanged

A few things are deliberately untouched even when this setting is on:

• Replies still go to your Support email (if set). The From-address is just where the email appears to be from — Reply-To is a separate header. If you've set Support email, replies land in your inbox regardless of what's in From.
• Bounce-handling and rate-limiting continue on TrekMail's infrastructure. We process the bounce normally and surface it in your dashboard if relevant.
• The unsubscribe link in non-mandatory emails still points at your TrekMail-account preference center (rewritten to your branded domain).
• DKIM signing uses your domain's key as long as we have one (selector1._domainkey.yourbrand.com is the typical path). You don't have to do anything to enable signing — it's automatic on send.

What stays TrekMail

A technical user reading raw email headers (View source in Gmail, full headers in Apple Mail) will still see a few TrekMail-related lines:

• The Received: chain shows the path the message took through our outbound mail servers — these are TrekMail hostnames.
• The Return-Path: header (where bounces actually go) is on a TrekMail-controlled subdomain, so we can process the bounce.

Both are infrastructure-level, not customer-facing. Outlook, Gmail, and Apple Mail UIs don't surface Received: or Return-Path: in their normal display — only the From-name and From-address. The "envelope from = TrekMail, header from = your domain" pattern is industry-standard for branded transactional email and doesn't hurt deliverability.

Common questions

Do I need a separate DKIM key for the sender domain? No. You already have one because the same domain hosts your mailboxes. The key our mail server uses to sign messages is looked up by the From-domain at send time — it's the same key whether the sender is alice@yourbrand.com (your team member) or noreply@yourbrand.com (a transactional system message).

What if the domain isn't verified yet? The setting saves regardless, but emails from an unverified domain won't be signed by us — they'll go out unsigned, and Gmail / Outlook may flag them as spoofed. Verify the domain (add it under Domains in your dashboard, publish the DNS records, wait for the status to flip to Verified) before using it as a transactional sender. If you save the setting and then change DNS in a way that breaks DKIM, your mailbox emails also break — that's your earlier signal something's off, well before transactional emails are at risk.

Can I use a sender on a different domain than my mailboxes? Only if you've added that other domain to TrekMail too. The setting validates the address format but doesn't (yet) enforce that the domain belongs to your account. Practically: if the domain isn't yours under TrekMail, the email won't get a DKIM signature from us, and you'll see deliverability problems quickly. Stick to domains in your account.

What about the address showing up in recipient quarantine quietly? Gmail's DMARC dashboard (Google Postmaster Tools) is the place to spot this. The first few days after a brand-new sender domain starts mailing, a small amount of throttling is normal. Volume builds reputation. If you're going from zero to thousands of branded password-reset emails on day one, expect Gmail to ramp slowly.

Can I have one sender for password resets and another for mailbox invites? Not today. The setting is a single From-address for all branded transactional emails. If you need per-message-type customization, contact sales — that's a White Label Pro question.

Will my customers see anything different in their reply chain? They reply to whatever the From-address is. If the From is noreply@yourbrand.com and Reply-To is set to your Support email, hitting Reply opens a message addressed to your Support email. If Reply-To isn't set, the reply goes to noreply@yourbrand.com — which is a real address on a real mailbox if you've created one, and a delivery bounce if you haven't. Either set a Support email or create a noreply mailbox with auto-forwarding to handle the edge case.

Does this affect my SPF lookup limit? No. SPF allows ten DNS lookups before it gives up; our sending servers' SPF impact on your record is one include: directive, the same one that's already there for your mailbox sending. No additional record needed.

When you should not change this setting

A few situations argue for keeping the default noreply@trekmail.net:

• You haven't added your apex domain to TrekMail yet. Add the domain first, complete DNS verification, then come back to this setting.
• You're testing White Label Lite on a domain you don't own (a *.trekmail.dev subdomain, a localhost.example test).
• You're between domain transfers — wait until DNS for the new domain stabilizes on TrekMail before pointing transactional emails at it.

What's next

• Set up White Label Lite — the full setup walkthrough.
• What stays TrekMail-branded — the honest list of internal touches a curious customer might still spot.
• Adding a Domain — the prerequisite step. You need a verified domain before transactional emails will sign correctly.
• Checking DNS Status — verify your DKIM, SPF, and DMARC records are healthy before flipping this setting on.