Role-based address flagging

Role-based addresses (info@, admin@, support@, noreply@) route to shared inboxes staffed by multiple people, none of whom opted in personally. They generate disproportionate complaint rates because recipients feel no ownership of the subscription and report spam at 3–5× the rate of personal addresses. Campaigns sent to role addresses also score lower engagement — shared inboxes are typically managed for task completion, not reading newsletters — which trains ISP filters to classify your domain as low-value. Elevated complaint rates from these addresses can trigger CAN-SPAM enforcement scrutiny, since complaints are one of the signals ISPs forward to the FTC.

Detect role-based prefixes at ingest and store a flag on the contact record to gate campaign eligibility:

const ROLE_PREFIXES = [
  'info', 'admin', 'support', 'hello', 'noreply', 'no-reply',
  'postmaster', 'webmaster', 'contact', 'sales', 'team',
  'abuse', 'hostmaster', 'help', 'feedback'
]

function isRoleBased(email: string): boolean {
  const local = email.split('@')[0]?.toLowerCase() ?? ''
  return ROLE_PREFIXES.some(prefix => local === prefix)
}

await db.contact.create({
  data: { email, is_role_address: isRoleBased(email) }
})

Add where: { is_role_address: false } to cold campaign segment queries. Transactional sends (receipts, password resets) can still reach role addresses — exclude them from marketing campaigns only.

• ID: data-quality-list-hygiene.email-validation.role-address-flagging

• Severity: medium

• What to look for: Check whether the system identifies addresses with role-based prefixes: info@, admin@, support@, hello@, noreply@, postmaster@, webmaster@, contact@, sales@, team@, abuse@, hostmaster@. Enumerate all role prefixes the system checks and count the number covered out of the 12 known role prefixes — quote the actual prefix list found. These addresses often deliver to shared inboxes, go unread, and generate elevated complaint rates. Look for prefix detection in validation logic or a separate flagging system.

• Pass criteria: Role-based addresses are detected covering at least 8 of the 12 standard role prefixes. Detected addresses are either rejected (strict) or flagged with a metadata tag that prevents them from receiving certain campaign types (especially cold outreach). Report the count of covered prefixes even on pass.

• Fail criteria: Role-based addresses are accepted and treated identically to personal addresses. Or fewer than 8 role prefixes are covered.

• Skip (N/A) when: The system is a transactional system only (receipts, alerts) where role-based addresses are expected and acceptable recipients.

• Detail on fail: Example: "No role-address detection — info@ and admin@ addresses are treated identically to personal addresses"

• Remediation: Add prefix detection at ingest and tag the contact record:

  const ROLE_PREFIXES = [
    'info', 'admin', 'support', 'hello', 'noreply', 'no-reply',
    'postmaster', 'webmaster', 'contact', 'sales', 'team',
    'abuse', 'hostmaster', 'help', 'feedback'
  ]
  
  function isRoleBased(email: string): boolean {
    const local = email.split('@')[0]?.toLowerCase() ?? ''
    return ROLE_PREFIXES.some(prefix => local === prefix)
  }
  
  // Store the flag on the contact:
  await db.contact.create({
    data: { email, is_role_address: isRoleBased(email), ... }
  })
  

  Use the is_role_address flag to exclude these contacts from cold campaign segments.