Skip to content

Native DMARC XML Aggregate Radar

Last updated 28 October 2026

Eliminate expensive third-party DMARC monitoring tools. SadaSend ingests raw, Gzip, or Zip aggregate feedback XML directly, scoring sender alignment and guiding your domain from monitoring to strict enforcement.

SadaSend REST APIs, Port 587 ESMTP submission relay, hosted MCP tools for AI agents, and official zero-dependency TypeScript and Python SDKs are live in production. Every account receives 6,000 monthly transactional emails with strict server-enforced guardrails.

Understanding DMARC aggregate feedback (RFC 7489)

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is the industry standard that protects your brand from impersonation and phishing. Mailbox providers (Google, Microsoft, Yahoo, Zoho) generate daily XML aggregate reports detailing every email received claiming to originate from your domain.

By publishing an aggregate feedback tag (rua), mailbox providers automatically transmit these XML reports to your dedicated reporting address:

DNS
_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@sadasend.com; pct=100; sp=none;"

Three ways to ingest DMARC reports

SadaSend supports multiple ingestion channels for aggregate reports:

• Automated Inbound Ingestion: Direct your DMARC rua record to mailto:dmarc@sadasend.com. Our mail exchangers automatically unpack and parse incoming XML reports.

• Customer Console Upload: Drag and drop raw .xml, .xml.gz, or .zip archives directly into the DMARC Radar interface (/app/domains?tab=dmarc).

• Automated REST API: Submit report files programmatically via POST /dmarc/reports.

BASH
curl -X POST https://api.sadasend.com/dmarc/reports \
  -H "Authorization: Bearer sada_live_sk_..." \
  -H "Content-Type: multipart/form-data" \
  -F "file=@google.com!yourdomain.com!1729814400!1729900800.xml.gz"

Alignment analysis: SPF vs DKIM

For an email to pass DMARC, it must satisfy two requirements:

1. Cryptographic Authentication: SPF or DKIM must evaluate to pass.

2. Domain Alignment: The domain authenticated by SPF (Return-Path) or DKIM (d=) must match the domain displayed to the human user in the From: header.

SadaSend visualizes both relaxed alignment (subdomains allowed) and strict alignment (exact domain match required), highlighting misconfigured third-party tools (like Zendesk, HubSpot, or Salesforce) before they cause delivery failures.

Threat classification: Spoofing vs Forwarders

Not all DMARC failures indicate a cyber attack. Many legitimate failures occur when users auto-forward emails or participate in corporate mailing lists. SadaSend’s forensic engine separates genuine threats from benign anomalies:

• Spoofing Unauthorized IP (`spoofing_unauthorized_ip`): Servers attempting to send email as your domain without valid SPF or DKIM signatures. These represent impersonation risks.

• Forwarding Relays: Legitimate third-party forwarding servers that preserve DKIM signatures while failing SPF due to IP relocation.

• Misconfigured Relays: Internal transactional servers sending email before your SPF record was updated.

The safe path to strict enforcement (p=reject)

Never jump directly to p=reject without an audit period; doing so can accidentally block legitimate transactional emails.

Follow SadaSend’s proven 3-phase enforcement timeline:

1. Phase 1: Monitor (`p=none`) for 2 to 4 weeks: Collect aggregate reports, identify all legitimate sending services (SadaSend, support desks, marketing tools), and ensure each has valid DKIM and SPF records.

2. Phase 2: Quarantine (`p=quarantine; pct=25` to `pct=100`): Tell receiving mailboxes to route failing messages to spam folders while monitoring for unexpected disruptions.

3. Phase 3: Strict Reject (`p=reject; pct=100`): Complete deliverability hegemony. Unauthenticated emails claiming to originate from your domain are rejected outright at the receiving mail exchanger.