Authentication

DMARC reporting — see who sends in your name.

DMARC is the policy layer above SPF and DKIM. MailGuard sends daily aggregate reports to the addresses configured in DNS and parses incoming DMARC reports for your domain — the dashboard shows you who is sending mail in your name and whether it's legitimate or phishing.

What DMARC actually does

DMARC (RFC 7489) builds on SPF and DKIM. A domain's DMARC policy tells recipient mail servers: "If you receive mail from example.com that fails SPF and DKIM — what do you do with it?". Three modes:

  • p=none: do nothing (monitoring mode) — let mail through but send reports to the sender domain
  • p=quarantine: move to spam folder
  • p=reject: refuse with a 5xx error

Plus the reporting addresses (rua for aggregate, ruf for forensic) — the daily reports from recipient mail servers are delivered there.

What MailGuard does in DMARC reporting

Parse incoming aggregate reports

When Microsoft 365, Gmail, Yahoo etc. send aggregate reports to your rua address (typically daily, in XML format), MailGuard parses them automatically and visualises them in the dashboard:

  • Who sent mail in your name today? (sender IPs)
  • Which IPs passed SPF/DKIM, which didn't?
  • How many mails per IP, per recipient provider?
  • Trend over time — new sender IPs, unusual volume, spoofing attempts

Send outbound aggregate reports

For every domain configured in MailGuard with a DMARC record published: send daily aggregate reports to other domains' rua addresses — when mail from external senders arrives at our domain, we report back to those sender domains what we received. This is mandatory in the DMARC ecosystem — without these reports the trust model doesn't work.

Forensic reports (RUF, optional)

Forensic reports contain headers and parts of the body of individual failed mails — far more detailed than aggregate reports. For data-protection reasons (they can contain personal content) RUF reports are off by default. The operator can enable them per domain when forensic depth is needed (e.g. during an active spoofing attack).

The typical onboarding path

  1. Phase 1 (weeks 1–4): p=none. You publish DMARC with policy "do nothing, just send reports". The dashboard reveals everyone sending in your name — typically marketing tools, CRM systems, older mail servers, third-party services like Mailchimp.
  2. Phase 2 (weeks 5–8): SPF/DKIM for legitimate senders. You expand the SPF record with the legitimate sender IPs and configure DKIM signing where possible. The dashboard shows progress — the share of passing DMARC checks rises.
  3. Phase 3 (weeks 9–12): p=quarantine. You move DMARC to quarantine — failing mail goes to recipients' spam folder. The dashboard monitors false-positive risk.
  4. Phase 4 (from week 13): p=reject. Full DMARC strictness. Spoofing attempts are refused at the SMTP level.

MailGuard accompanies this process — you can tell at any time whether your domain is ready for the next step.

Multi-domain in the standard plan

Per-domain DMARC configuration and reports. Tenant A can be on p=reject while tenant B is still in p=none monitoring. Reseller pattern fully supported.

DMARC without external tools.

Parse and send aggregate reports, forensic reports on request, dashboard visualisation — all included in the standard plan.

See pricing