a记录是直连身份证，cname是别名跳转牌，mx是邮局分拣单；三者职责分明，混用会导致邮箱收信失败、解析异常等核心问题。
配置DNS记录不是填几个字段就完事，关键在理解每类记录的职责边界、生效逻辑和协作关系。企业上云过程中，内网解析、公网邮件认证、混合架构服务发现三类场景最容易出错，核心问题往往出在记录类型混用、TTL设置失当、权威链断裂这三点。
搞清A、CNAME、MX各自能干什么，不能干什么
A记录是“直连身份证”，把一个主机名（如web.internal）直接绑定到IPv4地址（如192.168.10.5）。它不依赖其他域名，独立生效，适合固定IP的服务。
CNAME是“别名跳转牌”，只能指向另一个域名（如app.internal.company → web.internal.company），不能同时存在MX或TXT记录在同一主机名下。常见误操作是给@（根域）设CNAME，这会直接让邮箱收不到信——因为MX必须作用于根域本身。
MX是“邮局分拣单”，只对邮件系统生效，且必须指向一个能被A或AAAA解析出来的主机名（不能是CNAME链末端的别名）。优先级数字越小越先投递，两条记录是底线配置，避免单点故障。
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
企业上云时DNS配置的三个关键断点
断点一：私有域与公有域命名冲突
云厂商内网DNS（如阿里云PrivateZone、腾讯云Private DNS）要求私有域名不能与已注册公网域名完全一致。用internal.company可以，但company.com不行——哪怕你没注册这个公网域名，只要ICANN库里有同名注册，云平台就会拒绝创建。推荐统一用svc.prod、dev.local这类无歧义后缀。
断点二：VPC子网未关联DNS服务器
在云控制台建好私有域只是第一步，必须手动将该域“绑定”到具体VPC及子网。否则EC2或云主机发DNS查询时，根本找不到这个权威源，只能走默认公网DNS，结果查不到内网服务。
断点三：混合环境缺少递归出口
本地IDC部署了BIND，云上用了CoreDNS，两者没打通。这时云上服务查db.onprem会失败。解决办法不是全量同步，而是配置条件转发：在云上DNS里加一条规则，把onprem后缀的查询全部转发给IDC的DNS服务器IP。
TTL不是越大越好，也不是越小越灵
TTL本质是缓存寿命，影响变更生效速度和DNS查询压力：
- 上线前测试阶段：设为300秒（5分钟），改完马上能验证
- 生产稳定期：设为3600秒（1小时），平衡响应与负载
- 紧急切换（如主备切换）：临时调成60秒，但切完务必改回，否则长期高查询量会压垮DNS节点
- MX/SPF/DMARC这类安全记录：建议始终用3600，避免因缓存过期导致临时拒信或伪造通过
邮箱安全记录必须四件套配齐
腾讯、阿里、网易等企业邮箱服务商都要求四类记录协同工作，缺一不可：
- MX：告诉别人邮件往哪发（如mxbiz1.qq.com）
- SPF：声明“只有哪些IP或服务商能代表我发信”，格式是TXT记录：v=spf1 include:spf.mail.qq.com ~all
- DKIM：用私钥签名+公钥验签，防内容篡改，需在DNS添加一条长字符串TXT记录（名称类似default._domainkey.yourdomain.com）
- DMARC：定义收到伪造邮件时怎么处理，也是TXT记录：v=DMARC1; p=none; rua=mailto:postmaster@yourdomain.com
注意：SPF和DMARC都只能各有一条TXT记录；DKIM记录名中的default是腾讯后台生成的selector，不能手改；所有记录值末尾不加句点，除非你明确要写绝对域名。
