Suppression and Consent (RFC 6449, 8058)

Sending is the easy half. The hard half - the half that protects your reputation - is not sending: maintaining a suppression list that remembers every “do not send” signal you have ever received and honoring it on every campaign. Those signals come from three machine sources - addresses that bounced (covered in Bounces and DSN parsing), recipients who complained (marked your mail as spam), and recipients who unsubscribed - plus a fourth, manual source: addresses you suppress by policy.

This page covers the standards that generate those signals - the List-Unsubscribe header (RFC 2369), one-click unsubscribe (RFC 8058), ARF feedback reports (RFC 5965, with applicability guidance in RFC 6650), and the operational recommendations for running a complaint feedback loop (RFC 6449) - and the consent practices that keep addresses off the suppression list in the first place. Feeding every signal into suppression, promptly and durably, is the single most reputation-protective thing a sender does.

The 60-second version

• A suppression list records bounces, complaints, unsubscribes, and manual entries; it is consulted before every send, and entries are added easily but removed only deliberately.
• The List-Unsubscribe header (RFC 2369) offers a mailto: and/or HTTPS way to unsubscribe. It “MUST only be generated by mailing lists, not end users.”
• One-click (RFC 8058) adds a List-Unsubscribe-Post: List-Unsubscribe=One-Click header so a mail client can unsubscribe with a single HTTPS POST - no landing page, no login.
• One-click requires the List-Unsubscribe/List-Unsubscribe-Post headers to be covered by a valid DKIM signature.
• A spam complaint arrives as an ARF report (RFC 5965): a multipart/report; report-type=feedback-report message you parse to find which recipient complained.
• A feedback loop (RFC 6449) is keyed to your sending IP or your DKIM d= domain; treat each complaint “similar to an unsubscribe request.”
• Consent is the upstream control. Confirmed (double) opt-in keeps bad addresses off the list; suppression is the cleanup for the rest.
• Honor every signal promptly. Complaints and continued sending to dead or unsubscribed addresses are exactly what receivers penalize.

Suppression: the four signals in operational detail

A suppression list is a single authoritative set of addresses (and sometimes domains) that must never receive mail, regardless of which campaign, list, or customer is sending. Four sources feed it:

Signal	Source	Standard	When to suppress	How durable
Bounce (hard)	Action: failed + 5.x.x DSN	RFC 3464 / 3461	Immediately on a permanent failure	Permanent until re-verified
Bounce (soft, persistent)	4.x.x over repeated sends	RFC 3464 / 3461	After consecutive failures over time	Until it delivers or persists
Complaint	ARF feedback report (FBL)	RFC 5965 / 6650 / 6449	Immediately on receipt	Effectively permanent
Unsubscribe	List-Unsubscribe / one-click	RFC 2369 / 8058	Without delay; “all mail” by default	Permanent
Manual	Operator / policy decision	-	On the policy event	Per policy (role accounts, legal holds)

The discipline is one-directional: signals are easy to add and should be slow to remove. Each signal also has a distinct operational shape:

• Bounces are inferred from the SMTP/DSN layer - you classify them yourself from the reply code and DSN fields (see the next section). They are the noisiest source, because a single failure can be transient; correctness depends on separating permanent from transient.
• Complaints are delivered to you as ARF messages by mailbox providers that run a feedback loop. They are high-signal (a human pressed “report spam”) but you only see them for providers whose FBL you have registered for.
• Unsubscribes are requested by the recipient through the headers you put in the message. They are unambiguous: the person asked to stop.
• Manual entries are policy: role accounts (abuse@, postmaster@, noreply@), known spam-trap or competitor domains, addresses under a legal hold, and any address an operator decides must not be mailed.

Industry guidance is consistent that hard bounces and complaints are suppressed immediately - M3AAWG’s Sender BCP states senders “must process all unsubscribe requests without delay,” and deliverability operators (Spamhaus) describe processing feedback-loop complaints and removing complainants “immediately” as best practice. The standards below are the machinery that delivers those signals to you.

Bounce classification feeding suppression

Bounces are the one signal you derive rather than receive, so the suppression rule depends entirely on correct hard-vs-soft classification. The full mechanics live in Bounces and DSN parsing; the suppression-relevant rules are:

