Email Feedback Loop: Definition, Complaint Data, and Deliverability

An email feedback loop is a system through which a mailbox provider tells a verified sender when a recipient marks one of its messages as spam or junk. The sender uses that complaint signal to stop mailing that recipient, investigate the campaign, and reduce future deliverability damage.

What is an email feedback loop?

An email feedback loop, often shortened to FBL, is a complaint-reporting mechanism between a mailbox provider and an email sender. When a recipient selects a provider’s “Report spam” or “Junk” control, the provider may send data about that event back to the sender or make aggregated complaint data available through a postmaster reporting tool.

The important word is feedback. A feedback loop is not a bounce, a delivery receipt, or an open-event signal. It is a negative recipient action: someone received a message and indicated that they did not want it in their inbox.

Traditional complaint feedback loops commonly send an individual report for a specific complaint. Those reports are often delivered in Abuse Reporting Format (ARF), a machine-readable email-report format defined by RFC 5965. Other feedback systems provide aggregate reporting instead, meaning a sender sees that a campaign or message category generated complaints without necessarily receiving the individual recipient’s address.

The practical purpose is the same in either case: identify unwanted mail early, remove or suppress the affected recipient where possible, and change the sending practice that led people to complain.

A feedback loop generally involves four parties:

1. The recipient, who marks a message as spam or junk.
2. The mailbox provider, which records that recipient feedback and decides whether to expose it to the sender.
3. The sender or sending platform, which receives or views the feedback.
4. The list owner or campaign operator, which must act on the signal by suppressing the address and improving the program.

For an email program, a complaint is more than an isolated preference. Mailbox providers use recipient behavior as one input into filtering and reputation decisions. A sender that repeatedly generates complaints can see more messages routed to spam, deferred, or rejected. That makes an email feedback loop a core deliverability control rather than a nice-to-have reporting feature.

Why email feedback loops matter for deliverability

An email feedback loop matters because mailbox providers are trying to distinguish expected mail from unwanted mail. Authentication proves important facts about who is sending a message, but it does not prove that recipients welcome the message. Complaint behavior fills in that gap.

A message can pass SPF, DKIM, and DMARC and still cause harm if it reaches people who never asked for it, who no longer recognize the brand, or who receive it too frequently. In that situation, a complaint is direct evidence that the sender’s permission, relevance, or frequency strategy has failed for at least one recipient.

Complaints affect more than one message

When a person complains, the immediate outcome is typically that the provider moves or labels that message as spam. The broader outcome can affect future campaigns. Mailbox providers can evaluate complaint patterns by sending domain, IP address, stream, campaign type, recipient engagement, and other internal signals.

That means the cost of a high complaint rate is rarely limited to the exact campaign that triggered it. A weak promotional blast can make the next legitimate newsletter less likely to land in the inbox. If marketing and transactional mail share the same sending identity or reputation pool, a poorly targeted campaign may also put important receipts, password resets, and account notifications at risk.

Feedback loops reveal a problem ordinary metrics can hide

Open rate, click rate, and conversion rate are useful campaign metrics, but they describe only a portion of audience behavior. They are also increasingly imperfect measures because privacy features and image blocking can distort open data.

Complaint data answers a different question: How strongly did recipients reject this mail? A campaign can generate healthy revenue from a small active segment while creating unacceptable complaints among a larger, less engaged segment. Looking only at opens and clicks can conceal that tradeoff.

Consider a reactivation campaign sent to 100,000 dormant subscribers. If 2,000 people click and 80 purchase, a dashboard focused on engagement may call the campaign successful. But if 400 people mark it as spam, the 0.4% complaint rate is a deliverability warning. The campaign may have created short-term revenue while damaging the sender’s ability to reach the remaining audience.

Complaint controls are now an operational requirement

Major mailbox providers publish sender guidance that emphasizes low spam complaint rates, authentication, and easy unsubscribe methods. Gmail’s sender guidance says senders should keep spam rates shown in Postmaster Tools below 0.3%. Yahoo’s sender best-practice guidance also states a 0.3% spam-rate threshold and recommends enrolling in its Complaint Feedback Loop so senders can process complaints quickly.

The exact methods, data availability, and calculation approaches vary by provider. The durable lesson does not: a sender needs a reliable way to see complaint signals and a process that treats those signals as suppression events, not as optional analytics.

