Deliverability questions, answered

For an active crisis, fast, we can get on a triage call quickly and I'll tell you what to change first, in order. Authentication and configuration fixes (SPF, DKIM, DMARC, custom MAIL FROM) can change inbox placement within days; reputation recovery is slower and takes a few weeks of consistent, clean sending. A full audit runs about three weeks, with the action plan delivered at the end.

Typically read access to your ESP's sending data and analytics (bounce, complaint, open and click metrics), visibility into your DNS records, and a list of your sending domains, templates and email flows. For setup and managed work I may need scoped access to make DNS or ESP changes, which we agree on up front. I work with the minimum access needed to do the job.

No honest consultant guarantees inbox placement, mailbox providers like Gmail, Yahoo and Microsoft make the final call, and reputation is earned over time. What I commit to is fixing everything you control: correct SPF, DKIM and DMARC, alignment, clean suppression, proper warm-up and separation of mail streams. That's what reliably moves placement in the right direction and reduces risk.

I'm fully provider-agnostic and work with Amazon SES, SendGrid, Mailgun, Postmark, Brevo and others. The fundamentals, authentication, reputation, list hygiene, bounce handling, are the same regardless of who sends your mail, so I meet you on whatever stack you already have rather than push a default.

A full diagnosis: an inventory of your domains, templates, email types and flows; an SPF, DKIM and DMARC review; reputation and blacklist checks; analysis of bounce, complaint, deferred, open and click data; a suppression and bounce-handling review; and monitoring/alerting recommendations. You get a prioritized action plan, a written summary, and a 60-minute review call. It runs about three weeks.

A one-time audit is a focused diagnosis with a prioritized action plan. The 3-month operations retainer adds hands-on implementation support, weekly calls, async support, and monthly health summaries. Custom implementations are tailored to your scale, infrastructure, and goals, with ongoing ownership, dedicated sending architecture, continuous monitoring, and SLA-backed support where agreed.

Yes, I'm happy to sign an NDA before we share any data, and confidentiality is the default regardless. Your sending data, customer lists and infrastructure details stay private and are only used for the work we've agreed on. I keep access scoped to what the engagement requires and remove it when we're done.

The fee covers my expertise, analysis and hands-on work, not third-party costs you'd pay regardless: your ESP's sending fees, domain or DNS hosting, a monitoring tool's own subscription, or separate legal and development work. Where an optional monitoring layer applies, that's called out separately. No hidden line items beyond your own provider bills.

I'm an email-deliverability specialist with 15+ years in the field (GetResponse, Woodpecker, Email Industries). I help teams get their mail into the inbox, through audits, hands-on setup (SPF, DKIM, DMARC, custom MAIL FROM, warm-up, ESP onboarding, bounce/complaint routing, transactional vs marketing separation), ongoing consulting, and training. The work spans diagnosis, implementation, and keeping things healthy as you scale.

Mostly SaaS companies, e-commerce stores, and marketing teams that depend on email, transactional, marketing, or both. Typically they're launching a new sending setup, scaling volume fast, or fighting an active deliverability problem. I work with technical founders, engineers, and marketers alike.

A one-time audit costs $2,400. The 3-month operations retainer costs $1,875 per month. Custom implementations start at $3,000 per month, with final scope based on volume and requirements.

It's structured in phases: Month 1 is discovery, inventory and baseline; Month 2 is optimization and risk reduction; Month 3 is monitoring, validation and handover. You get a weekly 30-minute call plus async Slack and email access, monthly health summaries, and optionally a dedicated monitoring layer. It's the right fit when you're growing volume and want guidance through the changes.

From an audit: a written summary, a prioritized action plan ranking fixes by impact, and a 60-minute review call to walk through it. From a retainer: monthly health summaries plus the phase outputs (baseline, optimization changes, and a final handover). Managed clients get ongoing reporting backed by always-on monitoring and an SLA where agreed.

Yes, everything is remote, calls, async Slack and email, and shared docs. I work in both English and Polish, using the standard technical terms (SPF, DKIM, DMARC, bounce, warm-up, opt-in, suppression) that practitioners use in either language. Timezone overlap is arranged when we start.

Absolutely. Use the free Source check: paste the raw source of a message you received and it will inspect SPF, DKIM, DMARC, the Received chain, and Gmail/Yahoo bulk-sender signals locally in your browser. It is a useful first read on whether a real message has an authentication or routing gap before we talk.

Book a free 30-minute call. We'll look at where your mail goes today and what it would take to fix it, then decide whether an audit, a setup engagement, a retainer, or managed deliverability fits best. No commitment until we both agree on scope.

The published prices are $2,400 for a one-time audit, $1,875 per month for the 3-month operations retainer, and from $3,000 per month for custom implementations. Final custom scope depends on volume and requirements.

A full diagnosis in about three weeks: an inventory of your domains, templates, email types and flows; an SPF, DKIM and DMARC review; reputation and blacklist checks; analysis of bounce, complaint, deferral, open and click data; a suppression and bounce-handling review; and monitoring/alerting recommendations. You walk away with a prioritized action plan, a written summary, and a 60-minute review call.

The audit tells you what's wrong and what to fix; the retainer means I actually do the fixing alongside your team over three months. If you're scaling volume, migrating providers, or fighting a recurring deliverability problem, the retainer is the better fit. If you just need a clear diagnosis and an action plan your own engineers can execute, start with the audit.

Month 1 is discovery, inventory and baseline, establishing where you stand. Month 2 is optimization and risk reduction, fixing authentication, alignment, suppression and reputation issues. Month 3 is monitoring, validation and handover, so your team can run it without me. Throughout you get a weekly 30-minute call plus async Slack/email and monthly health summaries.

Prices on the English page are shown in USD: $2,400 for the one-time audit, $1,875 per month for the operations retainer, and custom implementations from $3,000 per month.

Custom implementations are tailored to your scale, infrastructure, and goals. They add ongoing end-to-end ownership, dedicated sending architecture and multi-domain strategy, continuous monitoring and alerts, orchestration and warm-up automation, incident response, and SLA-backed support where agreed. They start at $3,000 per month, with final scope based on volume and requirements.

The fee covers my expertise, analysis and hands-on work, not third-party costs you'd pay regardless, like your ESP's sending fees, domain or DNS hosting, or a monitoring tool's own subscription. Where an optional monitoring layer applies, that's called out separately. No hidden line items beyond your own provider bills.

No honest consultant guarantees inbox placement, mailbox providers like Gmail, Yahoo and Microsoft make the final call, and reputation is earned over time. What I commit to is fixing the things you control: correct SPF, DKIM and DMARC, alignment, clean suppression, proper warm-up and separation of mail streams. That's what reliably moves placement in the right direction.

Yes. The published engagements are starting points. If you need only a migration, a one-off DMARC rollout, team training, or a different cadence, we can scope it on a free 30-minute call. Custom implementations start at $3,000 per month, with final scope based on volume and requirements.

No. Start with a free 30-minute call where we look at where your mail goes today and what fixing it would take. You can run the free Source check beforehand to bring evidence from a real message. Only then do we decide whether a one-time audit, the operations retainer, or a custom implementation fits. No engagement starts blind.

Deliverability is whether your mail reaches the inbox, not just whether the receiving server accepts it. It is the cumulative result of three things: authentication (proving who you are), reputation (how recipients have reacted to you over time), and how you handle bounces and complaints. It is not a single setting you turn on, it is earned and maintained.

