MX Record Monitoring: How Agencies Catch Client Email Problems Earlier

Jordan's team launched the client site cleanly. The homepage worked, SSL was valid, the redirect plan looked fine, and everyone signed off. The next morning the client said email was broken. The website agency had not migrated mailboxes, but it had touched DNS. The new zone included the website records and missed the old MX records. From the client's point of view, the launch broke email.

MX record monitoring helps agencies catch that kind of problem earlier by watching the DNS records that tell the internet where to deliver inbound mail for a domain. If MX records are removed, pointed to an unexpected provider, changed during a migration, or left in a mixed state, email can bounce, route incorrectly, or trigger support panic.

MX monitoring is not a deliverability guarantee. It does not read mailboxes, test every mailbox rule, inspect spam filters, or prove provider health. It gives the agency visible DNS evidence: what public mail-routing records exist, when they changed, and whether the state matches the expected provider. For broader context, pair this with DNS monitoring for agencies, Inbox Pulse, and External Footprint Monitoring.

The short answer

For every domain that sends or receives business email, track:

• current MX hostnames;
• priority values;
• expected email provider;
• DNS provider or nameserver context;
• change date;
• accountable owner;
• related SPF, DKIM, DMARC, MTA-STS, and TLS-RPT records where relevant;
• status note: expected, planned migration, unknown, or needs review.

Monitoring can tell you that MX records are present, missing, or changed. The agency still needs context to know whether the change is correct. That context is the difference between a useful report and a panic alert.

Why MX records matter

MX stands for mail exchanger. MX records tell other mail systems where to deliver email for a domain. A domain can load a website perfectly while its inbound mail routing is broken. That is why MX records belong in domain operations, not just email-admin work.

Common MX destinations include:

• Google Workspace;
• Microsoft 365;
• Zoho Mail;
• Fastmail;
• hosting-provider mail;
• security gateways;
• transactional or routing services.

A website agency may not manage the mailbox platform, but it often controls DNS during launches, hosting moves, registrar cleanup, and domain portfolio maintenance. If the agency touches the DNS zone, MX records are part of the blast radius.

Where agencies get caught

MX issues usually appear around operational change, not random failure.

Website launches can recreate DNS zones. The A record and CNAME get copied. MX records are forgotten. The site launches. Email stops.

Hosting migrations can move nameservers. The new provider starts with a clean zone. Website records are added first, mail records later, or not at all.

Email migrations can leave mixed states. Old and new provider MX records overlap, priorities route mail unexpectedly, or temporary records remain long after the migration.

Registrar cleanup can reset nameservers or park a domain. That can remove MX records alongside SPF, DKIM, and DMARC records.

Client self-service edits can remove records that look unfamiliar. Clients may delete old-looking mail hosts without realizing they still route important mail.

Vendor handover can lose ownership context. A previous IT provider, freelancer, or host may know why MX records look strange, but that knowledge never reaches the agency's care plan.

The common thread is not email expertise. It is change control around public DNS.

What monitoring can prove, and what it cannot

MX monitoring can prove that public DNS showed certain MX records at a certain time. It can show that records are missing, changed, or pointed at a provider that does not match the expected note.

It can support statements like:

• "MX records are currently present and point to Microsoft 365 hostnames."
• "MX records changed after the nameserver migration."
• "No MX records are visible for a domain marked as receiving email."
• "MX records point to a provider not listed in the client notes."

It cannot prove:

• every mailbox receives mail correctly;
• spam filtering is healthy;
• sending reputation is good;
• provider-side routing rules are correct;
• mailbox licenses are active;
• Google Workspace or Microsoft 365 tenant settings are correct;
• deliverability is guaranteed.

That boundary is not pedantic. It prevents the agency from promising more than DNS evidence can support.

The MX baseline before a change

Before a website launch, DNS migration, registrar move, or email-provider transition, capture a baseline.

Record:

• all MX hostnames and priority values;
• current nameservers;
• DNS provider;
• expected mailbox provider;
• email owner or client contact;
• SPF record;
• DMARC record;
• known DKIM selectors if the client or email owner provides them;
• MTA-STS and TLS-RPT presence where relevant;
• whether the domain is expected to receive email.

This baseline gives Jordan a comparison point. It is not a rollback button. It is evidence of what existed before the change, so the right owner can restore or adjust records in the DNS provider if needed. For a portfolio-level before/after workflow, use the DNS change evidence guide to preserve snapshots, changed record groups, timestamps, and confirmation notes.

During and after email migrations

Email migrations deserve special wording because agencies are often adjacent to them without owning them.

