# 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

```
POST https://api.dnsradar.dev/monitors

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:

```
POST https://api.dnsradar.dev/monitors

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:

```
POST https://api.dnsradar.dev/monitors

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:

```
POST https://api.dnsradar.dev/monitors

domain: piedpiper.com
  record_type: MX
  expected_value: ["10 mx1.mail-provider.com", "20 mx2.mail-provider.com"]
  is_exact_match: false
```

> ⚠️ **WARNING:** **Priority Format**: When specifying priorities, use the format `"<priority> <hostname>"`. The priority must be the first part, followed by a space, then the hostname.

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

> 🚨 **DANGER:** **All or Nothing**: You must be consistent within each monitor. Either specify priorities for all MX records or for none. Mixing formatted records causes validation errors.

Invalid configuration (mixed formats):
```json
{
  "expected_value": ["10 mx1.mail-provider.com", "mx2.mail-provider.com"]
  // ❌ Inconsistent: one with priority, one without
}
```

Valid configurations:
```json
// 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

> ℹ️ **INFO:** **Priority Independence**: The `is_exact_match` parameter only controls whether additional MX records are allowed. It doesn't affect priority validation, which is controlled by whether you include priorities in `expected_value`.


## 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:

```
POST https://api.dnsradar.dev/monitors/bulk

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

- [Flexible A/AAAA Record Matching](/docs/a-aaaa-flexible-matching)
- [Flexible SPF Record Matching](/docs/spf-flexible-matching)
- [Configure webhook notifications](/docs/configure-webhooks)