Delivery means the receiving server accepted the message, it did not bounce. Inbox placement means it landed in the inbox rather than the spam folder. A message can be delivered (no bounce) and still go straight to spam, so a high delivery rate tells you almost nothing about whether anyone sees your mail. Track placement, not just delivery.

Almost always one of four pillars is failing: authentication (SPF/DKIM/DMARC), sender reputation, bounce/complaint handling, or infrastructure. Mailbox providers treat every sender as guilty until proven trustworthy, so "legitimate to you" counts for nothing if your mail can't prove who sent it. Start by checking authentication, the vast majority of sudden spam-foldering is a DNS or authentication regression you can find in minutes.

Four, in order of priority: authentication (SPF, DKIM, DMARC with alignment), reputation (engagement, low complaints, consistent volume), list hygiene (suppressing bounces and complaints immediately), and infrastructure (subdomain separation, warm-up). Authentication is binary and cheap to fix; reputation is slow-moving and the hardest to repair. Fix them in that order.

Send a real message to a mailbox you control and read the Authentication-Results header, confirm dkim=pass (with header.d = your domain), spf=pass, and dmarc=pass. For placement across providers, connect Google Postmaster Tools and Microsoft SNDS to see reputation and spam rates from their side. mail-tester.com gives a quick 0–10 score with an auth/content/blacklist breakdown for a pre-launch sanity check.

A seed test sends a campaign to a panel of test addresses across major providers (Gmail, Yahoo, Outlook) to see where each one places the mail, inbox, spam, or a tab. It's a useful snapshot but limited: seed addresses have no real engagement history, so they miss the per-recipient reputation signal that dominates real placement. Treat seed results as directional, and weight Postmaster Tools data above them.

A DNSBL (also called an RBL) is a published list of IPs or domains known for sending spam; receiving servers query it at connection time and may reject or junk mail from listed senders. Check your sending IP and domain against major lists with a tool like MXToolbox. If you're listed, fix the behaviour that caused it first, then follow each list's delisting process, delisting before the fix just gets you re-listed.

Shared IP for most senders: you inherit a pool reputation the provider polices, no warm-up needed, and it works at any volume, ideal for low or variable traffic. A dedicated IP is only worth it at high, steady volume (commonly tens of thousands of messages per day), because below that it never accumulates enough signal to build trust. On shared infrastructure, domain reputation is the lever you actually control.

Reputation is tracked per sending domain, and marketing mail is inherently riskier, higher volume, more complaints, more unsubscribes. If you send marketing from the same domain as your password resets and receipts, a marketing reputation hit drags your transactional mail into spam too. Isolating streams (e.g. m.yourdomain.com for marketing, t.yourdomain.com for transactional) walls off the risk so a campaign misfire can't sink critical mail.

Avoid sending program mail from the apex (yourdomain.com) if you can. Keep its reputation pristine for human and corporate mail, and protect it with DMARC p=reject, sp=reject so it's hard to spoof in phishing. Route every automated stream, transactional, marketing, third-party tools, through dedicated subdomains, each with its own SPF, DKIM, and DMARC.

Treat complaint and bounce rates as early-warning metrics, not universal provider laws. Gmail asks bulk senders to keep its Postmaster spam rate below 0.1% and avoid reaching 0.3%; Yahoo asks bulk senders to keep its inbox-delivered complaint rate below 0.3%. Your ESP's rate can use a different denominator, so compare like with like. Investigate a rising bounce cohort by recipient, source, and SMTP outcome; immediately suppress confirmed hard bounces and complaints.

Because it has no reputation, and a fresh sender that suddenly blasts thousands of emails looks exactly like a spammer who just bought a new IP. You need to warm up: start with your most engaged users at ~50–100/day and ramp gradually over several weeks, sending consistently. If complaints rise or deliverability dips during a week, hold volume flat rather than escalating, the ramp is a guideline, not a deadline.

Mailbox providers can evaluate both the authenticated domain and the sending IP, but the weight and scope vary by provider and message stream. Changing an IP does not erase a domain's sending history; shared infrastructure makes domain-level controls especially important. A dedicated IP gives you more control over that IP's traffic, not a guaranteed placement reset. Diagnose the affected identity and recipient provider before choosing a migration or warm-up action.

When delivery breaks suddenly across all providers, it's almost always a DNS or authentication regression: a second SPF record someone added, an expired DKIM selector, a TTL still serving an old value, or a TXT record that got "cleaned up." Diff your DNS and re-run dig for SPF/DKIM/DMARC, and check your IP against blacklists. If only one provider (say Microsoft) is failing, it's provider-specific reputation or throttling, read that provider's postmaster signals.

SPF (RFC 7208) is a DNS list of which servers may send for your domain, checked against the connecting IP. DKIM (RFC 6376) is a cryptographic signature proving the message was signed by a key you control and wasn't altered. DMARC (RFC 7489) ties SPF or DKIM back to the visible From: address and tells receivers what to do when neither passes and aligns.

Use all three: SPF and DKIM authenticate different paths, while DMARC tells receivers how the visible From domain aligns. Gmail and Yahoo introduced bulk-sender requirements in February 2024; Microsoft announced comparable requirements for consumer Outlook traffic in 2025. Their thresholds and details are provider-specific, so do not turn one provider's policy into a rule for every sender. Authentication is still the sound baseline for transactional and marketing mail alike.

Alignment means the domain that passed SPF or DKIM must match the domain in the visible From: header, the only identity a human reads. DMARC passes if either SPF passes and the Return-Path domain aligns, or DKIM passes and the d= signing domain aligns. Only one needs to pass and align, which is why DKIM is the workhorse: it survives forwarding and aligns with your domain even when the provider owns the Return-Path.

Authentication only proves who you are, not that your mail is wanted. Once identity is correct, placement depends on sender reputation: engagement, complaint rate, bounce rate, and spam-trap hits, tracked per domain and per IP. A perfectly authenticated message from a damaged reputation, a missing one-click unsubscribe header, or a cold un-warmed IP will still land in spam.

SPF authenticates the envelope sender (the SMTP MAIL FROM, surfaced as Return-Path), not the visible From: header. Most providers use their own bounce domain as the Return-Path, so SPF passes for their domain, fine for SPF itself, but it does not align with your From:. That's why you must rely on DKIM, signed with your own domain, to carry DMARC alignment.

SPF caps DNS-querying mechanisms (include, a, mx, ptr, exists, redirect) at 10; exceed it and SPF returns permerror, which DMARC treats as a failure. Each vendor include: can expand into several nested lookups, so two or three vendors can silently blow the budget, audit the expanded count, not the literal includes. If you genuinely need more, flatten includes to literal ip4:/ip6: ranges, accepting that you must re-flatten whenever a vendor changes IPs.

No, there is exactly one SPF TXT record per domain, and two of them is a permerror that fails SPF entirely. Always edit the existing record and add the new include: to it. The classic symptom is intermittent SPF passes that mysteriously stop, because some resolvers concatenate multiple TXT strings and others do not.

If DKIM signs with the provider's domain in d=, it passes DKIM but fails DMARC, because the signing domain doesn't align with your From:. Always sign with d=yourdomain.com so the durable mechanism carries alignment. Otherwise you may pass DMARC today on an aligned SPF Return-Path, then lose alignment the moment forwarding strips SPF and nothing aligned survives the hop.

