Flexible MX Record Matching

MX (Mail Exchange) records direct email to mail servers. Flexible matching allows you to verify that specific mail servers are configured while permitting customers to add backup or additional mail providers.

The Need for Flexible MX Matching

When customers use your email service, they need your MX records in their DNS. But they might also want backup mail servers or use additional email services. Exact matching would trigger false alerts whenever they make these additions.

Exact Matching Limitations

curl -X POST https://api.dnsradar.dev/monitors \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "domain": "piedpiper.com",
  "record_type": "MX",
  "expected_value": [
    "mx1.mail-provider.com",
    "mx2.mail-provider.com"
  ],
  "is_exact_match": true
}'

If the customer adds a backup mail server, the DNS response becomes:

mx1.mail-provider.com
mx2.mail-provider.com
mx.backup-service.com

With exact matching, this triggers a MISMATCH alert even though your required servers are still present.

Enabling Flexible Matching

Set is_exact_match to false to verify only that your required MX records exist:

curl -X POST https://api.dnsradar.dev/monitors \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "domain": "piedpiper.com",
  "record_type": "MX",
  "expected_value": [
    "mx1.mail-provider.com",
    "mx2.mail-provider.com"
  ],
  "is_exact_match": false
}'

How Flexible Matching Works

With flexible matching enabled for MX records, DNSRadar:

  1. Verifies all MX records in your expected_value are present in the DNS response
  2. Ignores additional MX records not in your expected list
  3. Allows any priority values unless you explicitly specify them
  4. Considers the monitor VALID as long as your required servers exist

Valid MX Configurations

With the flexible configuration above, these MX record sets would all be VALID:

# Just your servers
mx1.mail-provider.com
mx2.mail-provider.com

# With backup server
mx1.mail-provider.com
mx2.mail-provider.com
mx.backup-service.com

# With multiple additional servers
mx1.mail-provider.com
mx2.mail-provider.com
mx.google.com
mx.microsoft.com

All contain your required MX records, so they pass validation.

Managing MX Priorities

MX records include priority values that determine mail server preference. You can monitor priorities or ignore them based on your needs.

Without Priorities (Default)

If you don't specify priorities, any priority value is accepted:

curl -X POST https://api.dnsradar.dev/monitors \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "domain": "piedpiper.com",
  "record_type": "MX",
  "expected_value": [
    "mx1.mail-provider.com",
    "mx2.mail-provider.com"
  ],
  "is_exact_match": false
}'

These would all match:

10 mx1.mail-provider.com, 20 mx2.mail-provider.com
5 mx1.mail-provider.com, 10 mx2.mail-provider.com
100 mx1.mail-provider.com, 100 mx2.mail-provider.com

With Priorities

To enforce specific priorities, include them in your expected values:

curl -X POST https://api.dnsradar.dev/monitors \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "domain": "piedpiper.com",
  "record_type": "MX",
  "expected_value": [
    "10 mx1.mail-provider.com",
    "20 mx2.mail-provider.com"
  ],
  "is_exact_match": false
}'

With priorities specified, the monitor validates both the hostname AND the priority value. This configuration would only match:

10 mx1.mail-provider.com
20 mx2.mail-provider.com

But NOT:

5 mx1.mail-provider.com   ❌ Wrong priority
20 mx2.mail-provider.com

Priority Consistency

Invalid configuration (mixed formats):

{
  "expected_value": ["10 mx1.mail-provider.com", "mx2.mail-provider.com"]
  // ❌ Inconsistent: one with priority, one without
}

Valid configurations:

// All without priorities ✓
{
  "expected_value": ["mx1.mail-provider.com", "mx2.mail-provider.com"]
}

// All with priorities ✓
{
  "expected_value": ["10 mx1.mail-provider.com", "20 mx2.mail-provider.com"]
}

When Monitors Trigger

A MISMATCH alert is triggered if:

  • One or more of your required MX records are removed
  • Priority values don't match (when you've specified priorities)
  • All MX records are removed
  • DNS query returns an error

Best Practices

  1. Omit Priorities for Flexibility: Unless priority order is critical, omit priorities to avoid false alerts
  2. Monitor Primary Servers Only: Focus on your critical mail servers, allowing customers to add backups
  3. Use Flexible Matching: Enable is_exact_match: false for MX monitors unless you need strict control
  4. Document Requirements: Clearly communicate to customers which MX records must remain configured

Combining with Email Authentication

Complete email infrastructure monitoring:

curl -X POST https://api.dnsradar.dev/monitors/bulk \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "monitors": [
    {
      "domain": "piedpiper.com",
      "record_type": "MX",
      "expected_value": [
        "mx1.service.com"
      ],
      "is_exact_match": false
    },
    {
      "domain": "piedpiper.com",
      "record_type": "TXT",
      "expected_value": "v=spf1 include:_spf.service.com",
      "is_exact_match": false
    },
    {
      "domain": "piedpiper.com",
      "subdomain": "_dmarc",
      "record_type": "TXT",
      "expected_value": "v=DMARC1",
      "is_exact_match": false
    }
  ],
  "group": "email-infrastructure"
}'

Next Steps