Overview

DMARC Reporter provides three categories of alerts — Event, Metric, and Summary — that monitor your email authentication posture and notify you when something changes or needs attention.

This guide covers what each alert type does, how to configure it, and recommended settings for domains at p=reject.

How to Create an Alert

1. Navigate to Alerts in the dashboard
2. Click New Alert
3. Alert Name — Use a descriptive name (e.g., DMARC Record Change - Production Domains)
4. Domain Selection — Choose domains individually or select by Tags to automatically include all domains sharing a tag. Tag-based selection means new domains added to the tag inherit the alert automatically.
5. Additional Emails — Add team distribution list addresses so alerts reach more than one person
6. Alert Type — Select Event, Metric, or Summary
7. Configure the trigger:
   • Event: Select the event type from the dropdown
   • Metric: Choose the metric, threshold value, and time window
   • Summary: No additional configuration needed (runs weekly)
8. Click Submit

Recommended Baseline for Reject Domains

Setting up the four required alerts takes approximately 5 minutes. Adding the recommended alerts brings total setup time to about 10 minutes for comprehensive coverage.

Alert Categories

Event Alerts

DMARC Changed

What it does: Monitors your domain's _dmarc. TXT record every 12 hours and alerts you if anything changes.

What it detects: Any modification — policy changes (p=, sp=), RUA/RUF address changes, pct modifications, alignment mode changes, or complete record deletion.

Why it matters at reject: Your DMARC record is your enforcement mechanism. A single-character change — p=reject to p=none — removes protection entirely. This can happen from accidental DNS edits, domain registrar changes, or infrastructure-as-code deployments that overwrite records. This alert catches it within 12 hours.

Alert email contents: The previous record value and the new value, displayed side by side. Also flags if the RUA address changed, which affects where aggregate reports are delivered.

SPF Changed

What it does: Monitors your SPF TXT record every 12 hours and alerts on any modification.

What it detects: Added/removed include: mechanisms, IP changes, all mechanism changes, record syntax errors.

Why it matters at reject: SPF is one of two alignment mechanisms (with DKIM) that DMARC evaluates. At reject, a broken SPF record means any sender relying solely on SPF alignment will have their email bounced. Common failure scenarios:

• Exceeding the 10 DNS lookup limit after adding a new include:
• Removing an include: for a service still actively sending
• Changing -all to ~all during troubleshooting and forgetting to revert
• DNS propagation delays causing inconsistent SPF evaluation

Alert email contents: The old and new SPF record values.

MX Changed

What it does: Monitors your MX DNS records every 12 hours for changes.

What it detects: Changes to MX record priorities, addition/removal of mail exchangers, hostname changes.

Why it matters: MX changes don't directly affect DMARC authentication, but they're a critical DNS health signal. MX changes often correlate with email infrastructure migrations — and those migrations frequently break SPF/DKIM alignment. An unexpected MX change can also indicate DNS hijacking.

New Subdomain Detected

What it does: Alerts when DMARC aggregate reports arrive from a subdomain that hasn't been seen before (e.g., newsletters.example.com when only example.com was previously monitored).

What it detects: First-time appearance of any subdomain in your DMARC aggregate report data, evaluated in real time as reports are processed.

Why it matters at reject: New subdomains mean either:

1. Someone in your organization started sending from a new subdomain without configuring authentication — those emails are bouncing
2. An external party is attempting to use a subdomain to spoof your domain — your policy is blocking it, but you have data to investigate

Both cases are actionable. Case 1 requires SPF/DKIM setup. Case 2 provides threat intelligence.

New Forensic Report

What it does: Sends periodic digests of DMARC forensic (failure) reports. You configure the frequency — every 1 day, 3 days, 1 week, etc.

What it provides: Forensic reports are individual authentication failure records. Each one represents an email that was bounced at reject. The digest includes:

• How many forensic reports were received in the period
• A direct link to view them with date filtering applied

Why it matters at reject: Reviewing forensic data tells you:

• Whether the source IP belongs to a legitimate sending service (misconfiguration) or an unknown host (spoofing)
• Which authentication mechanism failed (SPF, DKIM, or both)
• The header_from and envelope_from alignment details
• Geographic and infrastructure patterns in spoofing attempts