Bounce type	Signal	Suppression rule
Hard	Action: failed with a 5.x.x Status (e.g. 5.1.1 user unknown, 5.1.2 bad domain)	Suppress on the first occurrence. The address is confirmed dead or refused.
Soft (transient)	Action: delayed, or a 4.x.x Status	Do not suppress on one event. Retry on a backoff.
Failed-but-transient	Action: failed with a 4.x.x Status (the MTA gave up on a transient condition)	Treat as a failure for this send, but apply consecutive-failure logic, not immediate permanent suppression.
Repeated soft	The same address soft-bouncing across multiple campaigns	Suppress after a threshold. M3AAWG’s Sender BCP suggests removing an address that “bounces consecutively at least two times over two weeks or more.”

Two cautions from the primary sources shape the thresholds:

• RFC 3464 Appendix C warns that “almost any failure status code (even a ‘permanent’ one) can result from a temporary condition,” and recommends removing a subscriber “only on the persistence of delivery failure over a period of time,” never on a single delayed report. The exception it grants: persistent user unknown over several days “could be considered a reliable indication that [the] address [is] no longer valid.”
• The receiver penalizes repeated hard failures. M3AAWG notes that “large volumes of hard-bounces are too often indicative of a poorly managed registration process,” and that receivers “penalize a sending IP for too many messages that end up bouncing with permanent failures.” Immediate suppression of confirmed hard bounces is therefore reputation-protective, not just hygienic.

So the rule is asymmetric by design: a single 5.x.x is enough to suppress; a single 4.x.x is never enough, and you wait for persistence.

The List-Unsubscribe header (RFC 2369)

RFC 2369 defined a family of List-* headers for mailing-list commands; the one that matters for senders is List-Unsubscribe, which “describes the command (preferably using mail) to directly unsubscribe the user.” The contents are angle-bracket-enclosed URLs:

List-Unsubscribe: <mailto:list-off@host.com>
List-Unsubscribe: <http://www.host.com/list.cgi?cmd=unsub&lst=list>,
    <mailto:list-request@host.com?subject=unsubscribe>

Key rules from RFC 2369:

• Multiple alternates may be given as a comma-separated list of angle-bracket URLs, in “order of preference from left to right”; a client uses the leftmost protocol it supports (§2).
• Generators “SHOULD usually include a mailto based command, in addition to any other protocols,” to support users without web access (§2).
• These headers “MUST only be generated by mailing lists, not end users,” and there “MUST be no more than one of each field present in any given message” (§3).
• A mailto: may carry a ?subject= or ?body= so the unsubscribe mail is pre-filled (§3.2).

The mailto: form is important for suppression: an unsubscribe request can arrive as an email to a parsing mailbox, which you process the same way you process a complaint. Build that mailbox to extract the recipient identity (from the envelope, the To:, or an opaque token in the address) and suppress on receipt.

One-click unsubscribe (RFC 8058)

The plain List-Unsubscribe HTTPS link historically led to a landing page, which is friction. RFC 8058 added one-click: a way for the mail client itself to unsubscribe with a single POST, no page visit. It works by pairing the existing header with a new one.

What the sender must put in the message (RFC 8058 §3.1)

• One List-Unsubscribe header and one List-Unsubscribe-Post header.
• “The List-Unsubscribe header field MUST contain one HTTPS URI. It MAY contain other non-HTTP/S URIs such as MAILTO:.”
• “The List-Unsubscribe-Post header MUST contain the single key/value pair ‘List-Unsubscribe=One-Click’.” That is the exact and only valid value (§5).
• The unsubscribe URI “MUST contain enough information to identify the mail recipient and the list,” so the action can complete automatically - and “SHOULD include an opaque identifier or another hard-to-forge component” rather than plaintext names.
• “The mail sender MUST NOT return an HTTPS redirect, since redirected POST actions have historically not worked reliably.”

The canonical example (RFC 8058 §8.1):

List-Unsubscribe: <https://example.com/unsubscribe/opaquepart>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Which produces this request when a client acts on it:

POST /unsubscribe/opaquepart HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 26

List-Unsubscribe=One-Click

A more complete message pairs a mailto: fallback with the HTTPS one-click URI (RFC 8058 §8.2):

List-Unsubscribe:
    <mailto:listrequest@example.com?subject=unsubscribe>,
    <https://example.com/unsubscribe.html?opaque=123456789>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

A client that supports one-click POSTs to the HTTPS URI; an older client that does not falls back to the mailto: (or opens the link). Either path must end at the same suppression action.

The DKIM requirement (RFC 8058 §4)

