# Do I need… > Blunt answers to the email questions everyone asks. YES, NO, or IT DEPENDS—with the reasoning to back it up. doineed.email is written and maintained by the team at [Resend](https://resend.com), the email platform for developers. The people behind these answers run email sending infrastructure at scale and carry decades of combined deliverability experience—the verdicts here are the same ones we give when someone asks us directly. This file contains every answer in full. Each answer's canonical page is linked at the end of its section. --- # Do I need 2048-bit DKIM? **NO**—1024 is fine > Bigger keys sound safer, but 1024-bit DKIM is RFC-compliant, accepted by every major mailbox provider, and satisfies every bulk-sender requirement. 2048 buys you DNS headaches, not deliverability. Security instinct says a bigger key must be better. For DKIM on transactional and marketing mail, the practical answer is that 1024-bit keys are the right choice—and no inbox provider rewards you for going larger. ## 1024-bit is compliant and universally accepted [RFC 8301 §3.2](https://datatracker.ietf.org/doc/html/rfc8301#section-3.2) establishes 1024 bits as the minimum length verifiers must support and recommends signers use at least that. Gmail, Outlook, Yahoo, and Apple all accept 1024-bit signatures, and 1024-bit keys remain widely used across the industry. This is why Resend signs outbound mail with 1024-bit keys. ## The bulk sender rules don't care about key length The bulk sender requirements from Google, Yahoo, and Microsoft—the ones that apply once you send 5,000+ messages a day—require DKIM alongside SPF and DMARC. **None of them mandate a key length.** A 1024-bit signature satisfies them completely. ## What 2048 actually costs you - **Latency at scale.** Larger keys take longer to sign and verify on every single message. - **DNS friction.** The longer public key doesn't fit comfortably in a TXT record. Some DNS providers hit character limits or force you to split the value across strings—a classic source of broken DKIM records and failed verification. - **Zero placement upside.** Mailbox providers do not give 2048-bit signatures better treatment. A valid 1024-bit signature and a valid 2048-bit signature are, to the inbox, the same thing: valid. ## The exception If your security or compliance team has a hard policy requiring 2048-bit keys, that's a policy decision—a legitimate one—but it's not a deliverability decision. Make it with eyes open about the DNS setup it demands, and test the record carefully once it's live. --- - Canonical: https://doineed.email/2048-bit-dkim - Learn more: https://resend.com/docs/knowledge-base/do-i-need-2048-dkim - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need accessible emails? **YES** > Of 376,348 emails analyzed in 2026, eight passed every accessibility check. The fixes are small and mechanical—and they serve screen readers, dark mode, bright sunlight, and the agents now reading mail on humans' behalf. The Email Markup Consortium's 2026 report analyzed 376,348 emails. **Eight passed every accessibility check**—0.002%. Nearly all the failures were rated serious or critical, and yet most of the fixes are small, mechanical changes. That combination—near-universal failure, trivial remediation—is what makes this a yes. ## Who accessibility actually serves - **Assistive technology.** Screen readers, braille displays, low-vision zoom, right-to-left languages. For these readers, document structure isn't decoration—it's the only way to navigate a message. - **Every reader, situationally.** A phone in bright sun, an inbox that forces dark mode, a client auto-translating your copy. Accessibility failures degrade all of it. - **Machines acting for humans.** Mail clients and operating systems increasingly summarize, extract, and act on email. Accessible email is machine-readable email—the same structure that helps a screen reader helps the agent triaging someone's inbox. ## The six mechanical fixes 1. **Language and direction attributes** (`lang`, `dir`)—so screen readers pronounce your words in the right language and translation tools know what they're looking at. 2. **Mark layout tables as presentational** (`role="presentation"`)—email layout still leans on tables; without the role, assistive tech reads your two-column design as tabular data. 3. **A real semantic outline**—headings that are headings, not styled `
`s. Structure is navigation. 4. **Descriptive links and alt text**—"View your invoice", not "click here"; images described or explicitly decorative. 5. **A `` tag**—trivial, near-universally missed. 6. **Color contrast**—which, tested honestly, also catches the gray-on-gray footer text nobody can read in sunlight. If you build with a maintained framework (React Email templates, for instance), several of these come along by default—but "the framework probably handled it" is worth one audit to confirm. ## The verdict logic No qualifier on this one. There's no volume threshold below which excluding readers is fine, the fixes cost minutes, and the same markup quality pays you back in every context from dark mode to AI assistants. This is the rare email question where the right thing and the cheap thing are the same thing. --- - Canonical: https://doineed.email/accessible-emails - Learn more: https://resend.com/blog/6-tips-for-accessible-emails - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need AMP for email? **NO**—cool demo, tiny reach > Interactive email sounds like the future, but AMP is effectively a Gmail-only format that requires sender registration, a third MIME part, and a fallback that does the real work anyway. AMP for email embeds a third, interactive version of your message—forms, carousels, live-updating content—alongside the HTML and [plain-text](https://doineed.email/plain-text-version) parts. The demos are genuinely impressive. The economics mostly aren't. ## Why this is a no - **The audience is one inbox.** Gmail is the meaningful surface for AMP; support elsewhere is niche to nonexistent, and Apple Mail—a giant share of real-world opens—will never render it. You'd be building an experience most of your list can't see. - **The toll booth is real.** Gmail requires per-sender registration and approval before your AMP parts render, with quality and authentication bars to clear first. Miss any condition and recipients silently get the fallback. - **You must build the fallback anyway.** Every AMP email still needs a complete HTML version for everyone else—so the AMP part is additive work on top of a finished email, not a replacement. Dynamic AMP content also expires (stale messages fall back too), which means testing two experiences forever. - **It solves a problem the web already solved.** A well-labeled link to a page you control works in every client, needs no approval, and is where your form/survey/checkout probably lives anyway. ## The narrow yes hiding in the depends If your audience is measurably Gmail-heavy, you send high-value interactive flows (think booking confirmations with live seat maps, or in-email RSVP at serious volume), and you have the engineering appetite for a third rendering pipeline—AMP can genuinely lift completion rates by removing a click. Companies in that exact position make it work. If you had to check whether you're in that position, you're not. ## The honest framing AMP is a hype-check classic: real technology, real demos, and a cost/reach ratio that only pencils out for a sliver of senders. Ship great HTML, keep the plain-text honest, and put interactivity on the other side of a fast link. --- - Canonical: https://doineed.email/amp-for-email - Learn more: https://developers.google.com/gmail/ampemail - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need BIMI? **NO**—nice to have > BIMI puts your logo next to your emails, which is lovely branding—and does nothing for deliverability. It also quietly requires the thing that does matter: an enforcing DMARC policy. BIMI (Brand Indicators for Message Identification) is the standard that displays your logo next to your messages in supporting inboxes. It's a genuinely nice touch—recognizable senders get opened more—but it is decoration on top of authentication, not authentication itself. ## Why this is a no - **Zero deliverability effect.** No mailbox provider ranks your mail higher because a logo record exists. Whatever placement you have without BIMI, you have with it. - **It gates on the hard part anyway.** BIMI requires your DMARC policy to be `p=quarantine` or `p=reject`. If you're not at enforcement yet, BIMI isn't your next step—[DMARC is](https://doineed.email/dmarc). - **The certificate landscape is a mess.** The classic route needs a VMC—a certificate that requires a *trademarked* logo, with real cost and lead time. Gmail now also accepts CMCs (proof you've used the logo publicly for 12 months), but only Gmail honors those. Outlook supports none of it. ## If you want the logo anyway There's a pragmatic, mostly-free path once DMARC enforcement is in place: - **[Apple Branded Mail](https://resend.com/blog/apple-branded-mail)**—free, set up through Apple Business Connect, shows your logo in Apple Mail regardless of the recipient's email provider. - **BIMI without a certificate**—Yahoo and Fastmail display BIMI logos with no VMC/CMC at all. - **Then decide** whether Gmail coverage is worth paying for a CMC (or a VMC, if you want Gmail's blue checkmark, which is reserved for trademarked logos). That combination covers a large share of real inboxes for the price of a DNS record and an afternoon. ## The honest framing BIMI is a reward for finishing your authentication homework, not a shortcut to the inbox. Do SPF, DKIM, and DMARC properly, get to enforcement, and then—if the brand team is excited—collect the logo as a trophy. --- - Canonical: https://doineed.email/bimi - Learn more: https://resend.com/blog/email-changes-for-bimi - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need to watch my bounce and complaint rates? **YES**—the two numbers that matter > Bounces under 4%, complaints under 0.08%—these two numbers are how mailbox providers grade you, and they move before your open rates do. Watch them like uptime. "Deliverability" gets discussed like weather—mysterious, ambient, unaccountable. It isn't. Two operational metrics predict most of it, and both are on a dashboard you already have. ## The two numbers - **Bounce rate: keep it under 4%.** Repeatedly sending to invalid addresses tells providers you don't know your own list—the signature move of a spammer with a scraped database. Bounces are also the earliest warning that your list is aging. - **Spam complaint rate: keep it under 0.08%.** That's the healthy zone; **0.3%** is the ceiling Gmail, Yahoo, and Microsoft enforce on [bulk senders](https://doineed.email/bulk-sender-requirements) before filtering gets punitive. Complaints are recipients telling the referee, not you. One definitional trap while we're here: **delivery is not deliverability**. "Delivered" means the receiving server accepted the message; it says nothing about inbox versus spam folder. A 99% delivery rate with mail rotting in spam is a deliverability failure your delivery metric will never show—which is exactly why you watch bounces and complaints instead. ## How to actually watch them - **Your ESP's dashboard.** On Resend, the [Metrics tab](https://resend.com/metrics) charts bounce and complaint rates continuously, and per-email [Deliverability Insights](https://resend.com/docs/dashboard/emails/deliverability-insights) flag issues before they become patterns. - **Webhooks for automation.** Subscribe to `email.bounced` and `email.complained` events and wire them to alerts—and to your list, so offenders are removed automatically. A [suppression list](https://doineed.email/suppression-list) does the removal part natively. - **Gmail's blind spot.** Gmail doesn't report individual complaints back to senders, so your ESP-side complaint rate undercounts your biggest audience. [Gmail Postmaster Tools](https://doineed.email/gmail-postmaster-tools) is where Gmail shows you its number—watch both. ## When the numbers move Rising bounces → clean the list and check what changed at the source (a stale segment? a broken signup form?). Rising complaints → your content or targeting outran consent: make [unsubscribing effortless](https://doineed.email/one-click-unsubscribe), tighten to engaged recipients, and slow down. Both respond fast if you respond fast—the expensive failures are the ones nobody was watching. --- - Canonical: https://doineed.email/bounce-and-complaint-rates - Learn more: https://resend.com/docs/dashboard/emails/deliverability-insights - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need to comply with the bulk sender requirements? **YES**—law at 5,000 a day > Since 2024, Gmail, Yahoo, Microsoft, and Apple enforce the same baseline on bulk senders: full authentication, one-click unsubscribe, complaints under 0.3%. Below the threshold you're graded on it anyway. Between 2024 and 2025 the major mailbox providers stopped treating sender best practices as suggestions. Gmail and Yahoo enforced first (February 2024), Apple hardened its recommendations into requirements, and Microsoft joined in May 2025—with SMTP-level rejections (`550 5.7.515`) for senders who fail authentication. ## Who's a "bulk sender" The consistent threshold is **5,000 or more messages a day** to a provider's consumer domains (gmail.com, yahoo.com, outlook.com/hotmail.com/live.com). It targets newsletters, promotions, and campaigns rather than triggered transactional mail—but the practices apply to everyone, and enforcement mechanisms don't always check your volume badge first. ## The requirements, in one place 1. **Authenticate fully.** [SPF](https://doineed.email/spf), [DKIM](https://doineed.email/dkim), and a [DMARC policy](https://doineed.email/dmarc)—`p=none` satisfies the requirement; the point is that a policy exists and your mail aligns with it. 2. **One-click unsubscribe.** The RFC 8058 `List-Unsubscribe` + `List-Unsubscribe-Post` headers on bulk mail, honored within two days—[details here](https://doineed.email/one-click-unsubscribe)—plus a visible unsubscribe link in the body. 3. **Complaints under 0.3%.** The hard ceiling; healthy senders sit under 0.08%. This is the requirement that punishes bought lists and lazy targeting, and the one you [monitor continuously](https://doineed.email/bounce-and-complaint-rates). 4. **Valid sender addresses.** Microsoft additionally requires that your From and Reply-To addresses actually accept mail—one more reason [no-reply@ is a bad habit](https://doineed.email/no-reply-address). ## Why comply below the threshold Because the requirements are just deliverability fundamentals with enforcement attached. Authentication, easy exits, and low complaints are how mail lands in inboxes at *any* volume—and if you're growing, crossing 5,000/day with these already in place is a non-event instead of a scramble. A good ESP handles the mechanical parts by default (Resend requires domain authentication and sets the unsubscribe headers on Broadcasts automatically); the list quality half is yours. The one-page version: authenticate, make leaving easy, send to people who want it. The providers didn't invent new rules—they started enforcing the old ones. --- - Canonical: https://doineed.email/bulk-sender-requirements - Learn more: https://resend.com/blog/gmail-and-yahoo-bulk-sending-requirements-for-2024 - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need click tracking? **IT DEPENDS**—the reliable half > Unlike opens, a click is a real human act—it's the engagement number you can actually trust. The cost: your links get rewritten, so do it on your own domain or not at all. Click tracking rewrites each link in your email to pass through a redirect that records the click before forwarding the reader on. Where [open tracking](https://doineed.email/open-tracking) measures whether an image loaded, click tracking measures whether a person acted—which makes it the half of email analytics worth having. ## Why clicks are the trustworthy metric A click is deliberate. Nobody's privacy proxy accidentally reads your pricing page—if they clicked, they read the email and cared enough to act. That makes click data useful for the decisions that matter: which content earns attention, which segments are alive (feeding your [sunset policy](https://doineed.email/sunset-policy)), whether a campaign moved anyone. Opens can't honestly answer any of those. ## What it costs you - **Your links stop being your links.** Every URL in the message becomes a tracking redirect. Done on a shared ESP domain, that's a reputation and trust problem—which is why click tracking and a [custom tracking domain](https://doineed.email/custom-tracking-domain) are a package deal, not separate decisions. - **Security scanners click things.** Corporate mail gateways follow links to inspect them, generating clicks no human made. Click data is *far* cleaner than open data, but treat single-click signals from corporate domains with mild suspicion—and never make a tracked click perform a destructive action on its own. - **A redirect is a dependency.** If the tracking domain has issues, your links do too. (One more reason it should be a subdomain you control.) ## The verdict logic For marketing and lifecycle email, this leans firmly yes: it's the engagement signal that's actually real, and the setup cost is one DNS record. For transactional mail, think before enabling it—a password-reset link that passes through a redirect looks less trustworthy to both filters and humans, and you already know the recipient is engaged (they triggered the email). Resend ships both open and click tracking **off by default** for exactly this reason: turn clicks on deliberately, per domain, for the streams where the data changes decisions. --- - Canonical: https://doineed.email/click-tracking - Learn more: https://resend.com/docs/dashboard/domains/tracking - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need a custom return path? **YES**—the default is fine > Your ESP already sets a working, aligned Return-Path on a subdomain it manages—deliverability-wise you're covered. Customize it when branding or a picky security review demands it. The Return-Path (also called the envelope sender, bounce address, or MAIL FROM) is where bounces go and where SPF looks during authentication. It's mostly invisible plumbing—recipients see your From address, not this—but some email clients will surface it in a "via" hint or in the raw details view. ## What you get by default A good ESP configures this for you on a subdomain of your own sending domain—Resend, for example, uses `send.yourdomain.com` unless you say otherwise. That matters for one technical reason: because the Return-Path lives under *your* domain, SPF authenticates and **aligns** with your From domain, which is what DMARC wants to see. Bounce handling is wired up, the records are part of domain verification, and there is nothing to maintain. In other words: the deliverability box is already ticked. A custom return path does not improve inbox placement. ## When customizing makes sense - **Naming standards.** Your security or brand team wants `mail.acme.com` rather than `send.acme.com`, or has conventions for what may appear in DNS. - **Client exposure.** Since some clients surface the Return-Path domain, you may care that it reads professionally. (Related: avoid values that undermine credibility—`testing.acme.com` in a customer's mail client is not a great look.) - **Multiple streams.** Distinct return paths per mail stream can make bounce attribution tidier at scale. The constraints are mundane: 63 characters or fewer, letters/numbers/hyphens, must start with a letter. Set it when you add the domain—changing it later means new DNS records and re-verification. ## The verdict logic You need a working, aligned return path—that part isn't optional, and your ESP's default already provides it, which is why this is a yes you probably don't have to do anything about. Whether you need a *custom* one is taste: if something is broken, this isn't the fix; if you want the plumbing labeled your way, it's one setting and a DNS record. Polish, not performance. --- - Canonical: https://doineed.email/custom-return-path - Learn more: https://resend.com/docs/dashboard/domains/custom-return-path - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need a custom tracking domain? **YES**—if tracking is on > Tracking links default to a domain you share with strangers—and their reputation becomes yours. If you track opens or clicks, the redirect domain should be one you own. When click tracking is enabled, every link in your email gets rewritten to pass through a redirect domain that records the click before forwarding the reader on. The question is whose domain does that job. ## The default is a shared domain Out of the box, most ESPs route tracking through a domain shared across many customers. Shared domain, shared reputation: if other senders on it behave badly, the domain's standing degrades—and every link in *your* email now carries that smell. You did nothing wrong and inherited the damage anyway, which should sound familiar if you've read [the dedicated IP answer](https://doineed.email/dedicated-ip). Links are the same story with worse defaults. ## Why your own domain wins - **Link alignment.** Inbox providers like consistency between the sending domain and the domains inside the message. Tracking links on `links.yourdomain.com` align; tracking links on a third-party domain are a small, persistent mismatch. - **Reader trust.** Hover over a link and the URL shown is yours, not an unfamiliar redirect host. Recipients trained to distrust weird domains have one less reason to hesitate—and so do the filters that think like them. - **Isolation.** Your tracking reputation rides on your behavior alone, like everything else on your domain should. ## The setup It's one DNS record. On Resend, custom tracking domains are free: pick a tracking subdomain (say, `links.yourdomain.com`) in the domain's configuration, add the record, and all tracking routes through it automatically—configurable via the API too. Both open and click tracking are off by default, so this only matters once you switch something on. ## The verdict logic The qualifier carries the whole answer: this is a *yes* precisely when tracking is enabled. If you track nothing—[a reasonable choice for transactional mail](https://doineed.email/open-tracking)—there are no tracking links to align and nothing to set up. But the moment tracking is on, running it through someone else's domain is an unforced error. --- - Canonical: https://doineed.email/custom-tracking-domain - Learn more: https://resend.com/blog/introducing-custom-tracking-domain - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need a dedicated IP? **IT DEPENDS**—most likely no > If you have to ask, you probably don't. Dedicated IPs pay off for senders with high, steady volume and deliverability expertise—everyone else inherits a cold IP and a warming project. Dedicated IPs get pitched as the instant fix for deliverability problems. The reality is less flattering: they're a specialist tool that rewards one specific kind of sender and quietly punishes everyone else. ## The part nobody tells you Mailbox providers care far more about your **domain reputation** than your IP. Domain reputation reflects *you*—what you send, how people engage with it, whether your authentication and hygiene are in order—and it follows you across providers, platforms, and IPs. The sending IP, meanwhile, has become a weaker filtering signal over the years: senders switch providers and rotate IPs all the time. True IP blocks are rare, temporary, and straightforward to fix. Domain reputation damage is the slow, ambiguous kind. If your emails are landing in spam, changing your IP is rarely the cure—it usually just resets the clock somewhere new. ## When the answer is yes A dedicated IP makes sense when all three are true: 1. **High volume.** Hundreds of thousands of emails per month, consistent week to week. 2. **Predictable patterns.** A regular cadence without long gaps or sudden spikes. 3. **Deliverability expertise.** You understand IP warming, list hygiene, and engagement metrics—because the reputation is now entirely yours to build and maintain. For that sender, a dedicated IP means control: your reputation is shaped only by your own behavior, and troubleshooting gets simpler when things go wrong. ## When the answer is no A dedicated IP starts stone cold. You have to warm it gradually, and if your volume is modest or spiky, you can't sustain the reputation you built—quiet weeks let it decay. A well-run shared pool gives you the opposite deal: you inherit the established reputation of vetted senders and get solid inbox placement from day one, while the provider monitors the pool and removes bad actors. A startup sending a monthly newsletter to a few thousand people does not need a dedicated IP. It needs a clean list and a good domain reputation. ## The honest test Daily sends, six figures a month, someone on the team who owns deliverability? Go dedicated—and warm it properly. Anything less, stay on the shared pool and spend the energy on your domain reputation instead. That's the asset that actually moves the needle. --- - Canonical: https://doineed.email/dedicated-ip - Learn more: https://resend.com/blog/do-you-need-a-dedicated-ip - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need DKIM? **YES** > DKIM is your cryptographic signature—proof the message came from you and wasn't altered in transit. Every major provider expects it, and DMARC is hollow without it. DKIM (DomainKeys Identified Mail) signs every message you send with a private key, and publishes the matching public key in your DNS. When an inbox receives your mail, it verifies the signature against the public record—proving the message really came from your domain and wasn't tampered with along the way. ## Why this is a yes - **The big providers require it.** Google, Yahoo, and Microsoft's bulk sender requirements demand DKIM alongside SPF and DMARC. For everyone else it's still the baseline of looking legitimate. - **It's the DMARC workhorse.** DMARC passes when SPF or DKIM passes *and aligns* with the From domain. SPF breaks when mail is forwarded; a DKIM signature survives the trip. If only one of the two holds up in the real world, it's DKIM. - **Spoofing protection scales with your brand.** The more recognizable your domain gets, the more attractive it becomes to impersonate. A signature only you can produce is the counter. ## How it works in practice 1. You publish a public key in DNS (usually CNAME or TXT records your ESP hands you). 2. Every outbound message gets a `DKIM-Signature` header generated with the private key. 3. Receivers look up the public key and check the pair. Having multiple DKIM records is normal—typically one or more per sending provider, each under its own selector. They don't conflict the way SPF records do. ## The gotchas - **Key length:** 1024-bit is the right choice for transactional and marketing mail—see [do I need 2048-bit DKIM?](https://doineed.email/2048-bit-dkim) (spoiler: no). - **Verify after setup.** A broken record—DNS typo, truncated value, wrong selector—means failed signatures, and under an enforcing DMARC policy, failed signatures mean blocked mail. - **Don't sign and forget.** If a private key is ever exposed, rotate it. Your ESP should make that boring. If you send through an ESP like Resend, DKIM comes with domain verification out of the box. Confirm the records resolve, then move on to [DMARC](https://doineed.email/dmarc). --- - Canonical: https://doineed.email/dkim - Learn more: https://resend.com/blog/email-authentication-a-developers-guide - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need to rotate my DKIM keys? **NO**—unless a key leaks > Routine DKIM rotation is security theater for most senders—your ESP manages the keys, and a broken rotation hurts more than a stale key ever did. Compromise is the exception: rotate immediately. Key rotation is real security hygiene—for credentials humans handle. DKIM keys mostly aren't that, and the rotation advice gets cargo-culted from contexts where it earns its keep into one where it mostly adds risk. ## Why this is a no - **Your ESP already owns this.** If you send through a platform, [DKIM signing](https://doineed.email/dkim) came with domain setup: the platform generated the keys, holds the private half in infrastructure you never touch, and is the party responsible for their lifecycle. Rotating a key you can't leak has the flavor of changing a password nobody knows. - **The failure mode is worse than the threat.** Rotation means new DNS records, propagation windows, and selector coordination—and a botched rotation produces failing signatures, which under an [enforcing DMARC policy](https://doineed.email/dmarc-p-reject) means bounced mail. The realistic risk of a stale-but-secret 1024-bit key is far smaller than the realistic risk of a DNS mistake. - **No deliverability upside.** Providers don't reward key freshness, the same way they [don't reward key length](https://doineed.email/2048-bit-dkim). A valid signature is a valid signature. ## The exceptions that flip it - **Compromise—rotate immediately.** If a private key is exposed (a leaked server, a departed vendor who had signing access, keys checked into a repo), that's not rotation, that's revocation: publish a new selector, cut over, and null the old key's DNS record. - **You run your own signing.** [Self-hosted infrastructure](https://doineed.email/my-own-mail-server) means the keys live on machines you patch, and periodic rotation becomes ordinary operational hygiene—industry best-practice guidance suggests a regular cadence precisely because self-managed keys accumulate exposure. - **DKIM replay concerns.** Spammers occasionally re-send a legitimately signed message at scale to ride the signer's reputation. Rotation helps only after the fact; if replay is a live concern for you, the real mitigations live in signing practices (like header oversigning), not in a calendar reminder. ## The verdict logic Keys managed by your platform: leave them alone and spend the energy on [the reports](https://doineed.email/dmarc-reports). Keys you manage yourself: schedule rotation like any other credential. Keys that leaked: this page was never the question. --- - Canonical: https://doineed.email/dkim-rotation - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need DMARC? **YES**—at least p=none > Every serious mailbox provider now expects a DMARC policy on your domain. Publishing p=none costs nothing, breaks nothing, and shows you exactly who is sending as you. DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy layer on top of SPF and DKIM: a DNS record telling receivers what to do with mail that claims to be from your domain but fails authentication—and, crucially, asking them to *report back* what they're seeing. ## Why this is a yes - **The requirements say so.** Google, Yahoo, and Microsoft all require bulk senders to publish a DMARC policy. Send meaningful volume without one and you're volunteering for the spam folder. - **Spoofing is your problem even when you didn't send the mail.** Phishing that wears your domain burns your customers and your reputation. DMARC is the mechanism that lets receivers refuse it. - **The reports alone are worth it.** With reporting enabled, you get visibility into every source sending as your domain—including the marketing tool someone connected two years ago and forgot. ([Read them](https://doineed.email/dmarc-reports)—publishing without reading is half the value.) ## Starting is free The minimum viable DMARC is one TXT record: ```txt _dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com" ``` `p=none` is observation mode: no enforcement, no risk to legitimate mail, full visibility. This is the right starting point for almost everyone—it establishes a baseline of who sends on your behalf and surfaces misconfigured senders before they become incidents. ## Where it goes from here `none` is the floor, not the destination. The escalation path is `none` → fix what the reports surface → `quarantine` → `reject`. Enforcement is where DMARC actually stops spoofing—but it's a decision with teeth, which is why it gets [its own verdict](https://doineed.email/dmarc-p-reject). One warning: don't publish `quarantine` or `reject` on day one because a security checklist told you to. Unauthenticated legitimate mail—a billing system, a support desk, that forgotten marketing tool—gets filtered or bounced, and you'll find out from angry humans instead of tidy reports. One footnote: the spec itself is evolving—[a new revision of DMARC](https://resend.com/blog/the-new-dmarc-is-here) is on the way, and everything above carries over. --- - Canonical: https://doineed.email/dmarc - Learn more: https://resend.com/docs/dashboard/domains/dmarc - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need p=reject? **IT DEPENDS**—earn it first > Reject is where DMARC actually protects your domain—but publish it before every legitimate sender passes and aligns, and you'll block your own mail. Monitor, fix, then enforce. `p=reject` tells every receiving mail server: *do not deliver anything from my domain unless it passes DMARC.* It's the strongest stance email authentication offers—highly effective against phishing that spoofs your domain, and equally effective against your own misconfigured senders. ## When the answer is yes - **You send bulk mail to consumers.** Enforcement is increasingly the expectation, not the extra credit. - **Your domain is a phishing target.** Fintech, healthcare, anything with logins and money—reject is the point of the whole exercise. - **You want BIMI.** Logo-in-inbox standards require an enforcing policy (`quarantine` or `reject`) before they'll even look at you. - **Your reports are clean.** Every legitimate source authenticates and aligns, and has for a while. ## When the answer is not yet If you haven't spent time in [your DMARC reports](https://doineed.email/dmarc-reports) (`rua`), you don't actually know who sends as your domain. The billing platform, the CRM, the support desk, the survey tool marketing signed up for—any of them not passing and aligning gets bounced the moment you publish reject. With rejection, failures are loud: mail bounces, people complain, broken flows surface fast. That's a feature when you're ready and an outage when you're not. ## The rollout that works 1. **`p=none`** with reporting—gather data, no enforcement. 2. **Fix what you find**—authenticate every legitimate source, align domains. 3. **`p=quarantine`**—failing mail goes to spam rather than bouncing. Beware the quiet failure mode: broken-but-legitimate senders can sit in spam-folder purgatory unnoticed. 4. **`p=reject`**—once reports stay clean. Two footnotes from the trenches: the `pct=` parameter for gradual rollout is not widely respected by mailbox providers, so don't lean on it—and enforcement on the root domain applies to subdomains unless you say otherwise with `sp=`. DMARC was designed for gradual rollout; use the reports and the climb is painless. --- - Canonical: https://doineed.email/dmarc-p-reject - Learn more: https://resend.com/blog/dmarc-policy-modes - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need to read my DMARC reports? **IDEALLY**—rua, at minimum > Publishing DMARC without reading the reports is buying a smoke alarm and never checking the battery. The aggregate reports are where misconfigured senders and spoofers show up first. Reporting is the R in DMARC, and it's the part that makes the rest work: [the policy](https://doineed.email/dmarc) protects your domain, but the reports are how you find out what the policy is actually doing—and whether it's safe to [tighten it](https://doineed.email/dmarc-p-reject). ## Two report types, one worth your time - **RUA (aggregate)**—daily summaries from every receiver that saw mail claiming to be you: which sources sent, whether SPF/DKIM passed and aligned, and what the receiver did about it. This is the one to read. - **RUF (forensic)**—a per-failure report with message details. Don't build your monitoring on these: Gmail and Outlook don't send them for privacy reasons, volume can be overwhelming when something breaks, and delivery is batched anyway. Enable them only while investigating a specific incident. ## What the aggregates actually tell you Three things you can't see anywhere else: 1. **Every source sending as your domain**—including the CRM, billing tool, or survey platform someone connected and forgot. These are exactly the senders that break the day you enforce. 2. **Authentication gaps**—sources that send legitimate mail but fail alignment, quietly eroding your delivery. 3. **Spoofing attempts**—unauthorized senders wearing your domain, which is the abuse DMARC exists to stop. One subtlety worth knowing: your published policy is a *request*. The report's `disposition` field shows the receiver's actual *decision*, and the two don't always match. The reports are where you learn how the world really treats your mail. ## Nobody reads raw XML (use a tool) Reports arrive as XML attachments, often gzipped, and reading them by hand is penance. Resend open-sourced a [DMARC Analyzer](https://github.com/resend/resend-dmarc-analyzer) you can run yourself—it ingests RUA reports via inbound webhooks (compressed attachments included), gives you a paste-and-analyze UI, and can email you digests. ## The verdict logic This is an *ideally* because a small sender with one ESP and `p=none` can survive without ritual report-reading. But the reports cost nothing—one `rua=` tag in the record you're publishing anyway—and everyone touching enforcement, multiple sending tools, or a spoofing-prone brand should be reading them. The smoke alarm is free; check the battery. --- - Canonical: https://doineed.email/dmarc-reports - Learn more: https://resend.com/blog/how-to-read-a-dmarc-report - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need to worry about domain reputation? **YES** > Domain reputation is the score that actually decides inbox placement—it reflects what you send and how people react, and it follows you across every provider, platform, and IP. Every mailbox provider evaluates your reputation before deciding where your email lands. The criteria are private and differ by provider, but the inputs are broadly the same—and the identity they attach the score to is, overwhelmingly, your **domain**. ## Why the domain is the unit that matters Your domain reputation reflects *you*, not your infrastructure: what you send, how often, to whom, and how those people react. That's exactly why providers lean on it—infrastructure is easy to change, behavior isn't. And it cuts both ways: the reputation follows you across ESPs, platforms, and IP addresses. You can't switch providers to escape it, which also means the equity you build is genuinely yours. ## What feeds it - **Authentication.** [SPF](https://doineed.email/spf), [DKIM](https://doineed.email/dkim), and [DMARC](https://doineed.email/dmarc) in place and aligned—table stakes, and increasingly enforced outright. - **Recipient reaction.** Opens, clicks, and replies say "wanted"; spam complaints and deletes-without-reading say the opposite. This is why consent and [list hygiene](https://doineed.email/sunset-policy) are reputation work, not admin work. - **Sending behavior.** Consistent, predictable patterns build trust; spikes, gaps, and [bounce/complaint rates](https://doineed.email/bounce-and-complaint-rates) over the thresholds burn it. - **Shared responsibility.** Your ESP manages the infrastructure half (pool quality, authentication defaults); the behavioral half is not delegable. ## The asymmetry to respect Reputation damage is slow to diagnose and slow to repair—recovery means auditing authentication, cleaning the list, and ramping volume back up gently while engagement recovers. Prevention is cheap; repair is a project. If you only monitor one thing about your email program, monitor this—[Gmail Postmaster Tools](https://doineed.email/gmail-postmaster-tools) shows you the score directly for the provider that matters most. ## The honest framing Most "do I need X?" questions on this site are really this question wearing a costume. A dedicated IP, a warmup plan, a sunset policy—each is a lever on the same underlying asset. The answer here is the unqualified yes that makes the other answers make sense. --- - Canonical: https://doineed.email/domain-reputation - Learn more: https://resend.com/blog/6-steps-to-improve-your-sender-reputation-score - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need to warm up my domain? **YES** > A brand-new domain has no reputation, and inbox providers distrust strangers who shout. Ramp volume gradually—and re-warm whenever your provider, IP, or volume changes significantly. Warming up means progressively increasing your sending volume so inbox providers can build a picture of you as a consistent, trustworthy sender. Reputation is earned over time; a domain nobody has seen before suddenly blasting 50,000 messages looks exactly like what spammers do. ## When it applies Warm up whenever your sending pattern is about to change materially: - **New domain**—no history means no trust. Start small: on the order of ~150 emails on day one, roughly doubling toward ~2,000/day by the end of week one, and onward from there. - **New provider or new IP**—infrastructure changed, so part of your identity did too. An established domain can ramp faster (think 1,000 → 10,000/day over a week), but it should still ramp. - **A big volume jump**—a product launch or list migration that 10×es your daily send deserves a plan, not a spike. While ramping, watch two numbers: keep bounces under **4%** and spam complaints under **0.08%**. If either climbs, slow down and find out why before pushing further—the metrics are the warmup. ## When you're already warm If your domain is established, your volume is steady, and nothing about your infrastructure changed—there is nothing to do right now. Warming up isn't a recurring ceremony; it's how you start and how you respond to change. Consistent good behavior *is* the maintenance plan. ## The spirit of the thing Warmup schedules are baselines, not physics. The mechanism underneath is always the same: real recipients engaging positively with mail they expected, at a volume that grows smoothly. Start with your most engaged segment, lead with your most-wanted mail, and let the numbers tell you when to accelerate. And whatever you do, don't outsource it to a [warmup service](https://doineed.email/warmup-service). --- - Canonical: https://doineed.email/domain-warmup - Learn more: https://resend.com/docs/knowledge-base/warming-up - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need double opt-in? **IDEALLY** > Nothing proves consent like a click in a confirmation email. It's not legally required everywhere, but it keeps bots, typos, and grudges off your list—most lists are better with it. Double opt-in means a signup isn't a subscription until the person clicks a confirmation link you emailed them. Single opt-in trusts the form; double opt-in verifies the inbox. ## What it buys you - **Proof of consent.** The confirmation click is timestamped evidence that the actual owner of the address said yes—the strongest position you can be in under GDPR-style consent rules and Canada's CASL, and the cleanest answer when a complaint dispute arises. - **A cleaner list at the door.** Typos never confirm. Bots rarely confirm (pair it with a CAPTCHA and they mostly stop arriving at all). The address that confirms is valid, reachable, and belongs to someone interested enough to click—which is exactly the engagement baseline inbox providers reward. - **Fewer landmines.** The person who didn't sign up—mistyped address, prank entry, scraped form—never enters your list, never gets your campaign, never files the spam complaint. ## What it costs Friction. Some genuinely interested people won't complete the confirmation, and your list grows slower than your signup form suggests it should. That's the whole trade: a smaller list of people who demonstrably want your mail, versus a bigger list carrying unknown risk. For deliverability, the smaller list wins. Complaint and bounce rates—the numbers that decide your inbox placement—punish quantity without consent. ## Where it tips - **Marketing lists and newsletters:** default to yes. This is where complaints breed and where consent proof matters. - **Account-based products:** creating an account with email verification already *is* a double opt-in for transactional mail. You don't need a second ceremony—but marketing consent should still be its own [unchecked, specific checkbox](https://doineed.email/to-buy-an-email-list), never bundled into the terms of service. - **Markets where it's expected:** in much of Europe (Germany especially), confirmed opt-in is customary bordering on assumed. Follow the custom. If your complaint rate is comfortable and your acquisition is clean, single opt-in can work. But if you're asking, the safe default is the one with the receipt. --- - Canonical: https://doineed.email/double-opt-in - Learn more: https://resend.com/blog/how-to-properly-get-email-consent - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need email verification? **IDEALLY**—at the edges > Verify at the boundaries: a check at signup keeps typos and bots out, and a cleaning pass before mailing an old list saves your bounce rate. A pristine double-opt-in list needs neither. "Email verification" is really two different jobs, and the verdict differs by job. ## Job one: verify at the point of capture A signup form accepts anything with an @ in it. Real-time verification—syntax check plus a deliverability lookup against services like Emailable, ZeroBounce, or Kickbox—catches the typo (`gamil.com`), the fake, and the disposable address before it enters your list. Pair it with a CAPTCHA so bots don't get to play at all. This is cheap, invisible to legitimate users, and prevents problems instead of cleaning them up. If your signup volume is meaningful, it's close to a plain yes. ## Job two: clean an existing list Batch verification earns its keep in specific moments: - **An aged list.** You haven't mailed in six months? Addresses die constantly—people change jobs, abandon inboxes, domains lapse. Mailing the old list raw is how you blow through the ~4% bounce threshold in one campaign. - **Before a migration or a big send.** New provider, new subdomain, product launch—moments when your reputation is being re-evaluated are the worst moments to bounce heavily. - **A re-engagement push.** By definition you're mailing the least-alive segment; verify first. ## When you don't need it If your list is built on [double opt-in](https://doineed.email/double-opt-in), mailed regularly, and your ESP suppresses bounces automatically (good ones do), a verification service adds little—the list verifies itself through use. One honest caveat: verification checks whether an address *exists*, not whether its owner *wants your mail*. A cleaned list of people who never opted in still generates complaints—bounce rate is the only number it fixes. Verification is a tool inside [list hygiene](https://resend.com/docs/knowledge-base/audience-hygiene), not a substitute for it: keep sending to engaged recipients, and sunset the ones who've gone quiet for six months or more. --- - Canonical: https://doineed.email/email-verification - Learn more: https://resend.com/docs/knowledge-base/audience-hygiene - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need Gmail Postmaster Tools? **YES**—if you send bulk to Gmail > It's free, it's first-party, and it's the only way to see your domain reputation the way Gmail sees it. If Gmail matters to your list, sign up before you need it. Gmail Postmaster Tools is Google's free dashboard for senders: verify your domain once (a DNS record) and you get Gmail's own view of your domain and IP reputation, spam complaint rate, authentication results (SPF/DKIM/DMARC), encryption, and delivery errors. For most senders, some enormous share of the list is Gmail addresses. This is the scoreboard for that share, published by the referee. ## Why this is a yes - **It's the metric that decides your fate, from the source.** Gmail enforces a spam complaint ceiling of **0.3%** for bulk senders—and healthy senders stay under 0.08%. Postmaster Tools is where Gmail shows you *your* number. Third-party seed tests guess; this is the answer key. - **Reputation history is diagnostic gold.** When deliverability dips, the first question is "when did it start and what changed?" If you set up Postmaster Tools *before* the incident, you have the timeline. If you set it up after, you're reconstructing history blind. Sign up while things are fine. - **It's free and takes minutes.** One TXT record to verify domain ownership. There is no catch. ## The qualifier, explained Google anonymizes the data, which means **low-volume senders see sparse dashboards or nothing at all**—you need enough Gmail traffic for the numbers to render. That's the "if you send bulk" in the verdict: a few hundred emails a month won't chart. Verifying your domain anyway is harmless, but don't expect insight until volume arrives. ## Round out the set Gmail isn't the only provider with a window like this: Yahoo offers **Sender Hub**, and Microsoft has **SNDS** for IP-level insight into Outlook traffic. Same logic—free, first-party, set up before you need them. One thing Postmaster Tools won't do: fix anything. It's instrumentation. When it shows reputation sliding, the remedies live in your [authentication](https://doineed.email/dmarc), list hygiene, and [consent practices](https://doineed.email/double-opt-in)—the dashboard just makes sure you find out early. --- - Canonical: https://doineed.email/gmail-postmaster-tools - Learn more: https://support.google.com/a/answer/9981691 - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need idempotency keys? **IDEALLY**—if your code retries > Networks fail mid-request and retries are how you cope—but a retried send without an idempotency key is how a customer gets three copies of one receipt. One header makes retries safe. Here's the failure mode: your code calls the email API, the request times out, and you retry—sensible. Except a timeout doesn't mean the request failed; it means you didn't hear the answer. If the first attempt actually went through, your retry just sent the email twice. Email is the worst place for this bug, because the duplicate lands somewhere a human is guaranteed to look. ## What a key does An idempotent operation can run more than once with the same input and produce the same outcome, side effects included—which for email means: sent exactly once. You opt in by attaching a unique key to each *logical* send: ```txt Idempotency-Key: order-confirmation-8412 ``` Retry with the same key and the API recognizes the operation, returns the original result, and does not send again. The key should identify the event, not the attempt—derive it from something stable like `order-confirmation-${orderId}`, never a random value generated per request (that would defeat the whole mechanism). ## When it matters - **Anything that retries automatically.** Queue consumers, serverless functions with retry policies, cron jobs that re-run after a crash—all of them will eventually replay a send. - **At-least-once delivery systems.** Webhook handlers and message queues promise "at least once", and email is a side effect you want "exactly once". - **Transactional mail specifically.** A duplicate newsletter is mildly embarrassing; a duplicate "your payment was processed" makes customers file support tickets. On Resend it's the `Idempotency-Key` header (or the equivalent SDK option) on the send-email endpoint. ## The verdict logic This is an *ideally* rather than a yes because a low-volume app doing fire-and-forget sends with no retry logic has nothing to protect against—no retries, no duplicates. But the moment there's a retry path anywhere between your event and the send call (and in production systems there almost always is), the key is one line of code that removes a whole class of embarrassing bugs. Cheap insurance, like a [plain-text part](https://doineed.email/plain-text-version), but for your reputation with your own customers. --- - Canonical: https://doineed.email/idempotency-keys - Learn more: https://resend.com/blog/engineering-idempotency-keys - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need to worry about IP reputation? **IT DEPENDS**—your ESP worries for you > On a shared pool, IP reputation is your provider's job—and providers weigh the IP less every year anyway. It becomes your problem the day you take a dedicated IP. People fixate on IP reputation because when it fails, it fails loudly—scary SMTP responses, bounce spikes, blocklist drama. But the fixation is mostly misplaced. ## Why it's usually not your problem - **Providers weigh it less every year.** Senders switch ESPs and rotate IPs constantly, and IPv6 made addresses cheap—so the sending IP has become a weak identity signal. Mailbox providers moved the trust ledger to [domain reputation](https://doineed.email/domain-reputation), which reflects behavior rather than infrastructure. - **On a shared pool, it's managed for you.** A good ESP curates the pool: monitoring performance, enforcing standards, removing bad actors. You inherit the pool's standing on day one—that's the entire value proposition of shared sending. - **True IP blocks are the good kind of problem.** Rare, temporary, and mechanical to fix—unlike domain damage, which is ambiguous and slow to repair. If your mail is landing in spam, the IP is almost never the culprit. ## When it becomes your problem Take a [dedicated IP](https://doineed.email/dedicated-ip) and the ledger is yours alone: you warm it, your volume sustains it, your quiet weeks decay it, and your mistakes are unambiguously attributed to you. That's a fair trade for high-volume senders with steady patterns—and a self-inflicted wound for everyone else. Running [your own mail server](https://doineed.email/my-own-mail-server) is the same deal with less support and worse defaults. ## What to do instead of worrying Spend the anxiety on the things the IP conversation distracts from: authentication in order, [bounce and complaint rates](https://doineed.email/bounce-and-complaint-rates) under their thresholds, engaged recipients, consistent volume. Get those right and the IP question answers itself—usually with "the shared pool is fine." --- - Canonical: https://doineed.email/ip-reputation - Learn more: https://resend.com/blog/do-you-need-a-dedicated-ip - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need my own mail server? **NO**—please, no > Running Postfix in production means owning IP reputation, blocklists, TLS, key rotation, feedback loops, and 3 a.m. deliverability archaeology—to rebuild a commodity. Keep SMTP, drop the server. Self-hosting outbound email is one of those projects that looks like a weekend of Postfix configuration and turns out to be a permanent part-time job. The protocol is 40 years old and beautifully open; the *trust infrastructure* built on top of it is where your weekend goes to die. ## What you're actually signing up for - **A cold IP with no history.** Your fresh VPS address has zero reputation (or worse—check what the previous tenant did with it). You'll be [warming it](https://doineed.email/domain-warmup) from nothing, and low-volume senders can barely sustain a warm IP at all. - **The checklist that never ends.** Reverse DNS. TLS configuration. [SPF](https://doineed.email/spf), [DKIM](https://doineed.email/dkim) signing and key management, [DMARC](https://doineed.email/dmarc). Bounce processing. Feedback loop registration with each provider. Rate limiting and greylisting handling per destination. Blocklist monitoring, and the delisting rituals when you land on one anyway. - **Opaque failure modes.** When Gmail starts deferring your mail, there's no support ticket to file. You get a cryptic SMTP response and a long night of deliverability archaeology. Providers publish postmaster guidelines, not explanations. - **Zero economies of scale.** Sending platforms run high-reputation pools, monitor them constantly, and remove bad actors—work amortized across thousands of senders. Alone, you do all of it for an audience of you. ## The part worth keeping Here's the nuance: **SMTP the protocol is great.** It's the provider-agnostic standard that lets Laravel, Rails, Django, Supabase, or a 20-year-old ERP send mail without caring who's behind the socket. You can keep that portability—point your framework's SMTP settings at a provider (with Resend: `smtp.resend.com`, your API key as the password) and you've kept the interface while outsourcing the reputation management. ## The actual exceptions Hard data-locality or air-gap requirements, or you're literally building an email provider. Both are real; neither is asking this website. For everyone else, your product deserves the engineering hours more than your MTA does. --- - Canonical: https://doineed.email/my-own-mail-server - Learn more: https://resend.com/blog/why-smtp-still-matters-today - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need a no-reply address? **NO**—replies are a feature > noreply@ tells recipients and mailbox providers the same thing: this conversation only goes one way. Providers count replies as engagement, and Microsoft now requires sender addresses that actually work. `noreply@` is a UX decision wearing an infrastructure costume. It announces that you'd rather not hear from the people you're emailing—and both humans and mailbox providers price that in. ## Why this is a no - **Replies are engagement gold.** Mailbox providers use replies as one of the strongest "this mail is wanted" signals when deciding how to filter you. A no-reply address doesn't just discourage the signal—it structurally forbids it. - **It's becoming a compliance problem.** Microsoft's [bulk sender requirements](https://doineed.email/bulk-sender-requirements) demand From and Reply-To addresses that actually accept mail. An address that bounces replies fails that test by design. - **It erodes trust at the exact wrong moment.** The recipient confused by a charge, a login alert, or a broken link hits reply—the most natural act in email—and gets a bounce. Some shrug; the frustrated ones find the spam button, which costs you [far more](https://doineed.email/bounce-and-complaint-rates) than a support email would have. ## "But we can't monitor an inbox" You don't have to staff it like a call center—you have to not bounce it: - **Route replies somewhere cheap.** Pipe them into your support tool, or straight into a shared channel—Resend's inbound handling makes replies-to-Slack a one-time setup. - **Auto-acknowledge honestly.** "This inbox is lightly monitored; for help, go here" respects the sender and keeps the address valid. - **If you truly expect replies, say so.** "Just reply to this email" measurably outperforms buried contact links—if you promise it, honor it. ## While you're fixing the From line Two adjacent habits worth adopting: send from **your actual domain** with a recognizable name (a branded From address is part of how recipients and filters learn who you are), and **keep it consistent**—the From address is an identity signal, and identities that change constantly look like senders with something to rotate away from. `hello@`, `team@`, `support@`—anything that sounds like it might answer. Because it should. --- - Canonical: https://doineed.email/no-reply-address - Learn more: https://resend.com/docs/dashboard/emails/deliverability-insights - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need one-click unsubscribe? **YES**—if you send bulk > Send 5,000+ emails a day to Gmail or Yahoo and RFC 8058 one-click unsubscribe headers are mandatory, not optional. Below that, they're still the cheapest complaint-rate insurance available. One-click unsubscribe is not the link in your footer. It's a pair of headers (RFC 8058) that let the mail client itself offer an Unsubscribe button in its UI: ```txt List-Unsubscribe: <https://example.com/unsubscribe?id=abc123> List-Unsubscribe-Post: List-Unsubscribe=One-Click ``` When the recipient clicks the client's button, their provider sends a `POST` to your URL. You return a `200` or `202` and actually unsubscribe them—no landing page, no "are you sure", no login wall. ## Why this is a yes - **It's required for bulk senders.** Since February 2024, Gmail and Yahoo require one-click unsubscribe on bulk mail—their threshold is around 5,000 messages a day—alongside DMARC and a spam complaint rate below **0.3%**. [Microsoft followed with equivalent requirements in 2025](https://resend.com/blog/microsoft-bulk-sending-requirements-2025). Non-compliance means filtering, not a warning letter. - **It protects the metric that matters.** The client-level button catches the frustrated recipient *before* they reach for the spam button. Every complaint avoided is reputation preserved—you want complaints far under the 0.3% ceiling (under 0.08% is the healthy zone). - **It's nearly free.** Good sending platforms set these headers automatically for broadcast mail (Resend does on Broadcasts). If you're rolling your own: add the headers, handle the `POST`, done. ## The gotchas - **Both headers, exactly.** `List-Unsubscribe` alone gives you the older mailto/link behavior; the `List-Unsubscribe-Post` header is what makes it one-click. - **Handle POST without ceremony.** The one-click endpoint must unsubscribe on the `POST` itself. Save the preference-center tour for people who click the link in your footer. - **Process it fast.** Providers allow a couple of days to honor the request; treating it as instant is both easier and better for trust. - **Keep the footer link too.** Headers are for clients that support them; the [visible link](https://doineed.email/unsubscribe-link) is for humans and the law. --- - Canonical: https://doineed.email/one-click-unsubscribe - Learn more: https://resend.com/blog/gmail-and-yahoo-bulk-sending-requirements-for-2024 - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need open tracking? **IT DEPENDS**—not for transactional > The pixel lies: privacy proxies fire false opens, image blocking hides real ones, and inbox providers read trackers as a promotional smell. Fine for marketing trends, off for transactional. Open tracking works by embedding a transparent 1×1 pixel image with a unique reference in each email. When the image downloads, an "open" is recorded. That mechanism is the whole problem. ## Why the numbers lie - **False positives.** Some inboxes fetch every image before delivery—malware scanning, and privacy features like Apple's Mail Privacy Protection—firing "opens" no human performed. - **False negatives.** Other inboxes block images by default, or sit behind corporate firewalls that cache them. Real readers, zero opens recorded. Gmail also clips messages over 102KB, and a clipped message doesn't count as opened unless the recipient expands it. - **Structural blind spots.** A plain-text email can't be tracked at all—no HTML, no pixel. Add it up and open rate is not a statistically honest measure of engagement. It can sketch a *trend* on a large marketing list; as an absolute number, it's fiction. ## The part that should decide it for you Tracking pixels are the tooling of marketers—and of spammers. Inbox providers know this, and treat the presence of trackers as a signal that mail is promotional, which influences where it gets filed. That's why the recommendation for **transactional email is to turn open tracking off entirely**: a password reset gains nothing from a pixel and shouldn't smell like a campaign. ## What to use instead - **Click tracking.** A click is a real, deliberate act—if they clicked, they read. It's a far more truthful engagement signal (route it through a [custom tracking domain](https://doineed.email/custom-tracking-domain)). - **Outcomes outside the inbox.** Emails exist to cause something: signups, visits, conversions. Measure the something. ## The verdict logic Running a large marketing program and want directional trend lines? Fine—keep open tracking on and read it as weather, not measurement. Sending transactional mail, or making decisions off open rates? Turn it off and count clicks and conversions instead. --- - Canonical: https://doineed.email/open-tracking - Learn more: https://resend.com/docs/knowledge-base/why-are-my-open-rates-not-accurate - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need a physical address in my footer? **IT DEPENDS**—probably yes > For marketing email to US recipients, CAN-SPAM requires a valid physical postal address—and other jurisdictions have their own versions. Purely transactional mail is generally exempt. First, the disclaimer this page owes you: this is deliverability practitioners reading regulations out loud, not legal advice. Where you're incorporated, where your recipients live, and what your mail contains all change the answer—when money rides on it, ask a lawyer. ## Why the answer leans yes - **CAN-SPAM (US).** Commercial email to US recipients must include your valid physical postal address. The FTC's guidance allows a street address, a registered PO Box, or a private mailbox from a commercial agency—so "I work from home" has workable answers that aren't your living room. Violations are priced per email, which concentrates the mind. - **CASL (Canada) and friends.** Canada's regime requires sender identification including a mailing address in commercial electronic messages; plenty of other jurisdictions have identification requirements in the same spirit. If your list is international—and every list is—the union of applicable rules looks a lot like "just include it". - **It reads as legitimacy.** Beyond compliance, an identifiable sender with a real-world address is one more signal separating you from the spam cohort, for recipients and for the humans who review mail streams when things get escalated. ## Where the "it depends" lives - **Transactional email is generally exempt.** Receipts, password resets, shipping notices—mail whose primary purpose is the transaction—doesn't carry CAN-SPAM's commercial-email requirements. Mixed-content mail gets judged by its primary purpose, which is exactly the kind of edge a lawyer earns their fee on. - **Jurisdiction math.** A pure-transactional sender with no promotional program has a plausible "no". The moment a newsletter or promotion exists, the safe default is the address in the footer, right next to the [unsubscribe link](https://doineed.email/unsubscribe-link) the same laws care about. ## The practical move Put the address in your marketing footer template once and stop thinking about it. It costs a line of text, it's required more often than not, and no one has ever damaged their deliverability by being easy to identify. --- - Canonical: https://doineed.email/physical-address - Learn more: https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need a plain-text version? **IDEALLY**—cheap insurance > HTML-only mail usually lands fine—but the multipart text version costs nothing and quietly serves watches, screen readers, strict clients, and cautious filters. Cheapest robustness win in email. Email supports sending two renderings of the same message in one envelope—`multipart/alternative`, with a `text/plain` part alongside the `text/html` part. The client picks what it can display best. The question is whether the plain half is worth bothering with. ## The honest stakes Skipping it will not, by itself, send you to spam—plenty of large senders ship HTML-only mail and deliver fine. That's exactly why the verdict is *ideally* rather than a hard yes: the text part costs approximately nothing (most frameworks and platforms generate it from your HTML automatically) and buys you a stack of small, real wins. ## What the text part quietly handles - **Constrained clients.** Watches, notification previews, terminal mail readers, and some corporate gateways lean on the text part—it's often what generates the preview snippet you see before opening. - **Accessibility.** Screen readers handle a clean text alternative more predictably than whatever your HTML template's table-soup renders down to. - **Recipient settings.** Some people and some security-conscious organizations read mail with HTML disabled. HTML-only mail shows them nothing—or a wall of raw markup. - **Filter completeness.** A well-formed multipart message is one more small signal of a legitimate sender. Historically, HTML-only correlated with spam; the correlation is weaker now, but completeness never hurts. ## The gotchas - **Don't ship a garbage text part.** An empty part, or one containing only "View this email in your browser," is worse than useful—and a text part that *wildly* diverges from the HTML content looks deceptive to filters. - **Check what your tooling generates.** Auto-generated text from HTML is usually fine, but templates heavy on images and buttons can reduce to gibberish. Read it once. - **Links belong in both parts.** The text version should carry the same essential URLs—including the unsubscribe link. Two minutes of setup, one read-through of the output, and you've covered every inbox from a terminal to a wristwatch. That's the trade. --- - Canonical: https://doineed.email/plain-text-version - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need a preference center? **IDEALLY**—topics beat goodbyes > A lone unsubscribe link is all-or-nothing: one unwanted promo and you lose the reader entirely—or worse, they hit the spam button. Topic-level preferences turn goodbyes into downgrades. With only a global [unsubscribe link](https://doineed.email/unsubscribe-link), your recipients have exactly two settings: everything, or nothing. Someone who loves your changelog but got one promo too many has no way to say "less of *that*"—so they say goodbye to all of it. Or they skip the ceremony and press the spam button, which costs you far more than the subscriber. ## What a preference center changes Topic-level preferences let recipients decline a *kind* of email while keeping the rest. Think of each topic as a contract: "product updates", "newsletter", "promotions"—opt out of one, keep the others. Two things happen: - **You retain engaged subscribers** who would otherwise have left entirely over one content type. - **You collect signal.** Every topic opt-out is a recipient telling you precisely what they don't want—far more useful than a silent unsubscribe and infinitely more useful than a complaint. The deliverability angle is the same engine as always: mailbox providers rank you by engagement. Blasting every content type to everyone produces ignored mail and complaints; sending each stream only to the people who want it produces the open-and-click pattern that providers reward. ## Doing it well - **Keep it to 3–5 topics** with names a stranger understands ("Newsletter", "Product updates"—not "Category A"). A wall of checkboxes is its own unsubscribe incentive. - **Label every send with its topic.** An unlabeled campaign can only be unsubscribed from globally, which defeats the system. (Resend Topics enforce this shape: label a Broadcast and opted-out recipients are excluded automatically, and the unsubscribe page shows the choices.) - **Keep the one-click exit too.** A preference center complements [one-click unsubscribe](https://doineed.email/one-click-unsubscribe); it never replaces it. A preference page with no "unsubscribe from everything" option is a dark pattern. ## The verdict logic If you send one kind of email—a monthly newsletter and nothing else—a plain subscribe/unsubscribe is honest and sufficient; a preference center adds furniture to a one-room house. That's the *ideally*. The moment you're sending two or three distinct streams to the same audience, topics are how you stop making people choose between all and nothing. --- - Canonical: https://doineed.email/preference-center - Learn more: https://resend.com/docs/knowledge-base/why-use-topics - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need a subdomain for sending? **YES** > Send from notifications.acme.com, not acme.com. Subdomains isolate reputation damage and tell inbox providers what each mail stream is for—while your root domain stays clean. Send email from a subdomain (`notifications.acme.com`, `news.acme.com`) rather than your root domain (`acme.com`). It costs a few extra DNS records and buys you two things you'll be very glad to have on a bad day. ## Reputation isolation Things happen. Someone floods your signup form and you fire tens of thousands of verification emails at burner addresses. A campaign gets marked as spam at scale. When that damage lands on a subdomain, you can quarantine it—pause the stream, fix the problem, even retire the subdomain—while the rest of your email keeps flowing. When it lands on your root domain, everything you send wears the damage, and root-domain reputation is a long road back. ## Purpose transparency Not all mail deserves the same inbox treatment, and providers know it. A password reset is urgent; a monthly product digest is not. Gmail and Outlook constantly triage incoming mail into priority, promotions, and spam—and consistent, purpose-specific subdomains give them a clean signal for what each stream is. That predictability builds trust. A sensible split: - `send.acme.com`—transactional (resets, receipts, confirmations) - `news.acme.com`—marketing and newsletters ## One hard rule: no lookalike domains Whatever you do, don't "protect" your root domain by buying `getacme-mail.com` or `acme-alerts.com`. Brand-adjacent lookalikes are the shape of phishing: spam filters treat them with suspicion, and your recipients—trained for years to distrust almost-your-brand domains—will ignore or report them. Subdomains of the real domain give you the same isolation with none of the suspicion, and they inherit your brand's recognition instead of diluting it. ## The honest caveat If you're sending a trickle of transactional mail and nothing else, root-domain sending won't sink you. But domains are habits: set up the subdomain on day one and you'll never have to migrate reputation later. It's the cheapest insurance in your DNS zone. --- - Canonical: https://doineed.email/sending-subdomain - Learn more: https://resend.com/docs/knowledge-base/is-it-better-to-send-emails-from-a-subdomain-or-the-root-domain - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need to protect my signup forms? **YES** > An unprotected signup form is an open API for polluting your own list—bots stuff it with garbage, and list-bombers weaponize it against victims. CAPTCHA, honeypots, and rate limits are cheap armor. Your signup form is where list quality is decided, and it's reachable by every bot on the internet. Unprotected, it fails you in two distinct ways—one dirty, one nasty. ## The dirty failure: garbage in Bots submit forms constantly—credential-stuffing probes, scraper noise, junk automation. Every fake signup that lands in your list is a future bounce (invalid address), a mute subscriber dragging your engagement ratios, or occasionally a spam trap. You then pay to [verify](https://doineed.email/email-verification) and [sunset](https://doineed.email/sunset-policy) contacts that a form check would have rejected for free. ## The nasty failure: list bombing Attackers also use *other people's* signup forms as a weapon: scripting thousands of subscriptions for one victim's address across many sites, burying their inbox in confirmation emails. If your form participates, you're the abuse vector—your domain sends the flood, your [complaint rate](https://doineed.email/bounce-and-complaint-rates) eats the fallout, and your welcome emails start looking like an attack to mailbox providers. Providers have suspended senders over exactly this. ## The armor, in layers - **CAPTCHA** on submission—reCAPTCHA, hCaptcha, or Friendly Captcha if you want the no-interaction kind. This is the workhorse against bulk automation. - **A honeypot field**—an input hidden from humans via CSS; anything that fills it is a bot. Zero friction, catches the lazy majority. - **Rate limiting** by IP and by email address—no legitimate user subscribes 400 times a minute. - **[Double opt-in](https://doineed.email/double-opt-in)** as the final gate: unconfirmed signups never reach your sending list, which caps the damage of anything that slips through—and turns a list-bombing attempt into unconfirmed noise instead of sent mail. None of these are exotic; most form libraries and signup services have them a checkbox away. ## The verdict logic No qualifier on this one. The cost is an afternoon; the alternative is discovering the problem through a bounce spike, a complaint cluster, or an abuse report. Forms are infrastructure—treat them with the same suspicion you'd give any other unauthenticated endpoint that writes to production data. Because that's what they are. --- - Canonical: https://doineed.email/signup-form-protection - Learn more: https://resend.com/docs/knowledge-base/audience-hygiene - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need to trust spam-score checkers? **NO**—mostly > A 10/10 on mail-tester doesn't mean the inbox—score checkers and seed tests can't see the thing that actually decides placement: your reputation and how your recipients engage. Paste your email into a checker, get a score out of ten, chase the score to perfection, still land in spam. The tools aren't lying to you, exactly—they're answering a much smaller question than the one you're asking. ## What a score checker can actually see Static, per-message facts: whether SPF/DKIM/DMARC validate, whether your HTML parses, whether your domain or links sit on a public blocklist, whether a legacy content filter dislikes your words. Seed tests go one step further—sending to a panel of test inboxes and reporting where the message landed *for those inboxes*. ## What it cannot see - **Your reputation.** [Domain reputation](https://doineed.email/domain-reputation) is the dominant input to real filtering decisions, and it's invisible to a tool that just receives one message. A pristine email from a burned domain goes to spam; a mediocre one from a trusted domain doesn't. - **Your recipients.** Modern filtering is personalized—Gmail weighs whether *this* recipient engages with you. A seed inbox that has never opened your mail is not a stand-in for a subscriber who reads you weekly. - **Your patterns.** Volume history, consistency, complaint trajectory—the longitudinal signals providers actually grade—don't exist for a single test message. That's why the score converges on false confidence: the checkable things are the table stakes, and the unmeasurable things are the game. ## What they're still good for A pre-send smoke test. A checker will instantly catch a broken DKIM record, a missing unsubscribe header, a blocklisted link domain, HTML that renders as soup—mechanical failures worth catching before 50,000 sends. Use it like a linter: failures are real, a perfect score is not a promise. ## Where to look instead Real placement data comes from real mail: [bounce and complaint rates](https://doineed.email/bounce-and-complaint-rates) from your ESP, and [Gmail Postmaster Tools](https://doineed.email/gmail-postmaster-tools) for reputation as Gmail computes it. If those are healthy and a checker still tuts at you, believe your metrics. --- - Canonical: https://doineed.email/spam-checkers - Learn more: https://resend.com/blog/why-your-emails-are-going-to-spam - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need to avoid "spam trigger words"? **NO**—mostly a myth > No secret list of forbidden words decides your fate. Modern filters weigh reputation, authentication, and engagement—"FREE!!!" in a subject line is a style crime, not a spam sentence. Somewhere out there is a blog post with "473 spam trigger words to avoid in 2026," and it is wasting everyone's time. The idea dates to the early 2000s, when naive keyword and Bayesian filters really did score messages word by word. Filtering has moved on; the listicles haven't. ## What filters actually weigh Modern spam filtering is dominated by *who is sending*, not *which words they used*: - **Sender reputation**—complaint rates (stay under 0.08%; 0.3% is where Gmail and Yahoo consider you unacceptable), bounce rates (under 4%), and the consistency of your sending patterns. - **Authentication**—SPF, DKIM, and DMARC in order and aligned. Missing records hurt you more than any adjective ever will. - **Engagement**—do recipients open, read, reply, and keep your mail? Or delete unread and hit "report spam"? A trusted sender can put "free" in every sentence and land in the inbox. An untrusted sender gets filtered writing like a tax attorney. The words were never the variable. ## Where content still matters Deleting words from a list is cargo cult; these content signals are real: - **Misleading subject lines.** A subject that doesn't match the body erodes trust with recipients *and* filters—and deceptive subjects are a straight-up CAN-SPAM violation. - **Link hygiene.** URLs and redirects should align with your sending domain. Mismatched links, sketchy shorteners, or a domain that's landed on a blocklist like Spamhaus will hurt you regardless of prose. - **Overall coherence.** All-images-no-text, invisible text, deliberate misspellings to dodge imagined filters—these are spammer fingerprints. Writing normally is the optimization. ## Folklore, rated The recurring specimens, judged individually: - **"Never use all caps."** No. A SHOUTY subject line is a taste problem, not a filter trigger. - **"Avoid exclamation marks!!"** No. Same category—style, not spam. - **"Emojis get you filtered."** No. Half the inbox has emojis in it; send them to people who want your mail and nobody cares. - **"Never write the word free."** No. Trusted senders write "free" all day. Untrusted senders get filtered writing anything. - **"Avoid links."** No. Email exists to be clicked. What matters is where links point—aligned, reputable domains—not how many there are. - **"Avoid URL shorteners."** Actually yes—the one true entry on the list. Shorteners hide destinations, which filters treat with suspicion; Gmail has even flagged shortened YouTube links (`youtu.be`) as phishing-adjacent. Use full URLs on domains you control. ## The honest test If your mail is going to spam, the answer is in your [authentication](https://doineed.email/spf), your list quality, and your engagement—start with [why emails go to spam](https://resend.com/blog/why-your-emails-are-going-to-spam), not a thesaurus. Write like a human with something worth saying, to people who asked to hear it. That's the whole trick. --- - Canonical: https://doineed.email/spam-trigger-words - Learn more: https://resend.com/blog/why-your-emails-are-going-to-spam - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need SPF? **YES** > SPF is table stakes. It's a single DNS record telling mailbox providers which servers may send for your domain—and every major provider expects to find it. SPF (Sender Policy Framework) is a DNS TXT record that declares which servers are allowed to send email for your domain. When a mailbox provider receives your message, it looks at the Return-Path domain and checks that the sending server is on your list. Not on the list? Your email starts the conversation as a suspect. ## Why this one isn't a debate - **It's the first triage.** SPF is among the earliest checks an inbox runs—failing it means fighting uphill before anyone even looks at your content. - **The big providers require it.** Google, Yahoo, and Microsoft's bulk sender requirements demand SPF and DKIM authentication outright. Even for low-volume senders, missing SPF is a red flag. - **DMARC depends on it.** DMARC passes when SPF *or* DKIM passes and aligns. You want both in place so a single failure—like a forwarder breaking SPF—doesn't sink the message. - **It costs one TXT record.** There is no cheaper deliverability win. ## What it looks like ```txt v=spf1 include:_spf.google.com include:amazonses.com ~all ``` - `v=spf1`—the SPF version - `include:…`—origins allowed to send for your domain (your ESP, your workspace provider) - `~all`—what receivers should do with everything else (softfail) ## The gotchas - **One record per domain.** Two SPF records is a permanent error, not "double coverage". Merge the `include:` entries into one record. - **Ten DNS lookups, max.** Every `include:` costs lookups; blow past ten and SPF fails. Audit before adding another tool to the record. - **Subdomains aren't covered.** A policy on `domain.com` does not apply to `mail.domain.com`. Each sending subdomain needs its own record. - **SPF alone isn't authentication.** It checks the Return-Path, not the From address the human sees, and it breaks on forwarding. Pair it with DKIM and DMARC. If you send through an ESP like Resend, SPF for your sending domain is usually configured as part of domain setup—verify it's in place rather than assuming. --- - Canonical: https://doineed.email/spf - Learn more: https://resend.com/blog/email-authentication-a-developers-guide - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need a sunset policy? **YES**—six quiet months > Recipients who stopped engaging drag down the metrics providers grade you on—and eventually decay into bounces and complaints. Re-engage them once, then let them go. A sunset policy is the rule for when you stop mailing people who stopped reading. It feels like shrinking your asset; it's actually maintenance on it. ## Why quiet subscribers cost you Mailbox providers grade you on engagement ratios, not raw reach. Every send to someone who ignores you dilutes your open and click rates, and providers read sustained low engagement as "this sender's mail isn't wanted"—then file you accordingly *for everyone*, including the people who love you. It gets worse with time: abandoned mailboxes decay into bounces, some are reclaimed as spam traps, and a recipient who forgot subscribing is a spam complaint waiting for a bad morning. The unengaged tail isn't neutral; it's a slow leak in your [domain reputation](https://doineed.email/domain-reputation). ## The policy that works 1. **Pick the line.** The generally accepted standard: recipients with no open or click in the past **six months** leave your regular marketing sends. Adjust for your cadence—a daily sender can sunset sooner; a quarterly one, later. 2. **Try one honest re-engagement.** A short "still want these?" campaign—ideally with [topic-level choices](https://doineed.email/preference-center) so "less" is an option, not just "none". Whoever clicks stays. 3. **Let the rest go.** No response means the answer was no. Remove them from marketing sends (transactional mail they trigger is fine). Sending to someone who hasn't engaged in a year isn't persistence, it's noise with a complaint risk attached. Automate the boring parts: engagement-filtered segments make the policy self-executing, and bounce/complaint webhooks plus your [suppression list](https://doineed.email/suppression-list) handle the involuntary exits. ## The mindset shift List size is a vanity metric; *engaged* list size is the operational one. A 10,000-person list where 9,000 read you outperforms a 100,000-person list where the same 9,000 read you—same revenue, radically better reputation. Sunsetting isn't losing subscribers you had; it's admitting you'd already lost them, before the mailbox providers bill you for the pretense. --- - Canonical: https://doineed.email/sunset-policy - Learn more: https://resend.com/docs/knowledge-base/audience-hygiene - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need a suppression list? **YES**—your ESP runs one > A suppression list is the memory that stops you from re-mailing addresses that bounced or complained—the two fastest ways to burn a domain. Good ESPs run one natively; your job is to respect it. When a mailbox provider hard-bounces an address, or a recipient marks your mail as spam, sending to that address again doesn't just fail—it actively damages your [domain reputation](https://doineed.email/domain-reputation). A suppression list is the system that remembers so your send logic doesn't have to. ## How it works Addresses land on the list from three origins: **bounce** (the receiving server permanently rejected the mail), **complaint** (the recipient hit the spam button), and **manual** (you added it yourself—an angry customer, a legal request, a known trap). From then on, sends to that address are skipped automatically. On Resend the list is native, team-wide across all your domains and subdomains, visible in the dashboard, and manageable via API—including bulk import if you're migrating from another provider. ## The rules of engagement - **Never mail around it.** Exporting your list to another tool to reach suppressed addresses is how senders convert one bounce into a reputation incident. The suppression is protecting you, not inconveniencing you. - **Be very slow to un-suppress.** Removing an address without fixing the reason it was suppressed just replays the damage—it will bounce or complain again, get re-suppressed, and cost you twice. - **Mine it for signal.** A bounce spike traces to a stale segment or a broken [signup form](https://doineed.email/signup-form-protection); a complaint cluster traces to a campaign that outran consent. Wire up `email.bounced` and `email.complained` webhooks and the list becomes telemetry, not just a blocklist. - **Mind the Gmail gap.** Gmail doesn't report individual complaints back to senders, so complaint-origin suppressions undercount your Gmail audience—[Postmaster Tools](https://doineed.email/gmail-postmaster-tools) covers that blind spot. ## The verdict logic If your ESP is any good, you need a suppression list in the sense that you need brakes: it's already installed, and the failure mode is overriding it. If you're building sending infrastructure yourself, this is one of the systems you now owe the world—[which is its own answer](https://doineed.email/my-own-mail-server). --- - Canonical: https://doineed.email/suppression-list - Learn more: https://resend.com/docs/dashboard/emails/email-suppressions - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need to throttle my sending? **IT DEPENDS**—mostly handled for you > Blasting a day's volume in one burst is a classic self-inflicted wound— providers read spikes as spam behavior. But pacing is mostly your ESP's job; your job is the schedule. Mailbox providers don't just count how much you send—they watch *how* it arrives. A steady stream reads as a business emailing its customers; the same volume as a five-minute burst reads as an incident. Providers respond with greylisting, deferrals (`4xx` "try again later"), and stricter scoring, all before a human notices anything. ## Why you mostly don't need to build this Pacing outbound mail—per-provider connection limits, retry-on-deferral, backoff—is core ESP infrastructure. A good platform smooths delivery and honors receiver throttling automatically; that's part of what the [shared-pool deal](https://doineed.email/ip-reputation) buys you. If you're hand-rolling rate limiters in application code to protect your inbox placement on a managed ESP, you're probably re-solving a solved problem. ## When throttling becomes your problem - **Warmup.** A [new domain or changed setup](https://doineed.email/domain-warmup) has explicit hourly ceilings—on the order of dozens-to-hundreds per hour in week one, not thousands—and honoring them is your scheduling decision, not your ESP's. - **Volume cliffs.** A product launch that 10×es your daily send is a spike no matter who paces the SMTP connections. Spread the send across hours (or days), starting with your most engaged segment—their opens buy goodwill for the rest of the batch. - **One-provider concentration.** A list that's 80% one mailbox provider hits that provider's limits sooner. If a big send keeps deferring at a single provider, that's the signal to stretch the schedule. - **Your own infrastructure.** Running [your own mail server](https://doineed.email/my-own-mail-server) means every per-provider pacing rule is now yours to discover empirically. Enjoy. ## The verdict logic The lean says no because the mechanical half—connection pacing, deferral handling—arrives built into any serious sending platform. The residual yes is scheduling judgment: ramp new things gradually, spread big sends, and treat a wall of deferrals as the provider telling you to slow down. Consistency is the actual asset; throttling is just one way to buy it. --- - Canonical: https://doineed.email/throttling - Learn more: https://resend.com/docs/knowledge-base/warming-up - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need to buy an email list? **NO**—never > Bought lists are consent-free by definition—spam traps, stale addresses, and people who've never heard of you. There is no faster way to torch a domain reputation. Most verdicts on this site come with nuance. This one doesn't. ## Why this is a no, always **Consent doesn't transfer.** Valid permission means the recipient clearly and knowingly agreed to receive *your* mail—freely given, specific, informed. A list assembled by someone else fails every part of that definition. If a pre-checked box or a terms-of-service clause doesn't count as consent (and it doesn't), an address purchased from a broker counts even less. **The mechanics destroy you quickly.** Purchased lists are a package of everything inbox providers punish: - **Stale addresses**—bounce rates spike, and past a few percent, providers read you as a spammer. (Above 4% is the classic danger line.) - **Spam traps**—addresses that exist solely to catch senders who mail without permission. Hitting them can land your domain on blocklists like Spamhaus. - **Recipients who never asked**—which means complaint rates far above the 0.3% ceiling Gmail and Yahoo enforce, from people encountering your brand for the first time as an intruder in their inbox. **Your ESP will act before the providers do.** Sending to purchased lists violates essentially every email platform's acceptable use policy. High bounces and complaints from a bought list get accounts paused or terminated—the platform is protecting its shared infrastructure from you. And the damage lands on your *domain*, which follows you to any provider you flee to afterward. ## What to do instead Grow the boring way, which is also the only way that works: consent at the point of signup ([an unchecked, specific checkbox](https://resend.com/blog/how-to-properly-get-email-consent)), [double opt-in](https://doineed.email/double-opt-in) to prove it, content worth subscribing to. A thousand people who asked for your email outperform a hundred thousand who didn't—in revenue, not just in deliverability metrics. If a vendor promises "verified, opted-in leads," ask: opted in to *whom*? Not to you. That's the entire problem. --- - Canonical: https://doineed.email/to-buy-an-email-list - Learn more: https://resend.com/blog/how-to-properly-get-email-consent - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need an unsubscribe link? **YES**—for anything promotional > Marketing and nurture email must carry a visible way out—law and inbox providers agree. Transactional mail is exempt, but hiding the exit is how you earn spam complaints. If the email exists to nurture, promote, announce, or sell—it needs an unsubscribe link. Visible, working, and honored promptly. This isn't just etiquette: regulations like CAN-SPAM and GDPR are built around recipients being able to withdraw consent as easily as they gave it. ## The deliverability math Here's the part that matters even if you don't care about the law: **a recipient who can't find the unsubscribe link uses the spam button instead.** The unsubscribe costs you one subscriber who'd already checked out. The spam complaint counts against your sender reputation with every mailbox provider—and past a fraction of a percent, it starts costing you inbox placement for everyone else on your list. An easy exit is cheap. A hidden one is expensive. That's why "make it hard to leave" is the single most counterproductive move in email marketing. Retention by obstruction shows up in your metrics as complaints. ## What's exempt Transactional email—password resets, receipts, order confirmations, security alerts—serves a functional purpose the recipient triggered, and is generally exempt. Nobody should be able to unsubscribe from their own password reset. The gray zone is relationship content: product updates, onboarding tips, "here's what's new". If it's more about nurturing the relationship than completing an action, best practice is to include the link. When in doubt, add it—an unsubscribe link in a borderline email has never hurt anyone. ## Do it properly - Make it findable—footer is fine, invisible 4px gray-on-gray is not. - Honor it promptly and permanently. "Up to 10 business days" is a legal ceiling, not a goal. - If you send bulk, the link in the body isn't enough—you also need [one-click unsubscribe headers](https://doineed.email/one-click-unsubscribe). - Let people leave one stream without leaving all of them (topics/preferences), and the unsubscribe becomes a downgrade instead of a goodbye. --- - Canonical: https://doineed.email/unsubscribe-link - Learn more: https://resend.com/docs/knowledge-base/should-i-add-an-unsubscribe-link - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team. --- # Do I need a warmup service? **NO** > Warmup is real; warmup services aren't. Synthetic opens and scripted replies are detectable, meaningless to inbox providers, and can actively damage the reputation they claim to build. Warming up a domain—gradually establishing trust with inbox providers—is a real and important practice. Warmup *services* take that true premise and sell a shortcut: a network of inboxes they control that opens, replies to, and rescues-from-spam your messages, generating "engagement" they can guarantee because they're on both ends of it. ## Why this is a no - **The signals are synthetic, and providers know it.** Gmail and Outlook evaluate engagement patterns at scale. A closed loop of artificially connected inboxes with unnaturally consistent reply behavior is exactly the kind of footprint their systems are built to spot. Real engagement looks varied and unpredictable; scripted engagement doesn't. - **The cliff is a negative signal.** Reputation is longitudinal. When the automation stops and "engagement" collapses overnight, that decline tells providers the interest was never real—and filtering tightens. - **The pools can contain spam traps.** Automated inbox networks accumulate accounts that providers have reclaimed. Sending into those is indistinguishable from mailing spam traps, one of the fastest ways to burn a domain. Warmup services don't build reputation. They temporarily mask the absence of real engagement, and often leave you worse off than before. ## What warmup actually is Trust is earned through consistent behavior and engagement from real recipients. Providers watch volume patterns, complaint rates, unsubscribes, and how actual users interact with your mail. Which means the warmup that works is unglamorous: - authenticate properly (SPF, DKIM, DMARC), - ramp volume gradually and consistently—[there's a schedule for that](https://doineed.email/domain-warmup), - send to people who opted in and expect you, - lead with mail people reliably open: confirmations, welcomes, receipts. Your domain warms itself when your audience wants the message. If your list is real, you don't need anyone to fake enthusiasm for it—and if it isn't, no service can fake it convincingly for long. --- - Canonical: https://doineed.email/warmup-service - Learn more: https://resend.com/blog/do-you-need-a-warmup-service - All questions: https://doineed.email/llms.txt An opinionated answer from the [Resend](https://resend.com) team.