How an email feedback loop works

The mechanics differ by mailbox provider, but a common individual-report workflow looks like this:

1. A sender delivers a message to a recipient.
2. The recipient clicks a spam or junk-reporting control in the mailbox interface.
3. The mailbox provider records the complaint and applies its own filtering or mailbox action.
4. If the sender is eligible for the provider’s feedback loop, the provider generates an abuse report.
5. The report reaches an address designated during enrollment or another approved reporting destination.
6. The sender’s system parses the report, identifies the recipient and message stream, and writes a permanent suppression record.
7. The deliverability or lifecycle team analyzes the campaign, audience, and trigger that produced the complaint.

The sender should automate steps 5 and 6. A complaint that sits in a shared inbox for three days is not an effective feedback loop. The recipient may receive more unwanted mail during that delay, and a manual process will eventually fail as volume grows.

Individual complaints and aggregate feedback are different

Not every feedback loop gives the sender a recipient-level report.

Individual complaint reports can contain enough information to identify the complained-about message and, depending on the program and report, the recipient. This is the model most people mean when they say “FBL report.” It enables direct suppression of the complaining address.

Aggregate feedback summarizes complaints by campaign, identifier, or other grouping. It is still valuable because it helps locate problematic traffic, but it may not provide an address that can be suppressed. The sender must use the data to correct targeting, content, frequency, or list acquisition practices at the segment level.

Gmail’s Feedback Loop is an example of an aggregate-oriented tool for large-volume senders. It uses a Feedback-ID header to associate complaint behavior with sender-defined campaign identifiers, and the resulting data appears in the Gmail Postmaster Tools Feedback Loop dashboard. Gmail’s documentation specifies that the header can contain up to three optional identifiers plus a mandatory sender identifier.

A representative structure is:

Feedback-ID: campaign:customer:mailtype:SenderId

This is not an unsubscribe mechanism and does not replace a standard List-Unsubscribe header. It is a classification aid that helps a sender see which campaigns or traffic categories generate unusual complaint behavior. Gmail advises against using an identifier unique to every message, such as a unique Message-ID, because that would prevent useful aggregation.

Authentication connects the complaint to the real sender

Mailbox providers need confidence that feedback is being requested by the actual sender and not by an impersonator. That is why FBL eligibility is commonly tied to authentication and domain verification.

For example, Gmail requires traffic using Feedback-ID to be DKIM-signed by a domain the sender owns or controls, and that domain must be added and verified in Postmaster Tools. Yahoo’s Complaint Feedback Loop is domain-based and supports DKIM-signed email; Yahoo uses the enrolled signing domain to determine the sender and delivers ARF reports when enrolled traffic receives a spam complaint.

Authentication therefore has two jobs in a feedback-loop program:

• It establishes a trusted identity for enrollment and reporting.
• It makes complaint data attributable to the right sender, client, or message stream.

If an ESP sends for many customers, this attribution is particularly important. A shared sending system needs to distinguish one customer’s campaign from another’s so that one problematic list does not become invisible inside platform-wide metrics.

What an ARF complaint report contains

ARF stands for Abuse Reporting Format. It is a standardized email-report structure intended for machine processing. In broad terms, an ARF report packages an explanation of the report, structured metadata about the feedback event, and a copy of the relevant original message or its headers.

That structure is useful because it lets automated systems make decisions without relying on a human to read every report. A parser can extract fields, match the original message to sending logs, and invoke a suppression workflow.

The data you should preserve

The exact fields may vary, and senders should build parsers that tolerate provider differences. Still, a robust complaint-ingestion record usually preserves these categories:

• Report type, such as an abuse or spam complaint classification.
• Reporting provider, so the team can separate complaint patterns by mailbox ecosystem.
• Timestamp, including the time the provider generated the report and the time the sender processed it.
• Source IP or sending identity, if provided, to help isolate a sending pool or stream.
• Original message headers, especially the Message-ID, From, and other correlation data.
• Recipient or recipient token, when available and permitted by the report.
• Campaign, tenant, or message-stream identifier, recovered from headers or sending logs.
• Suppression outcome, including whether the recipient was already unsubscribed, already suppressed, or newly added to the suppression list.

Do not treat a complaint report as an ordinary inbound support email. It can contain original message material and recipient information. Limit access, store only the information required for abuse prevention and auditing, and set retention practices that match the organization’s privacy and security obligations.