Each provider publishes its public key at its own selector (e.g. s1._domainkey.yourdomain.com), so when you send from multiple providers you publish multiple selectors. To rotate, publish the new selector and switch signing to it, but keep the old selector live for at least a few days so in-flight and queued mail still verifies. Prefer 2048-bit RSA keys, rotate periodically, and never expose the private key.

By default many providers use their own bounce domain as the Return-Path, so SPF passes for the provider, not you. A custom MAIL FROM (a subdomain like bounce.yourdomain.com pointed at the provider) makes the Return-Path your own domain, giving you aligned SPF in addition to aligned DKIM. It's not strictly required if DKIM aligns, but it adds a second aligned mechanism and is worth configuring for redundancy.

p=none is monitor-only: no action is taken, you just collect reports. p=quarantine sends failing mail to spam. p=reject rejects failing mail outright, which is the end state that actually stops brand spoofing. Stopping at p=none forever gives you visibility but zero protection, only quarantine or reject defends against spoofing.

Never jump straight to reject. Start at p=none for 2–4 weeks and use aggregate reports to find every legitimate source (CRM, invoicing, helpdesk, old marketing tool) and get them all passing aligned. Then move to p=quarantine; pct=25, ramp pct toward 100 while watching for fallout, and only then enforce p=reject. Set sp=reject explicitly so subdomains can't be spoofed.

Aggregate reports are gzipped XML, one per reporting source per day, where each record shows a sending IP, message count, the disposition applied, and the SPF/DKIM/alignment results. Raw XML is unreadable at scale, so feed it to a DMARC processor that groups by source and answers the only rollout question that matters: which legitimate sources are not yet passing aligned? Note that SPF "passing" for a provider's bounce domain but not aligning is the normal, healthy pattern for provider-relayed mail.

BIMI displays your brand logo next to authenticated mail in supporting providers. It is not an authentication mechanism and adds no deliverability boost by itself, but it requires DMARC at enforcement (p=quarantine pct=100 or p=reject), an SVG Tiny PS logo over HTTPS, and for most providers a VMC or CMC certificate attesting you own the mark. Treat it as the capstone of a finished authentication program, not an early task.

ARC (RFC 8617) repairs the DMARC-versus-forwarding problem: when an intermediary like a mailing list or security gateway modifies a message and breaks SPF/DKIM, it records "authentication passed when I received it" in a tamper-evident chain of headers. A downstream receiver that trusts the intermediary can honour the original pass even though SPF/DKIM now fail. As an originating sender you can't turn it on, it's implemented in the MTA; your job is to keep DKIM intact with relaxed canonicalization and stable signed headers so fewer messages need ARC.

MTA-STS (RFC 8461) lets you publish a policy requiring senders to use TLS with a valid certificate when delivering to your MX hosts, closing the STARTTLS-downgrade gap for inbound mail. TLS-RPT (RFC 8460) asks senders to report TLS negotiation failures so you find problems before enforcement drops mail. Deploy them together: start MTA-STS in testing mode with TLS-RPT, read the reports for a couple of weeks, fix cert/MX issues, then switch to enforce. They're a capstone, not a first task.

Query DNS directly with dig: dig TXT yourdomain.com for SPF (expect exactly one v=spf1), dig TXT s1._domainkey.yourdomain.com for DKIM, and dig TXT _dmarc.yourdomain.com for DMARC. Then send a real test message and read the Authentication-Results header: confirm dkim=pass with header.d = your domain, spf=pass, and dmarc=pass with header.from = your domain. Tools like mail-tester.com and MXToolbox do the same checks without dig.

Authentication (SPF, DKIM, DMARC) proves who you are; reputation reflects how you behave over time. Mailbox providers track, per domain and per IP, how recipients react to your mail: opens, deletes without reading, spam complaints, bounces, and spam-trap hits. A strong reputation buys inbox placement, while a damaged one sends even perfectly authenticated mail to spam.

During warm-up, mailbox providers can evaluate both the authenticated domain and the sending IP, with weight and scope varying by provider and stream. A new IP does not erase the domain's sending history, and shared infrastructure makes domain-level controls especially important. Increase only when the relevant recipient-provider evidence is stable; a dedicated IP gives more control over its traffic, not a guaranteed placement reset.

A shared IP is fine and usually better for most SaaS and low-or-variable-volume senders, because the pool is already warm and the provider polices it. A dedicated IP is only worth it above a sustained, consistent volume, commonly cited as tens of thousands of messages per day, because a dedicated IP that sends too little never accumulates enough signal to build trust. Choose dedicated for high, steady volume or strict stream-isolation needs, not by default.

Ramp volume gradually so providers can observe positive engagement before you send at scale, a fresh sender that suddenly blasts 100,000 emails looks exactly like a spammer who just bought a new IP. A typical schedule is roughly 50-100/day in week 1, 200-500 in week 2, 1,000-2,000 in week 3, and 5,000-10,000 in week 4. Start with your most engaged users, send consistently, and don't rush the ramp.

Plan for roughly four weeks to reach meaningful volume, but the table is a guideline, not a deadline. If engagement dips or complaints rise during a week, hold volume flat or step back rather than escalating, pushing through deferrals only prolongs the problem. You also have to warm per receiving provider, since Gmail, Yahoo/AOL, and Microsoft maintain independent reputation and Microsoft in particular throttles more aggressively.

Treat the receiver's SMTP responses as backpressure, not errors. A 421 4.7.0, "too many connections," or "rate limited" means slow your send rate and don't retry aggressively; a 4.2.1 deferral or "mailbox temporarily disabled" means back off because the receiver is testing you. If you see deferrals, reducing volume for a few days and then resuming the ramp recovers faster than pushing through.

Reputation recovers slowly, so recovery looks a lot like warming up again: drop volume, mail only your most engaged users to rebuild positive signals, and fix whatever caused the damage first (purchased list, ignored bounces, a marketing spike, spam-trap hits). Suppress hard bounces and complainers immediately and permanently, and prune inactive addresses so you stop dragging your engagement rate down. There's no fast button, it's much easier to protect reputation than to repair it.

Google Postmaster Tools shows your domain and IP reputation, spam rate, and authentication pass rates straight from Gmail's perspective, the closest thing to seeing yourself through Gmail's eyes. Microsoft's SNDS (Smart Network Data Services) gives IP data, and JMRP is its complaint feedback loop for Outlook/Hotmail/Office 365. Without these you're flying blind on reputation and complaints, so connect and monitor them for every provider you send to.

Mailbox providers do not publish a universal weighting for engagement signals. Watch the signals you can measure, especially complaints, delivery outcomes, and relevant recipient activity, then evaluate them by provider and cohort. Start warming and recovery with recipients most likely to value the mail, and set sunset windows for your cadence, lifecycle, and observed response rather than a fixed universal range.

Reputation is tracked per sending domain, and marketing mail is inherently riskier, higher volume, more complaints, more unsubscribes. If you send marketing from the same domain as password resets and receipts, a marketing reputation hit drags your transactional mail into spam too. Isolate the streams on separate subdomains (for example t.yourdomain.com for transactional, m.yourdomain.com for marketing) so even if the marketing subdomain takes a hit, the transactional one stays clean.

