How the garden sends newsletters and takes replies

The garden now has a working two-way address, hello@ng-weijie.com: Resend sends the newsletters, ImprovMX catches the replies, and neither steps on the other because I split the domain's two jobs across them.

Here is how a reader's email travels, and the one setting that nearly broke it.

The garden's mail loop. Steps: 1) Subscribe: Email is validated and added to a Resend Audience; 2) Send: A Resend Broadcast mails new notes from hello@ng-weijie.com; 3) Reply: A reader replies to hello@ng-weijie.com; 4) Forward in: ImprovMX catches it and forwards to my Gmail; 5) Answer out: Gmail replies as hello@ through Resend SMTP
The five steps of the loop, from a new subscriber to a signed reply.

The prompt waits until you have actually read

The subscribe box does not ambush anyone. It opens only after you pass the halfway mark and read for eight seconds, so it asks the people who are actually reading, not the ones who bounced (a short note counts as read once the dwell is met). The moment it opens, it stamps the time in your browser and stays quiet for seven days, whether you subscribe, dismiss it, or ignore it, so nobody sees it twice in a week. That memory is localStorage, per browser, never a server.

Subscribe and a sakura blooms, five petals and a short confetti burst in the garden's pink; for reduced motion the same flower opens, held still.

Subscribe, then send

A reader drops their email in the form on the garden. A small serverless endpoint validates it, silently drops anything that trips the honeypot, and adds the address to a Resend Audience, the subscriber list. When a batch of notes is worth sharing, a Resend Broadcast mails a summary from hello@, signed by the domain so it lands in inboxes, not spam. Store the address, then send to it. The content pipeline fills what goes out.

Replies land in Gmail, and go back out as hello@

Resend only sends. A reply to hello@ needs a mailbox my domain did not have, so ImprovMX (free) forwards hello@ into my Gmail. To answer as hello@ instead of my personal address, Gmail's "send mail as" pushes the reply back out through Resend's SMTP, still signed by the domain. Two tools, two jobs.

Job Tool Key DNS record
Store and send to subscribers Resend Audience and Broadcast DKIM, plus a return-path MX on send.
Receive replies to hello@ ImprovMX forwarding root MX pointed at ImprovMX
Reply as hello@ from Gmail Gmail send-as over Resend SMTP none new, reuses the verified domain

One domain cannot be a mailbox and a sender by accident

This is where it bit me. Namecheap's built-in forwarding owns the MX records and locks them, and switching it on silently deleted the return-path MX that Resend needs to stay verified. Both wanted to steer the same MX, and the convenient toggle won. The fix: drop the built-in forwarder, switch to Custom MX, and place every record by hand so ImprovMX's receiving MX and Resend's sending MX sit side by side. They coexist because they live on different hosts, the root for receiving and a send subdomain for sending.

The bottom line

Sending mail and receiving mail are two systems, not one convenience. Give each its own tool and its own records, keep them on separate hosts, and one domain can be both a newsletter and an inbox.