Before migration, confirm who owns the mailbox platform and who will change DNS. Capture the existing MX records, expected target provider, rollback notes, and whether SPF, DKIM, and DMARC will be reviewed.

During migration, record the change window. Confirm the expected MX records are present. Watch for old records that remain with higher priority than intended. Ask the email owner to test sending and receiving in the mailbox platform.

After migration, update the domain record. Remove stale records only when the email owner confirms they are not needed. Add the change to the monthly report or handover note so the client does not have to reconstruct the story later.

The agency should avoid saying "email is fixed" from MX alone. Better wording is "public MX records now match the expected provider; mailbox owner confirmed mail flow." The second half matters.

Severity levels for MX findings

Use severity based on domain role and expected mail use.

Critical means MX records are missing or unexpectedly changed on a domain that receives business email. The next action is to confirm the expected provider and restore or correct records in the DNS provider.

Warning means MX records point to an unknown provider, a mixed migration state remains, or public lookup is inconsistent after a DNS move. The next action is to confirm with the email owner or client IT.

Watch means MX records changed during a planned migration. The next action is to verify that the change matches the project note and that mail flow was tested by the mailbox owner.

Informational means MX records are present on a domain not expected to receive mail, or absent on a parked domain. The next action is to document the intended state so future reviewers do not treat it as a surprise.

This keeps the response proportional. Missing MX on a primary business domain is urgent. Missing MX on a defensive parked domain may be intentional.

How MX connects to other email DNS records

MX is only one part of email-domain evidence. Agencies should connect it to the surrounding records.

SPF identifies which systems may send mail for the domain. DKIM adds signature keys through selector records. DMARC tells receivers what policy to apply and where to send aggregate reports. MTA-STS and TLS-RPT add transport-security policy and reporting signals. BIMI may appear where the domain has brand-indicator requirements.

A domain can have correct MX records and still have weak sending authentication. A domain can have strong DMARC and still route inbound mail incorrectly. That is why email DNS records checklist for agencies, DMARC, SPF, and DKIM agency ops, and TLS-RPT record explained sit beside this guide.

What to put in a client report

Clients need a plain-English account of risk, not a DNS lecture.

Useful report wording:

"MX records changed during the Microsoft 365 migration and now point to the expected provider. Client IT confirmed mail flow after the change."

"MX records changed without a matching project note. Agency recommends confirming whether the client recently changed email provider."

"No MX records are visible for this domain. If the domain is expected to receive business email, the email owner should confirm the provider and restore routing records."

"MX records are present on a parked domain. Client confirmed the domain should not receive mail; record retained for monitoring context."

Avoid unsupported wording:

"Email is guaranteed healthy."

"Deliverability is fixed."

"Microsoft 365 is configured correctly."

"No mailbox issues exist."

Those claims require mailbox-provider evidence, tenant settings, logs, or deliverability diagnostics that MX monitoring does not provide.

A monthly MX review routine

A lean routine is enough for most agencies.

1. Identify domains that receive business email.
2. Capture expected provider and owner for each domain.
3. Monitor current MX records.
4. Flag missing, changed, or unknown-provider records.
5. Pair MX review with SPF, DMARC, MTA-STS, and TLS-RPT review where relevant.
6. Add project notes for planned migrations.
7. Include material changes in monthly domain health reporting.
8. Resolve unknowns with the client or email owner.

This does not require the agency to become the client's mail administrator. It requires the agency to stop treating mail-routing DNS as someone else's invisible problem when it controls the zone.

How CertPilot fits

Inbox Pulse checks public email-authentication DNS signals across domains, including MX, SPF, DMARC, MTA-STS, TLS-RPT, and BIMI. External Footprint Monitoring keeps DNS, SSL, RDAP/domain-expiry, and email-authentication evidence in the wider domain-health context. The methodology page explains the public-check approach.

The boundaries stay strict:

• CertPilot does not scan mailboxes.
• CertPilot does not read message bodies, headers, or inbox contents.
• CertPilot does not connect to Google Workspace or Microsoft 365 today.
• CertPilot does not prove deliverability or provider-side mailbox health.
• CertPilot does not edit, restore, or roll back DNS records.
• CertPilot does not guarantee compliance, certification, or audit outcomes.

That makes it a monitoring and evidence layer, not a mail platform. The agency still uses the DNS provider, mailbox platform, and client owner to make changes. CertPilot helps make the public state visible and reportable.

Example before-and-after DNS notes

A useful MX note should explain the state without pretending to know more than DNS can show.

Before a launch: "Baseline captured on 2026-07-20. Domain receives mail. MX points to Google Workspace hostnames. Client IT owner: Priya. SPF and DMARC present. DKIM selector list not confirmed by client. Nameservers currently at provider A."

