The Contact Address on Your Site Might Be Silently Bouncing

This is the quietest failure on the list. A broken password reset generates support tickets within a day. A broken inbox generates silence, and silence is exactly what an early-stage product expects to hear.

Check it in one minute

Two steps, and the first one is the whole diagnosis.

dig +short MX yourdomain.com

# no dig?
nslookup -type=MX yourdomain.com

Step two: send a real message to the address from an account somewhere else entirely — a personal Gmail, a phone. Then wait five minutes and check both the inbox you expect it in and the sending account for a bounce notification. This is the test that actually settles it, because a domain can have a perfectly good MX record pointing at a mailbox nobody has ever opened.

The implicit MX, and why "no MX" is not always "no mail"

A detail worth getting right, because a lot of advice on this subject is imprecise. If a domain has no MX record, a sending server does not immediately give up. RFC 5321 §5.1 says it falls back to the domain’s A or AAAA record and attempts delivery there — the implicit MX rule.

So yourdomain.com with no MX but an A record pointing at your web host means mail gets attempted against your web server on port 25. In practice that almost always fails: web hosts do not run an SMTP daemon, the connection is refused, and the message bounces after the sender’s retry window. But "almost always" is not "always", and it cannot be proven without connecting to the host and attempting delivery.

This is why ShipReady only reports the two cases that are provable from DNS alone: a null MX, and no MX combined with no A or AAAA record. The middle case — no MX but an address record exists — is left alone, because reporting it would mean asserting a bounce the scan cannot observe. That is the general rule the whole scanner runs on, and it is the right trade here even though it means the check is deliberately conservative. If you are in the middle case, the send-a-real-message test above is what tells you.

How a domain ends up unable to receive

• You bought the domain to host a product, not to run a mailbox. The registrar’s defaults gave you an A record and nothing else, which is correct for a website and incomplete for an email address.
• You set up transactional sending with Resend, Postmark or SendGrid. Those require SPF, DKIM and sometimes a bounce subdomain — none of which are MX records, because they are about outbound mail.
• You migrated DNS to Cloudflare or Vercel and moved the records you knew about. MX records for a mailbox nobody had used yet are easy to miss.
• You published a support address before the mailbox existed, meaning to set it up next week.
• A previous provider had a null MX set deliberately, and it survived the migration.

Every one of these is a reasonable thing to have done. The failure is not carelessness — it is that the two halves of email look like one feature and are not.

Fixing it

Decide which you actually want, because the cheap option is genuinely fine for most small products.

Option A: forwarding

If you only need to receive — you are happy to reply from a personal or shared account — a forwarding service is enough. Cloudflare Email Routing, ImprovMX, and most registrars’ built-in forwarding all do this, several at no cost. You add the MX records they give you and mail to hello@yourdomain.com lands in an inbox you already read.

The catch is replying. A reply sent from your personal account shows that account’s address, and if you configure "send as" through a provider that does not authenticate for your domain, DMARC alignment fails and your reply may be filtered. For a low volume of support mail this is usually acceptable; for anything customer-facing it is not.

Option B: a real mailbox

Google Workspace, Microsoft 365, Fastmail and Zoho all give you a genuine mailbox at your domain. You add their MX records, and their setup adds the SPF and DKIM records so mail you send from that mailbox authenticates properly. This is the option that makes replies work correctly.

1. Add the MX records your provider specifies, with the priorities they specify. Remove any old MX records — leaving a stale one pointing at a dead host means retries and delays.
2. Confirm with dig +short MX yourdomain.com that only the expected hosts are listed.
3. Send a message from an outside account and confirm it arrives.
4. Reply to it, and confirm the reply arrives and is not marked as spam.
5. Check that your SPF record now includes the new sending source, if the mailbox will send mail.

While you are checking, check the rest of the route

An address that bounces is one way to be uncontactable. There are others, and they tend to travel together:

• A contact form that posts to an endpoint whose email integration was never finished. Submit your own form and confirm something arrives.
• Different addresses on different pages — a footer saying one thing and a contact page saying another. ShipReady reports that as a contact information contradiction.
• A privacy policy with no way to reach you at all. Under GDPR a policy is expected to give data subjects a route to exercise their rights, and ShipReady reports a privacy policy with no contact route as part of the Compliance pillar.
• MX records that resolve to a host that does not exist. Reported as an unresolvable MX host.

How ShipReady detects this

ShipReady reads the contact addresses your site actually publishes — on any page it crawls, whether that is a footer on every route or a single contact page — and resolves the domain each one belongs to. When that domain publishes a null MX, or has neither an MX nor an A/AAAA record, it reports a contact address that cannot receive mail at high severity, naming the address and the reason.

It also reports a domain that sends but cannot receive at the domain level. Both are read from public DNS and your published HTML — no mail is sent, and no mailbox is probed. Scan your site free to check the address in your own footer, or read the pre-launch DNS checklist for everything else worth confirming before you point a domain at production.