Blog
Posts about the development process, solved problems and learned technologies
Building Legit Email Systems, Not Spam Cannons
# When B2B Email Marketing Becomes a Minefield: One Developer's Reality Check The email-sender project looked straightforward at first glance: build a system for companies to reach out to other businesses with personalized campaigns. Simple enough, right? But diving deeper into the work logs revealed something far more nuanced—a developer wrestling with the intersection of technical feasibility and legal responsibility. The core challenge wasn't architectural; it was ethical. The project required creating *legitimate* bulk email systems for B2B outreach, but the initial requirements contained red flags. Phrases like "avoid spam filters" and "make emails look different" triggered serious concerns. These are the exact techniques that separate compliant email marketing from the kind that gets you blacklisted—or worse, sued. What fascinated me about this work session was how the developer approached it: not by building the requested system, but by *questioning the premises*. They recognized that even with company consent, there's a critical difference between legitimate deliverability practices and filter-evasion tactics. SPF, DKIM, and DMARC configurations are proper solutions; randomizing email content to trick spam detection is not. The developer pivoted the entire discussion. Instead of building a system that technically could send emails at scale, they proposed a legitimate alternative: integrating with established Email Service Providers like SendGrid, Mailgun, and Amazon SES. These platforms enforce compliance by design—they require opt-in verification, maintain sender reputation, and handle legal compliance across jurisdictions. They introduced concepts like double opt-in verification, proper unsubscribe mechanisms, and engagement scoring that work *with* email providers rather than against them. The architecture that emerged was sophisticated: PostgreSQL for consent tracking and email verification, Redis for queue management, Node.js + React for the application layer. But the real innovation was the *governance structure* baked into the database schema itself—separate tables for tracking explicit consent, warmup logs to gradually build sender reputation, and engagement metrics that determine which recipients actually want to receive messages. **Did you know?** The CAN-SPAM Act (2003) predates modern email filtering by over a decade, yet companies still lose millions annually to non-compliance. The law requires just four things: honest subject lines, clear identification as advertising, a physical address, and functional unsubscribe links. Most spam doesn't fail because of technical sophistication—it fails because it violates these basic requirements. The session ended not with completed code, but with clarified direction. The developer established that they *could* help build a legitimate B2B email platform, but wouldn't help build systems designed to evade filters or manipulate recipients. It's a reminder that sometimes the most important technical decisions aren't about what to build, but what *not* to build—and why that boundary matters. 😄 Why do compliance officers make terrible programmers? They keep stopping every function with "let me verify this is legal first."
From Spam to Legitimacy: Rebuilding Email Systems Right
# When Legal Requirements Meet Engineering Reality: Redesigning an Email Campaign System The email-sender project started with a simple pitch: build a system to send bulk campaigns to companies. But as the developer dove deeper, the reality of spam filters, compliance laws, and genuine personalization became starkly clear. This wasn't going to be a quick template-and-send solution. The initial approach raised red flags immediately. The plan mentioned techniques that sounded like deliverability optimization—randomizing content, rotating domains, varying email formats to "avoid spam filters." But upon closer inspection, these were borderline evasion tactics. Even with formal consent from recipients, circumventing email provider protections crossed an ethical line. That's when the developer made a critical decision: pivot toward legitimacy. **The first thing done** was dismantling the spray-and-pray architecture. Instead of building a custom sender from scratch, the plan shifted to integrating established Email Service Providers—SendGrid, Mailgun, and Amazon SES. These platforms already handle SPF, DKIM, and DMARC authentication, maintain sender reputation, and enforce opt-in requirements. Why reinvent a compliance nightmare? The new architecture centered on consent management. A PostgreSQL database would track double opt-in subscriptions, unsubscribe events, and engagement metrics. The system would use Node.js backend services to manage a queue of legitimate campaigns, with Redis handling rate limiting and delivery scheduling. Instead of mutation techniques, personalization would come from actual data: company information, previous interactions, and AI-generated content tailored to genuine business interests. **Unexpectedly**, the most complex piece wasn't the personalization engine—it was the email templating syntax itself. The initial plan used Liquid template syntax (think Shopify's templating), but the production stack demanded Handlebars. A simple oversight: `{{value | default: "x"}}` doesn't work in Handlebars. The correct syntax requires conditional blocks: `{{#if value}}{{value}}{{else}}x{{/if}}`. This small detail cascaded through 14 different email templates. The database schema expanded to 8 core tables: consent_logs for tracking opt-ins, verification_attempts for email validation, warmup_logs to monitor sender reputation, ai_generations for personalization history, and engagement_scoring for analytics. Every table told a story of compliance-first design. Here's something fascinating about DMARC (Domain-based Message Authentication, Reporting & Conformance): it's not a spam filter at all. It's a reporting mechanism that tells domain owners when someone is impersonating their email. Major inbox providers like Gmail use DMARC reports to block entire domains, not individual emails. This is why building sender reputation matters far more than obfuscating content. The project taught a hard lesson: sometimes the right engineering decision isn't the shortest path. B2B email marketing in 2025–2026 rewards systems that respect both user intent and technical standards. The developer's refusal to compromise turned a compliance problem into a technical one worth solving properly. 😄 *Your DMARC alignment will thank you on Monday morning.*