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.

Complaints bite hardest: keep the Postmaster-reported spam rate under 0.1% as your real ceiling, and treat 0.3% as the cliff Gmail enforces for bulk senders since February 2024. For bounces, under 1% is healthy, above 3% providers distrust you, and above 4% you risk active throttling and blocks. Suppress hard bounces and complaints immediately and permanently.

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.

Domain reputation follows your From/DKIM d= domain everywhere it sends and cannot be escaped by switching IPs, it's the lever you control on shared infrastructure. IP reputation follows the sending IP: on a shared IP you inherit the pool's, on a dedicated IP you own it entirely. They're tracked separately, so reason about them separately, and on a new dedicated IP you must warm both.

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.

You need all three. Since February 2024 Gmail, Yahoo, and Microsoft require bulk senders to pass SPF and DKIM and to publish a DMARC record (at least p=none) with alignment. Treat all three as mandatory regardless of volume, since providers increasingly apply the same checks to small senders too.

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.

Domain reputation follows your From:/DKIM d= domain wherever it sends and cannot be escaped by changing IPs, it's the lever you control on shared infrastructure. IP reputation follows the sending IP: on a shared IP you inherit the pool's reputation, while on a dedicated IP you own it entirely. Most small senders sit on shared IP pools, so domain reputation is the thing they actually steer.

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.

Opens, clicks, and replies are the single biggest positive signals, they tell providers your mail is wanted. Deletes without reading, long-term inactivity, and especially spam complaints are the negative ones, and sending to people who simply ignore you drags reputation down even if they never complain. This is why warming and recovery both start with your most engaged users, and why a sunset policy (stop mailing addresses inactive for 90-180 days) protects everyone who remains.

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.

Keep bounce rate under 4% (under 1% is healthy) and complaint rate under 0.1%, complaints are far more damaging per event because they're a direct recipient signal that your mail is unwanted. The February 2024 Gmail/Yahoo/Microsoft bulk-sender rules make this concrete: stay below 0.3% spam complaints (the cliff) and ideally near 0.01%. Track the rate Google Postmaster Tools reports, not your own opens-based estimate, because that's the number used against you.

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.

Keep your bounce rate under 2% and your complaint rate well under 0.1%. The Gmail/Yahoo/Microsoft bulk-sender rules (effective February 2024) set a hard ceiling of 0.3% spam complaints for anyone sending roughly 5,000+ messages/day to those providers, by the time you hit 0.3% your deliverability is already degraded. Set internal alerts much tighter, around 0.05%, so you can react before the provider-measured rate climbs into trouble.

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.

Hard bounces and complaints are permanent, never unsuppress them; a complaint reversal can even be a legal violation. Soft-bounce suppressions (after 3 failures) can be retried after a 30–90 day cooling-off, and manual removals can be reversed only if the user opts back in themselves. The crucial distinction is reversibility: bounces and complaints are final, the other two are conditional.

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 specifically means SPF/DKIM/DMARC alignment failed, so fix your authentication (SPF per RFC 7208, DKIM per RFC 6376, DMARC per RFC 7489) rather than pruning the recipient.

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 (RFC 8058) is a frictionless way out: the recipient leaves your list from the mailbox UI, and the mailbox provider POSTs to your List-Unsubscribe URL with body List-Unsubscribe=One-Click. The spam button files a complaint, which is far more damaging to your reputation. A good unsubscribe is the pressure-release valve that keeps annoyed recipients from clicking "report spam" instead, which is exactly why the February 2024 bulk-sender rules mandate it on marketing mail.

You need both. The List-Unsubscribe header (RFC 2369) carries the URL and a mailto fallback, and List-Unsubscribe-Post: List-Unsubscribe=One-Click (RFC 8058) is the token that tells the mailbox provider the link can be actioned without a confirmation page. Your endpoint must process the POST within two days, must not require login or confirmation, and should wire straight into suppression for the marketing stream.

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 is binary and permanent: a 'never send here' registry for hard bounces and complaints. Hygiene is graded and continuous: it prunes subscribers who are going cold before they hurt you. Suppression protects you from catastrophic signals; hygiene protects you from the slow rot of disengagement that pushes a domain over the 0.3% complaint threshold.

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.

