mx.targets_resolvable Reviewed July 2026

Quick fix

Confirm which MX targets are still required by the active mail platform.

What this finding means

SecuTest resolves the A and AAAA records of every non-null MX target. The check fails when one or more targets return no usable address. The result proves broken routing, not that an attacker can claim the target.

Interpretation boundary Use the exact evidence in your report. SecuTest reports externally observable conditions; it does not assume ownership, exploitability, compromise, or business intent when those cannot be proven remotely.

Associated attack or threat scenario

Threat type Mail denial of service and stale-route hijacking risk

How the attack or failure scenario works

SMTP senders must resolve an MX hostname before connecting. An unresolvable target causes delayed or failed delivery. If the target belongs to a retired third-party service and can be re-registered or reclaimed, an attacker could potentially receive mail addressed to the domain; that takeover scenario requires separate provider-specific evidence.

Conditions and limitations

  • At least one published MX target has no A or AAAA address.
  • Senders select the broken target based on MX priority or fallback behavior.
  • Mail interception additionally requires the target or its parent service to be claimable by an unauthorized party.

Why it matters

Security and business impact An MX target that does not resolve cannot receive mail and may indicate stale infrastructure or, in some provider-specific cases, a takeover opportunity.

Step-by-step fix

Where to make the change

  • The authoritative DNS zone for the registrable domain.
  • The outbound or inbound mail platform when sender authorization, signing, or routing is involved.
  • The DMARC reporting mailbox or reporting service when aggregate reports are required.

Remediation procedure

  1. Confirm which MX targets are still required by the active mail platform.
  2. Correct typographical errors or restore the missing provider DNS record when the service is valid.
  3. Remove retired or unauthorized MX entries from the authoritative zone.
  4. If a third-party tenant was deleted, verify account ownership and rotate credentials or routing rules before restoring the target.

Commands and configuration examples

Replace example values with the hostname, selector, IP address, port, provider, or policy values shown in your SecuTest evidence. Review every example before production use.

Resolve all MX targets
for h in $(dig +short MX example.com | awk '{print $2}' | sed 's/\.$//'); do echo "== $h =="; dig +short A "$h"; dig +short AAAA "$h"; done

Verify the fix

  1. Run `dig +short MX example.com` to list targets.
  2. Resolve each target with `dig +short A target.example.net` and `dig +short AAAA target.example.net`.
  3. Test SMTP reachability only against systems you own or are authorized to assess.
  4. Send an external message and verify delivery through the intended highest-priority server.
Confirm the externally visible result

After DNS, CDN, certificate, mail, or application propagation completes, run a fresh SecuTest scan and compare the new evidence with the original finding.

Re-scan your domain

Common mistakes

  • Removing a backup MX without confirming its disaster-recovery role.
  • Assuming NXDOMAIN automatically proves that the hostname can be taken over.
  • Testing only from an internal resolver that uses split-horizon DNS.

Authoritative references