A rising complaint or bounce cohort is the signal to act; there is no generic percentage that every provider enforces. For Gmail bulk traffic, keep the Postmaster spam rate below 0.1% and avoid 0.3%. For Yahoo bulk traffic, keep its inbox-delivered complaint rate below 0.3%. Segment the exact provider metric from your ESP's own rate, then fix acquisition, relevance, and failing recipient cohorts rather than chasing one blended number.

Spam traps are addresses that should never receive mail. Pristine traps were never used by a human, so hitting one means you acquired addresses without consent; recycled traps are formerly-real addresses a provider reclaimed after long dormancy, so hitting one means you don't prune inactive subscribers. Both are reputation poison and both are avoided by the same disciplines: real consent at capture and aggressive removal of inactive addresses.

A hard bounce is a permanent failure: the mailbox or domain doesn't exist, or the server permanently rejected the message (SMTP 5.x.x codes). A soft bounce is temporary: a full mailbox, a server that's briefly down, or greylisting (usually 4.x.x codes). Suppress hard bounces immediately and never retry; treat soft bounces as retryable until they cross your failure threshold.

Set internal alerts from your own historical cohorts, then read provider rules with their own denominators. Gmail tells qualifying bulk senders to stay below a 0.1% Postmaster spam rate and avoid 0.3%; Yahoo's bulk-sender guidance uses a below-0.3% inbox-delivered complaint rate. Neither statement makes a generic ESP bounce or complaint percentage a law. Split hard bounces, temporary failures, blocks, and complaints before deciding what to suppress or repair.

A suppression list is a permanent "never send here" registry checked before every send, it stops you mailing addresses that hard bounced or filed a spam complaint. Your provider keeps its own list and silently drops sends, but that's not a substitute: it doesn't travel with you when you migrate ESPs, doesn't sync across multiple providers, and gives you no analytics. Own the data so a migration is an export/import, not a reputation reset.

Treat hard bounces and spam complaints as do-not-send signals unless a verified correction and your applicable policy justify an exception. Temporary failures need reason-aware retry and expiry rules, not a universal count or cooldown. Manual marketing removals require a fresh, explicit opt-in. Store the suppression reason and source event so a human can review any exception safely.

No. A 5.7.1 or reputation/blocklist rejection is the receiving server refusing you, not telling you the address is dead, suppressing it discards good recipients and hides the real problem. Treat block bounces as a deliverability signal to investigate. A 5.7.26 result means more than one message authentication check failed under the receiving system's local policy; it does not identify which individual mechanism failed. Do not suppress the address merely because of this result. Inspect the complete SMTP response and authentication results or logs before identifying the cause, then fix the confirmed issue.

Two channels feed complaint suppression, and you should wire both. Your ESP forwards complaints as webhook events (the primary channel), and mailbox-provider Feedback Loops (FBLs) send an ARF report, RFC 5965, back to the sender when someone clicks "report spam," e.g. Microsoft's SNDS/JMRP and Yahoo's CFL. Gmail is the exception: it offers no per-message FBL, so you monitor your Gmail complaint rate via Google Postmaster Tools instead.

Suppress the address immediately and unconditionally, no threshold, no second chance, no "sorry to see you go" message, and remove it from every list. A complaint is an explicit statement that the recipient doesn't want your mail, and high complaint rates are among the fastest routes to the spam folder for all your recipients. Log the complaint so you can trace which campaign generated it and fix the root cause.

One-click unsubscribe is a frictionless way for a recipient to leave a mailing list; RFC 8058 defines a POST mechanism when a sender supports it. The spam button files a complaint, which is a stronger negative signal. Gmail requires RFC 8058 one-click support for qualifying bulk marketing and subscribed traffic. Yahoo requires a functional List-Unsubscribe header and strongly recommends POST, while accepting mailto. Give recipients a working exit before dissatisfaction becomes a complaint.

For qualifying Gmail bulk marketing and subscribed traffic, send List-Unsubscribe plus List-Unsubscribe-Post: List-Unsubscribe=One-Click with an HTTPS unsubscribe URI. Yahoo requires a working List-Unsubscribe header and strongly recommends POST; mailto remains accepted. RFC 2369/8058 describe these formats, not a universal rule for every message. Make any POST endpoint safe, login-free, and connected to suppression for the applicable marketing stream; verify received headers rather than assuming the template emitted them.

Verify each webhook's signature, acknowledge with 200 within ~5 seconds, then process asynchronously and idempotently (dedupe on the event ID). On a hard bounce or complaint, call suppressEmail and remove from all lists; on a soft bounce, increment a counter and suppress only after 3 failures. Because providers guarantee at-least-once delivery, idempotent processing is what makes their aggressive retries safe rather than double-suppressing.

No. Unsubscribe is marketing-only, it withdraws marketing consent, not the account relationship, so a user who unsubscribes from your newsletter still gets password resets and order confirmations. Make your send-time gate reason-aware and stream-aware: hard bounces and complaints block every stream, while unsubscribe and manual removals stop marketing but let transactional through. The one trap to avoid is putting promos inside transactional mail, which can pull a complaint onto your transactional stream.

Many providers report a full mailbox (5.2.2) as a hard bounce simply because the reply code starts with 5, but a full mailbox is almost always temporary. If you suppress on the first one, you permanently lose a recipient whose inbox was briefly over quota. Override your provider's classification for known-transient 5.2.x causes and treat them as soft bounces, count them and suppress only after the threshold.

Suppression records a specific reason not to send, such as a confirmed hard bounce, complaint, or marketing opt-out, and the send gate applies that reason to the relevant stream. Hygiene is continuous cohort management: it reduces or stops low-value marketing mail before quality deteriorates. Track both by provider and message class instead of treating one complaint percentage as a universal domain rule.

Because that list lives inside the provider and does not travel with you. The moment you migrate ESPs, routine during a deliverability incident or pricing change, you start fresh and immediately re-mail every hard bounce and complainer you ever had. Owning your own suppression store also lets you enforce a bounce on one provider across another, and join suppression events back to specific campaigns.

Treat hard bounces and spam complaints as do-not-send signals unless a verified correction and your applicable policy justify an exception. Temporary failures need reason-aware retry and expiry rules, not a universal count or cooldown. Manual marketing removals require a fresh, explicit opt-in. Store the suppression reason and source event so a human can review any exception safely.

Use a bounded re-engagement step before removing inactive marketing recipients when it suits your lifecycle and consent model. Define inactivity from reliable product and email signals, choose a window that matches your cadence, and stop if the recipient does not re-engage. Long-dormant addresses raise quality risk, so document the rule and review it by cohort rather than relying on a fixed calendar range.

A sunset policy is a standing rule that automatically stops mailing addresses past a defined inactivity horizon, so disengagement can never accumulate unbounded. A typical tiered version reduces frequency at 90 days, enters re-engagement at 180 days, and removes entirely after 12 months of no activity. Tune the windows to your cadence, a daily-deal sender sunsets far faster than a quarterly newsletter, but the principle holds: protect the engaged majority from the dead-weight minority.

Because purchased and scraped lists are full of pristine spam traps, addresses that were never real users and never opted in. Hitting one proves non-consensual acquisition and does silent, severe reputation damage with no bounce and no complaint to warn you. There is no recovery step that removes a trap, so the only defense is structural: never buy or scrape, and use confirmed opt-in.

