The Developer's Guide to Email Deliverability in 2025

Why Deliverability Matters More Than Ever

In 2025, inbox providers like Gmail, Yahoo, and Microsoft have tightened their filtering algorithms significantly. Google now requires bulk senders (those sending more than 5,000 messages per day) to fully authenticate with SPF, DKIM, and DMARC—and Yahoo has followed suit. If your application sends transactional or marketing email without proper authentication, you are virtually guaranteed to land in spam.

Deliverability is not just about authentication, though. It encompasses your sender reputation, engagement metrics, content quality, and infrastructure choices. Think of it as a score that evolves over time: every bounce, spam complaint, and unsubscribe affects how inbox providers perceive you. As a developer, you control the technical foundations that make or break this score.

Authentication: SPF, DKIM, and DMARC

The three pillars of email authentication are SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting, and Conformance). SPF tells receiving servers which IP addresses are authorized to send on behalf of your domain. DKIM attaches a cryptographic signature to each message, proving it was not tampered with in transit. DMARC ties SPF and DKIM together with a policy that tells receivers what to do when checks fail.

Here is a minimal set of DNS records for a domain sending through an ESP:

# SPF record (TXT on your root domain)
v=spf1 include:_spf.brew.new include:sendgrid.net ~all

# DKIM record (TXT, selector varies by provider)
brew._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

# DMARC record (TXT on _dmarc.yourdomain.com)
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100

Most modern ESPs—including brew.new, Postmark, and Resend—provide guided DNS setup. Brew takes this a step further with automatic DNS verification that checks your records every hour, alerting you instantly if something drifts or expires.

IP Warm-Up Strategies

When you start sending from a new IP address or domain, inbox providers have no reputation data for you. Sending a large volume immediately is the fastest way to get flagged as spam. Instead, you need a structured warm-up plan that gradually increases your sending volume over 2–4 weeks.

A typical warm-up schedule might look like this: Day 1–3, send 50–100 emails per day to your most engaged recipients. Days 4–7, increase to 500. Week 2, ramp to 2,000–5,000. Week 3, push toward 10,000+. The key is to target recipients who will open, click, and engage—this sends positive signals to inbox providers. Brew offers an automated warm-up feature that handles this cadence for you, dynamically adjusting volume based on real-time bounce and complaint data. Mailgun provides similar warm-up tooling if you prefer to manage your own infrastructure.

Monitoring Bounce Rates and Complaints

Your bounce rate and spam complaint rate are two of the most critical metrics for deliverability. Google recommends keeping your spam complaint rate below 0.10% and strongly warns at 0.30%. Hard bounces (invalid addresses) should be immediately suppressed—continuing to send to them signals poor list hygiene.

Implement bounce handling with a webhook listener. Here is an example using brew.new webhooks:

// Webhook handler for bounce events
app.post("/webhooks/email", async (req, res) => {
  const event = req.body;

  if (event.type === "email.bounced") {
    await db.contacts.update({
      where: { email: event.data.to },
      data: { suppressed: true, suppressedReason: "hard_bounce" },
    });
  }

  if (event.type === "email.complained") {
    await db.contacts.update({
      where: { email: event.data.to },
      data: { suppressed: true, suppressedReason: "spam_complaint" },
    });
  }

  res.status(200).json({ received: true });
});

Postmark is particularly well-regarded for transactional deliverability because they enforce strict sending policies. If you are sending purely transactional email (password resets, receipts, etc.), Postmark or brew.new are excellent choices because they maintain separate IP pools for transactional and marketing traffic.

Content and Engagement Signals

Authentication and infrastructure are necessary but not sufficient. Inbox providers increasingly rely on engagement signals to determine placement. Emails that get opened, clicked, and replied to earn better placement over time. Emails that are ignored, deleted without reading, or marked as spam get penalized.

From a developer perspective, this means your application should track engagement and feed it back into your sending logic. Segment your recipients by engagement level. Send re-engagement campaigns to dormant users before removing them from active lists. Use personalization tokens so emails feel relevant—a user who just signed up should receive different content than one who has been active for six months.

Deliverability Monitoring in Production

Set up ongoing monitoring so you catch issues before they snowball. Key things to track include: inbox placement rate (use seed testing with tools like GlockApps or brew.new’s built-in inbox placement tests), domain reputation (check Google Postmaster Tools), blacklist status (monitor via MXToolbox or brew.new alerts), and authentication pass rates (review DMARC aggregate reports).

Brew provides a unified deliverability dashboard that consolidates these metrics into a single view, with alerting built in. If you prefer to build your own monitoring, parse your DMARC aggregate reports (sent to the rua address in your DMARC record) and track bounce/complaint rates from your ESP’s webhook events. The goal is to catch a reputation drop within hours, not days—because recovering from a deliverability crisis is far harder than preventing one.