Hard bounces and spam complaints are permanent, never re-mail them; a hard bounce means the address is invalid and a complaint is often a legal line you cannot cross. Soft bounces (after 3 failures) can be retried after a 30–90 day cooling-off, and manual removals can be reversed only if the user themselves opts back in. The crucial distinction is reversibility, which is exactly why you store the suppression reason as a field.

Win them back first. Identify anyone with no opens or clicks in 45–90 days, send a single honest re-engagement message ('Still interested?'), wait 14–30 days, then remove non-responders from marketing lists. Some 'inactive' people are just busy, but long-dormant addresses can also turn into recycled spam traps, which is why you never mail them forever.

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.

Keep operational logs and delivery status around 90 days, bounce/complaint events about 3 years as a suppression audit trail, email content only 30 days because it is bulky and sensitive, and consent records well past their expiry as a legal requirement. The suppression list itself you keep indefinitely. A GDPR erasure request can force earlier deletion, but you generally keep consent and suppression entries, storing a one-way hash of the address satisfies erasure of identifiable data while still gating every send.

Watch three: bounce rate (target under 2%, page over 2%), complaint rate (target under 0.05%, page over 0.05%), and suppression-list growth (alert on a sudden spike). The internal 0.05% alert is deliberately stricter than the 0.3% Gmail/Yahoo/Microsoft ceiling so you react before the provider-measured rate climbs into trouble. Compute complaint rate over a rolling window of delivered messages, not lifetime totals, or a recent bad campaign gets masked.

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 is now a hard gate, not a nicety. Any domain sending roughly 5,000+ messages a day to those mailboxes must keep its spam-complaint rate under 0.3% (ideally near 0.1%), authenticate with SPF, DKIM, and DMARC, and offer RFC 8058 one-click unsubscribe. A list full of dead and disengaged addresses is the fastest way to breach 0.3%, and a frictionless unsubscribe is itself a hygiene tool because it keeps an annoyed recipient from clicking 'report spam' instead.

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.

More than 60% of emails are opened on mobile, and the person reading a 2FA code is often on the same phone they are logging in with. Use a single-column layout, buttons of at least 44x44px and full-width, body text 16px or larger, and OTP codes at 24 to 32px in monospace so 0 versus O is unmistakable. Keep the primary action above the fold (roughly the top 480 to 570px) so the user never has to scroll to find the button or code.

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 has to pass authentication or it lands in spam regardless of content, so SPF (RFC 7208), DKIM (RFC 6376), and DMARC (RFC 7489) with alignment are baseline for every sender. Since February 2024, Gmail, Yahoo, and Microsoft enforce these plus a spam-complaint rate under 0.3% for bulk senders, a threshold every serious sender should meet. Send from a dedicated transactional subdomain so a marketing complaint spike can never drag your password resets into spam.

A genuinely transactional, one-to-one message (a receipt to the buyer, a reset to the requester) is exempt from one-click unsubscribe (RFC 8058), so it doesn't need one. But the exemption is narrow and fragile: add a single promotional element like a discount banner or "you might also like" block, and a filter can reclassify the whole message as marketing, making the missing List-Unsubscribe header a compliance gap. For ambiguous streams (an "order shipped" that also nudges products) or high volume from one subdomain, add List-Unsubscribe and List-Unsubscribe-Post anyway, it's harmless and protects you.

Receipts are records people keep for taxes and expenses, so use a stable, sequential, never-reused invoice number and a downloadable PDF. Depending on jurisdiction, a compliant invoice needs the seller's legal name and tax ID, buyer details for business invoices, a unique sequential number, the issue date, a per-line and total breakdown, and the VAT/GST rate and amount shown separately. The email is just delivery; the PDF is the record, so generate it once and store it rather than regenerating with a different number on each download.

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.

Use double opt-in for all marketing lists: the subscriber clicks a link in a confirmation email, which proves both that the address is deliverable and that the person actually wants your mail. Single opt-in is fine only when the list is a byproduct of a transaction the user clearly initiated, like creating an account. Expect 10 to 30% of submissions to never confirm; those are mostly typos, fakes, and uninterested people you're better off without.

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's no universal number, but watch the relationship between cadence and your unsubscribe and complaint rates. If a frequency increase pushes unsubscribes above roughly 0.5% per send, or your complaint rate toward 0.1%, you're sending too often for that audience. Start conservative and let positive engagement signals earn more volume; it's far easier to add frequency than to win back annoyed subscribers.

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.