Yes, and ideally not just as separate lists but as separate sending domains or subdomains, each with its own SPF, DKIM, and DMARC. Mailbox providers build reputation largely per-domain, so if a marketing campaign tanks news.example.com, your password resets on notify.example.com keep landing. This domain-level split is the single most important structural protection for transactional deliverability.

No. Unsubscribe is marketing-only, it withdraws marketing consent, not a statement that the address is broken. A user who unsubscribes still needs their password resets and order confirmations, so transactional mail continues; only complaints and hard bounces suppress everything. The dangerous failure mode is the 'marketing message dressed as transactional', a promo in a receipt, which can pull a spam complaint onto your transactional stream.

Set retention by purpose, legal basis, security need, and the jurisdictions you serve; keep only what is necessary and document the schedule. A suppression record may be needed to honor an objection, but it should be minimized and reviewed rather than kept by an assumed universal period. A hashed email can still be personal data when it can be linked back to a person, so treat it accordingly when handling an erasure request.

Watch trend changes in bounces, complaints, engagement, and suppression growth by provider and cohort. Set internal alerts from your own baseline; they are operational signals, not universal provider thresholds. Compare each provider's published complaint metric with the same denominator, then investigate the acquisition source, message class, and SMTP outcomes behind a change.

Not on its own. Since Apple Mail Privacy Protection (2021), Apple pre-fetches tracking pixels and registers an 'open' whether or not a human read the message, so a meaningful fraction of opens are machine-generated. Prefer clicks as your primary signal, use a complete absence of opens as a weak negative signal, and blend in non-email activity like last login or last purchase where you have it.

List hygiene reduces the complaints and invalid-recipient signals that providers use, but the Gmail and Yahoo rules are not one shared checklist. Use each provider's current scope, metric, and unsubscribe guidance: Gmail's qualifying bulk rules include RFC 8058 one-click support, while Yahoo's header requirements differ. Keep acquisition, complaints, bounces, and unsubscribe processing observable so you can repair the affected cohort.

A transactional email is triggered by a specific action or state change tied to one recipient, and the recipient expects it because of something they did, like a password reset, OTP, receipt, or shipping update. That one-to-one property is what exempts it from marketing consent and unsubscribe rules in most jurisdictions. The moment a message becomes a broadcast you decided to send rather than a consequence of the user's own action, it is marketing, regardless of the subject line.

Almost every app needs three: email verification, password reset, and a non-promotional welcome. If you build nothing else, build these first. Beyond that, your app type dictates the rest, e.g. e-commerce adds order confirmation, shipping, and receipts, while SaaS adds renewal notices and payment-failed flows.

Put it in the subject only as a convenience copy ("123456 is your verification code"), but never put it in the subject if that is the only place it lives, and never in the pre-header alone. Lock-screen and notification previews render the subject and pre-header to anyone who can see the phone, so treat both as fully public. The canonical code belongs in the body, large and selectable; the subject copy just lets users read it without opening.

Be specific and name the account, app, or order: "Reset your password for Acme" or "Your order #12345 has shipped", never vague "Action required" (which reads like phishing). Front-load the meaningful words because mobile truncates around 35 to 40 characters, and notifications on a watch show even less. Carry no secrets, and skip emoji and ALL-CAPS that trip spam heuristics on a transactional stream.

Transactional messages are often read while the recipient is completing the same task on a phone. Use a responsive single-column layout, readable text, generous tap targets, and a clear primary action near the start of the message. Show OTP codes as large, selectable text in a typeface that makes similar characters easy to distinguish, and test the result in the clients your audience actually uses.

Yes, always send multipart/alternative with a genuine, hand-written plain-text part, not a stripped HTML dump. An HTML-only message is a mild spam signal, and the text part is what renders in text-first clients, on smartwatches, and for screen readers. For OTP and reset emails especially, the text part must carry the code or link in usable form because that is what some clients display.

Use semantic structure (one h1 stating the purpose, real headings and paragraphs), mark layout tables role="presentation" while keeping data tables' th and caption, and write descriptive link text like "Reset your password" instead of "click here". Meet WCAG 2.1 AA contrast (4.5:1 for normal text, 3:1 for large), never convey meaning by color alone, set lang on the html element, and keep the code and primary action as live text, not images. Because images are often blocked, the email must read correctly with alt text in place of every image.

Allow resend after 60 seconds, cap at 3 attempts per hour, and show a countdown so users don't hammer the button. Enforce the cooldown server-side and key the limit on a hash of the destination address (not the user ID), so an unauthenticated "forgot password" form can't be used to mail-bomb an arbitrary inbox. Re-issuing a token should invalidate the previous one.

Show a clear "This link has expired" message, not a raw 404, and offer to send a fresh link in one click right there, plus a support contact for repeat offenders. Distinguish expired, already-used, and malformed states for the user, but keep the response uniform to anyone probing tokens. Watch for link prefetch: security scanners and Outlook Safe Links can consume a single-use token before the human clicks, so commit state only on an explicit POST, never on the GET that renders the page.

Yes. Transactional mail still needs sound authentication, so SPF (RFC 7208), DKIM (RFC 6376), and aligned DMARC (RFC 7489) are a sensible baseline for every sender. Provider requirements for bulk traffic are separately scoped by message class; excluding transactional mail from a one-click unsubscribe requirement is not an authentication exemption. Separate transactional and marketing streams so marketing risk does not directly affect critical messages.

A genuinely transactional, one-to-one message still needs sound authentication, but Gmail's bulk-sender one-click requirement excludes transactional mail. RFC 8058 is a mechanism, not a universal law. Keep promotional content out of transactional templates: if a message is marketing or mixed, assess it under the provider rules and applicable jurisdiction. For an ambiguous high-volume stream, received headers and message purpose—not a label alone—should drive the decision.

Required invoice fields, numbering, tax treatment, and record format depend on the jurisdiction and transaction. Use the email as a clear delivery notice, keep the authoritative invoice in the accounting system with a stable identifier and version, and let the recipient retrieve the same issued record. Confirm the required seller, buyer, line-item, tax, and retention fields with current local tax and accounting guidance.

A failed-payment email that lands in spam becomes involuntary churn, the customer never updates the card and you lose the revenue, so it's a revenue metric, not a vanity one. OTP and password-reset emails are Tier 0: a code that arrives after it expires is worse than useless, so target inbox delivery in single-digit seconds with a fast path that bypasses your normal queue. Route both on your cleanest transactional identity, send them immediately, and never share that infrastructure with a noisy notification stream that earns complaints.

Only when the change forces the user to act, e.g. a deprecated API or a removed setting they actively use. The simple test: if the user does nothing and something breaks for them, it is transactional; if nothing breaks, it is marketing. The same logic decides trial-ending notices, "your trial ends in 3 days" is transactional when the trial auto-converts to a paid plan (the user must act to avoid a charge) and marketing when nothing happens if they ignore it.

If a reasonable recipient would describe its purpose as "they want me to buy something," it's marketing, regardless of what triggered it. A receipt is transactional, but a receipt with a "you might also like" cross-sell block becomes marketing and needs marketing consent. When in doubt, split it: send the lean transactional notice on your transactional stream and the promotion as a separate consented send.

Consent must be a deliberate, affirmative action: the user checks an unchecked box, clicks "Subscribe," or completes a form with clear subscription intent. Pre-checked boxes, opt-out models, assumed consent from a purchase, and purchased or rented lists do not count. Bundling "newsletter" and "promotions" into one tick also fails, because consent must be specific to what you'll send.

