mx.syntax Reviewed July 2026

Quick fix

Inventory the legitimate inbound mail platforms and their required MX hostnames and priorities.

What this finding means

SecuTest parses every published MX value as a numeric preference followed by a target hostname. The finding is raised when a record is malformed, has an invalid preference, or lacks a usable target. This is primarily an availability and routing-integrity defect rather than proof of active exploitation.

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 delivery disruption and routing ambiguity

How the attack or failure scenario works

SMTP senders use MX records to decide where to deliver inbound mail. A malformed record can be ignored, interpreted inconsistently, or cause delivery attempts to fail. An attacker normally cannot exploit this condition alone, but the resulting outage or inconsistent routing can support impersonation and social-engineering campaigns by making legitimate communication less reliable.

Conditions and limitations

  • The malformed value is published in the authoritative DNS zone.
  • External senders query the affected record and cannot identify a valid destination.
  • Material security impact generally requires an additional condition, such as a stale claimable target or users accepting alternate communication channels.

Why it matters

Security and business impact Malformed MX records can make inbound mail delivery unreliable or impossible and may send mail systems down unintended fallback paths.

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. Inventory the legitimate inbound mail platforms and their required MX hostnames and priorities.
  2. Remove malformed or obsolete MX values from the authoritative DNS zone.
  3. Publish only integer priorities from 0 to 65535 followed by fully qualified provider hostnames.
  4. Wait for the previous TTL to expire, then test delivery from an external mailbox before closing the finding.

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.

Inspect MX records
dig +short MX example.com

Microsoft 365 example
example.com. 3600 IN MX 0 example-com.mail.protection.outlook.com.

Google Workspace example
example.com. 3600 IN MX 1 smtp.google.com.

Verify the fix

  1. Run `dig +short MX example.com` and confirm every line contains a numeric preference and a valid hostname.
  2. Resolve every non-null target with `dig +short A mx.example.net` and `dig +short AAAA mx.example.net`.
  3. Send a message from an unrelated external provider and confirm it is accepted by the intended platform.
  4. Run a fresh SecuTest scan after DNS propagation.
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

  • Copying the provider hostname into the priority field or omitting the priority entirely.
  • Publishing a URL, IP address, or mailbox address as the MX target.
  • Editing a secondary DNS zone while another provider remains authoritative.

Authoritative references