An MX record is a DNS record that names the mail servers willing to accept mail for a domain, with a preference number for each. Its job happens entirely on the receiving side: a sender looks up the recipient's domain and finds out where to connect.
How is an MX record used?
At the moment of delivery, by the sending server, on the recipient's domain.
RFC 5321, the SMTP standard, describes the lookup:
The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found, the resulting name is processed as if it were the initial name. If a non-existent domain error is returned, this situation MUST be reported as an error. If a temporary error is returned, the message MUST be queued and retried later. If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.
That last clause is the one worth remembering: a domain with no MX record but an address record can still receive mail, because the address record is used as an implicit MX. This is the "fallback to A" behaviour, and it is in the standard rather than being a quirk of any one implementation.
What do the preference numbers mean?
Priority, counted downwards, with a tie-breaking rule that is easy to get wrong.
MX records contain a preference indication that MUST be used in sorting if more than one such record appears (see below). Lower numbers are more preferred than higher ones. If there are multiple destinations with the same preference and there is no clear reason to favor one (e.g., by recognition of an easily reached address), then the sender-SMTP MUST randomize them to spread the load across multiple mail exchangers for a specific organization.
So a set of records at 10, 20 and 30 is a failover chain, and a set all at 10 is a load-balanced pool. Publishing three records at three different preferences when you meant to share load will send everything to one server until it stops answering.
Two more constraints trip people up. An MX target has to resolve to an address record, and the standard specifically excludes pointing an MX at a name that returns a CNAME. And a sending server is required to try more than one target where they exist: "In any case, the SMTP client SHOULD try at least two addresses."
Do I need an MX record to send email?
No. Nothing in the sending path consults your MX record.
When you send to someone@example.org, the receiving server accepts or refuses your connection based on your IP, your authentication and its own policy. It looks up MX for example.org, which is its own domain, not yours. Your MX record is not part of the transaction.
This is genuinely different from SPF, which the receiver does query on your domain, and from reverse DNS, which the receiver checks on your sending IP. Those two are sender-side records. MX is not.
Then why does advice keep telling me to publish one?
Because a domain that sends and cannot receive causes problems that are not about the SMTP handshake.
- Bounces have to land somewhere. Delivery failures are addressed to your envelope sender. On a managed platform that hostname is handled for you, which is what Bird's bounce domain record does, so this obligation is met without an MX record at your apex.
- Replies go to a real address. A recipient answering your transactional mail sends to your From or Reply-To domain, and if nothing accepts mail there the reply bounces to them, not to you.
- Role addresses are expected to work.
postmaster@andabuse@on a domain that sends are how a receiving operator contacts you about a problem, and an unreachable one turns a solvable complaint into a block. - Some receivers score it. A sending domain that refuses mail is a pattern common in throwaway spam domains, and while nobody publishes a rule about it, it is a cheap thing to get right.
If you want to accept mail programmatically rather than into mailboxes, an inbound email API is the alternative shape, and Bird's receiving email guide covers the records for it.
What about the subdomain I send from?
It usually needs no MX record of its own.
A common and sound setup is to send marketing mail from a subdomain while the apex handles the company's real mailboxes. The subdomain needs its authentication records and a return path; it does not need to accept mail, because the addresses people reply to and complain to live at the apex. How to structure email subdomains covers why that separation is worth having in the first place.