Choose the consent flow for the law, abuse risk, and evidence standard that apply to your audience. Double opt-in adds a confirmation step that helps verify control of the address and records stronger evidence of intent; single opt-in removes that step but needs equally clear consent language and stronger protection against typos and abuse. Measure confirmation and complaint outcomes in your own cohorts instead of assuming a universal conversion rate.

Store an immutable, per-subscriber record at the moment of opt-in: normalized email, the specific purposes they agreed to, a UTC timestamp, the source/form URL, IP address, user agent, the exact wording shown (or a version id), the consent method, and the double opt-in confirmation timestamp. Keep it append-only; when someone changes preferences or withdraws, write a new record rather than overwriting. Regulators ask "what did the user agree to," and "the current text on our form" is not an answer if the text has since changed.

Extremely easy: prominent in every email, free, login-free, and honored fast. A frictionless unsubscribe is a deliverability feature, not a weakness, because the alternative is a spam complaint, which is far more damaging. Forcing someone through a preference center before they can fully leave breaks the rules; a preference center is a complement to one-click unsubscribe, never a replacement.

Send both headers required by RFC 8058: a List-Unsubscribe with an HTTPS URI (and optionally a mailto), plus List-Unsubscribe-Post: List-Unsubscribe=One-Click. The provider POSTs to your HTTPS URL with no human and no login, so the endpoint must accept unauthenticated POST, return 2xx, and suppress the subscriber idempotently. The token in the URL must be unguessable and scoped to one subscriber and one mailing, and a bare GET must not perform the removal so link scanners don't unsubscribe engaged users.

There is no universal number. Compare cadence changes within the same audience and message class, then watch unsubscribe, complaint, conversion, and engagement trends by recipient provider. Start conservatively, test one change at a time, and reduce frequency when a cohort's negative signals rise rather than applying a generic percentage to every list.

Segment by behavior, preferences, signup source, and especially engagement level, then send each group the most relevant content. Engagement is the single most valuable segment for deliverability: define tiers from server-side signals like clicks and conversions (not opens), mail your most engaged subscribers first when warming a domain or IP, and reduce cadence or suppress dormant ones. Pruning the dormant tier protects the aggregate engagement metrics that mailbox providers actually score.

Avoid image-only emails, always include a plain-text part alongside the HTML, set real alt text, and keep a genuine text-to-image balance, since a missing plain-text alternative and image-only layouts are spam signals. Don't use bare link shorteners or tracking domains that don't match your sending domain; put click-tracking and image domains on your own authenticated subdomain so they inherit your reputation and align with DKIM/DMARC. And never bury the unsubscribe link, hiding it just drives complaints.

Because "these are our customers" is not consent. Imported or purchased contacts never agreed to hear from you; they reliably produce high bounce and complaint rates, which mailbox providers punish across your entire sending domain, including the transactional mail real customers depend on. If you must use imported contacts, they need a documented legal basis or a one-time re-permission campaign before the first marketing send.

No, never silently re-add them. Their prior unsubscribe is a withdrawal you must honor until they re-consent explicitly, so run the new submission through fresh double opt-in and write a new consent record. If the address is on a suppression list for hard-bouncing, clear it only after a successful verification click proves the mailbox is now deliverable, never just because someone typed it again.

Use your own historical cohorts for internal bounce and complaint alerts, then apply each provider's metric separately. Gmail asks qualifying bulk senders to stay below a 0.1% Postmaster spam rate and avoid 0.3%; Yahoo uses a below-0.3% inbox-delivered complaint rate. These are not a generic ESP bounce or complaint law, and Microsoft has separately scoped consumer-Outlook requirements. Wire bounce and complaint webhooks into a reason-aware suppression list so signals are caught and acted on automatically.

The law follows the recipient's location, not yours, so a single campaign can fall under CAN-SPAM (US), GDPR + ePrivacy (EU), CASL (Canada) and others at once. You're bound by the strictest applicable rule on each point. The practical move is to build one program to GDPR-grade consent and CASL-grade unsubscribe longevity and you're compliant almost everywhere. (This is practical guidance, not legal advice.)

No. Order confirmations, shipping notices, password resets and security alerts don't need marketing consent under any major regime: CAN-SPAM exempts them, GDPR rests them on the contract lawful basis, and CASL treats them as exempt transactional messages. The catch is CAN-SPAM's "primary purpose" test, so keep promotional content out of these templates or the message becomes commercial and needs the full compliance treatment.

CAN-SPAM (US) is opt-out: you may email until told to stop, with conditions. GDPR/ePrivacy (EU) and CASL (Canada) are opt-in: you need explicit permission before sending marketing. When your list crosses borders, follow the stricter opt-in model everywhere, that's the only posture that's safe in every jurisdiction at once.

