DEV Community

Cover image for Trekmail: Four DNS Records, Generated The Moment A Domain Gets Added
Mihail/GoodInvestments
Mihail/GoodInvestments

Posted on Originally published at en.investitiibune.ro

Trekmail: Four DNS Records, Generated The Moment A Domain Gets Added

Trekmail: Four DNS Records, Generated The Moment A Domain Gets Added

SPF, DKIM, DMARC, and MTA-STS are the four records that decide whether a client's email lands in an inbox or a spam folder, and getting all four right by hand, on every new domain, is exactly the kind of repetitive DNS work that gets skipped under deadline pressure. None of the four does the same job -- SPF lists which servers may send for a domain, DKIM signs outgoing mail so it can't be altered in transit, DMARC tells receiving servers what to do when SPF or DKIM fails, and MTA-STS forces incoming mail onto an encrypted connection instead of letting it silently downgrade to plaintext. Miss one, and the other three stop meaningfully protecting the domain -- a DMARC policy with no aligned SPF/DKIM underneath it is just a TXT record nobody enforces. Trekmail's architecture removes the manual step rather than adding a checklist to follow more carefully.

What Gets Automated On Every New Domain

Bulk-adding domains puts up to a thousand client sites under a single dashboard, and SPF, DKIM, DMARC, and MTA-STS generation fires automatically the instant each one gets added -- no manual DNS record entry, no waiting on a registrar's control panel, no copying the same four TXT values into a different provider's interface for the fortieth time this quarter. The records are generated already aligned to each other, which is the part that's easy to get wrong doing it by hand -- a DKIM selector that doesn't match the published key, or an SPF record that lists the wrong sending IP after a provider migration, both pass a quick glance and both quietly break delivery.

Moving Mail Without The Manual Export

Built-in IMAP migration pulls existing mail straight from Gmail, Outlook, Yahoo, or iCloud into the new setup, sparing the export-import routine between providers that usually stalls a migration for days and leaves a window where old and new mailboxes both exist, unsynced, while someone tries to remember which client asked which question on which system.

Routing And Catching Problems Early

  • Per-domain SMTP routing keeps the Trekmail relay or routes through Postmark, Resend, SES, or Mailgun, whichever keeps a given domain's delivery rate highest -- routing decisions happen per domain, not as one blanket setting for every client on the account
  • Rspamd scoring runs against outgoing mail before it leaves, catching the kind of content/header combination that trips spam filters on the receiving end, rather than finding out after a client already missed the message
  • Bounce reporting surfaces soft-bounce patterns while they're still isolated to one domain -- the alternative is an agency finding out three weeks later that a client's invoice never arrived, because nobody was watching bounce logs domain by domain

Testing Before Committing

The Nano tier hands over ten free domains to test before any card details enter the picture -- enough to run the DNS generation and IMAP migration against a real domain, not a sandboxed demo, and see what the SPF/DKIM/DMARC output actually looks like before touching a paying client's setup. A fourteen-day trial on every paid tier covers migrating one real domain before further budget commitment, which is roughly the timeframe needed to watch a full billing cycle of bounce reports come back clean.

Full breakdown of what each tier actually unlocks: read the audit here.

Top comments (0)