One-click is not just convenience; it is authenticated. “The message needs at least one valid authentication identifier. In this version of the specification, the only supported identifier type is DKIM… senders MUST apply at least one valid DKIM signature.” Crucially, “the List-Unsubscribe and List-Unsubscribe-Post headers MUST be covered by the signature and included in the ‘h=’ tag.” If they are not, “the mail receiver SHOULD NOT offer a one-click unsubscribe.” So the unsubscribe headers must be in your DKIM h= list, or the feature silently does not work.

What the receiver does (RFC 8058 §3.2)

• The receiver “can do a one-click unsubscription by performing an HTTPS POST to the HTTPS URI,” sending the key/value pair as the body.
• The body “SHOULD be sent as ‘multipart/form-data’… or MAY be sent as ‘application/x-www-form-urlencoded’.”
• “The mail receiver MUST NOT perform a POST on the HTTPS URI without user consent” - and “MUST NOT include cookies, HTTP authorization, or any other context information.” The unsubscribe endpoint therefore must work as an unauthenticated, context-free POST.

The operational payoff: a recipient who would otherwise hit “report spam” can unsubscribe in one tap from their inbox. Making one-click work well is a direct way to convert would-be complaints into clean removals - which matters because, unlike an unsubscribe, a complaint also dents your reputation on the way out.

ARF feedback reports - how complaints reach you (RFC 5965)

When a recipient clicks “report spam” at a mailbox provider that runs a feedback loop (FBL), the provider sends you a complaint formatted as an Abuse Reporting Format (ARF) message. RFC 5965 defines it as “a [MIME] message with a top-level MIME content type of ‘multipart/report’… The ‘report-type’ parameter… is set to ‘feedback-report’.” (Same container as a DSN; different report-type.)

The three required parts (RFC 5965 §2)

Part	Content-Type	Purpose
1	text/plain	Human-readable description
2	message/feedback-report	Machine-readable metadata
3	message/rfc822 or text/rfc822-headers	The original message or its headers

“Each feedback report MUST be related to only a single email message.” The machine-readable part (part 2) is what you parse.

The fields (RFC 5965 §3)

Required, exactly once (§3.1):

Field	Meaning
Feedback-Type	The kind of report (from the IANA registry): abuse, fraud, virus, other (and auth-failure via RFC 6591).
User-Agent	The software that generated the report (documentation only).
Version	The ARF version - 1 in this spec.

Optional but high-value (§3.2-3.3) - these tell you who complained and about what:

Field	Meaning
Original-Mail-From	The MAIL FROM of the original message.
Original-Rcpt-To	The recipient address from the original RCPT TO - the address to suppress.
Arrival-Date	When the original message was received (formatted per RFC 5322 §3.3).
Source-IP	The IP the message was received from.
Reported-Domain / Reported-URI	Domain/URI the generator deems relevant.
Authentication-Results	The auth checks the generator ran.

A real ARF body (RFC 5965 Appendix B.2, trimmed):

Content-Type: message/feedback-report

Feedback-Type: abuse
User-Agent: SomeGenerator/1.0
Version: 1
Original-Mail-From: <somespammer@example.net>
Original-Rcpt-To: <user@example.com>
Arrival-Date: Thu, 8 Mar 2005 14:00:00 EDT
Reporting-MTA: dns; mail.example.com
Source-IP: 192.0.2.1

The Original-Rcpt-To is the field you act on: that recipient complained, so they go on the suppression list immediately. The catch (covered under feedback-loop operations below) is that some providers redact the recipient address for privacy - which is why senders embed their own recipient identifier in the message before it ever ships.

Feedback-loop applicability (RFC 6650)

RFC 6650 is the applicability statement for ARF - how feedback loops are actually run between mailbox providers and senders:

• The dominant use is solicited reports: “two mail systems make a private agreement to exchange abuse reports - usually reports due to recipients manually reporting messages as spam” (§3). This is the FBL you register for with a provider.
• Solicited reports “SHOULD use ‘Feedback-Type: abuse’,” and SHOULD include Original-Mail-From, Arrival-Date, Source-IP, and Original-Rcpt-To when available (§4.3).
• Providers must be able to throttle: “Feedback Providers MUST provide a way for report recipients to request that no further reports be sent” (§5.1).
• Reports are sent with a null return path to prevent loops: when sending a report “the MAIL FROM command SHOULD use the NULL reverse-path… MAIL FROM:<>,” and “if the message under evaluation… is an ARF [RFC5965] message, a report MUST NOT be automatically generated” (§6).
• Quality bar: “Mechanical reports of mail that ‘looks like’ spam, based solely on… inline content analysis tools, SHOULD NOT be sent,” whereas end-user complaints and spam-trap hits “are far more likely to be accurate and MAY be sent” (§5.2). This is why FBL complaints are a high-signal suppression trigger - they reflect a human pressing “report spam.”

