DMARCPulse May 2026 Update: Hosted Mailbox, App-Only and Honest SPF

What’s new — at a glance

Today’s update removes two of the most painful onboarding steps and clears up some dashboard confusion that customers have flagged in recent weeks:

Hosted DMARC Mailbox — we host the rua= address for you. No IMAP account, no OAuth consent, no Microsoft 365 admin approval.
Microsoft 365 App-Only without your own certificate — we bring the certificate. You only need to create an Application Access Policy and grant your tenant.
“Aligned” column in the Auth Results Breakdown — surfaces why the SPF Pass Rate looks low for senders like Brevo even though raw SPF passes everywhere. (Spoiler: that’s normal, not a problem.)

Plus a series of smaller improvements under the hood: more honest OAuth error messages, automatic retries for short database hiccups, and a switch to Brevo SMTP relay for our transactional mail (no more Junk classification in Microsoft 365).

Hosted DMARC Mailbox: no mailbox configuration required

Until now, DMARCPulse customers had three options for getting reports into the system: provide IMAP credentials, connect a Microsoft 365 or Google mailbox via OAuth, or use a service account. All three have trade-offs, but they share one ceiling: a mailbox has to exist first — and your IT team has to configure access to it.

The new option sidesteps that entirely. You pick an alias on in.dmarcpulse.io, say [email protected], and put it in your DMARC rua= record. We receive the reports, validate the attachments, and ingest them directly into your tenant database.

v=DMARC1; p=reject; rua=mailto:[email protected]

Concretely:

No mail server to configure or maintain.
No permissions to be cleared by IT.
No login that eventually expires.
RFC 7489 §7.1 — the cross-domain authorization records (*._report._dmarc.in.dmarcpulse.io) are already published; receivers accept the address straight away.

If you already have an IMAP or M365-OAuth setup running, no need to change anything — Hosted Mailbox is an additional option, not a replacement. For new domains and for setups inside hard Microsoft Defender lockdowns, though, it’s now our default recommendation.

A note on data protection: we only process aggregate DMARC reports (XML attachments with statistics, no per-message content). Forensic ruf= reports are intentionally rejected, because their payload contains personal data (recipient addresses, partial headers per RFC 6591 §5) that we cannot process without a separate Data Processing Agreement.

Microsoft 365 App-Only — without you generating a certificate

Microsoft 365 has supported Application Permissions (App-Only auth) for years, and they’re a substantially cleaner fit for DMARC polling than delegated OAuth tokens: no refresh-token expiry, no user consent dialog, scopable to a single mailbox via Application Access Policy.

The catch until now: Microsoft requires either a client secret (short-lived) or a certificate (longer-lived) for App-Only access. The certificate path is more robust, but it forced every customer to generate their own cert, upload it in the Azure portal, and rotate it every 1–2 years.

With this update we bring the certificate. DMARCPulse runs a centrally managed master certificate that gets registered in your Azure tenant as part of the multi-tenant app trust. You only need to:

Allow the multi-tenant app in your Microsoft 365 tenant.
Create an Application Access Policy that scopes DMARCPulse to exactly the mailbox(es) that should receive reports.
Enter the mailbox name in the wizard.

The dashboard wizard walks you through the required PowerShell steps, including auto-prefill of any mailbox you’ve already connected via App-Only — useful when you manage multiple domains and want to extend the policy. The reset path for misconfigurations is documented inline (Microsoft cache propagation can take anywhere from 30 seconds to an hour depending on region — the wizard explains it in context).

”Aligned” column: honest numbers, not a contradiction

Anyone who runs through a bulk-mail relay — Brevo, SendGrid, Mailgun, Postmark — has seen this confusion: the detail table reports “SPF: 100% pass”, but the KPI at the top says “SPF Pass Rate 9.8%”. Both are correct — but they measure different things.

Raw SPF (RFC 8601): the Mail-From domain has a valid SPF record that authorises the sending server.
Aligned SPF (DMARC): in addition, the organisational domain of the Mail-From address must match the visible From-header domain.

With Brevo and similar services, the message goes out through their bounce domain (bounces.sendgrid.net, gx.d.sender-sib.com, etc.) while your own domain sits in the From header. Raw SPF: pass. DMARC-aligned: no. DKIM saves the day, because the relay signs with a signature in your domain — but that wasn’t immediately visible from the dashboard.

So we’ve added an Aligned column to the Auth Results Breakdown. Per Mail-From domain (SPF) and per DKIM selector, it shows how many of the raw-passing messages are also DMARC-aligned:

Mailfrom Domain	Pass	Total	Aligned	Pass %
`gy.d.sender-sib.com` (Brevo)	292	292	0 (0%)	100%
`acme.com` (direct send)	45	45	45 (100%)	100%

The red 0 (0%) value tells you immediately: this sender does not contribute to DMARC — instead check whether it signs DKIM-aligned (Brevo, SendGrid, Mailgun all do, by default, once you’ve published the DKIM CNAMEs they ask for). The column doesn’t replace explanation, but it makes the apparent contradiction visually resolvable — and red values without compensating DKIM alignment indicate a real problem.

Under the hood — stability and deliverability

Three smaller improvements that matter day-to-day but don’t deserve their own chapter:

Transient database hiccups now retry automatically. When the connection to a tenant database drops briefly (typical under load or while a frozen replica warms up), a read query retries once silently rather than surfacing an error to the UI.
Transactional mail now reliably reaches Inbox. We migrated our SMTP relay onto Brevo’s shared pool — the younger dmarcpulse.io reputation wasn’t enough for Microsoft Defender’s bulk heuristics, and a warm pool fixes that structurally. Verification and trial-welcome mail now lands in the M365 Inbox instead of Junk.
OAuth errors are now diagnosable. When the token exchange with Google or Microsoft fails, the actual upstream error (e.g. “access blocked by policy”, “consent required”) is now surfaced in the UI instead of a generic oauth_failed. That saves a support round-trip.

Plus assorted UX fixes: aligned columns across the DKIM/SPF sub-tables, a warning when a DMARC record lists multiple rua= addresses (Microsoft 365 only sends to the first — RFC 7489 says otherwise, reality wins), UCEPROTECT-L2/L3 surfaced as informational tier alongside truly actionable blacklists.

Getting started

Existing tenants don’t need to do anything — every improvement is active automatically. To try the Hosted Mailbox, head to Domain Settings → Hosted Mailbox. Microsoft 365 App-Only sits in the same area under Email Sources → Microsoft 365 (App-Only).

If you don’t have a DMARCPulse account yet: 14-day trial, no credit card required — most setups are running in under ten minutes. Sign up.