"Use your domain for email" is the operation that turns yourcompany.com from a website address into a working email destination. The full configuration path covers DNS records, mailbox provisioning, authentication, and verification. The work splits into five concrete steps that any operator can finish in an afternoon — no server administration required, just dashboard clicks and DNS record copy-paste.
Most setup walkthroughs cover one specific provider's dashboard. The five steps below are provider-neutral and apply across TrekMail, Workspace, Zoho, or any credible mailbox host. Naming the steps separately makes the dependencies clear.
This guide walks the full configuration with concrete checks at each step. For the broader walkthrough see how to create email with domain.
What "Use Your Domain for Email" Actually Means
To use your domain for email is to configure DNS records that route incoming mail to a mailbox host and authenticate outbound mail so receivers trust it. The configuration spans five DNS records (MX, SPF, DKIM, and DMARC, plus a domain-verification TXT). Each record has a different job and a different format.
The mailbox host provides the values; you publish them at your DNS host. The whole configuration is provider-neutral — the same five records work whether mail lands at TrekMail, Workspace, or any other credible host. Switching mailbox hosts later means updating the same five records to point at the new host.
The Five Configuration Steps
Five steps cover everything needed to use your domain for email. Order matters: MX before authentication, authentication before testing, testing before tightening DMARC. Each step's output feeds the next; skipping any creates downstream failures that take longer to debug than the step itself takes to do.
- Point MX records at the mailbox host. Two or three MX records with priority values.
- Publish the SPF record. One TXT record listing authorized senders.
- Publish DKIM per sender. One TXT record per mail-signing service.
- Publish DMARC at p=none. One TXT record with a reporting address.
- Round-trip test and tighten DMARC. Verify PASS at three receivers, then move DMARC to p=quarantine after two weeks.
The five-step sequence is the same whether you use your domain for email at 1 mailbox or 1,000. The records scale with sender count, not mailbox count. Adding more mailboxes doesn't require new DNS records; adding more external senders (marketing platform, transactional service, CRM) does — each new sender needs its own DKIM selector.
Step 1: Point MX Records at the Mailbox Host
Step one to use your domain for email is publishing MX records that point at the mailbox host's mail servers. The mailbox host provides two or three MX values with priority numbers (10, 20, 30) that indicate failover order. Receivers try the lowest-priority value first and fall back to higher numbers if it's unavailable.
Publish all the MX values the mailbox host provides — not just the lowest-priority one. The redundancy matters during the rare incidents where the primary mail server goes offline. Without the backup MX records, inbound mail bounces during outages instead of queueing for retry.
Step 2: Publish the SPF Record
Step two to use your domain for email is the SPF record. SPF declares which servers may send mail claiming to be from your domain. The record is a single TXT entry at the domain root with syntax like v=spf1 include:_spf.trekmail.net ~all for a TrekMail-hosted setup that uses only TrekMail to send.
If you have other senders (marketing platform, transactional service), include their SPF records too. Each include: directive counts as one DNS lookup, and the total across the entire resolution tree must stay under 10 lookups. Audit the SPF record quarterly to catch lookup-limit creep before it bounces legitimate mail.
Step 3: Publish DKIM Per Sender
Step three to use your domain for email is DKIM, which cryptographically signs outbound mail so receivers can verify it. Every service that sends "from" your domain needs its own DKIM record under a unique selector. The mailbox host generates its DKIM record; marketing platforms and transactional senders provide their own.
The records publish as TXT entries under selector-specific subdomains: trekmail._domainkey.yourcompany.com for TrekMail's selector, mailgun._domainkey.yourcompany.com for Mailgun's, and so on. Each is a long base64 string that must paste as a single contiguous TXT value with no line breaks. See email authentication SPF DKIM DMARC for the deeper auth walkthrough.
Step 4: Publish DMARC at p=none
Step four to use your domain for email is DMARC, which tells receivers what to do when SPF or DKIM fails. Start at p=none for two weeks. Reports surface every IP claiming your domain, the SPF/DKIM result, and whether alignment held. The audit catches legitimate senders you forgot in step two.
The DMARC record format is v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.com. Replace the rua address with a mailbox where you'll actually read reports. After two clean weeks at p=none, tighten to p=quarantine. After another month of clean reports, tighten to p=reject. The graduated policy prevents legitimate mail from bouncing during the audit phase.
Step 5: Round-Trip Test and Tighten DMARC
Step five to use your domain for email is round-trip testing. Send mail from the new mailbox to a Gmail, Outlook.com, and Yahoo address. Open each received message and check the headers. All three should read SPF=PASS, DKIM=PASS, DMARC=PASS. Any FAIL means a record needs fixing before going live with real traffic.
After two weeks of clean DMARC reports at p=none with everything passing, tighten to p=quarantine. After a month of clean reports at quarantine, tighten to p=reject. The steady-state DMARC policy for a mature setup is p=reject with monthly report review. See set up email on my domain for the alternative walkthrough framing.
The reason for the graduated policy is that p=reject at week one would bounce legitimate mail from senders you haven't yet authenticated. The two-week audit at p=none surfaces every legitimate sender via reports. The month at p=quarantine confirms the fix held. Only then is p=reject safe. Skipping the graduation breaks legitimate mail and creates customer complaints that point at you rather than at the misconfigured sender.
Most operators who use your domain for email and skip the graduation pay the price within days. The DMARC report queue floods with quarantined messages. Inbound replies stop arriving. The fix is to revert to p=none and restart the audit window — losing the time saved by skipping it the first time, and then some.
Multi-Sender Configuration
The multi-sender wrinkle when you use your domain for email is that each external service signing mail with your domain needs its own DKIM selector at your DNS host. Marketing platforms, transactional services, CRM tools, support-ticket systems — each needs its own selector to align with your domain.
The most common scenario where this matters: a small operation that started with one mailbox host adds a marketing platform six months later, then a transactional sender, then a CRM with built-in mail features. Each addition needs its own DKIM selector configured. Operators who don't realize this watch their inbox-placement rate degrade slowly as more services join the chain without proper authentication.
Without per-sender DKIM, mail from those services fails alignment even when DKIM technically passes (because they signed with their own domain instead of yours). The DMARC aggregate reports surface the misalignment within days of activation; the fix is to configure the selector at each service so it signs as your domain. The work is annoying but one-time per sender.
Next Steps
The full configuration to use your domain for email takes about two hours of total clock time and produces a setup that lands reliably in the inbox. Five DNS records: MX, SPF, DKIM, DMARC, round-trip tested. The sequence applies whether the operation is 1 mailbox or 1,000.
Test TrekMail Nano free at trekmail.net/pricing — no card required. The Nano tier covers 10 domains × 10 mailboxes; Starter expands to 50 × 100 when send volume grows. For the conceptual frame see custom domain email.
After the initial five steps, the ongoing maintenance to keep the setup working is light. Read monthly DMARC reports to confirm no unauthorized senders are claiming your domain. Audit SPF quarterly to catch lookup-limit creep before it bounces legitimate mail. Verify DKIM rotation annually — TrekMail handles this automatically on all tiers, but confirm it ran. The total annual maintenance time is under 30 minutes, which is what makes it practical to use your domain for email across many brands without dedicated infrastructure staff.
For multi-domain operators, the five steps repeat per domain with no shared state between domains. Each domain gets its own MX, SPF, DKIM, and DMARC records. TrekMail's bulk-domain endpoint handles up to 500 domains at once, which compresses the per-domain provisioning work for agency-scale operations from days to hours.
