DarDev sends every Listmonk campaign and automated outreach message from send.dardev.net—not from the root @dardev.net domain that Zoho hosts for team inbox mail. That split is deliberate: one domain handles people replying to humans, the other handles bulk and product email with its own SPF, DKIM, DMARC, and reputation history.
We run this pattern on the Unified Mailer stack described in our inside-unified-mailer-stack guide. If you operate CRM plus marketing mail yourself, the same principle applies even when your inbound provider is Gmail, Zoho, or Microsoft 365.
Two jobs, one brand domain
A single DNS zone like dardev.net can serve multiple mail roles, but they should not share one sending identity. Root @dardev.net at DarDev stays on Zoho: MX records point to Zoho, and the root SPF TXT authorizes Zoho's servers. That is where ahmed@dardev.net receives customer replies, vendor invoices, and internal threads.
Outbound product and marketing traffic uses a dedicated subdomain—send.dardev.net—with DNS records that authorize only our Stalwart MTA on dardev-vps (51.75.205.103). Listmonk campaign From headers look like DarDev <noreply@send.dardev.net>. Recipients still recognize the brand; receivers at Gmail and Outlook see authentication aligned to the subdomain that actually submitted the message.
SPF on the send subdomain
Sender Policy Framework (SPF) tells receiving mail servers which hosts may send mail claiming to be from your domain. On send.dardev.net we publish a TXT record scoped to that subdomain only: v=spf1 ip4:51.75.205.103 ~all. Receivers evaluating mail from noreply@send.dardev.net check send.dardev.net's SPF—not the root Zoho SPF.
Keeping SPF off the root while Zoho owns inbound is critical. If we added our VPS IP to @dardev.net SPF for campaigns, we would broaden the surface area for spoofing the same addresses employees use daily. Subdomain SPF contains blast volume and infrastructure changes to the channel that already expects machine traffic.
DKIM signing with Stalwart
DomainKeys Identified Mail (DKIM) adds a cryptographic signature tied to a selector in DNS. Stalwart generates keys when you onboard send.dardev.net in the admin UI at mta.dardev.net. We paste the public key into GoDaddy as mail._domainkey.send TXT—selector mail, domain send.dardev.net—so the signature domain (d=) matches the From subdomain.
Misaligned DKIM is a common reason marketing mail lands in spam while transactional notices pass. Signing with the root domain while sending from a subdomain fails alignment under strict DMARC policies. Operating the MTA ourselves means we rotate keys on schedule without opening a ticket to a shared SaaS pool.
DMARC policy and reporting
DMARC builds on SPF and DKIM alignment and tells receivers what to do when authentication fails. Our _dmarc.send TXT record publishes v=DMARC1; p=quarantine; rua=mailto:dmarc@dardev.net. Aggregate reports flow to an inbox we monitor, which surfaces list hygiene problems, forged senders, or DNS drift after infrastructure moves.
We start with quarantine on the sending subdomain rather than reject, so legitimate forwarders or list mirrors do not hard-fail while we tune rules. Root @dardev.net can keep its own DMARC posture via Zoho without inheriting penalties from a large product newsletter. For a deeper split between campaign types, see email-compliance-marketing-transactional.
Reputation isolation
Mailbox providers score domains and IPs based on complaint rates, bounce handling, and engagement. A product launch email to ten thousand Hesabi prospects should not share reputation with ahmed@dardev.net negotiating an enterprise contract. Subdomain isolation limits blast fallout: if a list import goes wrong, we pause campaigns on send.dardev.net while Zoho inbox deliverability for @dardev.net stays intact.
PTR (reverse DNS) reinforces the story. OVH maps 51.75.205.103 to mta.dardev.net—the SMTP banner and HELO hostname Stalwart presents—while the friendly From remains on send.dardev.net. Consistent forward and reverse DNS reduces greylisting and spam-folder routing for MENA and EU recipients.
- Cold CRM prospects stay in Twenty until explicit opt-in before Listmonk lists
- Double opt-in on news.dardev.net subscribe forms
- Bounce and complaint webhooks reviewed before the next campaign batch
- Separate product lists (Hesabi, DarDevLab, EscaHire waitlist) to target content precisely
Operational checklist we follow
- DNS on send only
SPF, DKIM, and DMARC TXT records live on send.dardev.net. Root @ records remain Zoho for MX and SPF.
- Stalwart defaults
Server hostname mta.dardev.net, default sending domain send.dardev.net, submission listener on port 587.
- Listmonk SMTP
Host stalwart inside Docker Compose, user noreply@send.dardev.net, password from STALWART account—not Zoho credentials.
- Verify before scale
dig +short send.dardev.net TXT and mail._domainkey.send.dardev.net TXT after every DNS edit; send seed messages to Gmail and Outlook test inboxes.
Common mistakes
- Using @dardev.net in Listmonk because the brand looks cleaner
- Copying root Zoho SPF onto send and creating duplicate or conflicting includes
- Forgotten DKIM rotation after cloning VPS or restoring Stalwart data
- Shared IP sending both cold outreach and newsletter without bounce discipline
- Treating transactional receipts and marketing promos as one list (see compliance guide)
Self-hosting Listmonk and Stalwart was a product decision as much as a DNS trick—we document the tradeoffs in self-hosted-email-vs-saas. The subdomain rule still applies if you later move SMTP to a relay; only the SPF include changes.
Questions about our mailer architecture or deliverability reviews for your own stack: contact us via news.dardev.net or dardev.net—requests land in Twenty CRM like any other DarDev Services lead.
Can we still receive replies at @dardev.net?
Yes. Zoho continues to host team mailboxes on the root domain. Only outbound Listmonk and automated product sends use noreply@send.dardev.net. Set Reply-To to a monitored @dardev.net address when you want human responses.
Why not add the VPS to root SPF instead of a subdomain?
That would let any compromise on the campaign MTA affect authentication for employee mail and increase spoofing risk for addresses receivers trust. Subdomain SPF scopes bulk sending to infrastructure built for it.
What From address should Listmonk campaigns use?
DarDev <noreply@send.dardev.net> with SMTP user noreply@send.dardev.net on Stalwart port 587. Do not use Zoho SMTP or an @dardev.net From header for marketing lists.
How do we verify DNS is correct?
After propagation, run dig +short send.dardev.net TXT for SPF, dig +short mail._domainkey.send.dardev.net TXT for DKIM, and confirm PTR for 51.75.205.103 resolves to mta.dardev.net. Send test campaigns to Gmail and Microsoft seed accounts.
Does this apply to transactional mail too?
Product receipts and password resets should still originate from send.dardev.net (or a sibling transactional subdomain) with aligned SPF/DKIM. Keep marketing and transactional lists separate; the compliance guide explains consent differences.
