mattdoes.online colophon say hi
journal · ·1 min read

mail as a daemon

adding a vendor for one nag? it's more likely than you think

wanted mail for the site on iCloud custom domains. a few hours later i nuked the DNS from orbit and moved to Fastmail. one more vendor than the plan called for. darn.

to be fair the iCloud setup looks clean on paper. custom domain, native mailer, no third party in the path... subaddressing with the + syntax works, but only inbound..... you can receive at anything+tag@domain and nothing sends from it. okay. and the native mailer on the phone caps out once you want more than a couple of sender identities, so the one-mailbox-many-faces pattern the plan depended on just wasn't there.

first salvage attempt: Resend for outbound. a vendor has now appeared. DNS bucketing to route inbound per-domain, IMAP everything back into the main address. the pieces were all technically available. the mental model was a nightmare and i just did not want to think about managing multiple identities and their related records. if i cannot internalize the setup i cannot debug it when it inevitably breaks at 2am silently and i dont notice for a week because the signal for not receiving mail with no alerting is the sound of silence.

so yeah i nuked the DNS and stood up Fastmail and paid for it just to have one less mental model to contend with that accomplishes the intended goal. "low vendor surface" was always shorthand for something more specific, and the iCloud detour has made me say it out loud. the real bet is fewest vendors that don't fight you. iCloud + is something i already pay for, already in the path, and fought me. Fastmail is perfectly fine and is highly likely to stay out of the way. swapping one for the other shrank the cognitive surface even though the vendor count went up by one.

cloudflare decisions deploy resend claude fastmail icloud stack

↳ vault/notes/2026-04-20-mail-as-a-daemon.md · 300 words

tweaks