DKIM · TXT
selector._domainkey.mail.examplePublish the workspace-generated selector and value.
EmailDomains
Sending domains.
A name they can trust.
Give your email a recognisable, authenticated identity. Follow the DNS records, verification checks, and alignment behind a confident first send.
Know which record needs your attention.
See which sending-domain records are ready and what to configure next. Follow an example from DNS setup to an authenticated sender.
mail.example / FICTIONAL DNS CHECK01 02 03
Return-path · CNAME
send.mail.exampleBounce handling; SPF follows the generated CNAME.
DMARC · TXT
_dmarc.mail.exampleA valid DMARC policy covering the From domain.
Tracking CNAME is optional. Receiving MX is separate; keep an existing corporate MX unchanged unless you intend to change receiving.
Not inspected. Run the current selection to see the illustrative status.
Outside this basic example. It accepts only v=DMARC1 and one p value: none, quarantine or reject. Other valid tags need the full guide; this result is not a general DMARC validator.
Records are still propagating in this example. Keep readiness pending and recheck the actual verification result later.
Return-path CNAME is missing. Publish the exact generated target before rechecking sending readiness.
DMARC alignment needs attention. Compare the authenticated identities with the From domain; DKIM ownership alone does not establish alignment.
Example records are verified. This is not a live DNS check, delivery guarantee or inbox-placement test.
Cloudflare: enter the correct host label and keep the return-path CNAME DNS only.
Route 53: use the correct hosted zone and the exact generated record names and values.
Check whether your provider appends the zone name before entering a fully qualified host.
Companies that trust Bird across their communications.
Read Bird customer storiesDifferent records. Different responsibilities.
Start with your domain.
DKIM signs the message, SPF identifies authorized sending infrastructure, and DMARC evaluates alignment with the From domain. Publish the exact generated records before checking verification.
Understand authentication ↗Plan the transition.
Register and verify the sending identity in the intended workspace and region. Receiving MX is a separate choice; changing it can affect where incoming mail goes.
Set up a sending domain ↗无需手动翻查 DNS 记录，即可完成身份验证。
在 Bird Email API 上，可送达性从发件域名开始。Bird 生成记录、在边缘签名，并在域名失去对齐的那一刻通知你。身份认证成为一个设置步骤，而非持续的排查工作。
通往已签名域名的五个步骤。
我们生成所有记录。您只需发布一次，我们持续为您保持验证状态。
几分钟内添加一个域名。
在你的服务商处粘贴生成的 DNS 记录并点击验证。大多数会在传播后的几分钟内完成。
DKIM 签名、SPF 对齐和 DMARC。
Bird 使用 DKIM 签名，并验证 return-path 和 DMARC 记录。如需在支持的收件箱中显示品牌标志，请发布您自己的 BIMI 记录并满足提供商的要求。
为每个发送流使用独立域名。
为事务性邮件和营销邮件分别使用不同域名，或为每个品牌各设一个域名，各自积累独立信誉。您的工作区会显示当前的域名配额。
针对记录本身的工具。
对域名的实时 DMARC、SPF、DKIM、BIMI 和 MX 记录进行评估，获取失败项及原因。粘贴 DMARC 聚合报告，即可获得通俗易懂的解读。两项功能适用于任何域名，无需密钥。
对子域名友好。
从专用子域名发送，将你的发送声誉与企业邮件隔离开来。
一条命令，搞定所需的全部记录。
从仪表盘、API 或 CLI 添加域名。Bird 会返回需要发布的精确记录：一个用于签名邮件的 DKIM 密钥、一条无需改动你的顶级域记录即可对齐 SPF 的 return-path CNAME、一条 DMARC 记录，以及一条用于品牌化打开和点击链接的可选 tracking CNAME。然后它会替你完成验证。
bird email domains create
bird CLI
$ bird email domains create mail.acme.com \
| jq -c '.status, (.dns_records[] | {purpose, type, host})'
"pending"
{"purpose":"dkim","type":"TXT","host":"bird1._domainkey.mail.acme.com"}
{"purpose":"return_path","type":"CNAME","host":"send.mail.acme.com"}
{"purpose":"dmarc","type":"TXT","host":"_dmarc.mail.acme.com"}
{"purpose":"tracking","type":"CNAME","host":"links.mail.acme.com"}
# Publish them, then check: bird email domains verify <domain-id>
Create a sending domain with CLI or MCP, publish its DNS records and verify again. Inspect the verification result before using the domain to send.
品牌化的打开与点击跟踪。
添加可选的 tracking CNAME，Bird 就会在你自己的域名下衡量打开和点击，而不是通过通用重定向。打开数据来自 HTML 中的像素；点击数据来自通过你品牌化主机名重写的链接，因此重定向和链接的信誉都归属于你的品牌，并通过 HTTPS 提供服务。
跟踪是独立于发送的能力。一旦 DKIM、return-path 和 DMARC 验证通过，域名即可发送，无论是否配置了 tracking 记录。打开与点击跟踪会在 CNAME 验证通过并由你开启后生效。
它默认关闭是有原因的。重写后的链接会改变收件人悬停时看到的 URL 并增加一次重定向跳转，所以对于密码重置和安全类邮件，请关闭点击跟踪——在这些场景下，一条干净的直达链接比这项指标更重要。
一次验证，长久守护。
添加域名后，Bird 会每隔几分钟检查一次，在前三天内逐渐放宽至每小时检查一次，之后稳定为每天对所有活跃域名进行一次复查。如果已验证的记录开始出现问题，该域名将保持验证状态并进入警告状态，恢复为每小时检查一次，同时通知您的工作区；只有在连续 24 小时持续失败后才会降级，而在此期间内任何一次通过检查即可清除警告。短暂的 DNS 波动不会导致您的服务中断，修复后的记录会在下次检查时自动重新验证，无需您手动操作。
在文档中深入了解。
用 发送域名指南 添加并验证域名，并在 DKIM、SPF 与 DMARC 指南 中了解这些记录的工作原理。
付诸实践。
继续查阅此主题的文档、指南和示例。资源为英文。
关于发送域名的常见问题
验证域名需要哪些记录？需要多长时间？
我们会为您生成所需记录：一条 DKIM TXT 记录用于签名邮件，一条 return-path CNAME 记录用于对齐 SPF（无需顶级域 SPF 记录），以及一条 DMARC TXT 记录。用于品牌化打开和点击链接的跟踪 CNAME 是可选的。添加域名，将记录粘贴到您的 DNS 服务商处，然后点击验证：大多数验证在 DNS 传播后几分钟内即可完成，偶尔可能需要更长时间。
DMARC 记录实际上起什么作用？
DMARC 告知接收服务器如何处理 DKIM 或 SPF 对齐失败的邮件，以及将显示谁在以您的域名发送邮件的聚合报告发送到哪里。我们要求在域名可以发送邮件之前必须设置 DMARC 记录，建议从 p=none 开始，即仅监控而不影响投递。一旦您确认所有合法来源都已对齐，再将策略收紧到 p=quarantine 或 p=reject。如果您的域名或父域名已发布了 DMARC，我们会直接使用。主要邮箱服务商现在要求批量发送者发布策略，因此拥有 DMARC 记录越来越成为大规模送达收件箱的必要条件。
我可以从子域名发送，或使用多个域名吗？
两者都可以，我们推荐使用专用子域名，因为它可以将您的邮件信誉与企业邮件隔离开来。您还可以为事务性邮件和营销邮件分别使用不同域名，或每个品牌一个域名，各自拥有独立的身份验证和信誉。
从身份验证到送达
与我们的邮件团队交流
准备好您的发送域名。
讨论身份验证、域名设置和迁移方案。您也可以直接创建账户，自行开始验证域名。
创建账户，然后添加您的域名。您需要有权访问其 DNS 记录。