Parse for safety, not just convenience

Email is an adversarial input format. A complaint processor should not assume that every header is present, correctly formatted, or safe to render. It should avoid executing attachments, avoid trusting display names, validate identifiers before database operations, and keep raw-message storage separate from operational tables where possible.

The safe processing goal is simple: determine whether the report maps to a recipient and sender-controlled message, then suppress that recipient from future nonessential mail. If the mapping is ambiguous, flag the event for review rather than risking suppression of the wrong person.

Is feedback loop a metric? How to calculate complaint rate

“Feedback loop” describes a reporting mechanism, not a single metric. But the most important metric derived from it is the spam complaint rate, also called complaint rate.

At its simplest, complaint rate is:

Complaint rate = (unique spam complaints / delivered messages) × 100

The formula is straightforward, but the denominator matters. A complaint is an action on a delivered or presented message, so using attempted sends as the denominator can understate the problem when a campaign has many bounces or provider blocks. A provider may also calculate its own rate differently, such as using mail delivered to the inbox rather than every accepted delivery.

Always label the denominator in your dashboard. “0.12% complaint rate” is incomplete unless the team knows whether it means complaints divided by accepted messages, delivered messages, inboxed messages, or a provider-specific estimate.

Worked complaint-rate example

Suppose a promotional campaign has these results at one mailbox provider:

• 50,000 messages attempted
• 1,000 messages hard bounced
• 500 messages temporarily deferred and never delivered
• 48,500 messages delivered
• 97 unique recipients marked the campaign as spam

The campaign complaint rate based on delivered messages is:

Complaint rate = (97 / 48,500) × 100
Complaint rate = 0.2%

The campaign’s complaint rate is 0.2%.

If the team instead divides by all 50,000 attempted messages, it gets 0.194%. That difference looks small in this example, but the distortion grows when bounce or rejection volume is high. More importantly, it can obscure whether the recipients who actually received the message found it unwanted.

Now imagine that the same campaign was sent only to the 10,000 least-engaged subscribers and generated 97 complaints. The rate would be:

Complaint rate = (97 / 10,000) × 100
Complaint rate = 0.97%

The total number of complaints did not change, but the diagnosis did. The second calculation clearly shows that the inactive segment is unsafe to mail at that frequency or with that offer.

Use multiple time windows

A daily complaint rate detects sudden campaign failures. A rolling seven-day or 30-day rate helps reveal sustained reputation risk. Both are necessary.

Track at least these views:

• Per send: Find a bad campaign, trigger, template, or subject line quickly.
• Daily by mailbox provider: Detect provider-specific shifts in filtering or audience expectations.
• Rolling weekly: Avoid overreacting to a tiny send while still seeing a meaningful trend.
• By acquisition source: Discover whether a lead form, partner source, import, or signup flow produces low-quality consent.
• By audience age and engagement: Identify stale addresses and subscribers who no longer recognize the brand.
• By message category: Keep transactional, lifecycle, product, and promotional performance distinct.

A small sample can produce a noisy rate. One complaint in a send of 100 delivered messages is 1%, but it does not necessarily prove a systemic failure. Conversely, a 0.15% rate across millions of deliveries can represent thousands of unhappy recipients and a meaningful reputation issue. Read rates alongside absolute complaint counts, send volume, and trends.

Common causes of high complaint rates

A spam complaint is a recipient-experience failure before it is a technical deliverability failure. The best investigation starts with the question: Why did the recipient feel that the spam button was easier or more appropriate than unsubscribe?

Weak, unclear, or expired consent

The most common root cause is poor permission quality. A person may have entered an email address in exchange for a download, account, purchase, webinar registration, or contest entry without realizing they were also subscribing to frequent marketing.

Permission can also expire in practice. A subscriber who joined three years ago may technically remain on a list, but no longer remember the brand or expect the mail. Sending a sudden high-frequency promotion to that person often causes complaints even if the original signup was valid.

Risky acquisition patterns include pre-checked marketing boxes, vague consent language, scraped or purchased lists, co-registration, unverified imports, and manual uploads with no reliable consent record. None of these are fixed by better copywriting. The list itself needs review.

Frequency that exceeds the subscriber’s expectation

