MX record checker

That MX records exist at all. A domain with none does not receive mail through the normal path, which is correct for a domain that only sends and a serious defect for one that does not.

That each published exchanger is a well-formed hostname rather than an address, since an MX naming an address directly is invalid and handled inconsistently.

That each exchanger resolves to a real address. This is the check that catches the silent bounce.

That at least two exchangers accept mail, so an outage on one host delays rather than rejects.

That each exchanger's address has a reverse DNS name, which many receivers require before accepting mail from it.

A domain with no MX at all produces an immediate, visible failure. Someone notices within the day.

A domain with an MX pointing at a host that no longer resolves produces a bounce at the sending server. The sender sees it; the domain owner does not.

The usual cause is a migration where the mail platform changed and one record was left behind — often a secondary exchanger at a lower priority that nothing tested because the primary kept working.

That lower-priority record only comes into play when the primary is unavailable, which means the fault surfaces during an incident, on top of the incident.

Reverse DNS maps an address back to a name. Many receivers check it on the connecting server and reject or downgrade mail from an address that has none.

It matters for the hosts that send, which for most domains are the same hosts the MX names.

The check reports whether a reverse name exists. Whether it matches the forward name is a stricter requirement some receivers apply on top.

This is one of the few mail problems entirely in the hands of whoever controls the address block, which for a hosted platform is the provider rather than you.

At least two exchangers, each a hostname, each resolving, with priorities that reflect a real preference rather than being identical by accident.

Each exchanger's address carrying a reverse DNS name.

No exchanger belonging to a provider the domain no longer uses.

And a set you recognise — the exchangers of the platform you believe is handling your mail, with nothing else alongside them.

`email.mx.present` reports whether MX records exist. `email.mx.resolution` verifies each is a well-formed hostname that resolves.

`email.mx_targets` confirms every published exchanger resolves to a real address. `email.mx.redundancy` checks that at least two accept mail.

`email.mx.ptr` looks up the reverse DNS name of each exchanger address. `email.usage_context` establishes whether the domain looks like one that handles mail at all.

DNS is queried; no mail is sent and no SMTP connection is opened. Whether an exchanger accepts a message is outside this.

A resolving exchanger is not a working mail server. It resolves, which removes one failure mode and confirms nothing beyond it.

Priorities are reported as published. Whether they match your intended failover order is a decision only you hold.

Reverse DNS is checked for existence. Matching forward and reverse names is a stricter policy some receivers apply, and it is not asserted here.