Running a feedback loop (RFC 6449)

RFC 6449 (Complaint Feedback Loop Operational Recommendations, Informational, 2011) codifies the de-facto MAAWG practice for how feedback loops are set up and operated. It is the operator’s manual that sits next to the ARF format spec. The load-bearing points for a sender:

How a provider identifies you

A feedback loop is “usually (but not always) keyed to the ‘last hop’ IP address” - the IP that handed the message to the provider (§3.3). More durably, the provider can key on your DKIM d= domain: “the identity of each message Sender [is] generally determined from the SMTP session’s connecting IP address or a message’s DomainKeys Identified Mail (DKIM) signature domain, both of which are hard to forge” (§1). RFC 6449 Appendix B spells out why DKIM routing is preferable: “A single DKIM ‘d=’ value may be used across multiple servers with multiple IP addresses… when a Feedback Loop uses DKIM, no reconfiguration is necessary because the signing domain does not change.” For an ESP, signing with your own domain lets you “sign up for Feedback regarding all messages signed with that domain,” across thousands of customer domains.

Preparing to receive feedback (RFC 6449 §4.1)

Before you apply for an FBL, have these in place:

• The role addresses abuse@ and postmaster@ on the sending domain - providers “often send a confirmation link to those accounts to prevent End Users, Spammers, or competitors from signing up for Feedback for which they are not authorized.”
• A dedicated address for the reports themselves, such as fbl@example.com, so the stream is easy to process.
• A list of IPs whose ownership you can prove - providers commonly require that the reverse DNS for each IP shares your domain and that WHOIS clearly associates the IP with you.
• RFC 6449 also flags the obvious scam test: “if the application form asks for your credit card number or other financial information, it is assuredly a scam.”

What to do with each complaint (RFC 6449 §4.3)

The provider’s expectation “mostly boils down to three things” (§4.3): do not send “email of the same type to the same Recipient again”; “identify the underlying problem (if any) and fix it”; and there is no obligation to tell the provider what you did. On the suppression scope, §4.3.1 is precise: treat the feedback message “similar to an unsubscribe request,” but calibrate the breadth - “Suppressing the address across an entire ESP is likely too broad. However, if a single Feedback Consumer… has multiple segmented lists, then suppressing them across all those lists is probably a good idea.” The default posture: “assume the Recipient does not want more email and… suppress mail to the Recipient in all but fairly extreme cases” (paid lists, employer-to-employee mail, provider-to-user mail). Transactional mail is the documented nuance - RFC 6449’s own airline-ticket example notes that a customer who reports a purchase confirmation as spam “probably did not mean it,” so for genuinely transactional mail the right action can be to use a different channel rather than suppress.

Extracting the recipient when it is redacted (RFC 6449 §4.4)

Because some providers redact the recipient address, RFC 6449 §4.4 recommends embedding a recipient identifier in the message before you send, “similar to the one used for automated bounce handling using VERP.” Good places: the local part of the Message-ID, the Return-Path (VERP), or the one-click unsubscribe link. The example given is an opaque-but-decodable Message-ID like esp-423-27-42460@example.com, encoding customer 423, campaign 27, recipient key 42460. A neat implementation trick the RFC endorses: if your bounce processor already suppresses on hard bounces, the FBL processor can “create a ‘fake’ hard bounce and send it to the existing bounce processor, suppressing mail to that address” - one suppression path for both signals.

Reading complaint rate correctly (RFC 6449 §4.3.2)

The metric providers watch is the complaint rate = feedback messages received / emails delivered to that provider over the same period. RFC 6449 documents two arithmetic traps worth internalizing:

• The weekend artifact. Complaints are counted on the day the recipient reads the mail, not the day you sent it. A list that is “virtually silent on the weekend could end up receiving more complaints on a Saturday than email they sent that day, leading to complaint rates of well over 100%.”
• The denominator mismatch. If 9,500 of 10,000 messages land in the bulk folder, dividing 10 complaints by 10,000 looks like a respectable 0.1%; the provider divides by the ~500 that reached the inbox and sees 2% - “probably grounds for immediate blocking.” When your own complaint-rate number disagrees with a provider’s, this is usually why.