Subscribers often complain when the email cadence changes without warning. Someone who expected a monthly product roundup may object to daily sale announcements. A customer who signed up for shipping updates may complain if that address begins receiving marketing newsletters.

Frequency problems are often made worse by overlapping automations. A recipient might receive a campaign, browse-abandonment message, cart reminder, price-drop alert, and weekly digest in a short period because each workflow is optimized independently.

A contact-level frequency cap and message-priority system prevent this collision. Essential transactional mail should still send, but competing promotional messages should be paused or consolidated.

A sender identity the recipient does not recognize

The visible sender name and From address should make the relationship obvious. Complaints rise when a business uses a legal entity name, a generic brand, a newly changed domain, or an affiliate identity that does not match what the subscriber remembers.

This is especially common after acquisitions, rebrands, platform migrations, or when a marketplace sends on behalf of individual vendors. If a recipient cannot connect the sender to the signup context in one glance, they may mark the message as spam rather than investigate.

Use a stable recognizable display name, align the visible brand with the signup experience, and explain the relationship in the first lines of the message when there is any chance of confusion.

Misclassified transactional mail

A transactional label does not make unwanted content safe. Password resets, receipts, security alerts, and requested account notifications are normally expected. But marketing content added to those messages can undermine the recipient’s expectation.

For example, a receipt with a modest product recommendation may be accepted by many recipients, but a “shipping update” that is primarily a promotional email can attract complaints. Keep operational messages focused on the transaction. If promotional content is included, make its role secondary and honor the applicable consent and unsubscribe requirements.

Broken or difficult unsubscribe experiences

A recipient often uses the spam button when unsubscribe feels hidden, slow, confusing, or ineffective. A body link that leads to a login requirement, multiple screens, a survey wall, or a delayed confirmation can turn an easy opt-out into a complaint.

For marketing mail, provide a visible unsubscribe option in the message body and support standard unsubscribe headers where required or appropriate. Honor requests promptly. If a subscriber can reduce frequency or choose topics instead of fully opting out, a preference center can prevent some complaints—but it must never make complete opt-out difficult.

Bad segmentation and stale audiences

Sending every campaign to every historical contact is an easy way to create complaints. Subscribers with no recent engagement, no recent purchases, or no relationship to the current offer should not be treated as equivalent to active subscribers.

Segment by recency, stated preferences, lifecycle stage, acquisition source, geography where relevant, and observed engagement. Use a sunset policy that gradually reduces or stops marketing mail to persistently inactive recipients. A smaller active list usually produces better deliverability and business results than a large list that generates complaints.

How to fix and improve email feedback loop performance

The immediate operational response to a valid complaint should be fast and irreversible for marketing mail: suppress the affected recipient. The strategic response requires tracing the complaint back to the sending decision that produced it.

Build a complaint-suppression pipeline

A reliable pipeline has a simple rule: a spam complaint must take precedence over campaign eligibility. If a contact appears in an upcoming audience but is present in the complaint-suppression table, the send should not occur.

A practical workflow is:

1. Receive the complaint report or pull the aggregate data from the applicable postmaster tool.
2. Validate that the report belongs to mail sent by your organization or customer.
3. Resolve the recipient and original message using message headers, provider data, and delivery logs.
4. Add the recipient to a permanent complaint suppression list for nonessential messages.
5. Stop any queued campaigns or automation steps for that recipient.
6. Record campaign, stream, tenant, acquisition source, and timestamp for analysis.
7. Alert the responsible team when a campaign or segment crosses an internal threshold.
8. Review the cause, make a documented change, and monitor the next sends.

For a multi-tenant platform, suppressions should be scoped carefully. A complaint about one customer’s mail should prevent that customer from mailing the recipient again; it should not automatically block unrelated, independently consented mail from another legitimate sender. At the same time, shared reputation systems must identify and control customers whose complaints threaten the platform’s infrastructure.

Separate streams before a problem spreads

Use separate sending domains, DKIM identities, IP pools where appropriate, and analytics labels for materially different mail streams. The exact architecture depends on volume and infrastructure, but the principle is consistent: do not make it impossible to tell whether promotional campaigns, product alerts, account notifications, or a single tenant are responsible for complaint growth.

Separating streams also improves diagnosis. If marketing complaints rise while password-reset mail remains stable, the fix is likely audience policy or campaign design, not SMTP configuration. If all streams worsen together, investigate authentication, domain reputation, unexpected volume changes, or a broader sender-recognition problem.

