DarDev runs two mail systems on one brand domain: Zoho hosts human inbox at @dardev.net, and Stalwart on dardev-vps handles every Listmonk campaign, daily digest, and automated outbound message from send.dardev.net. The split is not a workaround—it is the operational rule in our MAIL-RULES team guide and the DNS layout documented in GoDaddy runbooks.
If you operate CRM plus marketing mail yourself, the same pattern applies whether inbound is Zoho, Google Workspace, or Microsoft 365. For the authentication story behind the subdomain, read why-send-dardev-subdomain; for where Listmonk and Stalwart sit in compose, see inside-unified-mailer-stack.
Two domains, two jobs
Root dardev.net answers one question: where do employees read and reply as humans? MX records on @ point to Zoho. contact@dardev.net receives inbound contact forms, Twenty workflow replies, and vendor threads. SPF on @ authorizes Zoho's servers only. Finance and leadership never compete with newsletter volume for the same authentication envelope.
send.dardev.net answers a different question: where does machine traffic exit? MX on send points to mta.dardev.net (Stalwart). SPF, DKIM, and DMARC TXT records live on the send subdomain. Listmonk From headers use DarDev <noreply@send.dardev.net>. Recipients still see DarDev; receivers at Gmail and Outlook evaluate alignment against the host that actually submitted SMTP.
From and Reply-To by scenario
- Listmonk product campaign — From noreply@send.dardev.net; Reply-To contact@send.dardev.net or a product-specific monitored address
- Daily internal digest — From news@send.dardev.net via sync-worker direct SMTP
- Sync-worker drip or batch jobs — From news@send.dardev.net unless a manifest overrides the product subdomain
- Twenty welcome or 1:1 human workflow — From contact@dardev.net on Zoho; Reply-To same
Reply-To is where humans re-enter the loop. Campaign mail often sets Reply-To to contact@send.dardev.net so operators read responses in Roundcube at webmail.dardev.net without mixing threads into personal Zoho inboxes. When a message must feel like a person wrote it—booking links, account onboarding—Twenty workflows stay on Zoho contact@dardev.net.
DNS: what stays on root vs send
GoDaddy DNS-GODADDY.md is explicit: do not change MX or SPF on @. Zoho MX and Zoho SPF remain untouched when you add Stalwart records. On send you add MX to mta.dardev.net, SPF authorizing 51.75.205.103, DKIM at mail._domainkey.send, and DMARC at _dmarc.send with quarantine policy and aggregate reporting to dmarc@dardev.net.
PTR at OVH maps 51.75.205.103 to mta.dardev.net—the HELO hostname Stalwart presents—while friendly From addresses remain on send.dardev.net. Misaligned PTR is a common greylisting trigger for MENA and EU recipients; we verify after every VPS migration.
Authentication checklist before campaigns
- SPF on send only
dig +short send.dardev.net TXT shows v=spf1 including the VPS IP. Root @ SPF still references Zoho.
- DKIM from Stalwart wizard
Copy mail._domainkey.send TXT from mta.dardev.net admin after onboarding send.dardev.net. Selector mail must match the signing domain.
- DMARC on send
_dmarc.send publishes p=quarantine and rua for aggregate reports. Tune before moving to reject.
- SMTP path
Listmonk uses stalwart:587 inside Docker with noreply@send.dardev.net—not Zoho SMTP. Automated jobs use sync-worker mail-sender to the same MTA.
- Validation scripts
Run scripts/check-dns-mail.sh and scripts/validate-stalwart-listmonk.sh after DNS edits or Stalwart restores.
Why DarDev Ops does not configure mail
DarDev Ops orchestrates solutions and surfaces connector health—it does not own SMTP From, Reply-To, or DNS paste jobs. Authoritative mail identity lives in Zoho admin, Stalwart domains, Listmonk settings, and GoDaddy/OVH. That boundary prevents a UI toggle from silently repointing campaigns at the wrong domain.
Cold CRM prospects reinforce the split: OECT, Startup Tunisia, DarDev Services, and 20.tn school imports land in Twenty only. Listmonk lists wait for public subscribe double opt-in or documented consent. Blasting imported rows would damage send.dardev.net reputation without touching Zoho—but compliance and trust damage is worse than a spam folder.
Webmail on the send subdomain
Roundcube at webmail.dardev.net authenticates against Stalwart mailboxes on send.dardev.net and sales.dardev.net. contact@send.dardev.net is the practical inbox for campaign replies. Root @dardev.net mail stays in Zoho. Operators learn quickly which webmail login to open after a product launch versus a finance thread.
Common mistakes we audit for
- Pointing Listmonk SMTP at Zoho because credentials already exist
- Adding VPS IP to root SPF to fix a campaign test
- Using a prettier @dardev.net From in Listmonk templates
- Forgotten DKIM rotation after restoring Stalwart data from backup
- Mixing cold CRM imports into marketing lists without consent fields
Self-hosting Listmonk and Stalwart was a deliberate product choice—we document tradeoffs in self-hosted-email-vs-saas. The Zoho-plus-Stalwart split still applies if you later relay through a third-party ESP; only the SPF include and signing keys change.
Questions about mail architecture or deliverability reviews for your stack: reach DarDev via news.dardev.net or dardev.net—requests land in Twenty CRM like any Services lead.
Can staff still use ahmed@dardev.net in Zoho?
Yes. Root @dardev.net is unchanged. Only outbound Listmonk and automated product mail use send.dardev.net identities on Stalwart.
Where do campaign replies go?
Typically contact@send.dardev.net in Roundcube webmail, or Reply-To contact@dardev.net when you want responses in Zoho. Pick one monitored path per campaign.
What breaks if we add Stalwart to root SPF?
You broaden spoofing surface for employee addresses and blur reputation between human and bulk traffic. Keep VPS authorization on send.dardev.net SPF only.
How does this relate to sales.dardev.net and agents.dardev.net?
Additional Stalwart outbound subdomains with their own SPF, DKIM, DMARC, and BIMI records. Root Zoho and send.dardev.net rules still apply—never route Listmonk through Zoho.
What should we verify before the first large send?
SPF, DKIM, DMARC, and PTR checks via validation scripts; seed messages to Gmail and Microsoft test inboxes; confirm warm-up profile if volume exceeds daily throttle.
