An outgoing application and an incoming mailbox can use different domains. The records that route replies do not have to sit on every subdomain used for sending.
How does a sending server use MX records?
The sending server looks up the recipient's domain to find the servers that accept its incoming mail.
For person@example.org, it looks up MX records for example.org. Each record names a destination server whose hostname resolves to an IP address.
RFC 5321 defines this lookup process for SMTP.
The sending server reports an error when the recipient domain does not exist. After a temporary lookup failure, it queues the message for a later attempt.
What happens when a domain has no MX record?
If no MX records exist, SMTP treats the domain itself as the destination and tries its address records.
This implicit MX has preference zero. There is no explicit MX list to outrank it, so delivery proceeds to the domain's own address when usable.
This fallback applies to an empty MX list. It does not rescue a domain whose published MX records are unusable.
A null MX is a different instruction: RFC 7505 defines an explicit record declaring that the domain accepts no mail. An absent record permits fallback. A null MX refuses delivery.
What do MX preference numbers mean?
Lower preference values identify the destinations a sender should try first.
With values 10, 20 and 30, the destination at 10 is preferred. The others provide alternatives if delivery cannot proceed there. Giving every destination the same value instead permits distribution among equal-preference choices.
Under RFC 5321, sending servers must randomize equal-preference destinations unless there is a clear reason to favor one. Equal preferences do not promise an exact division of traffic.
Point your MX record to a hostname whose address you publish so senders can connect. Use an A record for its IPv4 address or an AAAA record for IPv6. Do not use a CNAME alias as the destination. The alias prevents DNS from including the address with its MX answer. That adds lookups, as RFC 2181 explains.
SMTP clients must support trying alternative destinations. The specification recommends trying at least two addresses when available. A failure at the first then need not end delivery attempts.
Do you need an MX record to send?
SMTP does not require an explicit MX record on your domain merely to originate a message.
The delivery lookup uses the recipient domain. Your sending domain still needs valid DNS and authentication appropriate to the receiver's requirements. A receiver can apply its own checks to the sender domain.
A missing MX record therefore does not mean that an unreachable sender domain is acceptable to every receiver.
Where do delivery failures go?
Delivery failures go to the envelope sender, the address supplied for failure notices during SMTP delivery.
Where do replies go?
Replies normally use Reply-To when present, otherwise the visible From address.
A sending subdomain need not host every company mailbox. For example, news.example.com can send while replies go to a working address at example.com. Make that routing choice explicit in the message's addresses.
Where do operational reports go?
Operational addresses such as postmaster@ and abuse@ give other operators a way to report delivery or abuse problems.
Under RFC 5321, an SMTP server that relays or delivers mail must accept postmaster@ for its served domains. This supplies a contact for mail-service problems.
RFC 2142 requires organizations to support role mailboxes where the corresponding function exists. For example, an Internet service provider must support abuse@ at its organizational domain. This routes complaints to the responsible team.
How do you receive email with Bird?
You enable receiving for a domain and publish the MX records Bird returns.
The API's inbound.enabled field accepts true to enable receiving or false to disable it. Publishing the records alone does not enable the capability.
After verification, mail addressed to that domain becomes inbound messages. Use a dedicated receiving subdomain because replacing your company domain's MX records changes where its existing mail arrives.
Bird's return-path record handles delivery-failure notices separately from those inbound MX records. The receiving guide explains domain setup. The bounce-domain guide explains failure handling.
In short
MX records route incoming mail.
The sending server looks up the recipient domain to find a destination.
Missing MX records can fall back to addresses.
When no MX records exist, the sending server can use the domain's address records.
Lower preference values are tried first.
Equal-preference destinations are randomized when there is no reason to favor one.
Sending and receiving need separate decisions.
Outgoing mail still needs appropriate handling for delivery failures, replies and operational contact addresses.