How complaints feed suppression

The loop is mechanical once the pieces are in place:

1. You DKIM-sign mail (required for one-click anyway, and the durable FBL key per RFC 6449) and register for each provider’s feedback loop using abuse@/postmaster@ and a dedicated fbl@ address.
2. You embed a recipient identifier (VERP, Message-ID, or the one-click token) so you can still identify the recipient if the provider redacts the address.
3. A recipient marks a message as spam.
4. The provider sends you an ARF report; you parse Original-Rcpt-To (or your embedded identifier).
5. That address is suppressed immediately - across the customer’s segmented lists, per RFC 6449 §4.3.1 - and never mailed again.

Because providers weigh complaint rate heavily, the speed and completeness of step 5 directly protects your sender reputation. A registered, parsed, immediately-honored FBL turns a complaint into a one-time event instead of a repeated offense.

Consent models and consent records

Suppression is the cleanup; consent is the prevention. The reason a clean list rarely generates complaints or trap hits is that the addresses on it asked to be there. The consent hierarchy is consistent across M3AAWG’s Sender BCP, Spamhaus’s deliverability guidance, and Adobe’s deliverability guide:

Consent model	What it is	Standing
Confirmed / double opt-in (COI)	Subscriber confirms via a link sent to the address itself	Best. Prevents typos, forgeries, and most trap hits; the gold standard.
Single opt-in with notification	Address added, a welcome message is sent, but no confirmation required	Better. The welcome mail at least exercises the address.
Single opt-in	Address added from a form, nothing confirmed	Minimum acceptable, with caution - “allows unconfirmed addresses… typos or outright forgeries.”
Implied consent	Inferred from a prior relationship, no explicit subscription	Poor; “likely to cause abuse complaints,” requires close monitoring and a permission pass.
Opt-out / no prior consent	Mailed until they object	Unacceptable - “the least useful, messiest, and riskiest of all acquisition methods.”
Purchased / harvested / appended	Lists bought, scraped, or matched from other data	Prohibited - “permission is not transferable.” A direct violation of M3AAWG core values.

Confirmed opt-in is the one model that structurally defends against the worst list hazards: it “prevents a typo or a maliciously submitted address from being added to ongoing mailings” (M3AAWG) and is the recommended defense against typo and pristine spam traps (Spamhaus, Adobe).

Consent records

Consent you cannot prove is consent you do not have. M3AAWG and Spamhaus both call for storing, at the point of collection and in a form you can produce on demand to an ISP, blocklist operator, or regulator:

• the date and time of sign-up (UTC),
• the IP address that submitted the form,
• the channel / source - the website, event, or campaign where the address was collected,
• the form or URL used.

Two collection rules from the same sources: pre-checked consent boxes are “generally viewed as dishonest and… actively illegal in some countries,” and you must never “require a log-in to unsubscribe” - it “is illegal in some places and makes subscribers angry everywhere,” which is exactly the friction RFC 8058 one-click exists to remove.

Re-engagement and sunset policies

Consent decays. An address that opted in two years ago and has not opened a message in a year is a liability: it may have been abandoned and recycled into a spam trap, and it drags down the engagement signals receivers now weight most heavily. A sunset policy suppresses chronically unengaged recipients before they become a problem. Spamhaus’s documented cadence:

• Start the inactivity window at 12 months, then tighten to 6 and 3 months “depending on results.”
• A frequency-based variant: if a recipient does not open for a week, move them from weekly to monthly; if a month passes with no open, send a single “do you wish to continue?” re-permission message; if they do not respond, “add them to your suppression list and stop sending them emails.”

Two refinements from the broader guidance:

• Re-engage before you suppress. A win-back / reactivation campaign gives a quiet-but-valid recipient a chance to confirm interest. Run it on your current sending platform, not on a fresh IP - reactivating a stale segment on a new IP is a classic way to poison a warmup.
• Suppress the truly silent. M3AAWG’s spam-trap guidance is explicit that “senders should consider implementing a policy for suppressing recipients who remain chronically unengaged or non-deliverable,” precisely because a long-dormant address may have been “retired and repurposed as a spam trap.”

Data retention of suppression entries

No RFC sets a retention period for suppression entries - this is policy, and the policy follows from what each entry means:

