由 Hoelee Advisory 交付
WhatsApp + OCR 单据录入
WhatsApp 接单 + 收据 OCR，重复水单进账本之前就被拦住。
起价 RM 5,800+
RM 450/月起，含 2,000 张/月 OCR · Meta 会话费实报实销
查看 advisory 页面 →S52–4 天
事务性 SMTP 中继：发票与 OTP 专用发信通道
ERP 显示发票已发送，客户说没收到。我们把发票和 OTP 放到独立的发信子域上，配 DKIM 和真的退信告警——投递失败会变成你收到的一条通知，而不是三周后客户的一通投诉。
- 发信子域独立
- DKIM 签名、DMARC 报表
- 退信有告警，不是没声音
如果发票和你网站用的是同一个共享主机账号发信，下面两条大概已经成立。
- 发票进了 Gmail 垃圾箱，网站表单邮件却好好的——同一个域名，两种运气。
- 主机每小时限几百封，月底对账单要分三天才发得完。
- 上个月哪些发票退信了没人知道，因为哪儿都没有报告。
- 想换成正经的中继，但发信代码埋在 SQL Accounting 或 AutoCount 里。
我们配什么
- 独立的发信子域，中继信誉永远不和员工邮箱混在一起。
- 该子域上做 DKIM 签名与 DMARC 报表，第一封真发票发出之前先验证通过。
- SMTP 凭据直接接进 SQL Accounting、AutoCount 或你自己的程序；从你的系统里测，不用 curl 糊弄。
- 退信和投诉告警进一个真的有人看的邮箱，主题里直接写失败的那个地址。
- 每月发送量报表 + IP 监控，限流或被拉黑在月底之前就被发现。
- 一页运行手册：主机、端口、凭据归属，以及 ERP 升级时该改哪里。
需要你配合：发信子域的 DNS 权限、一个允许我们改 SMTP 设置的 ERP 账号，以及一个你能在 Gmail/Outlook 里查看的测试收件地址。
接中继之前与之后
事务邮件的标准只有两条：到没到，以及没到的时候你知不知道。
| 服务 | 走共享主机 | 走中继 |
|---|---|---|
| 发信来源 | 和主机上每个网站共用 IP | 专用子域，持续监控 |
| 认证 | 最好也就配个 SPF，通常什么都没有 | DKIM 签名，DMARC 出报表 |
| 发信失败时 | 静悄悄，或者一份没人看的日志 | 告警里带失败地址 |
| 每月发送量 | 主机限流，通常一小时几百封 | 配额按月底批量发的量算 |
| 谁来修 | 开一张让别人时区的人处理的工单 | 配这套东西的那个人 |
Nett —— 不收取 SST
先测现状，再替换
今天先发一封真发票
先看你现在这封发票到底落在哪、认证结果是什么，再谈方案。
隔离子域、接进 ERP
发信子域发布并签好，SMTP 凭据接进 ERP；员工邮箱完全不动。
盯一个月底
第一个对账单周期全程盯退信告警，把配额调到位才交接收工。
去看你自己发票的邮件头
用中继往你自己的 Gmail 发一封发票，点“显示原始邮件”：应该看到我们子域上的 dkim=pass、spf=pass，Return-Path 不是共享主机的。哪一项是 softfail，就说明我们还没做完。
把发票交给它之前，先问这几条
是。From 仍然是你域名下的发票地址；只有退信地址挪到我们签名并监控的子域上——正是这一步保住员工日常邮件的信誉。
两者都是用普通 SMTP 用户名密码发信，可以。我们在你的系统里配好，并从里面发一封真发票——只过命令行测试的中继，等于没在你那边验证过。
超出的量会排队并写进报告，不会静悄悄丢掉；等两个月看真实用量再报一个加量包。只用在年底高峰的容量，不该让你整年付。
不行，而且我们会明说。在事务邮件的 IP 上跑群发，会把发票一起拖进垃圾箱。电子报另用平台，我们宁可给你指一个，也不卖你一条错的管道。