本地部分与已识别的角色模式对照
info@、support@、sales@、billing@、abuse@ 和 postmaster@ 这类地址描述职能,而不是具名人。BillionVerify 会规范化地址,并将其本地部分与维护中的角色模式对照,以便一致分类常见别名。
互联网标准社区在 RFC 2142 中记录了常规服务邮箱名。真实组织还会使用额外别名,因此阴性匹配能收窄风险,但不能证明收件箱是个人的。
邮箱验证工具
这是个人收件箱还是通用角色邮箱?用聚焦的角色结果检测 info@、support@、sales@ 及类似模式。
角色账户检测标记 info@、support@、sales@、admin@ 等通用邮箱。
这些地址常能收信,但会拖累回复率、抬高垃圾投诉,并浪费 SDR 时间。聚焦工具让角色决策保持在最前。
检测结合本地部分模式与验证上下文,然后本页只显示角色结果与指引。
在保留独立路由和 SMTP 证据的同时,分类邮箱用途。
在进行任何网络检查前,先拒绝空值或格式异常的输入。
把规范化后的本地部分与 support、sales、billing 等已知职能邮箱名对照。
把 SMTP 收件人结果分开保留,因为角色邮箱仍可能正常接受邮件。
界面突出本页维度及其白话含义——而非完整多标记面板。
当一个决策比完整报告更重要时,使用专项工具。
在把导入联系人分配给 SDR 前,衡量有多少是共享职能而不是具名人。
把 info@、sales@ 和类似共享收件箱移出面向具名决策者的序列。
当流程本就是面向该组织职能时,保留 billing@、support@ 和 security@。
把角色标志当作批量导出和 API 决策中的字段,而不是删除原始记录。
这些是交互式邮箱验证工具——不是批量任务、不是 API、也不是免费工具(DNS / SPF / DKIM)。
本页隔离角色决策。其他工具要么展示完整多层结果,要么聚焦不同专项标记。
| 工具 | 功能说明 | 适用场景 |
|---|---|---|
| 电子邮件验证器 | SMTP 邮箱全面检查及所有风险标记 | 当送达率和发送安全至关重要时 |
| 邮箱检查器 | 单个地址的完整 SMTP + 全部风险标记 | 需要一处查看完整多层结果时 |
| 免费邮箱检查器 | 检测免费个人邮箱服务商(Gmail、Yahoo 等) | 线索质量与 B2B 域名评分——不是“免费额度”验证 |
| 邮箱校验器 | 仅语法 + MX——无 SMTP | 快速格式与域名初筛 |
| 一次性邮箱检测 | 标记临时 / 一次性域名 | 注册与线索捕获 |
| 退信邮箱检查器 | 聚焦退信与不可达风险 | 控制退信率的列表卫生 |
| Catch-All 验证器 | 检测 Catch-all 域名 | 当 SMTP 接受结果不可靠时 |
| 角色账户检测 | 发现通用角色地址 | B2B 外呼质量 |
| 邮箱列表清洗 | 一次验证多个地址(粘贴或 CSV) | 单次检查不够、需要清洗整份列表时 |
| 反向电子邮件查找 | 从电子邮件地址查找上市公司所有者和公司背景信息 | 线索研究和未知发件人审核 |
| 电话号码验证器 | 验证电话格式、国家/地区、类型和 E.164 输出 | CRM 外联前电话清理 |
角色账户表示通用邮箱模式。非角色账户表示本地部分不是常见角色关键词——仍不保证是个人收件箱。
角色分类和 SMTP 送达能力保持独立。共享的 sales@ 邮箱可以接受邮件,而看起来像个人的地址仍可能拒绝邮件或属于别名。
本地部分证据
角色检测描述 @ 符号前的邮箱名;它不替代域名或 SMTP 验证。
info@、support@、sales@、billing@、abuse@ 和 postmaster@ 这类地址描述职能,而不是具名人。BillionVerify 会规范化地址,并将其本地部分与维护中的角色模式对照,以便一致分类常见别名。
互联网标准社区在 RFC 2142 中记录了常规服务邮箱名。真实组织还会使用额外别名,因此阴性匹配能收窄风险,但不能证明收件箱是个人的。
角色邮箱可能完全可送达,看起来像个人的邮箱也可能无效。因此完整检查会解析接收路由并评估邮箱证据,而不会让角色标志覆盖 SMTP 结果。
若要完整面板,打开 邮箱检测器。本页对角色与可能个人的区别给出更多解释,因为它驱动不同的外联决策。
support@ 可以是客户问题的正确目的地,billing@ 适合发票,security@ 适合漏洞报告。同一个地址可能不适合人对人的销售外联,却最适合事务性流程。
因此分类应供给路由,而不是一条通用删除规则。保留角色标签,让每个工作流选择自己的动作。
阅读标签
同一个邮箱在一个工作流里可能很合适,在另一个里则不合适。
本地部分匹配已知的职能或共享邮箱模式。对具名人销售序列,把它移出主要受众,或要求人员特定联系人。对支持、发票、滥用报告和运营通知,当职能就是预定收件人时保留它。
发送前单独检查 SMTP 状态。角色标签描述用途,而不是服务器当前是否接受该邮箱。
本地部分不匹配当前角色数据集。它可能是个人收件箱,但也可能是不常见的共享别名、通讯组、转发地址或编造的本地部分。
发送决策请使用 邮箱验证器,并保留你的联系来源证据。仅角色检测不能确立所有权或身份。
信号可以共存。Catch-All 域名上的 sales@ 地址同时带有共享邮箱和全域名接受的不确定性。临时服务商上的角色式地址也可能是一次性的。
分别复核 Catch-All 验证器 和 一次性邮箱检测,而不是让一个标志解释整个地址。
按用途路由
清晰的路由政策比到处拦截每一个通用地址更准确。
产品注册可能需要用户可控的持久邮箱,销售序列可能需要具名决策者,发票流程可能明确需要 accounts-payable@。在选择抑制哪些角色标签前,先写清预期收件人。
这能防止全局拦截破坏合法运营邮件,同时仍保护人员级活动不受通用别名影响。
在注册、富化导入或 CRM 更新时使用 邮箱验证 API。把角色标志与总体状态分开存储,这样政策可以演进,而不会丢失验证器观察到的内容。
如果用户在仅限个人的表单里输入了角色地址,请要求具名工作地址,而不是静默接受、稍后又抑制该联系人。
在把潜客分配到序列前运行 邮箱列表清洗。导出角色、一次性、Catch-All 和 SMTP 字段,让收入运营能按活动目的建分段,而不是靠一个不透明分数。
复核较旧数据,因为即使域名仍活跃,邮箱别名和员工分配也会变化。
窄解读
本地部分分类是有用的元数据,不是地址背后那个人的画像。
通用邮箱本质上不是陷阱或无效收件人。许多正是为了让组织接收关于某项职能的消息而发布的。发送相关性、许可和频率仍决定消息是否合适。
firstname.lastname@ 可能是猜出来的、被转发的、共享的,或受 Catch-All 策略保护。阴性角色结果不能确认姓名、职位、雇佣关系或邮箱所有者。
使用 反向邮箱查询 时,只取它实际返回的公开上下文,并把推断身份与已核实事实分开。
角色检测既不证明 SMTP 接受,也不创造联系收件人的许可。独立应用邮箱结果、退订、抑制名单和你们自己的外联政策。
参考模型
标准提供稳定核心,产品数据则捕获实践中更广的集合。
该文档列出商务、网络和安全职能的常规邮箱,包括 postmaster、abuse、hostmaster、sales、support 和 security。来源及其互操作目的见 RFC 2142。
组织会发明超出标准的别名。把新增内容作为数据维护,复核误报,并保留结果时间戳,这样以后的数据集更新不会改写历史含义。
稳定的 API 合约应让消费者看到一个邮箱既可送达又是基于角色的。把这些事实合成一个状态,会掩盖本页想讲清楚的区别。
角色账户(或基于角色的地址)是由职能共享的通用邮箱——info@、support@、sales@、admin@、billing@、hello@ 及类似模式——而非具名个人。邮件可能投递,但回复率往往较低、路由不清晰,部分 ESP 与垃圾过滤器会把大量角色地址发送视为较低质量。
冷邮件与 SDR 序列对个人收件箱转化最好。角色账户会增加无回复、共享分拣延迟,以及许多团队冲击同一 sales@ 别名时的退订/投诉风险。角色账户检测让您对这类行与具名联系人不同地评分、抑制或分流,而无需丢弃每个非个人域名。
否。它表示本地部分不匹配常见角色模式。地址仍可能是不常见名称的共享别名、分发列表或个人收件箱。角色检测是质量信号,不是身份证明。请与邮箱检查器的可达性结果及您自己的增强数据结合。
当剧本决策明确是“通用角色 vs 可能的个人本地部分”时,使用角色账户检测。需要 SMTP 可达性加上一次性、Catch-all 与角色标记时,使用邮箱检查器。对整份文件,运行邮箱列表清洗,在序列启动前对每一行分类。
交互式检查使用与其他完整工具共享的公平使用免费完整验证配额(每个 IP 每滚动 24 小时 20 次)。注册后可通过批量与 API 路径做流水线规模过滤。
公开检查会返回结果并执行防滥用限制。我们不会用您粘贴到此工具的地址构建营销列表。
登录后可使用批量列表清洗、更高用量与 API,验证引擎相同。
24 小时 20 次免费 SMTP 检查 · 免费层无需信用卡 · 与批量及 API 同一引擎