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 ↗Authentication, without digging through DNS records.
Sending domains are where deliverability starts on the Bird Email API. Bird generates the records, signs at the edge, and tells you the moment a domain falls out of alignment. Authentication becomes a setup step, not an ongoing investigation.
Five steps to a signed domain.
We generate every record. You publish them once, and we keep them verified.
Add a domain in minutes.
Paste the generated DNS records at your provider and hit verify. Most resolve within minutes of propagating.
DKIM signing, SPF alignment and DMARC.
Bird signs with DKIM and verifies the return-path and DMARC records. For a brand logo in supporting inboxes, publish your own BIMI record and meet the provider’s requirements.
A domain for each sending stream.
Run separate domains for transactional and marketing, or one per brand, each carrying its own reputation. Your workspace shows the current domain allowance.
Tools for the records themselves.
Grade a domain's live DMARC, SPF, DKIM, BIMI, and MX records and get back what fails and why. Paste a DMARC aggregate report and get it read back to you in plain language. Both work on any domain, with no key needed.
Subdomain-friendly.
Send from a dedicated subdomain to isolate your sending reputation from your corporate mail.
One command, every record you need.
Add a domain from the dashboard, the API, or the CLI. Bird returns the exact records to publish: a DKIM key to sign your mail, a return-path CNAME that aligns SPF without touching your apex record, a DMARC record, and an optional tracking CNAME for branded open and click links. Then it verifies them for you.
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.
Branded open and click tracking.
Add the optional tracking CNAME and Bird measures opens and clicks under your own domain instead of a generic redirect. Opens come from a pixel in the HTML; clicks come from links rewritten through your branded hostname, so both the redirect and the link reputation stay with your brand, served over HTTPS.
Tracking is its own capability, separate from sending. A domain sends the moment DKIM, the return-path, and DMARC verify, with or without the tracking record in place. Open and click tracking switch on once the CNAME verifies and you turn them on.
It's opt-in for a reason. Rewritten links change the URL a recipient sees on hover and add a redirect hop, so leave click tracking off for password resets and security mail, where a clean direct link matters more than the metric.
Verified once, watched forever.
Right after you add a domain Bird checks every couple of minutes, backs off to hourly over the first three days, then settles into a daily re-check of every active domain. If a verified record starts failing, the domain is held verified in a warning state, re-checked hourly, and your workspace is notified; it is only downgraded after a full 24 hours of failures, and any passing check inside that window clears the warning. A transient DNS blip cannot knock you offline, and a fixed record re-verifies on the next check without you asking.
Go deeper in the docs.
Add and verify a domain with the sending domains guide, and read how the records work in the DKIM, SPF & DMARC guide.
Put it into practice.
Continue with the documentation, guides and examples for this topic. Resources are in English.
Watch the guideGetting started with emailImplementation guideSend your first emailFollow the learning pathBuild your first integration
Try the practice and get an implementation briefQuestions about sending domains
What records do I need to verify a domain, and how long does it take?
We generate the records for you: a DKIM TXT record to sign your mail, a return-path CNAME that aligns SPF (no apex SPF record required), and a DMARC TXT record. A tracking CNAME for branded open and click links is optional. Add the domain, paste the records at your DNS provider, and hit verify: most verifications resolve within minutes of DNS propagation, though it can occasionally take longer.
What does the DMARC record actually do?
DMARC tells receiving servers what to do with mail that fails DKIM or SPF alignment, and where to send the aggregate reports that show who is sending as your domain. We require a DMARC record before a domain can send, and recommend starting at p=none, which monitors without affecting delivery. Once you have confirmed every legitimate source aligns, tighten the policy to p=quarantine or p=reject. If you already publish DMARC at your domain or a parent domain, we use it as is. Major inbox providers now expect bulk senders to publish a policy, so having one is increasingly part of reaching the inbox at volume.
Can I send from a subdomain, or use more than one domain?
Yes to both, and we recommend a dedicated subdomain, since it isolates your email reputation from your corporate mail. You can also run separate domains for transactional and marketing mail, or one per brand, each with its own authentication and reputation.
From authentication to delivery
Sending
Transactional and marketing email, templates, and batch sends.
Deliverability
Authentication, IP warmup, suppression, and per-provider visibility.
Dedicated IPs
Managed dedicated IPs and pools, warmed automatically.
Email API overview
The full Email API: sending, deliverability, IPs, suppression, analytics, and broadcasts.
Talk to our email team
Get your sending domain ready.
Discuss authentication, domain setup and your migration plan. You can also create an account and start verifying a domain yourself.
Create your account, then add your domain. You will need access to its DNS records.