# Flexible DMARC Record Matching

DMARC (Domain-based Message Authentication, Reporting, and Conformance) records define email authentication policies. Flexible matching for DMARC records allows you to verify essential DMARC components are present while giving customers flexibility to adjust policy settings.

## Understanding DMARC Monitoring

DMARC records are TXT records published at the `_dmarc` subdomain. They control how email servers handle authentication failures and where to send reports.

Example DMARC record:
```
v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@example.com; adkim=s; aspf=s
```

## The Flexibility Problem

With exact matching, any policy adjustment triggers an alert:

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

domain: piedpiper.com
  subdomain: _dmarc
  record_type: TXT
  expected_value: "v=DMARC1; p=reject; pct=100; adkim=s; aspf=s"
  is_exact_match: true
```

If the customer changes `pct=100` to `pct=50` or adds a `rua` tag for reports, your monitor triggers a false alert.

## Enabling Flexible DMARC Matching

Use flexible matching to verify only the DMARC components that matter to you by setting the `is_exact_match` parameter to `false`:

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

domain: piedpiper.com
  subdomain: _dmarc
  record_type: TXT
  expected_value: v=DMARC1
  is_exact_match: false
```

> ℹ️ **INFO:** **DMARC Version Required**: Include `v=DMARC1` in your `expected_value` to indicate DMARC-specific matching rules should apply.

## How Flexible Matching Works

With `is_exact_match: false` for DMARC records, DNSRadar:

1. Verifies the record starts with `v=DMARC1`
2. Checks that all tags in your `expected_value` are present
3. Ignores additional tags or modified tag values not in your expected value


## Valid DMARC Variations

With the flexible configuration above, these DMARC records would all be VALID:

```
v=DMARC1; p=none
v=DMARC1; p=quarantine; pct=50
v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@example.com
v=DMARC1; p=reject; rua=mailto:reports@example.com; adkim=s; aspf=s
```

All contain the required `v=DMARC1` version tag, so they pass validation.

## Monitoring Specific DMARC Tags

Require specific DMARC policy tags while allowing others to vary:

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

domain: piedpiper.com
  subdomain: _dmarc
  record_type: TXT
  expected_value: "v=DMARC1; p=reject"
  is_exact_match: false
```

This ensures the customer maintains a `p=reject` policy while allowing them to adjust reporting addresses, percentages, and alignment modes.

## Enforcing Strict Alignment

Require strict DKIM and SPF alignment:

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

domain: piedpiper.com
  subdomain: _dmarc
  record_type: TXT
  expected_value: "v=DMARC1; adkim=s; aspf=s"
  is_exact_match: false
```

This configuration ensures both `adkim=s` (strict DKIM alignment) and `aspf=s` (strict SPF alignment) are present, regardless of other DMARC settings.

## When Monitors Trigger

A `MISMATCH` alert is triggered if:

- The DMARC record is removed
- The `v=DMARC1` version tag is missing
- Required tags from your `expected_value` are removed


> ✅ **SUCCESS:** **Policy Evolution**: Flexible matching allows customers to gradually strengthen their DMARC policy from `p=none` to `p=quarantine` to `p=reject` without triggering alerts if you're only monitoring for DMARC presence.


## DMARC Tag Reference

Common DMARC tags you might want to monitor:

| Tag | Purpose | Example |
|-----|---------|---------|
| `v` | Version (required) | `v=DMARC1` |
| `p` | Policy for domain | `p=reject` |
| `sp` | Policy for subdomains | `sp=quarantine` |
| `pct` | Percentage of messages to filter | `pct=100` |
| `rua` | Aggregate report URI | `rua=mailto:dmarc@example.com` |
| `ruf` | Forensic report URI | `ruf=mailto:forensic@example.com` |
| `adkim` | DKIM alignment mode | `adkim=s` (strict) |
| `aspf` | SPF alignment mode | `aspf=r` (relaxed) |

## Best Practices

1. **Start with Basic Monitoring**: Begin by monitoring for `v=DMARC1` presence only
2. **Gradually Add Requirements**: As customers mature their email authentication, add policy requirements
3. **Allow Reporting Flexibility**: Don't enforce specific `rua` or `ruf` values unless necessary
4. **Document Expectations**: Clearly communicate DMARC requirements to customers
5. **Combine with SPF/DKIM**: Monitor DMARC alongside SPF and DKIM for comprehensive email security

## Monitoring Email Authentication Stack

Complete email authentication monitoring:

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

monitors:
    - 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
    - domain: piedpiper.com
      subdomain: default._domainkey
      record_type: TXT
      expected_value: "v=DKIM1; k=rsa"
      is_exact_match: false
    - domain: piedpiper.com
      record_type: MX
      expected_value: ["mx1.mail-provider.com", "mx2.mail-provider.com"]
      is_exact_match: true
  group: email-authentication
```

## Next Steps

- [Flexible SPF Record Matching](/docs/spf-flexible-matching)
- [Flexible MX Record Matching](/docs/mx-flexible-matching)
- [Configure webhooks for email security alerts](/docs/configure-webhooks)