For implementation details on authentication, sending setup, and API-based delivery flows, consult the email API reference and setup guides alongside your provider-specific postmaster documentation.

Make the unsubscribe path better than the spam button

The goal is not merely legal compliance. It is reducing friction at the moment a recipient decides they no longer want the mail.

Good unsubscribe design includes:

• A visible link in the body, especially on mobile.
• A clear label such as “Unsubscribe” rather than ambiguous wording.
• A one-step or near-one-step opt-out flow.
• No forced login for a basic unsubscribe request.
• Immediate suppression of the address from promotional mail.
• A preference center for frequency or topic choices, offered as an option rather than a barrier.
• Correct List-Unsubscribe support for relevant message categories.

Test the experience from a real recipient’s perspective. Follow the link on a phone, in a private browser window, with no account session, and from an address that has never created a password. If the path feels harder than marking spam, recipients will choose spam.

Change targeting before changing creative

When complaints spike, teams sometimes rewrite the subject line first. That can help if the message was misleading, but it is often not the main cause. If the wrong people received the message, a more polished subject line will not restore consent or relevance.

Investigate in this order:

1. Did recipients knowingly subscribe to this type of mail?
2. Did the mailing frequency match what they expected?
3. Did the message arrive from an identity they recognize?
4. Was the audience segmented appropriately?
5. Was unsubscribing easier than reporting spam?
6. Did a content or rendering issue create confusion?
7. Did a technical or routing change alter the sender identity or delivery behavior?

This sequence directs attention to the highest-leverage causes. Better targeting can reduce complaints immediately; a cosmetic edit cannot rescue a fundamentally unwanted campaign.

Gmail Feedback-ID and campaign-level diagnosis

Gmail’s Feedback Loop is particularly useful when a sender needs to distinguish complaints among campaigns, customers, or message categories. Gmail documents a Feedback-ID header that contains sender-defined identifiers separated by colons.

The documented pattern is:

Feedback-ID: a:b:c:SenderId

The first three fields are optional identifiers. SenderId is required, must be five to 15 characters, and should remain consistent across the mail stream. Gmail aggregates data from the header fields, beginning from the right, and requires a sufficiently large volume and distinct user spam reports before data is generated for a day.

Design identifiers for decisions

Choose identifiers that answer operational questions. For example, an ESP might use identifiers that represent campaign, customer, and mail type. A brand might use a campaign family, lifecycle program, and channel.

Useful identifier ideas include:

• Campaign family: spring-sale, weekly-digest, winback.
• Customer or tenant ID: a stable internal identifier, not a recipient identifier.
• Mail type: promo, newsletter, product, transactional.
• Business unit: retail, marketplace, events.

Avoid putting personally identifiable information in headers. Also avoid a unique identifier for each message. The objective is aggregation: enough messages in a meaningful bucket to reveal that a specific campaign or stream is drawing complaints.

Do not confuse Gmail feedback data with a universal complaint feed

Gmail’s Feedback Loop applies to mail sent to personal Gmail accounts and reports aggregate feedback associated with its identifiers. It should complement, not replace, direct complaint processing from providers that deliver recipient-level reports.

A mature deliverability program combines several data sources:

• Feedback-loop reports where individual complaints are available.
• Gmail Postmaster Tools spam-rate and Feedback Loop data.
• Yahoo complaint-feedback data and related sender reporting.
• Sending-platform event logs.
• Unsubscribe events and preference changes.
• Bounce and deferral patterns.
• Audience and consent records.

No single dashboard can explain deliverability. Complaint signals become useful when they are correlated with what was sent, to whom, under which identity, and based on which consent source.

A practical monitoring framework

Feedback loop monitoring works best when it is operationalized before a complaint spike. Define ownership, thresholds, escalation rules, and corrective actions in advance.

What to put on the dashboard

A useful dashboard does not need dozens of charts. It needs enough detail to answer whether complaints are rising, where they are coming from, and what changed.

Track these core metrics by mailbox provider and message category:

• Delivered volume.
• Complaint count.
• Complaint rate.
• Unsubscribe rate.
• Hard-bounce rate.
• Deferred or throttled delivery volume.
• Spam-folder placement or reputation indicators where provider reporting makes them available.
• New-subscriber versus long-term-subscriber complaints.
• Complaint rate by acquisition source.
• Complaint rate by campaign and automation.

