Monitor SPF, DMARC, DKIM, and MX Records Continuously

Mail Authentication Records Break Quietly

You set up SPF and DMARC correctly. Months later a client calls: "Our emails are going to spam." SSL certificates have an obvious countdown; mail authentication does not. The failure is almost always discovered after the damage is done.

Common breakage patterns:

• Editing SPF and accidentally removing the v=spf1 prefix -- the record stops being recognized at all
• Adding a new email SaaS pushes the SPF lookup count past 10 -- RFC 7208 treats this as permanent failure
• Trying out DMARC p=quarantine but forgetting the p= tag itself -- the record becomes invalid
• Rotating a DKIM selector and forgetting to publish the new TXT record -- every signature verification fails
• Leaving a temporary MX hostname in place after a migration test -- deliverability silently degrades

Agencies managing dozens of client domains cannot live inside every DNS console. You need a system that confirms "the record is still correct, right now" -- not just "it was correct when we set it up."

Four Authentication Types to Monitor

The 2026-06-01 release of Miterl adds four new monitor types for mail authentication.

The key point is that Miterl validates syntax, not just record existence. If the record resolves but violates the RFC, the monitor is treated as Down. Subtle errors like DMARC pct=120 are caught by the internal RFC 7489 range checks.

Creating Monitors via the API

Mail authentication monitors live on the same Monitor resource as HTTP and SSL monitors. Set type to mx, spf, dmarc, or dkim.

MX monitor

# MX monitor -- checks every 5 minutes
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "example.com MX",
    "type": "mx",
    "url": "example.com",
    "interval_seconds": 300
  }'

url is the apex domain without a scheme (same convention as WHOIS monitors). The monitor goes Down when MX records are missing or unresolvable.

SPF monitor

# SPF monitor -- validates v=spf1, the all terminal, and ≤10 lookups
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "example.com SPF",
    "type": "spf",
    "url": "example.com",
    "interval_seconds": 300
  }'

Multiple v=spf1 records, a missing v=spf1 prefix, a missing all terminal, or include + a + mx lookups that sum to 11 or more all count as syntax violations and trigger Down.

DMARC monitor

# DMARC monitor -- validates p=, pct range, and rua/ruf URI format
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "example.com DMARC",
    "type": "dmarc",
    "url": "example.com",
    "interval_seconds": 300
  }'

p= is required, pct must be 0-100, adkim/aspf must be r or s, and rua=/ruf= must be mailto: or https: URIs. Anything that violates RFC 7489 puts the monitor into Down.

DKIM monitor (multi-selector)

# DKIM monitor -- bundle up to 5 selectors into one monitor
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "example.com DKIM",
    "type": "dkim",
    "url": "example.com",
    "interval_seconds": 300,
    "dkim_selectors": ["selector1", "selector2", "google"]
  }'

dkim_selectors accepts up to 5 entries. Miterl queries TXT at {selector}._domainkey.{url} for each selector and validates v=DKIM1 / p=<public key>. An empty p= (revoked key) or a base64 value that fails decoding flips the monitor to Down immediately. This lets you watch Google Workspace (google), SendGrid (s1, s2), Mailgun, and others under a single monitor without per-selector noise.

From the dashboard

If you prefer the UI, the monitor creation form now lists MX / SPF / DMARC / DKIM in the type dropdown. Selecting DKIM reveals a "DKIM selectors" tag input where you press Enter to add each selector your ESPs use.

Agency Workflow Example

For agencies running ongoing maintenance contracts, mail authentication belongs in the same playbook as SSL.

1. At client onboarding, register MX / SPF / DMARC immediately -- you find out on day one whether the existing setup is sane
2. Add DKIM monitors when ESPs change -- while selectors are still fresh in mind
3. Funnel alerts into Slack or Chatwork -- see Slack and Chatwork alert setup for the config
4. Include mail authentication status in the monthly report -- a direct way to show maintenance value

The classic "emails aren't arriving" complaint can take half a day to triage when you have to verify deliverability end-to-end. If the authentication monitors are Up, at least the DNS layer is healthy -- that alone sharpens the first response considerably.

Spot-Check Commands for Existing Domains

Useful for onboarding sanity checks or periodic audits of domains already under maintenance:

# MX
dig +short MX example.com

# SPF (extract TXT records starting with v=spf1)
dig +short TXT example.com | grep -E '"v=spf1'

# DMARC
dig +short TXT _dmarc.example.com

# DKIM (when you know the selector)
dig +short TXT selector1._domainkey.example.com

Run these once, register the domain in Miterl, and from then on you get notified the moment anything changes.

Listing All Authentication Monitors at Once

When you manage many domains, the API surfaces "which auth records are currently broken" in a single call.

# Filter for mail authentication monitor types only
curl -s "https://miterl.com/api/v1/monitors?per_page=100" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  | jq -r '.data[]
      | select(.type == "spf" or .type == "dmarc" or .type == "dkim" or .type == "mx")
      | "\(.type)\t\(.name)\t\(.status)"'

Anything marked down is either a syntax violation or a DNS publishing failure. Cross-reference down_at with your DNS change history to pinpoint the offending edit fast.

How This Fits with Other Uptime Monitors

Mail authentication is an independent set of monitor types alongside HTTP / SSL / WHOIS / DNS. The reference table in "The basic monitor types: HTTP, Ping, DNS, SSL explained" still applies; combine it with the suggested coverage below.

SPF and DMARC have the highest return on the lowest setup effort, because catching just the syntax breakage prevents many real-world deliverability disasters. Start with those two and expand as needed.

FAQ

How is a domain with two separate SPF records detected?

RFC 7208 allows only one v=spf1 record per domain. Miterl flips the monitor to Down as soon as more than one is observed, with multiple v=spf1 records in the error message. Some receiving MTAs silently use only the first match, so even if mail looks like it is going through, you should remediate quickly.

What's the right monitoring setup during DKIM key rotation?

Add both the old and the new selector to dkim_selectors, then remove the old selector once rotation is complete. While both are in play either may be used to verify signatures; keeping both in the monitor guarantees Miterl observes the same state your recipients do.

How do I avoid false positives during DNS migration?

Use the maintenance window feature the same way you would for planned outages -- silence alerts during the window. Checks keep running, so if the migration overruns the window you still notice.

Wrap-up

Mail authentication is one of those areas you cannot "set and forget." DNS edits and ESP changes silently break it, and the discovery vector is almost always an angry client.

• Auto-validating MX / SPF / DMARC / DKIM syntax catches breakage the instant it happens
• DKIM supports up to 5 selectors per monitor, so ESP combinations stay manageable
• Putting auth monitoring in the maintenance plan accelerates "emails aren't arriving" triage
• Reporting status monthly makes maintenance value visible to clients

For pre-launch domain checks, see "Pre-launch monitoring checklist". For the SSL counterpart, see "How to Prevent SSL Certificate Expiry Disasters". Setup details live in the documentation, pricing details in the FAQ, and you can start trying things out from the free signup. Recent releases are listed in the changelog.