A mail domain is a regular domain name (yourcompany.com) configured to receive and send email. The configuration is four DNS records: MX, SPF, DKIM, and DMARC. Each record does one job, and the four together turn a domain that owns nothing more than a website into one that handles mail reliably.
Most "mail domain" explanations skip the record-by-record walkthrough and leave operators with a vague sense that DNS does something mysterious. It doesn't. The four records are simple text entries with specific syntax that any operator can publish through a DNS dashboard. Knowing what each one does makes the rest of the setup obvious.
This guide walks the four records with what each does and the syntax for each. For the broader frame see custom domain email.
What a Mail Domain Actually Is
Any domain name can be configured to handle email by adding four DNS records to whatever already exists. MX points at the mail server. SPF lists authorized senders. DKIM cryptographically signs outbound mail. DMARC tells receivers what to do when authentication fails. The four together turn a bare domain into a properly functioning mail domain.
The same domain can host a website at the root and serve mail at addresses on the domain. The four records don't conflict with website records because they use different record types for different purposes. Most operational mail domains are also websites; the two services live at potentially different vendors and coordinate through DNS. Moving mail to a new host means updating only the mail-related records — the website records stay untouched.
The Four DNS Records at a Glance
Four DNS records define a working mail domain. Each record has a specific job and a specific syntax. The mailbox host generates exact values; you publish them at your DNS host. The table summarizes what each record does and where it lives in the DNS tree.
| Record | Job | Where it lives | Required? |
|---|---|---|---|
| MX | Routes inbound mail to the mailbox host | yourcompany.com (root) | Yes — without it, no inbound mail arrives |
| SPF | Lists authorized outbound senders | yourcompany.com (root, as TXT) | Yes — without it, outbound lands in spam |
| DKIM | Cryptographically signs outbound mail | selector._domainkey.yourcompany.com (TXT) | Yes — without it, alignment fails |
| DMARC | Tells receivers how to handle auth failures | _dmarc.yourcompany.com (TXT) | Highly recommended — without it, spoofing goes unreported |
The four records together cost nothing beyond the DNS host (free at Cloudflare). The configuration takes about 15 minutes once the mailbox host has generated the values. The benefit is reliable inbox placement, visible spoofing reports, and authentication that survives modern receiver scrutiny.
Record 1: MX (Where Mail Goes)
MX points at the mail server that receives inbound mail. The record format is a priority number plus the server hostname. Multiple MX records with different priorities provide failover; receivers try the lowest-priority value first and fall back to higher numbers if needed.
Typical values for a TrekMail-hosted mail domain: 10 mx1.trekmail.net and 20 mx2.trekmail.net. The mailbox host provides exact values; you publish all of them at your DNS host. Publishing just the primary without the backup means mail bounces during rare incidents when the primary is unavailable, instead of queueing for retry.
Record 2: SPF (Who Can Send)
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. Each include: directive points at another SPF record listing actual sending IPs. Misconfigure it and legitimate mail bounces silently.
Every external service that sends mail from your domain (marketing platform, transactional sender, support-ticket tool) needs to appear in SPF, either directly by IP or through an include. The total resolution tree must stay under 10 DNS lookups. Audit the SPF record quarterly to catch lookup-limit creep before legitimate mail starts bouncing. See email authentication SPF DKIM DMARC for the deeper walkthrough.
Record 3: DKIM (Cryptographic Signature)
DKIM holds a public key that receivers use to verify the signature on outbound mail. The mailbox host signs every message with the corresponding private key; the receiver checks the signature against the public key in DNS. A passing signature confirms the sender controls the domain.
DKIM records publish 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. Multiple selectors can coexist; each service signing for your mail domain gets its own. See DKIM setup for the deeper walkthrough.
Most operators miss the per-sender pattern at first. A new marketing platform added six months after initial setup needs its own selector. A transactional sender added a year later needs another. Without per-sender coverage, alignment fails silently and mail from those services lands in spam — even though the mail domain itself has a clean SPF/DKIM/DMARC configuration. One DKIM record per active sender is the fix.
Record 4: DMARC (Policy and Reports)
DMARC tells receivers what to do when SPF or DKIM fails. The record is a TXT entry at _dmarc.yourcompany.com with syntax like v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourcompany.com. The p= value sets the policy (none, quarantine, or reject). The rua= address receives aggregate reports.
Start at p=none for two weeks of audit. Reports surface every IP claiming to send from your mail domain and whether alignment held. After clean reports for two weeks, tighten to p=quarantine. After another month, tighten to p=reject. The graduated rollout prevents legitimate mail from bouncing during the audit phase, when you may discover senders you forgot to authenticate.
How the Four Records Work Together
The four records work together as a stack. MX gets inbound mail to the right server. SPF declares which outbound senders are legitimate. DKIM lets receivers verify the cryptographic signature. DMARC ties SPF and DKIM together and tells receivers what to do when either fails.
The interaction is what makes the stack work. SPF without DKIM means most outbound mail fails DMARC alignment (because alignment usually checks DKIM, not SPF). DKIM without DMARC means receivers don't know what to do when DKIM fails. DMARC at p=reject without proper SPF and DKIM coverage bounces legitimate mail. The four records have to be configured together; partial coverage costs deliverability rather than gradually improving it.
How TrekMail Generates the Four Records
TrekMail generates exact values for all four records during domain setup. Add the domain in the dashboard; the platform generates MX values pointing at TrekMail's mail servers, SPF including _spf.trekmail.net, DKIM under a TrekMail-specific selector with a freshly-generated key, and DMARC at p=none with a default reporting address. You copy-paste each into your DNS host's dashboard.
The platform handles the parts that don't vary per operator: SPF include path, DKIM key generation, key rotation schedule, DMARC report aggregation. You handle the parts that do vary: which DNS host the records publish at, which mailbox you want DMARC reports routing to, when to tighten DMARC policy. See domain email for the broader frame.
Next Steps
A working mail domain is four DNS records published correctly at a DNS host you control. MX routes inbound mail. SPF declares authorized senders. DKIM signs outbound. DMARC ties everything together with policy and reporting. The four records take about 15 minutes to publish and deliver reliable inbox placement for years — as long as the quarterly audit discipline holds.
Test TrekMail Nano free at trekmail.net/pricing — no card required, no trial expiry. The Nano tier covers 10 domains × 10 mailboxes; Starter at $4/month expands to 50 × 100 when send volume grows beyond Nano's cap.
The four records benefit from a "set once, audit quarterly" discipline. MX rarely changes after setup. SPF accumulates new senders over months as the operation adds marketing platforms and transactional services. DKIM keys rotate automatically on most platforms. DMARC reports flow continuously and reveal both legitimate sender drift and spoofing attempts. The quarterly audit cycle is light and prevents most deliverability incidents that show up in operations that ignore the records after initial setup.
For operators with multiple brand domains, each mail domain repeats the four-record setup independently. The MX values point at the same mailbox host; the SPF, DKIM, and DMARC records publish per domain. TrekMail's bulk-domain endpoint (up to 500 domains at once) compresses the per-domain setup substantially for agency-scale operations.
The four-record framework is also the diagnostic ladder when something goes wrong. Inbound mail not arriving? Check MX. Outbound mail in spam? Check SPF and DKIM. Spoofing reports flooding in? Check DMARC policy. Each failure mode points at one specific record, which makes troubleshooting fast.