After a DNS migration: "Checked on 2026-07-24 after nameserver move. MX still points to Google Workspace hostnames and priority values match baseline. SPF and DMARC still present. Client IT confirmed mail flow."

Problem state: "Checked on 2026-07-24 after launch. No MX records visible, but domain is marked as receiving business mail. Escalated to client IT and DNS owner. Do not claim mailbox outage from DNS alone; confirm provider state."

Mixed state: "MX includes old hosting provider and Microsoft 365 records. Migration note says Microsoft 365 should be target provider. Ask email owner whether old host records should remain."

Those notes are short, but they preserve context. A month later, Jordan can explain what changed, when, and who was asked to confirm it.

Agency handoff packet for email DNS

When an agency hands a domain project back to the client, include a small email-DNS packet.

The packet should include current MX records, expected provider, DNS provider, nameservers, email owner, SPF record, DMARC record, known DKIM selector status, MTA-STS and TLS-RPT presence where relevant, and the date checked.

It should also include boundary wording:

"This packet records public DNS configuration. It does not prove mailbox health, spam filtering, deliverability, tenant settings, or provider-side routing. The mailbox owner should confirm live sending and receiving."

That boundary protects the agency and helps the client route the right work. DNS evidence belongs with the agency if the agency touches DNS. Mailbox validation belongs with whoever owns the mailbox platform.

When to involve the client or mailbox owner

Escalate to the client or mailbox owner when:

• MX records are missing on a domain expected to receive mail;
• MX points to a provider nobody recognizes;
• a migration creates mixed old and new provider records;
• mail records changed without a project note;
• SPF, DMARC, MTA-STS, or TLS-RPT findings suggest adjacent email-authentication review;
• the client asks whether mail is actually flowing.

The last case matters. Public DNS cannot answer live mailbox-flow questions by itself. It can narrow the investigation and show whether public routing records look plausible. The mailbox owner must confirm provider-side behavior.

Why MX belongs in domain governance

MX is not only an email-admin detail. It is part of domain governance because it answers what a domain is used for and who depends on it.

A domain with no website but active MX may still be business-critical. A parked domain with no MX may be intentionally inactive. A campaign domain with MX might indicate a vendor or tool sends mail from it. A domain with old MX records can reveal a forgotten mailbox dependency.

That is why MX records should sit beside domain owner, purpose, lifecycle status, renewal decision, DNS provider, and sending-source notes. The record should answer: does this domain receive mail, who owns that fact, and what would break if the DNS changed?

A small audit question that catches big mistakes

For each domain, ask one simple question: "If this domain stopped receiving email tomorrow, who would notice first?" If the answer is the client, the agency has a monitoring gap. If the answer is the mailbox owner, record that owner. If the answer is nobody, the domain may be parked, legacy, or unmanaged — and that lifecycle state should be explicit.

This question keeps MX monitoring tied to operational reality. A technically valid MX record still needs an owner, and a missing MX record is only urgent when the domain is supposed to receive mail.

In short

• MX records route inbound mail and can break during DNS, hosting, registrar, or email migrations.
• Monitoring should track current MX records, expected provider, owner, change date, and status note.
• MX evidence can show public routing state; it cannot guarantee deliverability or mailbox health.
• Pair MX monitoring with SPF, DKIM, DMARC, MTA-STS, and TLS-RPT review.
• Report findings in plain language and avoid unsupported "email is healthy" claims.
• CertPilot reads public DNS evidence; it does not scan mailboxes, connect to Workspace or M365, or edit DNS.

Frequently Asked Questions

What is MX record monitoring?

MX record monitoring is the process of tracking the public DNS records that route inbound email for a domain. It helps agencies see whether mail-routing records are present, missing, changed, or pointed to an unexpected provider.

Can MX records break a website?

Usually no. MX records affect email routing, not the website itself. The risk is that website and DNS projects often touch the same DNS zone, so a website migration can accidentally remove or alter mail records.

Does MX monitoring guarantee deliverability?

No. MX monitoring helps detect routing configuration risk. Deliverability also depends on sender authentication, reputation, mailbox-provider rules, spam filtering, content, and recipient behavior.

Should agencies monitor MX records for every client domain?

At minimum, monitor MX records for domains that receive business email, send transactional mail, support campaigns, or sit inside a care plan. Parked or defensive domains should still have an intentional documented state.

Does CertPilot connect to Google Workspace or Microsoft 365?

No. CertPilot does not connect to Google Workspace or Microsoft 365 today and does not inspect mailboxes. Inbox Pulse and External Footprint Monitoring read public DNS records only.