Pair the metrics with annotations for launches, list imports, consent-form changes, domain changes, new templates, frequency changes, and major promotions. That historical context turns a chart into a diagnostic tool.

Establish internal guardrails

Published provider thresholds are important, but they should not be your only guardrail. Waiting until a program approaches a provider’s maximum recommendation means waiting until a reputation problem is already visible.

Set lower internal alert levels that reflect your list quality, audience size, and risk tolerance. For example, a team may define a normal baseline, an investigation threshold, and a stop-send threshold for each stream. The specific numbers should be based on historical performance and provider guidance, not copied blindly from another business.

The stop-send decision should consider both rate and volume. A 0.3% rate in a tiny test may need investigation but not a shutdown. A 0.1% rate that suddenly doubles across a multi-million-recipient program may deserve immediate action because the trend itself is the signal.

Feedback loops, bounces, unsubscribes, and spam traps compared

These signals are related because they all influence list hygiene and deliverability, but they mean different things.

An unsubscribe is not a complaint, but it can prevent one. A hard bounce is not a complaint, but repeatedly mailing invalid recipients can indicate poor list quality. A spam-trap hit is not recipient feedback, but it may point to the same underlying problems: stale lists, missing consent, or weak suppression handling.

The common principle is that sender reputation improves when an organization listens to negative signals and stops repeating the behavior that caused them.

Best practices for developers and email teams

Feedback-loop performance is not solely the deliverability team’s responsibility. Developers determine whether messages include reliable identifiers, whether suppression checks happen before send, and whether event data can be connected across systems. Marketers determine targeting, cadence, consent language, and message clarity. Compliance and support teams often see problems first through direct customer complaints.

A strong cross-functional program should include the following practices:

• Store consent source, timestamp, form version, and intended email categories at signup.
• Use confirmed opt-in where the risk profile and acquisition model justify it.
• Check unsubscribe and complaint suppressions in every audience-building query.
• Keep transactional and promotional use cases distinct in code and reporting.
• Add stable campaign or stream metadata at send time.
• Monitor provider-specific complaint data rather than relying only on aggregate platform metrics.
• Test unsubscribe behavior after every template or routing change.
• Require review before importing a large external list.
• Ramp new domains, streams, and audiences gradually.
• Document who can override a suppression and under what narrow circumstances.

A useful engineering rule is: suppression should be a safety control, not a campaign preference. An operator should not be able to casually re-add an address that complained just because the next campaign has a high projected revenue value.

Conclusion: treat complaints as product feedback

An email feedback loop is one of the clearest signals a sender can receive about whether its mail is wanted. It provides a direct connection between recipient dissatisfaction and the operational changes needed to protect deliverability: suppress the complaining address, identify the responsible stream, repair consent or relevance, improve unsubscribe access, and monitor the result.

The healthiest programs do not aim merely to stay below a published complaint threshold. They use feedback-loop data to build an email experience recipients recognize, expect, and control. That approach protects inbox placement, reduces wasteful sending, and makes campaign performance more durable over time.

FAQ

What is an email feedback loop in simple terms?

An email feedback loop is a reporting system that tells a sender when recipients mark its messages as spam or junk. The sender uses the report or aggregate data to suppress recipients and improve future campaigns.

Is an email feedback loop the same as an unsubscribe?

No. An unsubscribe is a recipient request to stop receiving a category of email. A feedback-loop complaint happens when the recipient marks a message as spam or junk. Senders should honor both, but a complaint is usually a stronger deliverability warning.

What is a good email complaint rate?

The answer varies by provider, volume, and message type. Gmail and Yahoo publish guidance that senders should keep spam rates below 0.3%, but responsible senders typically set internal alert levels below provider limits and investigate upward trends early.

Should a sender permanently suppress an address after a spam complaint?

For marketing and other nonessential mail, yes. A complaint should normally create a durable suppression record so the recipient does not receive more unwanted campaigns. Essential account or security messages may require separate policy handling.

Why do I have a high complaint rate when my open rate looks good?

Open rate reflects only part of audience behavior and can be distorted by privacy features. A campaign may perform well among active customers while upsetting less engaged or poorly consented recipients. Review complaint rate by segment, acquisition source, campaign, and mailbox provider rather than relying on opens alone.