Required DNS Records: MX, SPF, DKIM, DMARC

To activate your domain, TrekMail looks for four key DNS records. You’ll copy the exact values from your dashboard into your DNS provider, and we’ll show you what’s missing if anything doesn’t match.

If the domain’s incoming mail is staying with another provider and you only want to send from its addresses, the MX record is not one of them, see Send From a Domain You Do Not Host. Your dashboard drops it from the list automatically once you say so.

Who this is for

• System administrators configuring DNS.
• Users troubleshooting delivery issues or "Red" DNS status.

The four pillars of email DNS

1. MX Record (Receiving Mail)

Host: @ (or your domain root) Value: mail.trekmail.net. Priority: 10

This redirects incoming email to our servers.

• Common Mistake: Leaving old MX records (like Google or GoDaddy) alongside the TrekMail one. This splits your mail and causes lost messages. Remove all other MX records.
• Sending only? Leave the MX record exactly as it is. Open the domain, use the Incoming mail chip under its name, and choose to keep incoming mail with the current provider. The dashboard then asks for SPF, DKIM and DMARC and nothing else, and stops warning you about the MX record it can see. The domain can send, but it cannot hold mailboxes.

2. SPF Record (Authorized Senders)

Host: @ Required Include: include:spf.trekmail.net

SPF (Sender Policy Framework) is a whitelist of IPs allowed to send as you.

• If you have no SPF record: Create a TXT record with v=spf1 include:spf.trekmail.net -all.
• If you already have SPF: Edit your existing record to add our include, and keep the terminator you already have.
  • Bad: Two separate TXT records.
  • Good: v=spf1 include:spf.google.com include:spf.trekmail.net -all.
  • Also good: v=spf1 include:spf.google.com include:spf.trekmail.net ~all.

On the terminator: -all and ~all both pass our check. All TrekMail requires is that include:spf.trekmail.net appears before whichever one you use. Use ~all as a cautious temporary choice while you are still finding every legitimate sending service. Move to -all only after the SPF record includes all of them. Forwarding is a separate issue: it can break SPF regardless of this choice, which is why aligned DKIM matters. ?all and +all are not accepted; ?all is treated as if no SPF were published, and +all authorizes everyone.

Note on SPF Failures: If you see SPF failures in DMARC reports but DKIM passes, this is often normal. It typically means mail was forwarded (e.g., Gmail auto-forwarding) or passed through a security gateway. DMARC should still pass via DKIM alignment. Only investigate if both SPF and DKIM fail.

3. DKIM Record (Digital Signature)

Host: dkim._domainkey Value: (Unique long string starting with v=DKIM1...)

DKIM (DomainKeys Identified Mail) lets a receiving server verify the signing domain and the signed parts of the message.

• Provisioning: If the value says "Generating...", wait for the dashboard to display the key. Then publish that exact host and value and run Verify DNS.
• Formatting: Some DNS providers (like Route53) want the value split into quotes; most just want the full string. Paste it exactly as shown.
• Already have a record at this name? Then another service signs mail for this domain too. Don't replace it, check your dashboard: when the usual name is taken we generate the key under a different one, and the DNS tab shows the exact name to use. Both keys can live side by side.
• Using custom SMTP? The external provider can require its own DKIM record under another selector. Publish the record that provider gives you as well; TrekMail's key does not make the external provider's mail pass DKIM.

4. DMARC Record (Policy Enforcement)

Host: _dmarc Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@trekmail.net

DMARC ties SPF and DKIM together.

• Policies (p):
  • none: Monitoring mode. Start here if you are still identifying every legitimate sender.
  • quarantine: Ask receivers to treat failing mail as suspicious. This is TrekMail's default template.
  • reject: Ask receivers to reject failing mail. Move here only after reviewing reports and confirming alignment.
• TrekMail's Check: We look for any valid v=DMARC1 record. You are free to customize tags like rua (reporting address) as you see fit.

If TrekMail is the only service sending for a new domain, the dashboard's p=quarantine template is a practical starting point. If Google Workspace, Microsoft 365, a help desk, or another service also sends for the domain, begin with p=none, review reports, and enforce gradually so legitimate mail is not quarantined by mistake.

5. Advanced Deliverability (Recommended)

While not strictly required for basic flow, we recommend adding these records to improve security and deliverability reporting. Read the full guide on Recommended Records.

TLS Reporting (TLS-RPT)

Host: _smtp._tls Value: v=TLSRPTv1; rua=mailto:tlsrpt@trekmail.net

• Purpose: Allows other mail servers to report encryption failures when connecting to your domain.

MTA-STS

MTA-STS Policy (TXT): Host: _mta-sts Value: Copy the exact v=STSv1; id=... value shown in your dashboard. The identifier changes when the published policy changes.

MTA-STS CNAME: Host: mta-sts Value: mta-sts.trekmail.net.

• Purpose: Enforces strict TLS encryption for incoming mail, preventing downgrade attacks.

Common mistakes & quick fixes

• Symptom: SPF status is "Conflict".
  • Fix: Check for multiple TXT records starting with v=spf1. You can only have one.
• Symptom: DNS changes aren't showing up.
• Likely Cause: DNS publishing and resolver caches can take time to converge.
  • Fix: Confirm the type, host, value, and MX priority at your DNS provider. Then run a new check after the provider has published the change.