Configuration tip: Set the aggregation period based on your volume. High-volume domains: 1–2 days. Low-volume: 3–7 days. Daily digests can be noisy for domains under active spoofing.

SPF/DKIM Alignment & Delivery Rate Drops

What it does: Alerts when SPF alignment, DKIM alignment, or delivery rate drops below 90%, calculated from the last 7 days of aggregate report data. Evaluated in real time as reports arrive.

Why it matters at reject: This is the most operationally critical alert. A drop in alignment rate is the leading indicator of legitimate email being bounced. Common causes:

• A sending service rotated DKIM keys without updating your DNS
• A mail server migration changed the envelope sender, breaking SPF alignment
• A third-party ESP started using a new IP not covered by your SPF record
• DKIM signatures being stripped or modified by an intermediary (mailing list, forwarding service)

At reject, an alignment drop doesn't degrade deliverability gradually — it creates a hard cutoff. Email that was passing yesterday bounces today.

Alert email contents: Which metric dropped and to what percentage (e.g., "SPF Alignment dropped to 75%").

Note: One alert of this type per account. It covers all monitored domains automatically.

Low Message Credits

What it does: Alerts when your account's message credit balance drops to 20% remaining. Fires once per billing cycle.

Why it matters: Message credits determine how many DMARC report records your plan can process. If credits are exhausted, incoming reports stop being processed — you lose visibility entirely. Every other alert depends on report data being ingested.

Metric Alerts

Metric alerts fire when a value crosses a threshold within a time window you define (e.g., "more than 100 in 3 days"). The time window is configurable from 1–30 days, weeks, or months.

Note: Aggregate reports are typically received after a minimum of 24 hours. If you're not receiving alerts, consider extending the time window.

Non-Compliant Emails

What it measures: Total emails failing DMARC authentication (both SPF and DKIM alignment fail) within the time window.

Why it matters at reject: Non-compliant count is a direct measure of bounced email. Every non-compliant message represents either a blocked spoofing attempt or legitimate email that failed authentication. Setting a threshold appropriate to your baseline lets you detect:

• Sudden spike: Possible spoofing campaign or infrastructure failure
• Gradual increase: Configuration drift or new unauthorized sender
• Any non-zero on a domain expecting 100% compliance: Immediate investigation needed

Example: Domain sends ~1,000 emails/day at 99% compliance. Normal noise is ~10 non-compliant/day. Set threshold to 50 in 1 day — fires when something meaningful changes.

Emails Reported

What it measures: Total email volume appearing in DMARC aggregate reports (compliant and non-compliant combined).

Why it matters: Detects volume anomalies. A sudden doubling could indicate a compromised service sending as your domain, a misconfigured mail merge, or a spoofing campaign generating visible aggregate data.

Example: Domain averages 5,000 reported emails/week. Set threshold to 15,000 in 7 days.

Compliant Emails

What it measures: Total emails passing DMARC authentication within the time window.

Why it matters: Establishes an upper bound on expected legitimate volume. If a service account with valid DKIM keys is compromised, the resulting spam passes DMARC — only a volume anomaly reveals the problem.

Example: Set to 2–3x your normal weekly compliant volume.

Summary Alerts

Weekly Summary

What it does: Delivers a weekly email report every Sunday covering the past week's DMARC activity across your selected domains.

Email contents:

• DMARC compliance rates (pass/fail percentages)
• Forensic report counts by category (abuse, auth-failure, fraud, other)
• Top 5 sending IP addresses/hostnames by message volume
• Domain-by-domain breakdown (when multiple domains are configured)

Why it matters at reject: The weekly summary is the minimum viable monitoring commitment. A 30-second scan each week confirms your authentication posture is stable. It's the only alert type that gives a cross-domain, cross-sender overview in a single email — useful for spotting patterns that domain-specific alerts might not surface individually.

Pro tip: Use tag-based domain selection to create separate summaries for domain groups (e.g., "Production Brands," "Parked Domains," "Client Domains").