Keep your bounce rate under 2% (ideally under 1%) and your complaint rate under 0.05%. Since February 2024, Gmail, Yahoo, and Microsoft hold bulk senders to a complaint rate below 0.3% as a hard ceiling, with under 0.1% as the operating target, alongside SPF, DKIM, DMARC and one-click unsubscribe. Wire your provider's bounce and complaint webhooks into a global suppression list so breaches get 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.

The windows differ: CAN-SPAM gives 10 business days with the link valid 30+ days, CASL 10 business days with the link valid 60+ days, Australia just 5 business days, GDPR "immediately," and Gmail/Yahoo/Microsoft expect one-click processed within 48 hours. The safe engineering default kills the guesswork: process unsubscribes immediately and keep links valid at least 60 days. Do both and you satisfy the strictest column in every regime.

If you send in bulk, yes, and you need two headers, not one. List-Unsubscribe (RFC 2369) carries the unsubscribe URIs and must include an HTTPS URI; List-Unsubscribe-Post: List-Unsubscribe=One-Click (RFC 8058) opts the message into true one-click. A mailto:-only header does not qualify. Since Gmail/Yahoo (Feb 2024) and Microsoft (May 2025), bulk marketing mail without both can be throttled or junked.

They're mailbox-provider acceptance policies, not statutes, but they bite faster than any regulator, because non-compliant mail is rejected in minutes. If you send 5,000+ messages/day to Gmail, Yahoo (effective Feb 2024) or Microsoft (May 2025), you must authenticate with SPF (RFC 7208), DKIM (RFC 6376) and aligned DMARC (RFC 7489), keep spam complaints under 0.3%, support RFC 8058 one-click unsubscribe, and send over TLS with valid PTR. Below 5,000/day these are strongly recommended and your volume tends to cross the line sooner than expected.

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.

Severe and structured to multiply. CAN-SPAM is assessed per email at up to roughly $53,088 each (FTC inflation-adjusted), so one bad bulk send compounds with list size. GDPR fines reach the greater of €20M or 4% of global annual revenue, scaling to existential for large firms. CASL goes up to $1M CAD for an individual and $10M CAD for an organization per violation, and directors and officers can be held personally liable. (Figures current as of early 2026; this is practical guidance, not legal advice.)

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 sharp exception: an authentication-failure bounce (SMTP 5.7.26 from failed SPF/DKIM/DMARC) means your auth is broken, not the address, so alert your team rather than suppressing the recipient.

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 parses the headers to report SPF, DKIM and DMARC results plus alignment, the full Received chain, reverse DNS and TLS, and RFC 8058 one-click unsubscribe evidence. It checks Gmail/Yahoo bulk-sender compliance and gives you a deliverability score with concrete fixes. It is the fastest way to see exactly how a real message was authenticated and routed.

In Gmail, open the message, click the three-dot menu and choose "Show original", then copy everything. In Outlook (web or desktop) open the message, go to the menu and pick "View" then "View message 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 summarizes how well a single message meets the signals mailbox providers weigh when deciding inbox versus spam: passing and aligned SPF, DKIM and DMARC, a clean Received chain, valid reverse DNS and TLS, and a working RFC 8058 one-click unsubscribe. It is a diagnostic of 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 evaluates the February 2024 bulk-sender requirements on a real message: SPF plus DKIM plus DMARC all passing and aligned, and a working RFC 8058 one-click unsubscribe header. It cannot see your spam-complaint rate, which must stay under 0.3% and is measured at the provider over time. So it confirms the authentication and unsubscribe side; complaint rate you monitor separately via postmaster tools or your sending platform.

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: warm it up gradually instead of cutting over 100% on day one. Send your highest-engagement, lowest-risk mail first (transactional, recent active users), ramp volume over one to two weeks while watching bounces, spam complaints (keep under 0.3%), and Postmaster Tools data, and run both providers in parallel during the transition. Re-publish SPF, DKIM, and DMARC for the new provider and carry over your suppression lists so you never re-mail addresses that already bounced or unsubscribed.

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 own them, they live in your domain's DNS. The provider gives you an SPF include and DKIM CNAME/TXT records to publish, but the From-domain, the DMARC policy (RFC 7489), and the records themselves are yours. That's exactly why switching providers doesn't have to mean switching domains: you re-point the include and DKIM selector, keep your domain reputation, and stay covered by the Gmail/Yahoo/Microsoft bulk-sender rules (SPF + DKIM + DMARC) that took effect in February 2024.

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.