It must be a clear affirmative act, never a pre-ticked box, silence, or marketing bundled into terms-of-service acceptance (the CJEU's Planet49 ruling confirmed this). Consent must be freely given, specific, informed, granular (separate consents for separate purposes), and as easy to withdraw as to give. Critically, it must be demonstrable: a single boolean flag with no timestamp, source, or scope is unprovable, and unprovable consent is worthless to a regulator.

Process unsubscribe requests promptly and make the mechanism easy to use. CAN-SPAM requires honoring a valid opt-out within 10 business days and keeping a return mechanism available for at least 30 days; other jurisdictions and provider programs have their own rules. Confirm the timing and retention requirements for the markets and message class you serve rather than treating one operational target as universal.

For qualifying Gmail bulk marketing and subscribed traffic, provide List-Unsubscribe and RFC 8058 List-Unsubscribe-Post: List-Unsubscribe=One-Click with an HTTPS URI. Yahoo requires a working List-Unsubscribe header and strongly recommends POST, while accepting mailto. RFC 2369/8058 specify header formats, not a universal rule for every email. Microsoft announced separate requirements for consumer Outlook traffic in 2025, with its own scope and threshold. Check the provider and message class before treating a header as mandatory.

They are mailbox-provider acceptance policies, not statutes. Gmail and Yahoo introduced separate requirements in February 2024; their scope and complaint measures differ, and Yahoo publishes no numeric daily bulk threshold. Microsoft announced requirements for senders above 5,000 daily messages to consumer Outlook addresses in April 2025, with enforcement beginning in May 2025. Check each provider's current guidance and the law applicable to your audience.

CASL splits consent into two kinds with very different lifespans. Express consent (an affirmative opt-in) never expires unless withdrawn. Implied consent from a relationship has a clock: a purchase or contract gives you 2 years, a mere inquiry gives you 6 months, after that you may no longer email without obtaining express consent. So you must log which event created the implied consent and when, or you can't prove the clock ever started.

No. Most legislation and the mailbox-provider rules require a genuine single-action unsubscribe; a preference center is a valuable addition for retention but never a substitute. If your only exit is a multi-step form, the RFC 8058 one-click POST flow breaks because it can't navigate a form, and you're not compliant. The correct pattern: the POST one-click unsubscribes immediately with no UI, and the GET landing page confirms removal and then offers preferences as an optional secondary path.

Record every consent event as structured, append-only data: email, exact UTC timestamp, method (form, double-opt-in click, import), scope, source plus the consent-text version they saw, consent type (express vs implied, with the triggering event for implied), and evidence of the affirmative act. Never overwrite, write a new row so you can reconstruct the granted-to-withdrawn history. Keep consent proof roughly 3 years past expiry/withdrawal (CASL), but minimize the broader personal data you have no current lawful use for (GDPR storage limitation).

Yes, and you should. When you honor a GDPR erasure request (Article 17) you delete the profile, but you may retain a minimal suppression record: a hashed or plain email plus a "do not contact" flag and timestamp. Keeping someone off your list is itself a legitimate, often legally required reason to retain that one fact, so you don't accidentally re-import and re-email them later. Document this in your retention policy so the retained entry is defensible.

They can be material, but the framework and current amount depend on the law, jurisdiction, conduct, and date of enforcement. CAN-SPAM, GDPR, and CASL use different bases and regulators can update monetary limits. Treat provider policies separately from statutory duties, check current official guidance for every market you serve, and obtain legal advice for an actual compliance decision.

Use an idempotency key: a unique value you attach to each send, derived from a stable business event (like order-confirm-${orderId}). The provider records the key on the first request and replays the original response on any repeat, so retrying is always safe. The key must be reserved before the send happens and reused on every retry, generate it from immutable facts, never from a timestamp or fresh random value.

Retry transient failures: 5xx, 429 (rate limit), 408, network timeouts (ETIMEDOUT), connection resets, refused connections, and DNS hiccups (EAI_AGAIN). Never retry a plain 4xx like 400, 401, 403, or 422, those mean your request is wrong and will fail identically every time. A 409 on an idempotency key is special: it means the original is still in flight, so re-check rather than treating it as a hard failure.

Use exponential backoff with jitter: 1s, then 2s, 4s, 8s, capped at 30s, plus a small random offset so many clients failing at once don't retry in lockstep (the thundering herd). For a fleet of background workers draining a queue after a shared outage, prefer full jitter, a random point between zero and the exponential cap, so the recovering provider sees a smooth ramp rather than a synchronized wall of requests.

A 2xx means only that the provider accepted the message for delivery, it does not mean the receiving mail server got it, and certainly not that it reached the inbox rather than spam. Delivery to the recipient's MX is confirmed asynchronously via a delivered webhook, and inbox placement is never confirmed by SMTP at all. Treating a 200 as proof of delivery is the root of most reliability bugs and will mislead every incident investigation.

Queue anything the user is waiting on (login codes, receipts, confirmations) or anything legally required. A queue moves the send out of the fragile synchronous request path into durable storage, so it survives crashes and deploys, owns the retry loop, throttles against rate limits, and gives you an audit trail. A simple rule: if a missed send would create a support ticket, a security gap, or a compliance problem, queue it; a best-effort 're-engagement' email can send inline.

Because there's a class of failure, a connection reset, or a timeout after the request body was fully sent, where you genuinely cannot know whether the email went out. Those are exactly the cases you must retry for reliability and must not duplicate. A retry loop without an idempotency key is not a reliability feature; it's a duplicate-email generator. The rule is simple: never enable retries on a code path that doesn't carry an idempotency key.

Yes, always prefer it over your own computed backoff. When a 429 (or sometimes a 503) returns Retry-After, the server is telling you exactly how long its rate-limit window is, honoring it resolves the situation faster and marks you as a well-behaved client. Parse both formats the HTTP spec allows: delta-seconds ("120") and an HTTP-date. Then wait the larger of the server's value and your own backoff floor, never less than either.

Set 10 to 30 seconds per call, and always clear the timer in a finally block. Below ~10s you risk aborting requests that would have succeeded on a slow connection; above ~30s you tie up threads, connections, or serverless billing long past the point where retrying would be faster. Ideally set a short connect timeout and a separate, longer read timeout: a connection that never establishes is safe to retry, while a timeout after the body was sent is the ambiguous case that needs an idempotency key.

Wrap the provider call in a circuit breaker: after N consecutive failures it trips open, rejects sends fast for a cooldown, then allows one trial request before closing again. While it's open, route sends straight to the queue instead of burning retries against an endpoint you already know is down. This converts an outage from 'every request slow and failing' into 'requests fail fast and recover automatically when the provider returns,' and prevents thousands of workers from hammering the API the instant it recovers.

Use two queues with different drain rates: a low-latency 'fast lane' for transactional, user-blocking emails and a throttled 'bulk lane' for marketing. Sharing one queue is a real failure mode, a 200,000-recipient campaign can starve a single password reset stuck behind it. The split also maps cleanly onto separating transactional and marketing reputation, which is why those streams typically send from different subdomains too.

Drain with a token-bucket limiter sized below the provider's documented rate, it allows short bursts up to the bucket size while holding the long-run average at the refill rate. When you do hit a 429, treat it as a signal to lower the drain rate temporarily, not just to retry the one message. For a new sending domain or dedicated IP, your limiter also needs a daily ceiling, not only a per-second one, so you can warm up volume gradually instead of cold-blasting and tanking reputation.

A webhook is an HTTP endpoint you own that your email provider POSTs to whenever something happens to a message: delivered, bounced, complained, opened, or clicked. It is the reverse of an API call: instead of you polling "what happened to message X?", the provider pushes the event the moment it knows. Without webhooks you keep mailing addresses that bounce and people who already complained, which is exactly how a sending domain gets blocklisted.

The two you cannot ignore are bounced and complained: they directly affect deliverability and, for complaints, legal obligations. The other four (sent, delivered, opened, clicked) are valuable for status and analytics but optional, so you can ship with just bounce and complaint handling and add the rest later. If your provider emits a one-click unsubscribe event (RFC 8058), promote that to must-handle too and suppress the address immediately.

Polling is pull-based and lossy: a bounce or complaint can arrive seconds after the send or hours later, so you would have to keep polling every message for hours, multiplying your request volume. Most status APIs are rate-limited and don't retain per-message status for long, so events age out before you ask. Webhooks invert this: the provider tells you exactly once, the moment the event is known, and retries until you acknowledge. Keep polling only for periodic reconciliation, not as the primary mechanism.

Your webhook URL is a public endpoint, so anyone could POST a forged delivered or a malicious bounced to suppress a real address. The provider signs each payload with a shared secret (the Standard Webhooks scheme uses HMAC-SHA256 over id.timestamp.rawBody); you recompute the HMAC over the exact raw bytes received and compare in constant time with crypto.timingSafeEqual, rejecting with 400 on mismatch. Capture the raw body before any JSON parser touches it, since re-serialization changes the bytes and breaks verification.

Yes. The verification shape transfers even when header names differ. Mailgun-style providers send timestamp, token, and signature and you compute HMAC-SHA256 over timestamp+token; some sign just the raw body and send a hex digest; Amazon SES publishes to SNS, which signs with an X.509 cert, so you use the AWS SDK's SNS validation helper. Whatever the scheme, the invariants are identical: verify against raw bytes, compare in constant time, enforce a timestamp window, and reject on any failure. IP allowlisting is a weak supplement, never a substitute.

Providers give you a tight budget, return 2xx within about 5 seconds, and they read a slow or failed response as "delivery failed", which triggers retries and ultimately duplicate processing. So verify the signature first, persist the raw event cheaply (enqueue to a durable job queue), return 200, then do the real work later from the queue. Never run database writes, list updates, or follow-up sends before responding, or a slow downstream turns into a timeout and a retry storm.

Most providers guarantee at-least-once delivery, not exactly-once, so if your 200 is delayed or your server restarts mid-processing, the same event gets redelivered. Without deduplication that double-counts an open, double-suppresses, or sends a follow-up twice. The fix is to dedupe on the stable event.id before doing any work; if your provider sends no reliable ID, synthesize a key by hashing fields that stay constant across retries (messageId, type, email, occurrence timestamp). Make the dedup insert the first write so a unique-constraint violation short-circuits duplicates.

A hard bounce is permanent (address doesn't exist), so suppress immediately and remove from all lists; a soft bounce is transient (mailbox full, server down), so count it and suppress only after a threshold like three in a row. A complaint ("mark as spam") allows no nuance and no second chance: suppress unconditionally, remove from every list, and log it to find the offending campaign. One important exception: an authentication-related bounce with SMTP 5.7.26 means more than one message authentication check failed under local policy, not a named SPF, DKIM, DMARC, or alignment failure. Do not suppress the recipient merely because of that response. Inspect the complete SMTP response and available authentication results or logs before identifying the cause, then alert the team or correct the confirmed issue.

Webhooks are not guaranteed to arrive in event order, retries and parallel workers reorder them, so you can receive opened before delivered, or a stale sent retry after delivered. Make status transitions monotonic: rank the states (queued < sent < delivered < opened < clicked) and only advance to a further-along state, never overwrite with whatever arrived last. Track bounced and complained on a separate axis, because a delivered message can legitimately become complained later once a human marks it as spam.

Store the full history. Use an append-only email_events table keyed by the provider's event.id (type, message ID, timestamp, raw JSON) and derive current per-message status from it or keep it in a separate, rebuildable table. The log is your audit trail and ground truth: it lets you answer "when did this address start bouncing?", recompute metrics after a logic change, and replay processing if a handler had a bug. Raw payloads contain recipient emails (personal data under GDPR), so keep them hot for roughly 30-90 days, then delete or down-sample.

Use a tunneling tool like ngrok or cloudflared to expose your localhost port and register the printed HTTPS URL as the webhook endpoint, so real provider events reach your local handler where you can set breakpoints. To test deterministically without the provider, mint a correctly signed request yourself: the signature is just HMAC over id.timestamp.body, so sign a payload and POST it with curl. Exercise every failure mode, not just the happy path: hard and soft bounces, complaints, duplicate delivery, bad signature, stale timestamp, and out-of-order events.

You paste the full raw source of an email you received, and it reads header evidence: SPF, DKIM and DMARC results plus alignment, the Received chain, reverse DNS and TLS indications recorded in the received headers, and headers related to one-click unsubscribe. It shows what is present in that message and a local diagnostic score with concrete fixes; it does not prove sender volume, complaint rates, or complete Gmail/Yahoo bulk-sender compliance. It is a fast way to see how that particular message was authenticated and routed.

In Gmail, open the message, click the three-dot menu and choose "Show original", then copy everything. In Outlook on the web and new Outlook, choose More actions (...) → View → View message details to copy Internet headers; in classic Outlook, open the message in a separate window, then choose File → Properties and copy Internet headers. Those paths may not expose the full .eml message, so to analyze complete source download the message as .eml or use a client that shows raw source. In Apple Mail, select the message and choose View, then Message, then Raw Source. Paste the whole block into the Source check.

The Source check runs entirely in your browser. The raw email you paste is never uploaded to a server, so the content and headers stay on your machine. You can safely test real production messages, including ones with sensitive recipient data.

The score is a local heuristic based on signals read from a single message: SPF, DKIM and DMARC results and alignment, the Received chain, reverse DNS and TLS indications recorded in headers, and the presence of unsubscribe headers. It does not perform live DNS, TLS negotiation, or test whether an RFC 8058 endpoint accepts POST. It is header diagnostics for that one message, not a guarantee of placement. Treat it as a checklist of what to fix, with each deduction tied to a specific issue.

The Source check can inspect authentication and unsubscribe headers in a real message, but it cannot replace provider metrics. Gmail asks qualifying bulk senders to keep its Postmaster spam rate below 0.1% and avoid 0.3%; Yahoo asks bulk senders to keep its inbox-delivered complaint rate below 0.3%. Monitor those measures separately under the provider's current documentation, and do not automatically equate them with your ESP's metric.

The Source check is free. It needs the raw source of an email you already received and analyzes it locally in your browser without sending the message to this site's server.

Start from your use case, not the brand: pick a provider that gives you separate sending domains/streams, a clean API and SMTP, delivery and bounce/complaint webhooks, and first-class SPF, DKIM, and DMARC setup. Then weigh deliverability reputation, per-stream suppression lists, and pricing at your real volume. Any of Amazon SES, Postmark, SendGrid, Mailgun, Resend, or Brevo can be the right answer, the deciding factor is fit, not popularity.

Transactional ESPs optimize for low-latency, event-driven, one-to-one sends (receipts, password resets) with strong APIs and webhooks; marketing platforms optimize for campaigns, segmentation, templates, and consent/unsubscribe management. The two streams should be kept on separate subdomains regardless, so a marketing complaint spike can't poison your receipts. Some providers do both well, but you still isolate the streams, the split is architectural, not just a product-tier choice.

At a high level: Amazon SES is the cheapest raw infrastructure but you assemble warming, suppression, and dashboards yourself; Postmark is opinionated for fast transactional delivery with separate message streams baked in; SendGrid and Mailgun are general-purpose with both transactional and marketing tooling; Brevo (formerly Sendinblue) leans marketing/CRM with built-in campaigns. None is a universal default, match the operational burden you want to carry against the deliverability tooling you want out of the box.

For almost everyone, use a managed ESP. Self-hosted SMTP means you own IP warming, reputation monitoring, blocklist remediation, feedback loops, and TLS/authentication plumbing, a full-time job that mailbox providers trust far less than an established sending network. Self-hosting only makes sense at very high volume with a dedicated deliverability team, or for strict data-residency requirements; even then, most teams use a managed provider and keep SPF, DKIM, and DMARC on their own domain.

Treat the new provider's sending identity as cold: ramp gradually instead of cutting over all traffic on day one. Start with a low-risk, well-understood cohort, increase only while provider-specific bounces, complaints, deferrals, and placement signals remain stable, and keep a rollback path during the transition. Publish the new SPF, DKIM, and DMARC configuration and carry over suppression data before moving production traffic.

Yes, splitting transactional and marketing across two specialized providers is common and healthy, since it naturally isolates the two reputations. Some teams also run a second transactional provider purely as a failover for redundancy. The cost is operational: each provider needs its own SPF include, DKIM keys, DMARC alignment, suppression sync, and webhook handling, so don't multiply providers without a concrete reason like specialization or redundancy.

You control these records in your domain's DNS, while the provider supplies the SPF and DKIM values its service needs. The visible From domain, DMARC policy (RFC 7489), and publishing decisions remain yours. That is why changing providers can preserve the domain identity: update the authorized sending paths and selectors, verify alignment, and then assess the current requirements of each recipient provider separately.

Below roughly a few tens of thousands of messages a month, a provider's well-managed shared IP pool is usually better, there's enough steady volume to keep reputation warm, which you can't do alone at low volume. A dedicated IP only pays off once your volume is high and consistent enough to keep it warm; otherwise it can actively hurt deliverability. This is a high-volume decision; separating transactional and marketing at the subdomain level is the day-one decision.