• Unsubscribes and complaints are effectively permanent. They are an explicit “stop.” Removing such an entry re-introduces the exact recipient who already told you to stop, which is both a reputation risk and, for unsubscribes, frequently a legal one. Keep them indefinitely.
• Hard bounces are permanent until re-verified. A 5.1.1 address is dead; it does not become live again on its own. If you ever re-acquire the address through a fresh, confirmed opt-in, that is a new consent event - but the default is to keep the suppression.
• Soft-bounce suppressions are conditional. They exist because of persistence; if you suppress after repeated soft failures, retain the entry but allow a deliberate, evidence-based review.
• Consent records should be retained for as long as you mail the address plus a reasonable proof window, so you can answer a “prove consent” request after the fact.

The governing principle: suppression data is the cheapest insurance you own, and the cost of keeping an entry is zero. The cost of dropping one - re-mailing a complainer or a dead address - is paid in reputation. When in doubt, keep the entry.

Why suppression belongs in the infrastructure

A suppression list only works if it is impossible to bypass. If suppression is enforced per-campaign inside the application, every new campaign, integration, or import is a fresh chance to mail someone who unsubscribed. The robust design is a single “Do Not Contact” / “Do Not Send” set checked at the sending layer, below the campaigns: every message is tested against it at send time, so no campaign - and no mistake in a campaign - can reach a suppressed address. This is the same logic RFC 6449 §4.4 reaches when it suggests routing FBL complaints into the existing bounce-suppression path: one enforcement point, fed by all four signals, consulted on every send.

Why honoring suppression protects reputation

Mailbox providers infer “does the recipient want this?” from behavior. Continuing to send to an address that bounced hard, complained, or unsubscribed produces precisely the negative signals their filters are built to catch: repeated user unknown failures, repeat complaints, and mail to people who explicitly said stop. Suppression is the mechanism that prevents those signals from recurring. It is also the cheapest reputation insurance available - it costs nothing to not send, and the alternative (filtering, blocks, blocklisting) is expensive and slow to undo.

Two corollaries from the standards:

• Make unsubscribing effortless (one-click, no login, working endpoint) so recipients choose it over “report spam.” RFC 8058’s whole point is removing friction; the easier the unsubscribe, the fewer complaints.
• Default unsubscribe to “all mail.” RFC 2369’s List-Unsubscribe removes the recipient from the list; absent a preference center, treat an unsubscribe as a full opt-out rather than a single-stream tweak.

This page is the suppression side of a larger picture: authentication (DMARC in 2026) proves who you are, and reputation is what receivers decide about you - suppression is how you keep that reputation from eroding through self-inflicted negative signals.

Common confusion

• List-Unsubscribe alone is not one-click. One-click also requires List-Unsubscribe-Post: List-Unsubscribe=One-Click and DKIM coverage of both headers. Without them, clients fall back to the link.
• The one-click endpoint must accept an unauthenticated POST. No cookies, no login, no redirect - by spec.
• An ARF report is not a bounce. Same multipart/report container, different report-type (feedback-report vs delivery-status). Parse the right part.
• A complaint is broader than one list, narrower than the whole ESP. RFC 6449: suppress across the customer’s segmented lists, but “across an entire ESP is likely too broad.”
• Suppression is durable. Removing an address from suppression because “maybe it’s fine now” re-introduces exactly the risk suppression exists to prevent.
• Consent does not transfer. A purchased or appended address never consented to you, no matter who collected it.

What this means for you, and what Egressif does

Egressif maintains suppression automatically across all four signals, enforced at the sending layer so no campaign can bypass it. Hard bounces (Action: failed + 5.x.x) are suppressed on receipt; persistent soft bounces are suppressed only after repeated failure over time, per RFC 3464 Appendix C; FBL complaints are parsed from the ARF Original-Rcpt-To (or an identifier we embed for providers that redact) and suppressed immediately, scoped the way RFC 6449 advises; unsubscribes are honored without delay and default to all mail. One-click is wired end to end: messages carry List-Unsubscribe (an HTTPS URI plus a mailto: fallback) and List-Unsubscribe-Post: List-Unsubscribe=One-Click, and because we DKIM-sign with those headers in the h= tag, compliant clients show the in-inbox one-click button RFC 8058 describes - the endpoint accepts the context-free POST the spec requires. We register feedback loops on the DKIM d= domain so they survive IP changes (RFC 6449 Appendix B), and feed complaints, bounces, and unsubscribes into one durable Do-Not-Send set. None of this guarantees inbox placement - nothing does - but honoring every “do not send” signal promptly, and keeping the wrong addresses off the list through real consent, removes the most common, self-inflicted reasons reputation erodes.