a记录将域名映射到ipv4地址，aaaa记录映射到ipv6地址；二者均为基础dns记录，不可与cname共存于同一主机名，ttl建议设为300秒以兼顾更新效率与缓存稳定。

想让域名真正“活”起来，光买域名不行，得配对正确的DNS记录——它就像给域名发一张精准的导航卡。配置错一条，网站打不开、邮件收不到、HTTPS证书验证失败，都可能由此而起。核心不是堆砌所有记录，而是按需选对类型、填准值、设好TTL。

A记录与AAAA记录：指向服务器的“门牌号”

这是建站最基础、最常用的记录。A记录绑定IPv4地址，AAAA记录绑定IPv6地址。多数情况下，你只需配A记录；若服务器已启用IPv6且你希望兼容，再加一条AAAA记录。

• 主域名（如 example.com）直接填A记录，指向你的服务器公网IP，比如 192.0.2.100
• www子域名也建议用A记录而非CNAME，避免多跳解析延迟和潜在冲突
• TTL建议设为300秒（5分钟）：方便后续切换服务器时快速生效；稳定后可调高至3600秒节省查询压力
• 不要在同一个域名下同时设置A和CNAME——DNS协议禁止这种冲突配置

CNAME记录：别名转发的“重定向开关”

CNAME不直接指IP，而是把一个域名“等同于”另一个域名。它适合用于需要统一管理或对接第三方服务的场景，但有明确限制。

IntoDNS.ai

免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。

下载

• 典型用法：把 cdn.example.com 指向某CDN厂商提供的域名（如 a12345.cloudfront.net）
• 也可用于归一化：让 www.example.com CNAME到 example.com，再由后者走A记录
• 关键限制：CNAME不能和MX、TXT、NS等其他记录共存于同一主机名下；例如，example.com 本身不能设CNAME，否则MX邮件配置会失效
• 链式CNAME（A→B→C）尽量避免，超过2级可能导致部分解析器截断或超时

MX记录与邮件安全三件套：确保邮件能进能出

只要域名要收发邮件，MX就是必配项；而SPF、DKIM、DMARC这三项TXT记录，则是防止被标记为垃圾邮件、提升投递率的关键。

• MX记录目标必须是**完整域名**（结尾带点），如 mail.example.com.；不能是IP，也不能是CNAME别名
• 至少配两条MX，优先级不同（如10和20），实现主备容灾
• SPF记录示例："v=spf1 ip4:192.0.2.100 include:_spf.google.com ~all"，其中 ~all 表示软失败，适合初期调试
• DKIM需先生成密钥对，再将公钥以TXT形式发布在 selector._domainkey.example.com（如 mail._domainkey.example.com）
• DMARC建议从 v=DMARC1; p=none; rua=mailto:postmaster@example.com 开始，收集报告后再逐步收紧策略

NS记录与TTL管理：掌控解析权与更新节奏

NS记录决定“谁来管这个域名的DNS”，而TTL控制“别人缓存你记录多久”。这两项看似后台，却直接影响迁移灵活性和故障恢复速度。

• 更换DNS服务商（如从阿里云换到Cloudflare）时，必须在注册商后台修改NS记录，指向新服务商提供的NS地址（如 ns1.cloudflare.com）
• NS记录通常默认配2–4条，不可删减；少于2条会显著降低解析可用性
• TTL不是越小越好：设成60秒虽能秒级生效，但会大幅增加全球DNS查询负载，可能触发限流；日常建议300–1800秒平衡
• 计划变更前，可提前24小时将TTL调低，变更完成后再调回，减少过渡期不确定性