# Decay, bounces and suppression How to measure contact decay from your own records, classify bounces, and propose suppression without erasing evidence. ## First-party evidence only - Decay is measured on the fields your workflows depend on (employer, role, reachability, ownership), with your own dated evidence: a recent reply, a meeting, a form submission, a bounce, a billing contact list, a signed order. - A generic annual decay percentage from a vendor or a blog does not describe your records. Do not quote one in the report. - Do not upload addresses to a verification or enrichment service from this audit. That sends personal data to a third party and is a privacy decision for the privacy owner, outside this skill. ## Bounce classes - Address-dead (counts as decay): unknown user, user unknown, no such user, does not exist, invalid recipient, mailbox disabled, recipient not found, address not found; enhanced status codes 5.1.0 to 5.1.3, 5.1.6 and 5.2.1 (RFC 3463: other address status, bad destination mailbox, bad destination system, bad address syntax, mailbox moved with no forwarding address, mailbox disabled) and 5.1.10 (RFC 7505: the recipient domain publishes a null MX and takes no mail; Exchange Online also returns 550 5.1.10 when the recipient does not exist, checked 2026-11-06). - EmailBouncedReason holds the bounce reason as text, up to 255 characters on Lead. Salesforce doesn't document its format, so check real values before relying on the word matching. Words match only where a word starts, and "soft" only as a whole word, so neither "Microsoft" nor "software" reads as a soft bounce. - Mailbox full (not decay): mailbox full, over quota, 5.2.2. RFC 3463 calls X.2.2 a persistent transient failure, because the person can free space. HubSpot lists Mailbox full as a hard bounce and stops marketing sends to the address, so it still counts in E06, but it stays out of R03. - Enum-style values read the same as the words: UNKNOWN_USER is address-dead, MAILBOX_FULL is mailbox full. - Sender-side (not decay): content, spam, policy, blocked, reputation, DMARC, SPF, DKIM, authentication; enhanced status 5.7.x. These are filters and sender reputation; the address can be valid behind a strict gateway. Hand them to the email-sender-infrastructure skill if installed, otherwise to whoever owns sending domains. - Temporary: 4.x.x codes, pending, soft, deferred. HubSpot retries pending bounces for up to 72 hours. - Unknown: anything else, including HubSpot's "Other". Count it, do not guess. - HubSpot hard bounce reasons are Unknown user, Mailbox full, Content, Spam, Policy and Other. A HubSpot marketing hard bounce stops future marketing sends to that address. ## Global bounces - HubSpot can mark an address as globally bounced when it bounced across several HubSpot accounts. The "Email hard bounce reason" property can stay empty when your own account never recorded a hard bounce. - So a filter on an empty bounce reason never proves an address can receive marketing email. E06 counts any bounce evidence it can see; tell the user the global case is invisible in an export and check the contact's email events in the UI for the spot-checked records. ## Suppression versus deletion - Suppress first: set non-marketing (HubSpot), add to the suppression list, or flag do-not-email, as a change list item. Suppression keeps history, consent evidence and the reason a record must not be re-imported as new. - Deletion is a retention decision for the retention owner. It loses history; Attio can recreate people from later email or calendar activity; a deleted HubSpot contact re-imported from a list returns as a fresh, marketable record. - Never clear an opt-out or a bounce because an enrichment tool returned an address or because the address looks valid. Permission and deliverability are separate facts. - Merges can widen permission (see [merge-playbook.md](merge-playbook.md)). Run suppression changes after merges, not before, so the merged record carries them. ## Dormancy and never-engaged - Engagement means contact-initiated actions: form submissions, email clicks or replies, meetings booked, product logins if synced. Rep-logged calls and emails show effort, not reachability; opens are weak evidence because of mailbox privacy features and security scanners. - HubSpot's Last engagement date counts one-to-one email opens and is set only when the contact has an owner (default contact properties page, checked 2026-11-06). Export Recent conversion date and Last marketing email click date beside it, or unowned contacts read as never engaged in R02. - R01 dormant: latest engagement older than 365 days, WARN at 10% of the marketing population. R02 never engaged: created more than 180 days ago with no engagement. - The output is a sunset proposal: a list of record IDs, the rule and the proposed operation (set_non_marketing or suppress), for the marketing owner to approve. Optionally a re-permission campaign first, if the privacy owner allows it. ## Marketing contact billing timing (HubSpot) - Setting contacts to non-marketing takes effect at the next update date (the renewal day for monthly plans, the first of each month for annual plans), not immediately. - HubSpot does not lower the marketing contact tier mid-term; deleting marketing contacts frees capacity but does not lower the tier. - Forms with "Set new contacts as marketing contacts" on (the default) turn existing non-marketing contacts into marketing contacts when they submit. Check form settings before a sunset, or the numbers come back. - Update dates and tiers checked 2026-11-06 on HubSpot's marketing contacts billing page; the form setting dates from 2026-10-17. Re-check the live page before quoting them. ## Decay sample method (R04) - Pick one population that matters (for example open-deal contacts or customer admins), not the whole CRM. - Draw 200 records at random with a recorded seed. - For each, record the fact checked, the evidence source and date, and the outcome: correct, wrong, or not verifiable. - Report verification coverage (verifiable over sampled) and the defect rate among verified records, with both numbers. Example: 200 sampled, 160 verifiable, 10 wrong: coverage 80%, defects 6.25% of verified. Do not extrapolate to the whole CRM; the unverifiable 40 may differ. - Repeat with the same population definition and evidence rules each quarter. A change in coverage can look like a change in quality if the rules move. ## Hand-offs - Sender-side bounces, authentication and complaint rates: email-sender-infrastructure. - Suppression that must hold across several sending tools: preferences-caps-and-suppression. - Billing tier forecasting after a sunset: martech-cost-forecaster. - Each applies only if installed; otherwise hand the finding to the named owner with the record IDs.