What's New

Opening Reports on the Free plan used to hit a locked card with nothing to act on. Now it shows what upgrading actually adds — grounded in your own domain.

• A summary read from your real record. We look at your published DMARC record and tell you where you stand: no DMARC yet, watching but not stopping anything, or enforcing. The next step is specific to your situation — if your reports already flow to another tool, we say so and point to what's different about letting mxio maintain your records, rather than pitching you reporting you already have.
• A clearly-marked preview of the paid lenses. The sender, disposition, and impersonation views that DMARC reporting unlocks appear as a blurred, watermarked sample — labelled "not your domain" so it's never mistaken for your real data.
• A Free column in the pricing comparison. The full feature table now includes Free, so you can see exactly what you have today versus each paid tier.

When mxio manages your DMARC, we already keep any reporting address you had before — so a switch from another vendor never drops your reports. Now you can manage that list yourself.

• Add your own. Want your security team (or anyone else) to get a copy of the aggregate reports? Add their address and it's included immediately.
• Remove one you no longer need. Switched away from a previous vendor? Remove their address to stop sending reports there. mxio keeps receiving your reports either way — reporting is separate from the protection on your domain.

The control lives on the DMARC page for any domain mxio manages, under Where your DMARC reports go. Changes publish to your record right away. mxio's own reporting address is always kept — we need those reports to watch your domain.

A handful of dashboard polish items so the right information appears at the right moment.

The SPF record appears where you add senders. When you add a sender in self-managed mode, the side panel now shows the SPF record you need to publish — the same record shown on the SPF page. You no longer have to navigate away to find it.

"What changed" shows exact times. The per-domain change history previously showed relative labels like "3 hours ago," which made it impossible to distinguish two changes that happened on the same day. It now shows the precise date and time for every entry.

Your own DNS changes appear in "What changed." When you publish an SPF or DMARC record yourself in self-managed mode, that edit now shows up in the domain's change history alongside mxio's managed changes.

Managed activation and handback events appear in "What changed." When mxio activates Managed DMARC, or when you switch a managed service back to self-managed, those transitions now appear in the per-domain history on the SPF and DMARC pages.

Handback notifications read as plain titles. After switching a managed service back to self-managed, the in-app notification previously showed the raw internal event key. It now reads as a clear, plain-language title.

Several small improvements to how the dashboard communicates status and behaves on mobile and touch devices.

Clearer "Action needed" alerts. The banner that tells you something needs your attention now uses an amber color and a warning icon (⚠) — it previously shared the same teal color as informational notices, which made it hard to distinguish at a glance, especially for users with color-vision differences.

Status badges you can read without color. The "What changed" chips on record cards now carry a status symbol alongside the color — a checkmark, warning sign, or error mark — so the meaning is clear even when color isn't.

SPF Copy button is less ambiguous. The Copy button on the SPF page was labeled just "Copy." It copies your current SPF record (not the suggested fix), so it's now labeled "Copy current record" to make that clear.

Senders table scrolls on small screens. At high zoom or on a narrow screen, the senders table could crush the "In record" and "Actions" columns until they disappeared. The table now scrolls horizontally instead.

Outcome titles wrap instead of truncating. Card titles like "What happens to fakes" now wrap to a second line on small screens rather than cutting off mid-sentence.

Larger touch targets. Interactive controls now meet the 44 × 44 px minimum for touch devices, making them easier to tap accurately on phones and tablets. Mouse-pointer density is unchanged.

When you have a DMARC record but impersonators can still get through, the dashboard now says so plainly — and points you to the right next step.

"Watching, not blocking." If your DMARC record is set to monitor-only mode, the per-domain recommendation now leads with that: your domain isn't yet blocking impersonators, and here's how to change that. The old message ("Good news, you already have a DMARC record") buried the gap and sent you toward a cheaper reporting tier when the real fix was enforcement. The new message names the actual situation and routes to the enforcement path.

Already enforcing but flying blind? If your DMARC policy is already blocking impersonators but you're not receiving any reports, you now get a separate, honest next step: turn on reporting so you can see who's sending as you. This is a different situation from the watching-mode case, and the guidance now reflects that — it never claims impersonators are "being blocked" when you have no way to know.

Fix your sending tools first. If one of your authorized senders isn't covered by your SPF record yet, the dashboard now highlights that before pushing you toward enforcement. Enabling enforcement when a legitimate sender isn't in your record would cause that sender's mail to be rejected. The guidance holds off on the enforcement recommendation until your sending tools are covered, and points you to adding them first.

A few front-door improvements so a domain you check never gets lost or mistaken for something it isn't.

The sample on the home page is clearly labeled. Before you run a check, the hero shows an example report — it now carries a "Sample data" badge so it's never mistaken for your real result, and editing the field while a check is running no longer flips you back to the sample.

Retry when a check doesn't come back. If the home page check errors out or a piece of it (like the health check) doesn't return in time, you now get a clear message and a "Try again" button instead of a dead end.

The domain you checked carries into signup. When you run a check and decide to monitor or fix the domain, the "Monitor / Sign up to fix this" buttons now bring that domain with you through signup — the add-domain field is already filled in, so you don't retype it. (It's pre-filled, not auto-added — you confirm it yourself.)

After activating Managed SPF, the SPF workspace now polls for the updated status and flips the card automatically — no need to reload the page to see that your record is active.

Previously, the page could show a stale pre-activation state until you manually refreshed. The card now checks in the background and updates as soon as the activation is confirmed.

A few changes so the dashboard tells you the truth at the moments that matter most.

Your SPF fix now confirms everywhere, immediately. When you publish a corrected SPF record and click Recheck DNS, your domain hub now refreshes along with the SPF page — so it no longer keeps warning that a sender "isn't in your SPF record" for a few minutes after you've already fixed it.

A clear "you're covered" signal. Once every sending tool is in your SPF record, the SPF page now shows a green confirmation that all your senders are covered. Any remaining warning is about a separate item (such as turning on DMARC enforcement) — not the coverage you just fixed.

A heads-up when you take a managed service back. If you switch Managed SPF or Managed DMARC back to self-managed, we now send you an email and an in-app notice confirming you're publishing your own record again — and that your mxio setup stays in place if you want to switch back. Previously the only message on record was the original "now active" one, which could leave the impression that mxio was still managing it.

For domains using Managed DMARC, the hub and per-domain views now derive the displayed enforcement status from the policy that's actually published in DNS (the last record mxio successfully deployed), rather than from an internal intent value that could differ while a change was in flight.

Previously, a freshly-provisioned managed-DMARC domain could display "at reject / blocked" in the hub card while the published record still said p=none — the displayed stage was the reconciler's target, not what receivers were actually seeing.

The fix applies across every surface that names a managed-DMARC enforcement level: the hub card, the per-domain page, the DMARC assessments tab in Reports, and the enforcement-journey lifecycle email.

When you change your managed DMARC enforcement level (for example, moving from monitoring to quarantine) or update your managed DMARC settings, mxio now publishes the new policy to DNS in the same action — instead of queuing the change for the background reconciler to pick up within a few minutes.

The result: the change is live in DNS immediately, and the page reflects the updated status right away, without a reload.

The background reconciler is still running as a backstop — it handles recovery if anything unexpected interrupts the in-path publish — but it's no longer the primary path for getting your change into DNS.

The DMARC volume meter (the per-plan limit shown on the pricing page, billing dashboard, and usage surfaces) now reads "messages" instead of "emails." DMARC aggregate reports count messages processed by receivers, not email deliveries — so the term was always inaccurate. Seven surfaces updated.

When a domain has a valid SPF record but we have no independent way to confirm your full list of senders — no DKIM to vouch for your signed mail, and no DMARC reporting to show who's actually sending — the per-domain hub used to display a clean green "✓ SPF / your real mail passes." If one of your real senders (say, Klaviyo or Mailchimp) wasn't in your SPF record yet, that green check could read as an all-clear when it wasn't.

The "Will your real mail be trusted?" card now reflects that uncertainty honestly: the SPF check reads a neutral "Passes for senders we can see," and the card promotes a clear next step — Add your sending tools — so you can tell us which services send on your behalf and we can check them against your record.

Domains with DKIM configured, DMARC reporting on, or Managed SPF active are unaffected — those give us a way to confirm your senders, so the green check stays.

When you add, update, or remove a sending tool on a domain where Managed SPF is active, mxio now recompiles and republishes your SPF sub-record in the same action — the DNS change is live immediately.

Previously the update was picked up by the background worker, which could take anywhere from a few minutes to half an hour depending on queue timing. The worker is still running as a backstop for provider IP changes and recovery from any unexpected interruptions, but the action you just took now applies right away.

You can now get a free weekly watch on your domain without creating an account.

On the spoofability checker, enter your email address and mxio will re-scan your domain every week. If the result changes — say, a new gap opens up or something improves — you'll get a plain-language email explaining what changed and what (if anything) to do about it.

A confirmation email goes out first; the watch starts once you click the link. You can unsubscribe any time with one click from any email we send.

Advisor banners — the recommendations that appear at the top of each domain — now use plain language throughout.

Previously some banners included protocol shorthand in the description text: things like ~all, _dmarc, p=none, or pct=0. That syntax is precise for DNS records but adds friction in a reading context. The banners now describe the same situations in plain terms:

• SPF soft-fail is described as "soft-fail mode" and switching to hard-fail instead of -all
• DMARC monitoring mode is described as "monitoring mode" instead of p=none
• References to the _dmarc DNS label are replaced with "your DMARC record" or "your DMARC CNAME"
• The DMARC pct=0 situation is described in terms of what it does — evaluating no messages — rather than the tag syntax

The technical detail is still available on the focused record pages where it's actionable.

Fixed two edge cases where the domain list's teal "mxio SPF" mark showed for a domain whose hub page badge correctly read "Locked" — the list now agrees with the hub:

• Downgraded below Pro, include still in DNS: the domain list showed a mark, while the hub correctly showed "Locked" (the plan no longer includes Managed SPF). The list now drops the mark to match.
• Account suspended for non-payment (past due), include still in DNS: same shape — the list showed a mark while the hub showed "Locked". The list now agrees.

Both surfaces now share the same predicate, so they cannot contradict each other.

If a Pro or Business plan with Managed SPF was paused for a billing reason, the SPF card on the domain page could tell three different stories at once: a "paused over plan limit" message in the body, a "Self-managed" badge, and a "Let mxio manage it" button — all together.

The card now resolves to a single, consistent state when management is paused: it shows your SPF health without the mismatched badge or button. The banner at the top of the domain still guides you to the fix — reactivate your plan or manage your domains — so there's one clear path back, never a contradiction.

A few rough edges smoothed over, plus a new guide:

• Your plan name reads properly. The domain-list header and the Billing "Current Plan" label now show Pro or Business instead of the lowercase internal code.
• "Managed DMARC is available on Pro" is now a link — one click to the pricing page instead of hunting for it.
• Reviewing your senders from the SPF card opens in place. No more full-page navigation that lost your spot.
• New guide: Can Someone Spoof Your Domain? — a plain-English walkthrough of how to check whether attackers can send email as your domain, what the result means, and the safe path to lock it down.

Four quick wins from a six-competitor screenshot audit — each one surfacing data that was already computed, just not shown where you needed it:

• Forwarded mail is labelled, not lumped with failures. At enforcement, mail forwarded by mailing lists, aliases, or relay services legitimately fails SPF and DMARC alignment — it's not impersonation. The DMARC disposition view now shows a one-line note (e.g. "Forwarded mail accounts for ≈N messages in this 7-day window — expected, not impersonation") so you know this volume isn't a threat.
• SPF lookup count appears on the domain list. Each domain's SPF chip now shows its current lookup count (N/10). If a domain is getting close to the 10-lookup RFC limit, it shows in amber (8–9 lookups) or red (10+), so you can spot over-budget domains at a glance without drilling into /spf.
• Inline "Set up [provider] →" on uncovered sender rows. When a recognized sender (Mailchimp, Postmark, SendGrid, etc.) is authorized but not in your SPF record, the sender spine now shows an inline "Set up [ESP] →" link that opens the guided setup slideover right there — no separate navigation required.
• Readiness evidence beside "Advance now." When the DMARC enforcement rail says you're ready to advance to the next policy level, it now shows a one-line summary of why: alignment rate, message volume, and whether any anomalies were observed over the past 30 days. Same data the system already uses to make the call — now visible to you before you act.

A sweep of clarity fixes from an end-to-end journey audit — every managed-services step and status now reads the way it actually behaves:

• The "who maintains it" choice leads with what's shared. The SPF and DMARC focused pages now open the manage-it-yourself vs. let-mxio-do-it chooser with one orienting line: mxio discovers and maintains your sender list either way — the choice is only about who publishes the DNS. It's an equal fork, not "premium vs. basic."
• "Set up DMARC" and "Activate Managed DMARC" land where they promise. Clicking a managed-DMARC setup prompt now opens the chooser already on the Managed card, instead of dropping you into self-publish — including right after you upgrade.
• No more "publishing a DMARC record is free" on a paywalled domain. When DMARC isn't set up, the prompt now leads with the real value — DMARC Reporting, included on Monitor — instead of implying a free path that every door then gates.
• The free domain-health check leads with a plain sentence. Before the SPF/DKIM/DNS-lookup detail, the verdict now says, in one line, whether your email is protected — and it never claims "anyone can spoof you" when an enforcing DMARC policy already blocks it.
• DKIM page tells the truth when you already have senders. Instead of "No senders to show yet — add your senders" when senders exist, it now says your senders don't have DKIM set up yet and how to add it. The "Scan DNS" result no longer points at "the records above" when none are shown.
• Right after upgrading, Managed SPF shows "ready to activate," not "0 managed." The platform card now distinguishes a domain that's provisioned and waiting for your DNS (ready to activate) from one still setting up — so a fresh upgrade never reads as "I paid and got zero."
• "Last maintained" reflects your activation. Activating a managed SPF domain now stamps the maintained time, so the page reads "Last maintained: just now" right after you activate instead of an older provisioning timestamp.

The SPF ~all advisory also now points at DMARC enforcement as the real lever (your ~all setting is fine once DMARC is enforcing) rather than implying ~all itself is the defect.

A second pass of small clarity fixes from the same end-to-end journey audit — the leftover wording and consistency nits:

• "DMARC isn't set up" — not "DMARC is failing" — when there's no record. On the free domain-health and report cross-sells, a domain with no DMARC record was told its DMARC "is failing." There's nothing failing — there's no record yet. Both surfaces now say it isn't set up, and lead with what to do about it. (A misconfigured record still correctly reads "failing.")
• "Recheck DNS" now shows it's working. After you publish an SPF change, the self-managed "Recheck DNS" button shows a "Checking…" state while it re-reads your DNS, instead of looking like nothing happened on the first click.
• No more phantom MX "needs attention" on Google/Microsoft mail. A cosmetic reverse-DNS (PTR) mismatch on a shared mail provider no longer flags your Delivery/MX as needing attention on the hub while the MX page says "Healthy." Reverse DNS on your inbound mail servers doesn't affect delivery, so it's now an informational note, not a warning — and the two screens always agree.
• A fresh domain gets a clear nudge to add the apps you send from. Right after you add a domain, the senders section now prominently invites you to add the services that send as you — newsletters, invoicing, your CRM — so we can check they're covered, instead of leaving you to rediscover the gap.
• The DNS-host detection on the free tools degrades gracefully. A domain whose delegation can't be resolved now returns an "unknown host" result instead of erroring out.

If your plan drops below Pro (or you cancel), mxio now gives you 30 days before removing your managed SPF record — so you're not left with a broken include overnight.

During the grace period, your managed record stays live and current, and you'll receive three warning emails:

• At the start — the countdown has begun; your record is still active.
• Around two weeks in — a check-in reminder with days remaining.
• One day before teardown — a final warning that includes your exact SPF record to publish if you want your SPF to keep working after removal. If your apex SPF still points at mxio's managed include after teardown, it will return a PermError.

If you re-upgrade to Pro before the 30 days are up, the grace period is cancelled and Managed SPF resumes normally — nothing to reconfigure.

The DKIM page now reflects every sender you've added, not just the ones who already have DKIM published:

• Senders show up before DKIM is set up. When you add a sender — Mailchimp, Google Workspace, MailRoute, or any catalog vendor — a DKIM row appears immediately showing its current status. If DKIM isn't published yet, you see a "Setup needed" state (calm, not an alarm) rather than a blank page.
• Per-vendor setup steps. Each setup row tells you exactly what to do: where to enable DKIM at the vendor, which selectors we'll look for, and which target zones the records should point into. No guessing what a "selector" is or where to find it.
• Scan DNS confirms it. For vendors with known selectors (Mailchimp, Google, MailRoute), click Scan DNS after publishing at the vendor — the page tells you "Found Mailchimp DKIM ✓" or "Found 2 selectors ✓", and the row flips to Signing. If nothing is found yet, you get a clear "nothing yet — give DNS a few minutes" message instead of silence.
• Paste selectors for SES and Postmark. These services issue per-account selector names we can't know in advance. The row prompts you to paste the selector(s) your vendor gave you; we probe each one before registering, so a typo says "not found yet" rather than producing a false failure.
• Already-published vendors auto-cover. If a vendor's DKIM was already live when you added it, the row flips to Signing on its own — no manual scan needed.

DKIM strengthens your mail signing and protects against forwarding edge cases where SPF alone can't vouch for a message. It's optional for domains with DMARC enforcing via SPF, but recommended for any sender you rely on.

If you'd taken Managed DMARC back into your own DNS and later change your mind, you no longer have to click anything to re-enable it. The moment your _dmarc record points back at mxio's target, we detect it and resume managing your DMARC automatically — your policy picks up exactly where it left off, and your dashboard flips from "Self-managed" back to "Managed by mxio" on its own.

• Watching the page while you change DNS? The Managed DMARC page now has a "Check DNS" button and quietly re-checks every 30 seconds, so the switch shows up in seconds rather than on the next background cycle.
• Walked away? No problem — a background check (about every 5 minutes) catches it for you.

We only flip it back on once we've confirmed your _dmarc is a CNAME to our exact target — your own DMARC records never trigger a false switch. And because your managed record stays live the whole time you're on a paid plan, the change is instant and correct with nothing for us to rebuild.

When mxio manages your SPF or DMARC, the records we build for you under the hood (your flattened SPF include and your DMARC reporting target) now stay in place and stay current the whole time you're on a paid plan — whether mxio is actively publishing or you've taken the record back into your own DNS. They're only removed if you delete the domain or drop your plan. The practical wins:

• Take a record back, then change your mind — it just works. After you hand SPF or DMARC back to your own DNS, every surface correctly shows it as self-managed (the per-domain page, the hub card, and the dashboard counts all agree — no more "still managed by mxio" or "finish setting up" prompts on a record you deliberately took back). And re-pointing your DNS at mxio later picks up exactly where you left off, with no errors and nothing stale.
• Senders you add keep your record ready. Adding a sender keeps mxio's managed record current even while you're self-publishing, so a future switch back lands on a record that already includes everything.
• No false "isn't included in your SPF" warnings. A sender that's already covered by your SPF record is no longer flagged as missing.
• The dashboard DMARC count reflects what's actually live — it counts domains where DMARC is truly delegated, matching what each domain's page shows.
• You get an email the moment Managed SPF or Managed DMARC goes live — delivered right away, not on a delay, and exactly once per domain.
• Clearer free-tool and in-app wording — the domain-health SPF result leads with a plain verdict (and distinguishes "no SPF record" from "couldn't check"), the /spf page calls it "your current record," and the trust summary is appropriately cautious when we can't yet confirm signing for a sender we can see.

When you choose "You maintain it" to take a managed service back into your own DNS, the record we hand you now mirrors what's published today — intact:

• Managed SPF hands back every sender the managed record covers (not just the ones flagged "in SPF"), so you don't silently lose coverage for a newsletter or app you'd added.
• Managed DMARC hands back your current policy and all its settings (p=, sp, adkim/aspf, fo, pct) verbatim — never a blank p=none — and keeps mxio's reporting address by default so you still see who's sending as you. Remove that line only if you no longer want mxio monitoring.

Both instructions now tell you to replace the existing record rather than add a second one — DMARC swaps the _dmarc CNAME for a TXT, and SPF replaces your one SPF record — so the change can't briefly break your mail.

On the SPF and DMARC pages, picking "mxio maintains it" (or arriving from the "Let mxio manage it" button) could briefly reset back to "You maintain it" as the page finished loading — and the same reset could happen after opening and closing the senders panel. Your choice now sticks. If your DNS already shows the record is delegated to mxio, the page still reflects that automatically.

When you publish your Managed DMARC CNAME and we verify it, your protection now activates immediately — instead of waiting up to five minutes for a background job to catch up. The "Activating…" screen no longer lingers, your confirmation email arrives right away, and the page can never briefly show "self-managed / let mxio manage it" over a service that's already taking over.

We kept the background process as a safety net for the one case it's still needed: when activation finishes while you're away (a report arrives confirming your delegation).

A handful of refinements across the managed-services journey:

• Honest senders intro. The senders section no longer claims "we found these in your SPF record" — a line that contradicted any sender you'd just added by hand. It now describes the list by purpose: these are the senders allowed to send as you, and we check each one's SPF coverage and DKIM.
• Adding a sender updates the page immediately. Add a sender from a domain's hub and the advisor, the at-a-glance verdicts, and the SPF card now refresh on the spot — no navigation needed to see the coverage consequence.
• No more losing your "let mxio manage it" choice. Opening the full Senders page from the slideover on the SPF or DMARC page used to navigate away and reset your managed/self choice; that escape-hatch link is now hidden where it would have caused the reset.
• A more useful Pro welcome email. The subscription confirmation email now points you to your next step — activate Managed SPF and Managed DMARC by publishing one DNS record each — instead of being a bare billing receipt.
• Quieter DMARC page. The DMARC workspace no longer logs a stream of harmless "not found" errors while polling for a pending policy change.

The "Include in my SPF record" control on each sender is now the single source of truth for what's in your SPF record. Whatever you mark for inclusion is exactly what gets published — your managed record, the toggle, and the record you'd take back if you ever hand SPF off all agree.

A few changes make that work:

• Including a sender is available on every plan. On the free and Monitor plans you publish the record yourself; on Pro and above mxio publishes and keeps it current. Managed SPF only changes who publishes — not whether a sender is in your intended record. The checkbox is no longer greyed out for free accounts.
• Recognized senders default to "included." When you add a known vendor (Mailchimp, Google Workspace, and the like), it's marked for inclusion automatically. Custom/free-text senders default to off so you decide.
• Nothing is ever silently left out. Your SPF card — on the domain hub and the SPF page — now tells you when a sender isn't included yet, with a link to review your senders, so an excluded sender can't quietly slip out of your record.

Existing managed records were migrated so no sender you'd already folded in was dropped.

When you upgrade to Pro, Managed SPF now provisions immediately — no more waiting, no dead-end screens. And the record we prepare folds in every sender you've authorized, so nothing you rely on gets left out.

Secondary labels and status text across the dashboard now meet WCAG AA contrast, so the fine print — the caveats that matter — is easier to read.

Senders you added yourself now show "Listed by you" instead of "authorized" in the status column. This removes the confusing green/amber contradiction where "authorized" appeared next to "Not in record" — the IN SPF column is now the single clear good/bad signal.

The public SPF checker tool now shows "Valid record" instead of "Pass" when a record is syntactically healthy. "Pass" implied the record was verified against your sender list — which the anonymous tool cannot do (it has no knowledge of who sends email for your domain). "Valid record" is the honest verdict: the record itself is well-formed and within the lookup budget, but whether it covers all your senders still requires checking. DKIM, DMARC, and all other tools are unchanged.

A valid, passing SPF record that doesn't cover all of your known senders now shows "Partly verified — some senders unchecked" instead of a clean pass on your dashboard's delivery-verdict card. A real SPF failure is never softened — hard failures stay hard failures.

When we recognize a sender whose DKIM selectors are already known — MailRoute, for example, which signs with mr01/mr02/mr03 — we now register those selectors for you automatically. Previously the domain would show "missing DKIM selectors" even though we knew exactly which ones to look for, which was confusing.

The selectors are added the moment the sender is recognized (at domain-add and on a manual re-scan), so the next health check probes them and your DKIM coverage reflects reality without you having to type anything. Senders whose selector is unique to your account (e.g. Amazon SES, Postmark) still ask you to paste it — we can't know those ahead of time.

When you publish a DMARC record we hand you — moving your enforcement level up or down — the "Waiting for DNS publication" panel now checks your DNS on its own and flips to DNS record detected the moment your change is live. Previously the panel showed a ticking timestamp that implied we were watching, but it only refreshed the clock; you had to click I've published — check now to confirm. That button is still there for an instant force-check — the difference is you no longer have to use it.

When mxio hands you an SPF record to publish — during managed setup, converting to managed, handing control back to yourself, or reviewing an active managed record — you can now switch between ~all (lenient, the common default) and -all (strict, fails unauthorized mail outright) before you copy it. The toggle is right on the record, defaulted from whatever your current apex already uses, so you're not locked in to whatever we picked.

"Manage senders" from the SPF and DMARC setup steps now opens in-page as a panel instead of routing you to a separate page. You pick your senders, close the panel, and land back exactly where you were — no losing your place in the setup flow.

The Domain Spoofability Check — the plain-language "can anyone send email pretending to be your domain?" verdict — is now listed in the tools dropdown, the full tools index, and the related-tools rails alongside our other email-authentication checks. It leads the Email Authentication group, and the Domain Health check now links across to it.

The tool keeps its short, shareable /spoofable address; the menu and index simply point there directly.

On a Free domain, the DMARC card ("What happens to fakes") used to show a bare "Upgrade to Pro" button with no explanation of why, competing with a separate "Upgrade to Monitor" link below it.

It now presents the two paths as a clear, side-by-side choice — each paired with the outcome you get:

• See who's sending as you → Upgrade to Monitor (DMARC reporting + the self-managed enforcement journey).
• Have mxio publish & maintain it → Upgrade to Pro (Managed DMARC — we publish and advance the policy for you).

The context-free header button is gone; each tier now states its value before the price, so the choice between Monitor and Pro is obvious.

If a domain's DMARC aggregate reports stopped arriving, the "Customize policy" picker could mislabel the current level as "Watching" even though the published record was already at quarantine or reject — which made it look like there was no change to make, or like you could "advance" to a level you were already at.

The picker now reads the current policy from your live _dmarc record (the same source the enforcement journey uses), so the "Current" marker and the recommended next step are correct even when reporting is stale. Both surfaces now share one definition of "current policy," so they can't disagree.

The DMARC enforcement journey on a domain's /dmarc page is now the control, not just a map. Each enforcement level in the list — Watching, Send fakes to spam, Block fakes — is clickable: select one and the picker opens pre-set to that level, ready to publish (or, on Managed DMARC, ready for mxio to apply on your sign-off).

Crucially, you can now move back down the ladder, not only forward. If you advanced to quarantine or reject and decide you're not ready, you can return to a gentler level in a couple of clicks. Stepping up to Block fakes still asks you to confirm by typing your domain; stepping down is low-friction.

Two shortcuts sit at the top of the journey: a prominent Advance now → when your senders are ready for the next step, and a quieter Change enforcement level → that opens the full picker any time.

We also made the partial-rollout percentage clearer: the 10% / 25% / 100% control now sits below all three levels and is captioned to show which level it applies to, so it works the same for both Send-fakes-to-spam and Block-fakes. And the current level shows its live coverage right in the list (e.g. "Partial enforcement — 10% of failures quarantined").

Two refinements to the DMARC enforcement journey on a domain's /dmarc page.

Move back from anywhere. The already-completed steps at the top of the journey — Discover senders, Monitor alignment, Ready to advance — are now clickable once you've moved past them. Hovering shows they're interactive, and clicking one takes you straight back to Watching (p=none). Together with the clickable enforcement levels, you can now move in either direction along the path, not just forward.

Clearer partial rollouts. When you open the policy picker and a gradual rollout is pre-selected (say, quarantine at 25% of mail), that percentage is now called out directly: the selected level reads "Selected · 25% of mail," and the "Roll out gradually" control opens automatically so the percentage is visible instead of tucked away. Previously a partial rollout could look like no change was being made.

Two refinements to the manual (self-managed) DMARC enforcement override flow.

Stepping down is now a light confirmation. Moving to a lower enforcement level — for example back to Watching from Send fakes to spam — no longer asks you to acknowledge that you're "overriding the Advisor," and no longer shows the "no report data" warning. Stepping down only removes enforcement, so it gets a single plain Confirm. Stepping up keeps its existing safeguards, and Block fakes still requires the strongest confirmation.

After you confirm a change, you land on the publish step. Previously a self-managed policy change returned you to the domain overview with no record in hand. Now you land on the domain's DMARC workspace, scrolled straight to a clearly labelled "publish this record" panel showing the exact new record to add at your DNS host, with a one-click "I've published — check now" button. The record shown is the one you just chose, not a generic recommendation.

On a domain's overview, each record card — SPF, DKIM, DMARC, MX — now reliably takes you to its full workspace. The card's title is a link, and every card carries an always-on "Open SPF →" / "Open DMARC →" / "Open DKIM →" / "Open MX →" affordance, in every state.

This fixes a gap where a healthy, self-managed SPF card had no link to the SPF page at all — if nothing needed fixing, there was nothing to click. Now a clean card still opens its workspace, the same as every other card.

Action buttons on a card (like "Verify DNS" or "Let mxio manage it") still take priority — clicking those does what they say; clicking the title or the "Open →" link goes to the workspace.

When you invite someone to help manage your account, they get an invitation email that explains they're joining your account. Previously, if that person was new to mxio, they'd also receive the standard new-account welcome — the one that says "add your first domain." That's the wrong message for a teammate joining an existing account that already has domains.

Now we suppress that cold-signup welcome when someone's first sign-in is accepting a team invite. They get the invitation email and nothing that contradicts it. People starting their own account still get the full welcome as before.

A domain that resolves fine but simply has no MX records (a website-only or parked domain) was being reported as "Domain does not exist" — in the free MX checker and on the domain page, where it triggered a misleading "We can't resolve any DNS records for this domain… if you've just registered the domain, propagation can take a few minutes" banner.

The cause: the DNS library returns the same "not found" signal for a genuinely non-existent domain and for a domain that exists but has no MX record. We now confirm whether the domain actually resolves before deciding — so a web-only domain correctly reports "No MX records found", and the false "doesn't resolve / just registered" banner no longer appears for it. A truly non-existent domain still reports as such.

New free tool at /spoofable: enter any domain and get a plain-language verdict on whether it can be spoofed in email.

The check runs a live DMARC and SPF scan and returns one of three results — Spoofable, Protected, or Inconclusive — with a breakdown of exactly what's exposed and why. No signup required.

A domain is spoofable when DMARC isn't enforcing (policy none, or no DMARC record at all) or SPF is configured to pass everything with +all. The tool tells you which condition applies and what to do about it.

If a transient DNS failure prevents a clean scan, the result is Inconclusive rather than a false accusation — you can re-run once DNS settles.

The /spoofable verdict now ends with a short plain-language bridge — what fixing (or maintaining) your email authentication actually takes — and two value-framed next steps instead of one generic button.

If your domain is spoofable, you get a fix-first choice: Have mxio fix it for you (Managed DMARC + SPF — we publish and maintain the records) or Monitor it free (add the domain and let the Advisor walk you through the self-fix).

If your domain looks protected, you still get both, framed honestly as maintenance rather than a fix: SPF and DMARC drift as you add senders and tools, so you can Monitor it free or have mxio maintain it so the records stay right.

Either way there's no cold paywall — both paths start by adding the domain to a free account; the managed option opens the in-context upgrade only once you're looking at your own domain.

The DMARC focused page now shows the full enforcement journey and lets you move to any enforcement level directly — whether mxio manages your _dmarc record or you publish it yourself.

The enforcement journey is visible in both modes. A five-bead rail across the top of the enforcement section shows where you are — Watching, Senders identified, Aligned, Ready, Enforcing. The beads are the same whether mxio publishes your policy or you do.

Change your enforcement level from the page. A stage picker lets you move to any level in either direction. For self-managed DMARC: we show you exactly what record to publish. For Managed DMARC: we publish it, and the reconciler advances your live record — every change is reversible.

Moving to a more cautious level is low friction. Stepping back from enforcement doesn't require a form or a confirmation screen. The picker goes both ways.

pct is now an honest "extra cautious" option in both modes. The percentage dial is available as an opt-in cushion under an expander — a blast-radius limiter while you verify your sender inventory. It is not the default path. The correct path is: identify your senders, confirm they're aligning, then advance.

Corrected the DMARCbis pct explanation. Our earlier guides incorrectly said DMARCbis-aware receivers treat pct below 100 as testing mode. That is backwards. The DMARCbis update removes the pct tag (Appendix A.6), so receivers ignore it and apply your full p= policy — pct=10; p=reject means all failing mail is rejected, not that enforcement is suspended. The correct behaviour is now stated wherever pct appears.

Clicking "Let mxio manage it →" on a domain's SPF or DMARC card now takes you to the focused page with the managed option already selected, so you land on the setup steps you asked for instead of a self-managed view.

For DMARC, this also removes a redundant pop-up. The page already shows a side-by-side "you maintain it" vs "mxio maintains it" chooser; clicking the manage button used to open a dialog asking the same question on top of it. Now the chooser is the single place you make the choice — no double-asking.

Nothing about this is a commitment: arriving on the page still changes nothing in your DNS, and you can switch back to self-managed at any time. The only step that hands a record to mxio is publishing the record yourself.

We tightened the per-domain SPF views so they agree with each other instead of showing you slightly different things in different places.

The "In SPF" column matches your SPF page. On the Senders list, the "In SPF" column now reflects whether each sender is actually in your published SPF record — the same answer the SPF page gives. (Previously it could show a sender as out while the SPF page showed it covered.) When mxio is managing your SPF, that column stays the live on/off control it's always been.

The SPF health badge no longer disagrees with itself. The SPF status shown on your domain overview now matches the SPF page. If your DMARC policy is enforcing (quarantine or reject), a soft-fail ~all SPF record reads as healthy in both places — because your enforcing DMARC policy is what stops impersonation, and that's true whether or not we're currently receiving your DMARC reports.

Managed SPF setup now walks you through it, like Managed DMARC. Turning on Managed SPF is now a clear, numbered path — ① review or add your senders, ② replace your SPF record — the same shape as the Managed DMARC setup, instead of a wall of text with a warning on top.

Authorize a sender that's already in your record. If your published SPF lists a sender that isn't on your sender list yet, the SPF page now explains you can authorize it the same way you'd authorize a sender we found in your DMARC reports.

The SPF focused page now breaks down your DNS-lookup budget sender by sender. SPF allows at most 10 DNS lookups before receivers stop evaluating it — now you can see exactly which include is spending what (for example, include:_spf.google.com · 3 lookups), sorted by cost, so it's obvious where the budget is going. If any of your includes resolve to nothing — dead includes that still count against the limit — we call those out too.

The page also names the services your record authorizes: instead of just showing the raw record, it now reads "Authorizes mail from: Google Workspace, MailRoute, Fastmail" so you can check it against the senders you actually use at a glance.

And when your SPF record has an issue, the summary on your domain's hub card now says what the issue is — "Uses 9 of 10 DNS lookups", "Uses the deprecated ptr mechanism" — instead of a vague "minor issue."

The SPF and DMARC focused pages now include the DNS record you need to publish, right on the page. No switching between tabs or copying from a separate modal — the record is there next to the step that asks for it, with instructions for common DNS hosts.

The DMARC enforcement journey got a rail: five beads across the top show where you are — watching, senders identified, aligned, ready, enforcing. You can see the shape of the journey before you're in the middle of it.

When your domain isn't ready to enforce yet but is close, you can now opt in to an alert: "Notify me the moment it's ready." We'll email you once when your domain clears the readiness gates — not a drip, just the one email you actually want.

Both the SPF and DMARC pages now have a "What changed" history section. For SPF, it shows the flatten history alongside any changes we published on your behalf. For DMARC, it shows each policy advance and when it happened. If you've ever wondered whether the record changed and when, it's now in one place.

The domain advisor now leads with the verdict, not the jargon. Every recommendation states what's true and why it matters before explaining how to fix it — making it easier to know what to do next at a glance.

When a published DKIM key stops working, the per-domain DKIM card used to say only "A DKIM key is published but isn't working" — leaving you to figure out which one. It now names the specific sender (for example, "Your MailRoute DKIM key is published but isn't working"), with the full DKIM page carrying the deeper detail. When more than one key is affected, the card lists them.

The DMARC card on each domain's hub now surfaces the judgment we were already computing, not just a progress bar.

You'll see an alignment pair — your senders (the health signal) next to everyone else (all the mail that isn't from your senders). A low "everyone else" number is expected and good: it means DMARC is correctly catching mail that isn't really you, including impersonators, so we frame it as context, never a problem.

The readiness glance now shows the actual numbers behind the bar — "32 of 50 verified messages · 99% pass" — instead of just "N of M gates." When an authorized sender is dragging your alignment down, we name it: "Mailchimp is failing alignment." And a short "you started watching for impersonators; now you're sending fakes to spam" line tells the story of where this domain's enforcement journey began and where it is now.

The "Can someone impersonate you?" panel was also tightened to lead with the simple Watching → Send-fakes-to-spam → Block rail and a single plain line, rather than a paragraph of explanation.

The DMARC card now shows how close your domain is to safely enforcing DMARC. Once you have senders configured and enough clean mail flowing, the card links directly to your enforcement options.

On the DMARC detail page, the enforcement section shows the status of each readiness gate — senders configured, no recent anomalies, volume, and pass rate — so you know exactly what to watch before advancing.

The SPF detail page now labels the maintenance section based on your current SPF health. When your SPF record has problems or missing senders, the section reads "How do you want to fix this?" so the action is obvious. When everything looks good, it reads "How SPF is maintained" — no false urgency.

The DMARC hub card now shows a visual progress bar for enforcement readiness instead of just a count, making it easier to see how close you are to being ready to enforce at a glance.

The DKIM weak-key warning used to accuse every registered key when any one was short — for example, flagging MailRoute and a default key alongside the one genuinely-weak Google Workspace key. It now names only the specific key that is short, with its exact bit length, so you know exactly what to act on.

SPF sender coverage was also undercounting: senders like MailRoute and Google were missing from the "N of M senders covered" fraction because their stored include host wasn't being checked. The count now reflects your actual sender list.

The coverage line itself now explains the relationship — instead of a bare fraction it reads "Fastmail is on your sender list but isn't in your published SPF record — its mail can fail SPF" — so it's clear what the gap means and why it matters.

The self-managed DMARC enforcement panel now opens with concrete, numbered next steps instead of an abstract phase ladder. Step one is to review or add the services that send mail as you, so your record covers everyone. Step two is the exact record to publish — shown in full, copyable, with plain instructions to add a TXT record named _dmarc at your DNS host (and the option to preserve the tags already on your current record). The none → quarantine → reject progression is still there as supporting context below the steps, so you can see where enforcement is heading — it's just no longer the first thing you have to decode.

The four records on a domain's overview — SPF, DKIM, DMARC, and MX — now lead with what they actually do for you, not just their acronym.

Each card's header pairs a full-size protocol label with a plain-language title and a one-line status: Who can send as you (SPF), How your mail is signed (DKIM), What happens to fakes (DMARC), and How your mail is routed (MX). The status line underneath states the fact in words — "6 of 6 senders covered", "3 keys · 1 weak", "sending fakes to spam · reports on", "via your mail host" — so you can read your domain's posture at a glance before opening anything.

The DMARC line describes the outcome honestly: watching, sending fakes to spam, or blocking fakes — never "to spam" for a blocking policy. Each card still carries its managed/self-managed badge and its "Open →" link into the focused page, exactly as before.

A round of follow-ups makes the managed-vs-self choice read cleanly everywhere it appears.

On the DMARC page, choosing You maintain it now always shows the record to publish and the enforcement next-steps — even on a brand-new domain that hasn't collected reports yet, where the card used to go blank. Choosing mxio maintains it shows only the managed setup, reworked into clear numbered steps: review or add your senders, then replace your _dmarc TXT with the single CNAME (shown in full, copyable, with the record being replaced and what we'd publish), followed by a short "from here, we handle the path" note — we move you from watch-only to quarantine to reject, with your sign-off at each step. You no longer see the self-publish instructions and the managed CNAME setup at the same time.

On the per-domain overview, the DMARC card no longer shows a "Managed DMARC — Available" block while you're self-managing; like the SPF card, it stays focused on your record with a single "Let mxio manage it →" route. The SPF card leads with "Open SPF →". The DKIM card now names the senders that still need DKIM set up instead of saying "some senders". And the managed-card button reads "Managed by mxio" once your domain is actually pointed at us.

The "How does pct work?" explainer is now complete — it covers both today's behavior (RFC 7489) and the in-progress DMARCbis revision, and why reaching pct=100 is what actually enforces your policy.

The per-domain SPF and DMARC pages now open with one symmetric choice — keep maintaining the record yourself, or let mxio manage it — instead of scattering the managed option across buried links and inline pitches. Both options are shown side by side with the same weight, and whichever you're actually doing today is pre-selected automatically from your live DNS — not from whether a service happens to be provisioned behind the scenes. That means the page always matches reality and never claims a record is "managed" before your DNS actually points at us. Toggling to the other option just previews its switch instructions; nothing changes until you act. The choice now stays on the page in every state — including once a record is fully managed by mxio — so taking a record back into your own hands is always one click away: the "you maintain it" side carries the step-by-step hand-back when mxio is currently managing it. The hub record cards were tidied to match — one "Let mxio manage it" doorway and a direct link to the sender evidence, instead of duplicated pitches and an inline expander.

If you added a sender — your newsletter tool, an invoicing app — and it isn't yet in your published SPF record, the next-step advisor now says exactly that: "A sender isn't covered by your SPF record", with the senders named and a link to the record to publish. Previously a more general "your SPF ends in ~all, set up DMARC" recommendation could sit on top of it, so the concrete, fixable coverage gap — the thing most likely to be putting your mail in spam — stayed hidden behind best-practice advice.

We also recalibrated how a ~all ("soft-fail") SPF record is ranked. ~all is the recommended ending for an SPF record and is only weakly meaningful on its own — DMARC is what actually stops spoofing. So a standalone ~all is now a quiet watching note rather than an attention alert, and it always sits below real problems (a malformed DKIM record, a missing or invalid DMARC record, an uncovered sender). The banner will never lead with "your ~all is soft-fail" while a genuine defect waits underneath.

What changed

We reframed how the pct= (percentage) tag is taught across our DMARC guides and error pages:

• The enforcement path is now policy-based: p=none → p=quarantine → p=reject, advanced when your senders are identified and authenticating cleanly — not by turning a percentage dial. This replaces the old pct=10 → 25 → 50 → 100 ramp that several guides presented as the way to enforce.
• Percentage stepping is framed as the "extra-cautious" option — a blast-radius limiter for operators who want to ease in, clearly labeled as optional and not a substitute for confirming sender readiness.
• The honest fallback is stated everywhere pct appears: mail outside the sampled percentage is not delivered — it falls to the next-softer treatment (under p=reject; pct=25, the other 75% is still quarantined).
• The DMARCbis caveat is noted consistently: the updated DMARC standard removes the pct tag, so newer receivers ignore it; treat it as transitional.

Affected articles include the DMARC Deployment Guide, the DMARC Enforcement Journey, the Office 365 setup guide, the email-authentication guide/glossary/101, the "p=none" and "no DMARC record" error pages, and the RFC 7489 standards reference.

Why

The conventional "ramp your policy up by percentage" advice is folklore that has outlived its usefulness. A percentage only changes how much of your failing mail the policy acts on — it can't tell you whether a sender is safe, and you don't even get to choose which fraction is protected. The real work is identifying every legitimate sender and getting it to authenticate; once that's done, you enforce. DMARCbis removes the tag entirely, so doubling down on a percentage ramp now points customers at a mechanism the spec is retiring. Our guidance leads with what actually makes enforcement safe, and keeps the percentage option for the cautious without overselling it.

The Managed DMARC activation screen now spells out the policy progression before you hand over the record: we start in watch-only mode (p=none) so nothing changes for your mail while we learn your real senders, then advance you automatically — and only when it's safe — to sending suspected fakes to spam (p=quarantine) and finally to blocking fakes outright (p=reject). You stay in control and can pause or hand it back anytime. The reassurance now lives at the exact moment you decide to turn it on.

We're consolidating our middle plans into a single Monitor tier, sized by how many domains you watch. The first piece is a free upgrade for everyone already on the $19 plan.

What changed for the $19 (2-domain) plan — automatically, at the same price:

• Health checks every 6 hours — up from once a day, so problems surface sooner.
• 30 days of check history — up from 7 days.

There's nothing to do; the faster checks and longer history apply on their own.

Across your dashboard and our emails, your plan now reads as Monitor (2 domains) or Monitor (5 domains) — one product, two sizes, the same feature set.

On the pricing page and across the site:

• One Monitor card with a 2 / 5 domain switch. The old split between "DMARC Starter" and "Monitor" is gone — it's a single tier you size by domain count ($19 for 2, $34 for 5), with the same features either way and 100k DMARC reports a month across your whole account at both sizes.
• DMARC reporting starts at Monitor ($19). Included from the entry paid tier on up.
• Clearer on what Manage actually is. Pro and Business don't just report — we run your SPF and DMARC for you: one change to your SPF, one to your DMARC, and we keep them correct and walk you to full enforcement at your pace, with your sign-off at each step. Enforcement isn't about cranking a dial up — it's about knowing every sender is ready.

When you turn on Managed SPF, there's a brief window where your apex record delegates to mxio and the new record is still propagating across DNS. Previously, a health check landing in that window could send you a generic "SPF now failing" alert — alarming, since you'd just handed mxio the job of keeping SPF correct.

We now recognize when an SPF failure is self-inflicted by Managed SPF still converging (or mxio repairing the record) and suppress that email. Your domain page still shows the live, honest activation status, and a genuinely broken SPF record on a fully-active domain still alerts you as before.

When you add a sender to your SPF record without Managed SPF, mxio now hands you the single include: to add to your existing record — instead of a fully-flattened list of raw IP addresses. A flattened record you publish yourself silently breaks the moment a provider (like Google) rotates its sending IPs; the simple include stays correct on its own. If adding the sender would push you past SPF's 10-lookup limit, we say so plainly and point you to Managed SPF — which keeps a flattened record correct for you automatically — rather than handing you a record that will break later.

Adding a sender to your domain marks it "authorized" in mxio — but that doesn't mean its mail is actually passing SPF yet. If the sender's include isn't in your published SPF record, its mail can still land in spam, and until now the only place that said so was the dedicated SPF page. A naive user could add their newsletter tool, see "authorized," and walk away thinking it was fixed.

Now the coverage truth shows up where you're actually looking:

• Senders list — an authorized sender that isn't in your published record reads "not in your SPF record yet" with a Review SPF → link.
• SPF record card — when senders are uncovered, the card adds "N of M senders covered — not covered" and a See the record to publish → link.
• Your domain's top-line verdict — instead of an unqualified "✓ SPF," it names the uncovered sender and notes its mail can land in spam.

The framing is calibrated, not alarmist: a best-practice ~all record with an uncovered sender degrades that sender's deliverability — it doesn't take your mail down — so we say exactly that and point you at the one-line fix. (When mxio publishes your SPF for you via Managed SPF, this coverage check is suppressed — your senders are maintained inside the managed record, so there's nothing for you to publish.)

A passing SPF result on the free Domain Health check only means your record is valid for the senders already in it — a one-time DNS scan can't see the newsletters or apps you actually send from. The SPF "pass" row now says so plainly and links you to add the domain to your dashboard, where DMARC reporting and sender discovery surface who's really sending as you (and flag anyone who isn't authorized).

Managed DMARC now finishes setup automatically once your CNAME is live — even if you don't come back to click Verify.

Previously, a domain sat at "Ready" indefinitely if you published the _dmarc record and closed the tab before completing the manual verification step. That's fixed. Once a DMARC receiver sends a report for your domain and your DNS is confirmed to be pointing at mxio, setup completes and your domain moves to active Managed DMARC on its own.

If you're already active, nothing changes. If you were stuck at "Ready," you'll see the domain activate automatically the next time a DMARC report arrives for it.

The "Are you ready to move toward enforcement?" email (sent ~14 days after your first DMARC report) now shows your actual DMARC policy status rather than assuming you're at p=none. If you're already at p=quarantine or p=reject, the email acknowledges that and shifts its focus accordingly. Domains managed by mxio (Managed DMARC) get copy that reflects automated advancement rather than manual DNS steps.

Four fixes to the minutes right after you (or we) touch DNS:

• Managed SPF won't report Active until the whole chain answers. Activation now verifies both your apex record and the managed record on our side, end to end. If our side isn't answering, the card says so plainly — "we're re-publishing it; nothing to change on your side" — and the system re-publishes automatically instead of silently retrying lookups.
• No more false "restore your include" right after a clean activation. Status surfaces now trust the freshest authoritative read of your record, so a just-published change can't be contradicted by a stale cached lookup.
• The DMARC "Verify DNS" button actually verifies DNS. It runs the check against your nameservers and tells you the result — "Found it" or "not visible yet" — instead of doing nothing.
• Waits are honest. The reporting setup screen updates itself, and a Managed DMARC activation that runs past its promised window now names the stuck step and whose side it's on.

Several fixes from a deeper review of the activation and notification journey:

Activations now confirm themselves. The moment your Managed SPF or Managed DMARC delegation goes live — the instant your DNS is pointing correctly — you get an in-app notification and a confirmation email. Previously, the smoothest activations were completely silent. You'd published the record, it resolved correctly, and then: nothing. That silence is gone.

The welcome email pipeline is repaired. A longstanding issue where certain accounts with incomplete channel setup could block the delivery queue for everyone behind them is fixed. If you've been waiting on a welcome email or an onboarding follow-up, the pipeline will clear.

Monitoring no longer alerts on DNS edits we asked you to make. When you follow the activation instructions — replacing your SPF record with the one we provide, or publishing the DMARC CNAME — that DNS change no longer fires a "record changed" notification. The change was expected; the alert was noise. Same for mail server IP rotation: providers like Google regularly cycle the IP addresses behind their MX hostnames, which isn't a meaningful DNS change. That noise is also gone.

DMARC reporting setup on Pro+ leads with the managed path. When enabling DMARC reporting on an account with a Managed DMARC enrollment, the enable dialog now offers the managed CNAME route first — one delegation that covers both the record and the reports, with no TXT to publish and then replace later. The self-managed TXT path is still available as an explicit alternative.

Choosing a paid plan before signing up now lands you back at checkout. If you clicked "Start with Pro" from the Managed SPF page and then completed the email login, you were previously dropped onto the free dashboard with no path back to the plan you'd selected. The "Start with Pro" link now carries your intent through signup so you arrive at the right checkout after your first login.

Four fixes from our end-to-end journey review, all aimed at moments where the product told you the wrong thing:

Reports works from day one. Aggregate DMARC reports usually take 24–48 hours to start arriving after a domain begins reporting — and during that window, the Reports page could fail with an error instead of rendering. It now shows a clear "No reports yet" notice with that timeline, and the Executive Summary renders its full layout so you can see what the report will look like while you wait.

Plan gates look like plan gates. On plans without DMARC reporting, the "Start sending fakes to spam" dialog used to show a loading error that retrying could never fix. It now explains that policy changes are guided by DMARC report evidence and shows where reporting is included — an answer, not an error.

Honest gradual-rollout text. The confirmation checkboxes for partial (pct) policy rollouts previously said mail outside the sample is "not delivered." That was wrong: under the DMARC standard, non-sampled mail falls back to the next-lower policy and is still delivered — quarantine falls back to normal delivery, reject falls back to spam placement. The confirmation text now says exactly that.

Accessible upgrade confirmation. The subscribe confirmation on the pricing page is now announced properly to screen readers: focus moves into the dialog when it opens, stays there while it's open, and returns to where you were when it closes.

Your DMARC record carries a list of addresses that receive reports about who's sending mail as your domain. Three different places in mxio could produce that list, and they didn't all agree.

Now there is one rule, everywhere: we keep your existing reporting addresses and add mxio's — never replace, never repeat. The record suggestion that says it "adds the reporting address" now genuinely adds it to your current record (keeping your policy and your own addresses exactly as they are). Changing your enforcement policy keeps every reporting address you had. And Managed DMARC records can no longer list the same address twice — domains that already published a doubled address are being corrected automatically; no action needed from you.

The dashboard tells this story honestly, too. Where reports are sent now labels each address — yours vs. mxio's reporting address — never lists one twice, and no longer claims "no address is set" while showing you the address two inches above. And when you move a domain to Managed DMARC while already using another reporting service, the page now says what we've always done: we kept your existing reporting address — reports continue to flow there as well as to mxio.

When Managed SPF showed "We've added 8 entries to your managed record," it never said which eight — and they were never new senders at all, just your existing senders' addresses written out the way receivers need them. The comparison now says exactly that ("Same senders (Google Workspace), written out the way receivers need — 8 address blocks") and every entry is one click away behind Show the entries.

Your Senders list used to claim "this is everyone who sends email as you." It can't know that — it's seeded from your SPF record. It now says where the list came from and asks the question that actually catches gaps: send from anything else — a newsletter service, invoicing app, CRM? Add it so we can check its coverage. The free SPF checker got the same honesty: its score is now labeled Syntax & lookup health (it grades the record, not your domain), and the result names what the record authorizes so a missing sender can finally click.

Pricing got a plain-language pass: the plan chooser answers real needs ("Email going to spam → Monitor", "Want it handled for you → Pro"), no surface names the retired "Core" plan anymore, upgrade links land highlighted on the plan they name, plan-gated buttons show their from-price before you click, and the subscribe confirmation states the exact charge — with a one-click switch between annual and monthly — before Stripe does.

Two more truths: a domain whose DMARC mxio manages at the monitoring stage now reads DMARC: Watching on your domain list (not "DMARC: none" next to an "mxio DMARC" badge), and the active Managed DMARC page replaces "we'll guide you forward when you're ready" with the actual checklist — including the part only you can do, like publishing a DKIM record for a sender that isn't signed yet. Nothing advances without your approval; now you can see exactly what it's waiting on.

When mxio prepares a Managed SPF or Managed DMARC record for your domain, it sets up everything on our side first — then waits for you to publish the record in your DNS. Previously, the "ready to activate" reminder emails and the admin follow-up queue would fire based on that preparation alone, even for accounts that had never opened the setup page. That meant some customers received prompts about a feature they'd never touched.

Now, mxio tracks whether you've actually started setup. Copying the delegation record or clicking Verify registers your intent. Reminders only go out after that signal — so if you haven't looked at the setup page yet, you won't hear from us until you do. The setup flow itself is unchanged; this is a timing fix.

When you hand a service to mxio to manage, there's a short gap between publishing the record and that change being visible in DNS everywhere. We used to fill that gap with whatever we'd last seen — which could briefly read as "not set up" right after you'd set it up. Now, for a few minutes after you publish your managed DMARC record, the DMARC card shows a calm "Confirming…" while the change propagates, then settles into the real state once we can see it. No more contradictory flicker during the moment you most want reassurance.

The Advisor is more honest about what's already in place, too. It no longer tells you to "add a DMARC record" when your domain already has one — if we can see a record in your DNS, it says so, and points you at the actual next step instead of an action you've already taken.

And the managed-service indicators now read from shared sources. Whether a managed DMARC record is active, drifting, or still self-managed is decided once — so your domain list, the domain's page, and the Advisor stay in step. Managed SPF indicators on the domain list and domain pages draw on the same observed-DNS signals, so disagreements there are now rare edge cases rather than everyday flicker.

Your recurring health digest email is clearer. It used to lead with a 0–100 "Overall Health Score." That number answered "how do I feel?" but not "what do I do?" — so we replaced it with a categorical status that points straight at action.

Now the digest opens with one plain line — "All domains are healthy" or "2 of 5 domains need attention" — and each domain carries a Healthy / Warning / Failing badge with the specific checks that changed. The 0–100 score stays where it belongs: on the free diagnostic tools and public domain report, where a single comparable number is genuinely useful. On your operational surfaces — the dashboard, the Advisor, and now this digest — we lead with status and the next step.

Your sender list now confirms DKIM setup for more services. For Mailgun, Brevo, Zoho, and Klaviyo, mxio knows exactly which DKIM record to look for — so instead of "can't confirm," each sender now tells you whether its DKIM is set up, set up correctly, or still needs a record published.

A few services (HubSpot, Salesforce, SparkPost, Mimecast) give every customer a different DKIM selector, so there's no single record we can check for in advance. For those, the Add-a-sender step now prompts you to paste your own selector — once you do, mxio confirms it the same way. We don't guess at a selector that might not exist: if a service genuinely doesn't expose a predictable record, we say "can't confirm" rather than show you something misleading.

The senders we recognize in your DNS now roll up across your whole account. On the Reports Overview, a "Found in your DNS" group lists every vendor we've recognized in your domains' DNS that isn't on your verified sender list yet — one row per vendor, showing which of your domains it was found on.

From there it's the same one-click path: pick a domain and Confirm / Add opens that domain's sender list with the vendor highlighted. Recognizing a vendor in your DNS still isn't the same as authorizing it — nothing is added until you confirm. This is the account-wide companion to the per-domain view: if a sender shows up on five of your domains but you've only confirmed it on two, you can see and fix that from one place.

Senders we recognize in your DNS now surface for your review. When you add a domain, we look at its DNS for the signatures of known email vendors. Anything we recognize but that isn't on your verified sender list yet now appears in a "Found in your DNS" group — on the sender map for the domain and on the DMARC Sources tab.

Each one shows the vendor we recognized and a single Confirm / Add action that opens your sender list with that vendor highlighted, so you can authorize it in one step. Until you do, it's just a suggestion: recognizing a vendor in your DNS isn't the same as authorizing it to send as you, and nothing is added on your behalf. Once you confirm it, it moves to your verified senders and leaves the review group automatically.

We now reach out when a new sender starts using one of your domains. If a recognized email vendor (SendGrid, Mailgun, and the like) begins sending as your domain and isn't on your authorized sender list yet, you'll get a short email naming the sender and how much it's sent in the past week — with a one-click path to review it and add it to your SPF record if it's yours.

It's built to be quiet and useful, not noisy:

• Named senders only. You only hear about vendors we can recognize and name — never anonymous traffic, and never a "blocked" or "spoofing" claim. Suspicious mail stays where it belongs, on your in-app sender and Reports surfaces.
• New arrivals only. The email fires when a sender first shows up, not every week for a sender that's been there a while.
• At most one email per domain per week, and it batches every new sender it found into a single message.

You're opted in by default, but there's a New-sender alerts toggle on your notification settings, and every email carries a dedicated unsubscribe link that turns only these alerts off — your digest and other emails are untouched. Your monthly account summary now also shows how many new senders started using your domains that month.

When a vendor sends as your domain through a shared platform (think a tool that signs with its own DKIM key on Amazon SES), we can often recognize it by that DKIM signature in your DMARC reports — even when it isn't on your verified sender list. That signal already showed on the DMARC Sources tab; now it also appears in a "Recognized in unverified mail" group on the per-domain sender map and account-wide on the Reports Overview.

These rows are informational. We recognize the vendor by its DKIM signature, which is an identity hint — not proof it's a configured sender for you, and never a claim that anything was blocked. So there's no one-click action here: if you recognize a vendor and want it on your list, the regular "Add a sender" flow is the place to do it. On the account view, each vendor is one row with the domains it was seen on, so you can spot a shared-platform sender showing up across several of your domains at a glance.

Senders now finds more of who sends as you. When you add a domain, we check its DKIM setup and name services that authenticate through a shared platform (Resend, SendGrid, Mailgun and more) — so they show up in Senders ready to add, even when they're invisible in your SPF record.

Many services send your mail through a shared platform and prove it's really you with their own DKIM signature rather than an entry in your SPF record. Those senders used to be hard to spot. Now, when you add a domain — or re-scan an existing one — mxio reads your DKIM setup and surfaces each recognized service by name, marked "found in your DNS," ready for you to add to your authorized sender list.

Adding a sender that uses a custom value is now guided. For services that give each customer their own SPF include or DKIM selector — Mimecast, Amazon SES, Postmark and others — the Add-a-sender picker now prompts you to paste your specific value, so it's set up right the first time.

Some email services issue every customer a unique SPF include host or DKIM selector, rather than a shared one. Before this change, adding one of those senders required knowing to find and enter that value separately — easy to miss, and easy to get wrong. Now the picker recognizes when a vendor works that way, shows you what to look for, and validates the format before saving. The right value ends up in your record without a separate step.

DMARC Sources now names more of your senders. When a service signs your mail with its own DKIM signature — even from a shared sending platform like Amazon SES or SendGrid — we now recognize it by name in the "unverified mail" section of your DMARC Sources, so you can spot and add legitimate senders faster.

Previously, a sender using a shared IP would show up as an anonymous source in the unknown group, even if its mail was signed with a recognizable DKIM domain. Now, when we see mail signed with a known sender's domain, we surface that sender by name — so you know what it is before deciding whether to add it to your authorized list.

Activating a managed service is one DNS record — but if the instructions aren't landing, we'd rather hear it from you than have you stall.

• A one-click "is this clear? / I'm stuck" prompt now sits at the bottom of the Managed SPF and Managed DMARC activation pages. Say "Yes" and it gets out of your way; say "I'm stuck" and you can tell us what's tripping you up in a sentence.
• We see it immediately. A "stuck" note flags your domain and where you are in setup for us, so we can reach out and help rather than leaving you to figure it out alone. You only send the domain — we fill in the rest on our side.
• It asks once per service per domain, so it never nags.

A common, healthy pattern looks alarming at first glance: a sender shows SPF alignment 0% next to DKIM 100% and DMARC passing. That's normal — many email services sign with your DKIM key but send from their own address, and forwarded mail breaks SPF while the DKIM signature survives. DMARC passes when either SPF or DKIM lines up, so the mail is authenticated as yours.

• A "Why is SPF 0%?" explainer now appears wherever per-sender SPF/DKIM/DMARC alignment is shown — the account-wide sender roster, the per-domain DMARC Sources view, and the sender-discovery list — but only when a sender actually exhibits the pattern. It explains, in plain language, that DKIM is doing the authenticating and that SPF 0% is only a problem when DKIM is failing too.
• "Likely spoofing" is now reserved for senders that fail DKIM. A forwarder keeps a valid, aligned DKIM signature; a spoofer can't forge one. So an unrecognized source that's actually authenticating through DKIM is no longer labeled a probable impersonator — the spoofing call is gated on DKIM not aligning.
• The per-domain Sources verdict explains the SPF 0% case instead of a generic "monitor for regressions," so you can see at a glance why a recognized service is fine.

The net effect: a legitimate sender that authenticates via DKIM reads as healthy, and the impersonation warning is saved for traffic that genuinely can't prove it's you.

The Executive PDF (Reports → Executive Summary → Download PDF) now includes a geography map showing where your mail came from, by sending-source country.

• Countries are colored by mail volume and DMARC alignment — teal for well-aligned traffic, red for low alignment.
• The map sits above the existing per-country breakdown table and gives you an at-a-glance picture of your global authentication posture.
• As with all the report's figures, the map shows alignment as reported by receiving mail servers — what your DMARC policy directs them to do, not a guaranteed outcome.

A sweep of fixes so every screen tells the same honest story while you set up and manage email authentication.

• A duplicate SPF record now reads as "remove the extra one" — everywhere. Publishing two v=spf1 records is a permanent error that stops receivers from evaluating SPF at all. The hub card, the advisor, the delivery-foundation panel, and the focused SPF page now all say the same thing — and never tell you to "add a record," which would only deepen the problem.
• Managed setup converges on its own. If you leave the domain page open after publishing your record, it now confirms and updates by itself (bounded, and only while the tab is in front of you) instead of waiting for a manual reload.
• One DMARC path, not two. When Managed DMARC is set up, the advisor no longer also tells you to add a reporting address by hand — the managed record carries it. And the "set up Managed DMARC" suggestion now reads as an available option, not an "action needed" defect.
• Over-budget SPF? Here are your options. A record over the 10-lookup limit now shows two clear paths: let mxio manage it (recommended — it flattens the record and auto-tracks vendor IP changes), or trim senders yourself with a live "you'd be at N/10" as you consider each one.
• Self-managers get the whole record. When a sender isn't covered by your SPF record, we now show the complete, copy-pasteable record to publish — plus an in-app heads-up so you know a sender is uncovered without having to go looking.
• Calmer, truer signals. A brand-new domain's mild soft-fail reads "Recommended next step," not "Action needed," on the domain list (matching the per-domain page); a ~all soft-fail no longer flags your real-mail delivery as a problem (it's a DMARC-enforcement note); and a DKIM coverage gap reads "Setup," not "Warning."
• Handing a domain back is easy to find. "Take back control" of Managed DMARC is now reachable on the focused DMARC page, and the handback warns you if you'd stop receiving reports unless you add your own rua= address.

Managed SPF now reliably offers you an activation path once your domain's SPF record is published — not just at the exact moment you add the domain.

• Add the domain first, configure DNS later — and it still works. Previously, Managed SPF was set up in a single pass when you added a domain. If your SPF record wasn't published yet (a brand-new domain, or DNS that hadn't propagated), there was nothing to set up — and nothing tried again later. Now a routine check that observes your live SPF record automatically completes the setup, so the per-domain page shows you the record to publish within a short window.
• No more "no SPF record" on a domain that clearly has one. When we look at your domain to set up Managed SPF, we now read your SPF record straight from your domain's nameservers rather than a shared cache — so a record you just published is seen right away instead of being missed for up to half an hour.

This is part of a standing automated check that verifies, end to end, that the activation instructions we show you are valid and followable: what we tell you to publish, when published exactly as shown, produces a working setup — and the common wrong move (a duplicate or wrong record) is caught rather than silently accepted.

A follow-up sweep so the SPF and DMARC surfaces tell one consistent, honest story — during setup, after activation, and when something drifts.

• Opening the SPF page no longer claims you've published when you haven't. The page checks your DNS quietly in the background; that background check no longer flips the card into a "Confirming — you've published the record / nothing else to do" state before you've actually published. The activation instructions stay in front of you until your record is live. (The same fix applies to Managed DMARC.)
• Two SPF records reads as "remove the extra one" — on every surface. Publishing two v=spf1 records is a permanent error. The advisor, the delivery-foundation panel, the SPF card, and the published-record strip now all say "You have N SPF records — remove one" and the same wording everywhere — never "No SPF record."
• Panels converge the moment a managed service activates. After you publish your record, the advisor and the "Will your real mail be trusted?" panel update in lockstep with the card instead of one of them lingering on a stale "broken" until the next background cycle.
• A freshly-added domain doesn't flash false failures while DNS propagates. If you add a domain seconds after setting up its DNS, the page now shows a calm "we're still checking — propagation can take a few minutes" instead of hard red "no SPF record" failures that resolve on their own.
• An already-protected domain leads with reassurance. A domain already at the strongest DMARC policy now leads with "All clear — impersonators are blocked," with the Managed DMARC offer kept as a quiet, secondary option rather than a top "action needed."
• A _dmarc conflict shows on the hub card. If your _dmarc record has both a CNAME and a TXT (or points at another DMARC service), the hub card now flags it directly, not only when you click Verify.
• DKIM setup reads consistently. A recommended DKIM setup step now reads "Setup" on both the hub and the focused page; a key that's actually broken reads "Warning" on both — they no longer disagree.
• Smaller polish: the "real mail trusted?" summary no longer overclaims when there's a soft-fail caveat, the DMARC card no longer briefly says "Setting up…" while its body says "Available," and the "Skip for now" option on the sign-in setup screen is easier to find.

Turning on a managed service is one DNS record — but it helps to see the whole flow before you make the change.

• New guide: How Managed SPF and Managed DMARC actually work — step by step. It walks the real flow in plain language: what mxio already set up on our side, the single record you publish (the SPF include / the DMARC CNAME), how we confirm it, what Available, Activating…, and Active mean, and how to hand it back anytime. You keep ownership of your zone throughout.
• Linked right where you activate. A "How does this actually work?" expander now sits on the SPF and DMARC activation pages, with a link straight to the matching section of the walkthrough — so the explanation is one click from the record you're about to publish.

The account Reports Overview stops being a dead end — it routes you to where the fix lives.

• A domain picker on the Overview. Scope the whole view to one domain (or keep "All domains"). Picking a domain makes its sender rows directly actionable.
• Suspicious and unregistered senders are now links. A recognized sender that's failing DMARC links straight to that domain's Senders page with the sender highlighted, so you can authorize it (if it's really yours) or leave it (your DMARC policy already handles spoof). An unregistered-but-passing sender links the same way, framed "Add."
• At "All domains," a row hands you the door. Because a portfolio-wide row can touch several domains, it expands to the domains it appeared on — each a one-click jump into that domain to act. No more seeing a problem at the account level with no way to act on it.
• Honest by design. The "Unidentified senders" bucket — unrecognized IPs with no single sender to add — stays informational (with an optional "Investigate in DMARC sources" at a single domain), never a misleading link to an empty page. The Executive Summary and its PDF stay read-only.

A sharper, more honest definition of "suspicious" on the account Reports — so your real senders stop being accused.

• One stray failure no longer brands a legit sender. Before, any sender with even a single failing message landed under "Senders failing DMARC" — so your own Google Workspace mail (98% authenticated) could show up as a suspicious impersonator over one forwarded message. Now a sender only counts as suspicious if it's materially failing and not already established — a high DMARC pass rate is cryptographic proof the mail is really yours (an impersonator can't forge DKIM), so its occasional failures are forwarding noise, not spoofing.
• The headline number matches the list. The "suspicious messages" count is now the sum of just those materially-failing senders, so the number and the senders behind it always agree — and it stops counting forwarded legitimate mail as impersonation.
• Legit senders aren't sitting under a "Suspicious" header anymore. The panel is now "Who's sending as your domains," with the suspicious count as the lead alarm inside it. Senders that weren't flagged carry a clear "Not flagged" marker, and your authorized senders are marked "Authorized" — so nothing reads as accused when it isn't.

The account-wide Reports (Overview, Executive Summary, and the downloadable Executive PDF) now tell a straighter story about who's sending mail as your domains.

• Two groups, not one mixed list. The senders behind the "Suspicious messages" number are now split into Senders failing DMARC (the ones that make up the number — each shown with its failing count) and Not on your authorized-sender list (senders that pass DMARC fine but aren't in your registry yet). Previously a fully-passing sender like a forgotten Barracuda or Fastmail could appear under an "impersonation" heading it didn't belong to.
• The headline number is traceable. Each suspicious sender row leads with its failing-message count, so the totals add up to the headline instead of being buried under each sender's total volume.
• The unidentified-sender bucket has a name. Mail from unrecognized senders now reads "Unidentified senders" instead of an unlabeled row.
• Consistent wording. The headline is "Suspicious messages" across the Overview and the Executive Summary (it previously read "Spoofing attempts detected" on one tab). As always, we never claim mail was "blocked" — only what your DMARC policy directs receivers to do.

The "Who sends mail as you" list on each domain now tells two different stories apart.

• Recognized but not on your list — a service we can identify (e.g. an email platform) that you haven't added yet. These keep the + Add button: you know what it is, so adding it to your authorized senders makes sense.
• Seen sending — not verified as you — an unidentified source with no recognizable identity that isn't authenticating. These no longer offer + Add (adding one would have authorized a possible impersonator). Instead, each row shows the message volume, how many IP addresses it came from, and an Investigate → link that opens the full DMARC source detail — IP, reverse DNS, network, and country — so you can decide what it is. When a source is actually failing DMARC, the row says plainly that it's being seen impersonating you and that your DMARC policy is handling it.

This makes the list safe to act on: the only thing you can "add" is something we recognize, and anything that looks like spoofing routes you to the evidence instead of the authorize button.

Managed DMARC now has its own section on the homepage, symmetric with Managed SPF. It shows the path from monitoring to enforcement — Watching every sender, then fakes sent to spam, then fakes refused — advanced automatically as your authorized senders come into alignment, with the Advisor telling you the one next step.

We also reordered the homepage so it reads in one line: see who sends as your domain (DMARC Reporting) → we keep it right (Managed SPF, Managed DMARC) → always-on monitoring → your dashboard.

A round of fixes to make turning on Managed SPF and Managed DMARC feel instant and honest:

• Activation confirms in seconds, not minutes. While you're on a managed-service setup page, we now check your DNS every few seconds and flip the card to Active the moment your change is live — instead of waiting for the next background health check. Fixing a CNAME conflict is detected the same way, with no extra click.
• Honest framing on the SPF card. A ~all "soft fail" now points you to DMARC (where enforcement actually happens) instead of suggesting Managed SPF "fixes" it — Managed SPF keeps your ~all exactly as it is. An active managed record no longer shows a yellow "Warning" for that intentional setting.
• Calmer first day. A domain you just added with a normal p=none + ~all baseline reads "Recommended next step" rather than red "Action needed." And right after you enable Managed DMARC, the advisor reflects the staged journey ("we'll guide you to enforcement once reports arrive") instead of telling you to enforce immediately.
• "Reports incoming," not "paused." Just-enabled DMARC reporting now says reports are on the way (usually 24–48h) — it's only labeled paused when it's genuinely paused.
• Consistent cards. Managed SPF and Managed DMARC now share the same status block, status words, and upgrade treatment, so two adjacent cards never look like two different products. Free-plan cards lead with a single, clear upgrade step.
• Quieter, smoother setup. Clearer "skip for now" on the 2FA step, empty-portfolio "Set up…" buttons that take you straight to adding a domain, and no stray console errors on free-plan domains.

A few refinements to how we explain mxio:

• The homepage hero now says it straight: We manage SPF and DMARC for you — or show you exactly how. A three-point summary sits right under it — see every sender by name, SPF & DMARC managed or self-served, reach DMARC enforcement safely.
• The three service-page heroes (DMARC Reporting, Managed SPF, Managed DMARC) now share one consistent layout — same alignment, spacing, and eyebrow order — so nothing shifts as you move between them.
• Managed SPF and Managed DMARC each gained a "Two ways to use mxio" section: hand the record to us, or keep managing it yourself with our reporting and the Advisor telling you exactly what to publish and when it's safe to enforce. It's not all or nothing — and you own your records either way.

We've sharpened how the site explains what mxio actually does. The thread running through all of it is your Senders — the list of services that send mail as your domain.

• The homepage now leads with the managed story built around that list: see every sender by name, make one last change to your SPF and DMARC, and we keep them right from there — while you still own the records.
• The three service pages (DMARC Reporting, Managed SPF, Managed DMARC) now read as one platform built on your Senders list, not three separate tools. Each links to the other two.
• Pricing opens with the same idea: every paid plan is built on your Senders, and from that list we keep your SPF and DMARC right for you — or tell you exactly what to publish.
• A new guide, Who Sends Mail as Your Domain, explains why your senders are the foundation of SPF, DKIM, and DMARC, how to find the ones you didn't know about, and how mxio either advises you or takes on the upkeep.
• The Managed Email Authentication guide gained a plain section on how the handover actually works — record by record, what stays yours, and how to take it back. The honest version: you delegate the upkeep, not the ownership.

No features changed — this is about making the story match the product.

The Domain Status table headers are simpler — the small "(i)" markers that cluttered each column (and quietly linked to billing) are gone. Free-plan accounts now see a single, clear note that DMARC details need a plan, instead of four cryptic icons.

The monthly account summary now reports a full calendar month (e.g. "May 2026" covers May 1–31), so the label and the numbers always line up. Previously the window was a rolling 30 days that didn't quite match the month name.

The Executive Summary tab in Reports now has a domain selector. Leave it on All domains for the account-wide picture, or pick a single domain to print a one-page summary scoped to just that one — the verdict, pass rate, delivery, and senders all narrow to the domain you chose. Same honest framing throughout. Available on DMARC Starter and up.

Turning on Managed SPF or Managed DMARC for a domain is now a clearer, no-surprises step:

• The SPF and DMARC cards on a domain's page now show status plus a single "Let mxio manage it →" link. Clicking it just takes you to the setup page — it doesn't change anything in your DNS. Previously a freshly added domain could show DNS records to publish before you'd opted in.
• The setup page names the move plainly ("You're looking at moving your-domain.com to Managed SPF/DMARC"), explains what changes and what stays the same, and makes the one commitment point explicit: nothing changes until you publish the record.
• There's a genuinely-free "Keep it self-managed" exit on the setup page that takes you back with nothing to undo — and switching back to self-managed after activating stays available too.

You always keep full control of your DNS zone, in both directions.

We tightened the window right after you turn on Managed SPF or Managed DMARC — the moment the product used to second-guess a change you'd just made correctly:

• No more false "DKIM is broken" right after activating Managed SPF. Publishing your SPF change no longer trips a false DKIM failure (or a health-score drop) for CNAME-based senders like MailRoute, Google, SendGrid, and Mailchimp.
• The advisor and the SPF page now stay calm while we confirm your change. Right after you publish, they show a neutral "Confirming…" instead of telling you to "restore" or "publish again" the record you just added.
• DMARC reporting is ready at setup — no "Setting up…" wait. We publish the reporting authorization the moment Managed DMARC is provisioned, and the page keeps refreshing on its own until everything settles.
• Honest SPF coverage. A not-yet-activated domain no longer reads "active — nothing to do," and we no longer warn that activating "may drop coverage" for senders that are already folded into your managed record.
• Accessibility: the closed Senders panel no longer leaks its controls to screen readers and keyboard navigation.

The Reports page had two per-domain tabs — Domains and Enforcement Status — that both showed your domain and its DMARC policy. We've merged them into a single Domain Status tab.

• One row per domain shows everything in one place: sending status, DMARC policy, alignment %, messages for the period, Managed SPF status and last deploy, and when the domain's settings last changed.
• The Sending Status and Policy filter chips carry over, alongside the date-window picker.
• One Open → action takes you straight to the domain — where you both view and configure it.
• Old links to #enforcement-status now land on the merged Domain Status tab automatically.

The monthly account-summary email now comes with a polished PDF attachment you can forward straight to leadership — your DMARC pass rate, mail volume, how many domains are enforcing, the receivers' reported dispositions, and a plain-English verdict, all in one page.

You can also turn the monthly summary on or off yourself from the notifications settings — no need to ask support. When it's on, we show you when the next summary will arrive.

As always, the report is honest about what it can and can't claim: it describes what your DMARC policy directs receivers to do with impersonators, never a fabricated "we blocked N messages" figure.

The monthly account summary email is now on by default — every account gets a once-a-month read on its email-authentication posture, and you can turn it off any time from notification settings.

When it arrives, the attached PDF is now the full Executive report — per-sender SPF/DKIM/DMARC, where mail came from, and an honest read on impersonation risk — the same one you can download in-app, not a stripped-down version.

Single-domain Executive PDFs now include the country-of-origin breakdown too.

As always: the report describes what your DMARC policy directs receivers to do — it never claims mail was "blocked."

Two upgrades to the Reports page:

• The account Overview now shows SPF, DKIM, and DMARC alignment for each sender — not just an overall figure — so you can see exactly which service is misconfigured.
• A new Download PDF button on the Executive Summary tab produces a polished, presentation-ready report you can forward to leadership: headline numbers, what receivers did with mail claiming to be you, who sends as your domains (with their authentication), where mail came from, and an honest read on impersonation risk. Scopes to all domains or a single domain. (The browser Print / Save as PDF option stays too.)

As always, the report describes what your DMARC policy directs receivers to do — it never claims mail was "blocked."

The hardest part of owning email security is often proving it's working to someone who doesn't live in DNS. The new Executive Summary tab in Reports gives you a single, plain-language page you can print or save as a PDF and forward to a CEO or CMO.

For your whole account over the window you choose, it leads with:

• A one-sentence verdict — e.g. "3 of 5 domains are enforcing DMARC. The other 2 are still in monitoring."
• Spoofing attempts detected, authenticated email volume, DMARC pass rate, and domains protected — the four numbers an executive actually asks about.
• Is your mail being delivered? and who sends mail as you — the delivery picture and your sender roster.
• A trend arrow on your pass rate vs. the prior period.

It's deliberately honest: we never claim we "blocked" mail. When your DMARC policy is enforcing, we say your policy directs receivers to quarantine or reject impersonators — a statement of what your policy does, not a number we can't actually prove. A short methodology footnote spells out exactly what each figure means.

Hit Print / Save as PDF and you've got the artifact. Available on DMARC Starter and up. A scheduled monthly version that lands in your inbox automatically is coming next.

A few rough edges on the Reports page are smoothed out:

• The redundant Email Insights tab is gone — it duplicated the Activity page (in the left nav), so there's one place to see your account history now.
• The sender filter now offers autocomplete from the senders we've actually seen on your account, and only appears on the tab where it does something (Domains).
• The Senders tab has a short intro explaining what Senders, In SPF, and Discoveries mean.
• The Overview impersonation summary reads more clearly — it separates what the suspicious messages are from what your DMARC policy directs receivers to do about them, without ever overstating it.

We walked the whole "set up a domain, then try the managed services" flow end to end and fixed the places where it told you two different things at once.

What changed

• One DMARC instruction, not two. When Managed DMARC is provisioned for a domain, the DMARC card now shows only the managed path (publish the _dmarc CNAME to activate). It no longer also asks you to add a self-managed reporting TXT record — two mutually-exclusive changes at the same DNS name — and it never reverts to asking for the TXT after you've published the CNAME.

• "Let mxio manage it" can't strand you. On a plan that doesn't include Managed DMARC (or before it's provisioned), the "Let mxio manage it" button now takes you to the right place to enable or upgrade, instead of opening a wizard that asked you to publish a blank record and then waited forever.

• The advisor stops contradicting the card. If your domain has a published p=none DMARC record but mxio reporting is off, the SPF soft-fail tip no longer claims you have "no DMARC record" — it correctly says your DMARC isn't enforcing yet.

• Plan label fixed. The DMARC reporting upgrade prompt now says DMARC reporting is available on DMARC Starter or higher (it was incorrectly saying "Pro").

• "Check DNS" for Managed SPF is reliable. Right after you publish your SPF record, the check now confirms it immediately instead of saying it can't see the record for a few minutes.

• Your senders show up right away. A newly added domain now lists the senders found in your SPF record immediately, instead of staying blank until you added one by hand.

• Smaller fixes: the SPF comparison now counts DNS "entries" instead of mislabeling IP ranges as "senders"; the DKIM card shows an at-a-glance health pill; a duplicate "Add sender" button was removed; a just-published handover now shows a brief "confirming…" note instead of momentarily showing the old record; and a dead "Set up Managed SPF" link was fixed.

Activating Managed SPF or Managed DMARC should feel like the system is on your side the moment you make the change. A round of fixes makes that true end to end.

No more false "you broke it" right after you did it right. Previously, the instant you published your Managed SPF record, the page could flash a red "SPF is broken — restore the include" warning — pointing at the exact record you'd just added — and the refresh button didn't clear it. That was a timing artifact: we flipped the service to active off live DNS, but the card was reading a moments-old cached observation. Now the card shows an honest "Confirming…" state, checks the real record at your nameserver, and flips to active on its own within a minute or two. "Check DNS" actually re-checks.

The card stops contradicting itself. A correctly-flattened SPF record no longer reports a phantom "policy mismatch," and the "is your mail trusted?" summary and the SPF card now always agree — they read from one source of truth.

Managed DMARC tells you to replace, not add. If you already have a _dmarc record, turning on Managed DMARC now says "Replace your existing _dmarc TXT with this CNAME" and shows the record you're replacing — because a name can't carry both. If both are present, "Verify" tells you to remove the old one instead of falsely reporting success.

Honest plan gates and honest value. On a plan without Managed DMARC, "Let mxio manage it" now leads to a clear "Managed DMARC requires Pro or higher — Upgrade to Pro" instead of quietly dropping you into self-managed setup. And we no longer claim Managed SPF "fixes" a soft-fail it doesn't change — its real value is stated plainly: it keeps your record under the 10-lookup limit and updates vendor IPs for you.

Calmer first impression. A brand-new domain with a normal monitoring baseline now leads with "Recommended next step" rather than a red "Action needed" — we save the alarm for things that are genuinely broken.

Until now, the rich DMARC analytics — the sender breakdown, the world map, the alignment trend, the volume-by-reporter chart — only existed one domain at a time. If you run more than one domain, you had no single screen that answered "how is my email authentication doing, across everything I own?"

The new Overview tab in Reports does exactly that. It's now the first thing you see when you open Reports, and it shows, for all your domains together over a 7/30/90-day window you choose:

• Spoofing attempts we detected — mail sent from sources you haven't authorized that failed DMARC. We split it into mail on domains where your DMARC policy tells receivers to quarantine or reject impersonators, versus domains still in monitoring. We're careful here: we tell you what your policy directs receivers to do, not a claim that every message was blocked.
• Is your mail being delivered? — the allowed / quarantined / rejected breakdown receivers reported.
• Who sends mail as you — your sending services rolled up across every domain, with their alignment rates, plus the unauthorized sources worth a look.
• Where your mail comes from, the alignment trend over time, and which mailbox providers are reporting — all account-wide.

Available on DMARC Starter and up. This is the foundation for a downloadable executive summary you'll be able to hand to your boss — that's coming next.

If you selected several domains and clicked Delete, the page gave almost no sign anything was happening. The only cue was a tiny "Deleting…" label on a button, and the rows didn't change until you reloaded — so a delete that takes a few seconds (domains with managed services and lots of report history take longer to tear down) looked like it had silently failed.

What changed

• The selected rows disappear immediately. When you confirm a bulk delete, those domains are removed from the list right away so the page reflects what you asked for instead of sitting still.
• A clear in-progress indicator. While the delete runs you now see a "Deleting N domains…" status with a spinner — not just a 4px text change on a button.
• Failures are visible and the list stays honest. If a delete doesn't fully succeed, an error is shown and the list is refreshed against the server, so any domains that weren't actually deleted come back instead of vanishing.
• Same treatment for bulk Pause, Resume, and Check Now, which share the in-progress indicator and the always-refresh behavior.
• The monitored-hosts list got the identical fix — bulk actions there behaved the same way and now give the same feedback.

The per-domain DKIM page could contradict itself: a green "Healthy — DKIM keys observed" banner sitting directly above "1 sender recommended for setup." And once you'd added a selector, nothing on the page told you whether its key was actually live in DNS — that signal only showed up as tiny text in the status line.

What changed

• One status, top to bottom. The DKIM banner is now coverage-aware and matches the domain list's DKIM card exactly. If a sender still needs DKIM setup, the banner says so ("Some senders aren't set up for DKIM") instead of claiming everything's healthy. A real problem with your published keys still leads — coverage never hides it.
• An "Observed keys" strip shows which selectors are live. A new always-visible strip lists every selector your latest health check actually probed, each with a status: Working (key found and verifying), Not verifying (key published but failing), or No key found (nothing in DNS yet). Selectors we haven't checked yet stay quiet until the next cycle.
• Selector tools demoted to "Manage selectors manually." The per-sender setup list is the guided path; the raw selector tools (auto-discover, provider lookup, manual entry, remove) now live behind a collapsed "Manage selectors manually" section — separate from the read-only status strip above.
• Provider lookup before manual entry. Inside that section, "Add by provider" now sits above the manual text box — picking your provider is easier than typing a raw selector name from memory.

The DKIM page used to show a healthy DKIM check next to an unconditional "publish these records" list — a confusing contradiction. Now it tells one honest story per sender.

What changed

• Per-sender DKIM coverage. The DKIM page shows each of your registered senders and whether it actually has a working DKIM key: signing (green), recommended for setup (with the exact record to publish), or published-but-not-working.
• One consistent story across three places. The domain-list DKIM chip, the per-domain DKIM card, and the DKIM page now agree — if a sender needs DKIM, all three say "setup" (amber), never "failing".
• Recommended, not failing. A sender missing DKIM is an opportunity, not an error — your existing DKIM keeps working, and the copy says so.
• Paste a selector for any sender. For providers that use random selector names (Amazon SES, Postmark) — or your own custom senders — paste the selector your provider gave you and we'll confirm it on the next check.

Adding a domain used to leave the per-domain page on "Running first health checks…" for up to a few minutes — the domain was queued for the next monitoring sweep rather than checked on the spot.

What changed

• The first health check fires the moment you add a domain. MX, SPF, DKIM, and DNS hygiene results now appear within seconds, and the per-domain page fills in on its own as they land.
• Normal monitoring continues as before. After the first check, the domain follows its regular recurring schedule.

A full audit of every per-domain detail page surfaced places where one part of the page contradicted another — a card warning while the check passed, a "no record" message on a domain that had one, a status code leaking into copy. This pass makes the page tell a single, honest story top to bottom.

What changed

• A paused domain says "Paused." When a domain is paused for billing or in a grace period, the header pill now reads Paused instead of a green "Monitoring" — and the DMARC reports panel frames it as paused-but-still-protected, never a raw dmarc_not_enabled code, and never "contact support."
• "No SPF record" vs "SPF has a problem" are now distinct. A domain with no SPF record is told to add one ("Add SPF →"); a domain with a broken record is told to fix it ("Fix SPF →"). The SPF status badge and the card's colored edge always agree.
• DKIM that isn't set up is no longer flagged as a defect. When no DKIM selector is registered, the card and the delivery leg now say "DKIM isn't set up yet — add a selector to monitor" (a neutral, optional suggestion) instead of implying something is broken. A DKIM key that is published but invalid still says so plainly.
• The DMARC card stops asking you to publish a record you already have. If your DMARC record exists but its reports don't route to mxio, the card now shows your published record and frames the change as adding the reporting address — not publishing from scratch. The "reports take 24–48 hours" reassurance only shows for the first few days after you turn reporting on; after that it switches to "Reporting is on. No mail observed for this domain yet."
• Sender list copy matches reality. Once DMARC reporting is configured, the empty sender table says "reporting is on — these columns fill in once the first reports arrive" instead of prompting you to set it up again. The third checkmark on an unrecognized sender now reads Aligned, not "Trusted," so it doesn't collide with that sender's "Needs review."
• The excluded-mail line counts correctly and is phrased in plain terms ("excluded from alignment stats") rather than referencing an internal score.

When you added a brand-new domain, the per-domain page would briefly claim your email was "set up correctly" — green checks on SPF and Delivery — before a single health check had run. The records below it honestly said "the check hasn't run yet," so the page told two opposite stories at once. It also froze on "Running first health checks…" until you manually reloaded.

What changed

• No more false all-clear. A protocol shows a green ✓ only when its check has actually passed. Before the first checks land, each shows a neutral em-dash (—) and the page says "We're still checking your records" — never "set up correctly."
• Results now appear on their own. While the first checks are running, the page refreshes itself and fills in MX, SPF, DKIM, and DNS results as they complete — no manual reload needed. It stops refreshing once everything's in.
• No phantom history. The sender list no longer says "last 30 days" on a domain that has no DMARC reporting yet — there's no 30-day window of data to summarize, so it just shows your sender list.

The "What changed, and what we keep an eye on" section on each domain's detail page now shows more detail. The Delegation row lists the observed nameservers by name instead of just a count. The MTA-STS row shows the published MTA-STS TXT record when MTA-STS is configured.

On Pro and Business plans we set up the behind-the-scenes records for Managed SPF and Managed DMARC the moment you add a domain — but that's provisioning on our side. Until you actually point your DNS at us, the record is still yours to maintain. The per-domain SPF and DMARC cards used to jump straight to the teal "Managed by mxio" badge as soon as we'd provisioned, which overstated what was live.

What changed

• The badge now tracks observed delegation, not provisioning. The SPF and DMARC cards read "Managed by mxio" only once your DNS is actually delegated to us — your apex SPF includes our record, or your _dmarc CNAME points at our zone and is verified.
• Provisioned-but-not-delegated domains read "Self-managed." A brand-new domain whose managed service is set up on our side but not yet wired up in your DNS now honestly shows "Self-managed" alongside the "activate with one DNS change" offer — the offer and the badge agree.
• No change to what's actually published. This is a labelling fix only; your records and the activation flow are unchanged.

If you weren't using Managed SPF, the Senders page banner used to imply the list did nothing for you — "won't be added to your SPF record automatically." But mxio uses your authorized-sender list whether or not Managed SPF is on.

What changed

• The banner leads with purpose, not an upsell. It now explains that mxio uses your sender list to track DKIM coverage, make sense of your DMARC reports, and recommend what your SPF record is missing.
• Self-managers see the value too. If you manage your own SPF record, we use this list to recommend what's missing — Managed SPF is now framed as the optional "we'll keep it in sync for you" upgrade, not the only reason to maintain the list.

A domain's screen looks at email authentication from a few angles at once — is it healthy? is it set up? is mxio managing it? are reports flowing? Those angles are supposed to agree. We found and fixed a set of cases where they could quietly contradict each other on the same screen, and added tests so they can't drift apart again.

What changed

• A "needs a look" item is never shown as a green checkmark. When a check comes back with a soft warning or an inconclusive result, the delivery-foundation summary now shows it as a caution instead of a clean ✓ — matching what the detail card already said.
• A missing or broken SPF record is never hidden behind "Setting up". If your published SPF record is missing, over its lookup limit, or broken, the SPF card now leads with that problem and how to fix it — with "or let mxio manage it" as the secondary option — instead of showing managed-SPF onboarding copy over the top of a real problem.
• The impersonation verdict credits quarantine. A domain at p=quarantine now reads "Partly — spoofed mail is sent to spam, not blocked" (not the same "your domain isn't protected" as a domain with no policy at all). At p=reject it reads "No — impersonators are blocked."
• "Consider advancing to reject" only appears when your data supports it. At quarantine, the advisor stays calm ("All clear — monitoring") and only suggests moving to full rejection once your authorized senders are consistently aligned — never on thin data.
• A single MX record is advice, not a warning. Having one MX host is fine for most setups, so it's now shown as informational ("add a backup MX for failover if you want") rather than a yellow warning that made an otherwise-healthy domain look like it had a problem.
• No more raw internal codes in the DMARC reports view. A domain without reporting enabled now shows a friendly explanation instead of an internal code.
• Clearer DMARC card states. When both a CNAME and a TXT exist at _dmarc (a conflict receivers can't resolve), or when a managed domain's DNS has drifted away from mxio, the card now says so plainly instead of claiming "Managed active."

A pass to make each per-domain card prove what it claims, with the actual DNS record right there.

What changed

• SPF drift gives the right fix. When your SPF record stops pointing at the record mxio maintains for you, the card now says exactly what to do — re-publish your SPF record at your DNS host (the record is shown) — instead of a button that only re-publishes the part mxio already manages. Only you can change your own SPF record; we don't, and now the card says so. It also spells out the consequence: senders that rely on your managed SPF may start failing.
• The DMARC card confirms reports reach mxio. Instead of a vague "DNS is set up," the card shows your published DMARC record and confirms its reports go to mxio.
• MX hosts are shown on the card. The MX card now lists the mail hosts we observe, with their priorities.

When you open a domain, the first thing you usually want is simple: what's actually published right now? That information was there, but inconsistent — the SPF card labeled it one way, the DMARC card another, and the MX card showed its hosts with no label at all — and it was often buried partway down the card.

What changed

• One unified "Current published record" strip, at the top of every card. The SPF, MX, and DMARC cards now each lead with the record we observed at the last check, in the same monospace box with the same label and a quiet "seen at last check" note. No more hunting for it, no more three different treatments.
• MX records are labeled and sorted. Your mail hosts now appear under "Current published records" with their priority, sorted, instead of an unlabeled list.
• When nothing is published, it says so. A domain with no SPF/MX/DMARC record shows a plain "No record published yet" in the same spot — still useful, still consistent.
• Removed a duplicated protocol heading. The SPF and DMARC cards had started showing their name twice ("SPF" right under "SPF"); the card now shows it once, keeping the health badge.

The detailed views haven't gone anywhere — the DMARC "Current configuration" panel, the SPF drift and setup guidance, and the per-record focused pages all still carry the deeper detail. This just makes sure the record you're publishing is the first thing you see.

The handover step used to tell you how many senders were on file. A number isn't something you can actually check against — so it now shows you the list.

What changed

• The confirm step lists your actual senders. Before you hand SPF or DMARC to mxio, you see every sender we'll include — your email providers, plus any custom include: and raw ip4 / a / mx entries — not just a count.
• Senders we see but you haven't added are flagged. If your DMARC reports show mail from a sender that isn't on your list, it's surfaced separately with a one-click Add, so you can include it before the switch instead of discovering a delivery problem after.
• It never blocks you. The flagged list is a prompt, not a gate — you stay in control of who's authorized.

If you run a domain but don't think about email authentication for a living, the per-domain screens asked a lot of you. They talked about your "apex SPF record," whether senders were "aligned," "softfail" versus "hardfail," and "DMARC aggregate (RUA) reports." We did a systematic plain-language pass so every primary label, status line, and button reads the way a knowledgeable friend would explain it — with the technical detail still one click away for anyone who wants it.

What changed

• DMARC stages are labeled by what they do to mail. "Monitor / Quarantine / Reject" now read as Watching → Send fakes to spam → Block fakes, and advancing always carries the honest reassurance: mail from senders on your list is never affected — only mail that fails the checks, including impersonators.
• "Aligned" became "set up correctly." The sender list ("Who sends mail as you") now uses plain column labels with hover explanations, and shows "No data yet" instead of an ambiguous "0 msgs" when reporting hasn't filled a column in.
• Your SPF record is shown the way you'd publish it. The internal flattened record we maintain behind the scenes is tucked behind a "Show what we publish behind it" expander, so the record you actually paste into DNS leads.
• Strict vs lenient, with the stakes spelled out. The SPF policy choice now reads Lenient ("unknown senders are flagged but still delivered") vs Strict ("rejected — use only once every real sender is listed") instead of ~all (softfail) / -all (hardfail). The same plain wording now appears in the free SPF Builder too.
• Jargon moved one layer down, not away. Implementation terms (flatten, reconcile, deploy, lookup, apex), mechanism syntax (~all, include:, rua=, _dmarc), and RFC references now live in tooltips, expanders, and the "how to add this record" helper — available when you want them, out of the way when you don't. Acronyms like DNSSEC, MTA-STS, and "Domain expiry" carry plain-English tooltips.

Why

A status screen that a domain owner can't read is a status screen that doesn't get acted on. Plain language in the primary positions — labels, summaries, buttons — serves the person who's never heard of SPF; the precise technical detail, one click away, serves the engineer who wants to verify the claim. Both readers are right to expect accuracy; only one of them wants the RFC number in the headline. The approved phrasings are collected in an internal glossary so the whole product stays consistent as it grows.

The per-domain page used to be a grid of record cards — you had to read the DNS to work out whether you were actually protected. It's now one calm, scrollable surface that leads with the questions you came to answer, and keeps the technical detail right where you'd reach for it.

What changed

• It leads with outcomes, not records. The top of the page answers two plain-English questions: Can someone impersonate you? and Will your real mail be trusted? The delivery foundation (SPF, DKIM) collapses underneath, so you see the verdict first and the mechanics on demand.
• A new "Who sends mail as you" list. Below the verdict is every sender on this domain and how each one really authenticates — not what you intended, what we observe. Senders you've registered but haven't seen traffic from are shown plainly as waiting, never as failing. (The authentication columns fill in once DMARC reporting is on.)
• Your DNS records, as the evidence beneath. The actual SPF / DKIM / DMARC / MX records still live here, one scroll down, as the proof behind the verdict — each card edged in green, amber, or red so a record that needs attention stands out even when mxio is managing it.
• What changed over time stays at the bottom, so you can always see recent movement on the domain.

New: hand management over, or take it back

• Switch a domain to mxio-managed SPF or DMARC with a short guided doorway — we show the exact DNS change, then watch real DNS until it's live before flipping the domain to managed.
• Or take management back to self-managed — same guided steps in reverse. We hand you back a working record (one that keeps tracking your senders' IP changes, not a frozen snapshot), and we keep your managed record live until your own record is proven published. No window where the domain is left unprotected.

The domain list (/dashboard/domains) is your triage queue. This update makes it tell the truth in three places it didn't, and adds the one signal it was missing.

What changed

• You can see which records mxio manages. Domains where Managed SPF or Managed DMARC is active now carry a quiet teal mxio SPF / mxio DMARC mark next to the SPF/DKIM/DMARC posture chips. It's a separate axis: it says who runs the record, never whether it's healthy — a managed record can still need your attention, and the mark sits alongside the health chips rather than recoloring them.
• A new alignment warning for enforcing domains. If your DMARC policy is enforcing (quarantine or reject) and your authorized senders are failing alignment, the list now surfaces "Authorized senders are failing DMARC alignment" in Needs attention, with the alignment figure in the hover detail. This catches the case where a p=reject domain is quietly bouncing some of your own legitimate mail. Crucially, it reads only your authorized senders' alignment — so a domain that's correctly rejecting spoof (which drags down the raw pass rate) is left alone. No false alarms for working protection.
• No more "0% aligned" on a healthy domain. A domain that's all-clear at p=reject used to print "0% aligned" — a number born of "we've ever received a report" rather than "you have recent mail." That figure has left the row entirely. When alignment is genuinely the problem, the number appears in the warning above, with context; otherwise it's simply absent.
• The header strip and the list agree now. The header's "Monitoring" card carried a domain count from a different pipeline than the list below it, so the two could disagree on the same screen (the strip saying "critical," the list saying "healthy"). That card is gone. The strip now shows only your service cards — DMARC Reporting and Managed SPF — and your domain triage counts live in one place: the grouped list (Needs attention / Watching / Healthy).

Why

The list is where you decide what to fix first, so every signal on it has to be trustworthy. A managed-vs-unmanaged record and a health-vs-broken record are two different questions — collapsing them onto one chip lies about both, so they're now two axes. A low aggregate DMARC pass rate often means your protection is working (it's rejecting forgeries); the honest alarm is when your own authorized senders are the ones failing — so that's the only thing we flag. And a header that contradicts the list it sits on top of erodes trust in both — so the one number that could disagree is gone, and the counts live in a single place.

When mxio manages your SPF, we maintain the flattened record we publish — but you still own your apex, and the apex has to keep pointing at us with an include:. If that pointer goes missing, the advisor needs to tell you plainly. It wasn't.

What changed

• One verdict instead of two contradictory ones. A Managed-SPF domain whose apex SPF no longer included our managed record used to surface both "No SPF record — anyone can send mail as your domain" (add SPF) and "SPF record may be out of date" (redeploy) on the same domain. Those can't both be true. There's now a single verdict — "Your SPF record no longer includes your managed SPF" (or, if the apex record is gone entirely, "Your domain has no SPF record") — with one clear action: Restore SPF include →.
• The false "stale" alarm is gone. The old verdict claimed your managed record "hasn't been redeployed in over a week." That was misleading: we re-check your senders every cycle and only rewrite the record when something actually changes, so a stable record legitimately goes weeks without a rewrite while staying perfectly correct. The "weeks since last redeploy" trigger is removed — the only thing we flag now is the real condition: your apex no longer carries our include.
• The verdict is now treated as urgent. A missing include means your authorized senders may not be covered (or, if the whole record is gone, anyone can send as you). It's surfaced in Needs attention, not as a low-priority watch item.

Why

"Managed SPF" means we run the flattened record — not that we own your apex zone. You keep full control of the apex, which means you (or a DNS change on your side) can remove the pointer to us, and we can't silently fix that for you. The honest thing is one accurate verdict that names the real problem and the real fix — not two verdicts that contradict each other, one of which prescribes a "redeploy" that wouldn't even address it.

What changed

The per-domain Advisor and the portfolio domain list now prioritize by demonstrated need instead of a fixed protocol order:

• Your real problems lead. If a domain's SPF is broken or over the 10-lookup limit, it's on a blacklist, or its DKIM is misconfigured, that's the top recommendation — it's no longer pushed below DMARC setup prompts you never asked for.
• DMARC reads as available, not pending. For a domain where you haven't set up DMARC, the advisor now shows a single calm item — "DMARC monitoring is available for this domain" — instead of "No DMARC record — your domain isn't protected" or "Managed DMARC is ready — activate now." A domain runs fine without DMARC; the offer is there when you want it.
• DMARC still leads when it's the only gap. If everything else is healthy and DMARC is the one thing missing, it's still your top item — just framed as an option rather than an alarm.

Why

The advisor used to rank DMARC above SPF unconditionally. For someone who came to fix an over-budget SPF record, that buried their actual problem under two DMARC nudges — for a capability that auto-provisions in the background and that they may not want. Driving priority from what's demonstrably wrong (or what you've actually engaged with) fixes both cases from one rule: the broken thing leads for the person with a broken thing, and DMARC leads for the person whose only gap is DMARC. "Engagement" means a DMARC record we can actually observe in your DNS (or reports we've received) — not just that your plan includes it.

What changed

The advisor now ranks SPF and DKIM problems above DMARC in its priority order. If a domain has, say, an over-budget SPF record and a DMARC setup prompt, the advisor leads with "Fix your SPF" — not the DMARC item. The same holds for a missing/invalid SPF record or an invalid/weak DKIM key.

When SPF and DKIM are healthy and DMARC is the only gap, DMARC still leads — this only changes the order when both have issues.

(The rare cases where a Managed DMARC delegation is actively broken — a DNS conflict or a CNAME pointing at the wrong place — still surface at the top, since those need resolving regardless.)

Why

DMARC works by checking whether SPF or DKIM align with the From domain. If your SPF is broken (missing, malformed, or over the 10-lookup limit so receivers drop it), DMARC has a weaker foundation to act on — so fixing SPF/DKIM first is the right order of operations. The advisor now reflects that dependency instead of leading with DMARC.

What changed

A few wording and clarity fixes on the DMARC surfaces:

• "Available" replaces "Pending activation." A pre-built but not-yet-activated Managed DMARC capability now reads as an option you can take whenever you want — not a task with a clock running. On the domain hub it shows a calm "Available" with no management badge (matching how pre-built Managed SPF already behaves), and the focused page leads with "Want DMARC monitoring for this domain? We've pre-built it — activating is a single CNAME record, whenever you're ready."
• The staged-record label softened. "We'll publish (replaces your current record)" is now "Here's what we'd publish if you turn this on."
• Honest enforcement wording. When your policy is at pct < 100, the advisor heading now says "Partial enforcement — monitoring for changes" instead of "Enforcing" — only pct=100 (or p=reject) reads as full "Enforcing." The exact percentage still shows just below.
• Two new plain-language explainers (collapsible, so they don't crowd the page):
  • How does pct work? — Under today's DMARC standard (RFC 7489), pct=10 applies your policy to roughly 10% of failing mail; the unsampled remainder gets the next-softer treatment (under p=reject; pct=10, the other 90% is quarantined, not delivered free). Move to pct=100 for your policy to apply across all failing mail. Forward note: the DMARCbis update removes the pct tag entirely (Appendix A.6), so newer receivers already ignore it and apply the full p= policy regardless of any percentage set — treat pct as a transitional safety net, not a long-term mechanism.
  • Does p=reject guarantee rejection? — receivers MAY honor p=reject; large mailbox providers generally do.

Why

The old wording quietly pressured customers toward DMARC and overstated what their policy was doing. "Pending activation" implied a task you'd started and needed to finish, even on domains where you'd never asked for DMARC. "Enforcing" at pct=10 reads as full protection when only 10% of failing mail is actually being acted on — and when DMARCbis receivers adopt the update, they will ignore pct entirely and apply the full p= policy regardless of any percentage set. Stating these precisely, with the spec details one click away, respects both the admin who just wants the gist and the expert who needs the citation.

What changed

• DMARC result card + wizard lead benefit-first. When you check a domain with no DMARC record, the result card used to say Managed DMARC "watches alignment, and walks the policy from monitoring to enforcement" — three terms you'd need to already know. It now leads with what you get: "Managed DMARC sets this up for you, watches who's sending as your domain, and makes it harder for spammers to fake you — no DNS work on your side." The same rewrite applies to the Managed DMARC offer on the DMARC wizard.
• The precise terms moved into a depth layer. Both surfaces now carry a collapsible "How does Managed DMARC work?" explainer with the exact RFC vocabulary — SPF/DKIM alignment, advancing your policy from monitoring (p=none) to enforcement (p=quarantine/p=reject) — and a link to RFC 7489. Available to anyone who wants it, out of the way for anyone who doesn't.
• Plainer pricing headline. The /pricing H1 changed from "Stop managing email authentication by hand." to "Pricing — Diagnose, Monitor, and Manage email authentication" — it now names what's on the page using the same Diagnose → Monitor → Manage vocabulary as the plans themselves.

Why

A first-time visitor checking their DMARC shouldn't have to decode "alignment," "policy," and "enforcement" before they understand what the product does — but an expert evaluating us shouldn't find the explanation dumbed-down either. Leading with the plain-language benefit and putting the spec-grounded detail one click away serves both. And a buyer who's already finished evaluating wants the pricing page to label itself, not pitch at them.

What changed

Adding a domain you're already monitoring now returns a clear "domain already added" error (HTTP 409) instead of creating a second copy. The duplicate check runs at the application layer, so it holds regardless of database-level constraints.

Why

A database schema change had removed the unique constraint the create path quietly relied on to catch duplicates, so re-adding the same domain could create a duplicate entry. The check is now enforced explicitly in the domain-create handler.

We made the dashboard noticeably faster for accounts with lots of domains and long monitoring histories.

What changed

• The domain list loads almost instantly. Previously, opening Domains could take many seconds for accounts with a large number of domains, because the page was computing a per-domain health summary it never actually displayed. We removed that wasted work — the list now paints in well under a second, and your per-domain advisor recommendations fill in right behind it.
• Timeline and stats stay fast as history accumulates. The per-domain history timeline and the health-percentage stats are now backed by a precomputed per-cycle summary instead of scanning every raw check result on each page load. The views look identical; they just don't slow down as months of monitoring history pile up.

Why

As an account grows — more domains, more months of continuous monitoring — the underlying check history grows with it. The old approach re-derived everything from the full raw history on every page view, which got slower over time. These views now read from a compact rollup that's maintained as checks run, so performance stays flat no matter how much history is behind it. No setting to change and nothing to migrate on your end.

What changed

A few small wording fixes for clarity:

• A monitored domain now reads "Monitoring," not "Active." On the per-domain page, the status pill for a watched domain said "Active" — which collides with the "Active" state used by Managed SPF and Managed DMARC. It now says "Monitoring," with a tooltip: "We're watching this domain's email-auth records." "Active" is reserved for managed services that are actually publishing on your behalf.
• The "DNS health checks" section is labeled plainly. The collapsible substrate on the domain page was titled "Monitoring & DNS hygiene"; it's now "DNS health checks," and its empty state explains what runs there: "Delegation, expiry, and blacklist checks run here."
• Login page bullets are plainer. "Alerts the moment your SPF, DKIM, or DMARC breaks" → "Alerts the moment something breaks that could send your email to spam" (with the protocol detail in a tooltip). "A heads-up if your mail server hits a spam blacklist" → "A heads-up if the IP your email provider uses ends up on a spam blacklist."

Why

"Active" meant two different things depending on where you saw it — a domain being watched vs. a managed service publishing your records. Splitting those words removes the ambiguity. The login and section copy lead with the outcome a non-expert cares about (email landing in spam, the right IP getting blacklisted), with the technical specifics available but not in the way.

What changed

A follow-up to the health-first card fixes — making "a real problem always shows over a setup prompt" a structural guarantee rather than a per-case patch:

• A malformed DMARC record now surfaces on every plan. Previously a Free-plan domain with a broken _dmarc record showed "Locked — DMARC Reporting (paid)," hiding the broken record. Fixing a DMARC record is free, so the broken record now shows ("Malformed record") regardless of plan.
• A stale or failed-to-provision domain shows that problem instead of "Managed active" / "Available."
• Under the hood, the DMARC card derivation and the SPF/MX card derivations now run through an explicit precedence — structural delegation errors, then health problems, then setup/availability — so a future managed-service card can't re-introduce a setup message that buries a health problem.

When everything's healthy, the calm "Available" / "Ready to activate" framing still leads, exactly as before.

Why

These cards exist primarily to tell you the health of each record. The fix generalizes the principle into the code's structure: a setup or availability message is always secondary to a real problem, in every card.

What changed

The SPF, DKIM, and DMARC cards on the per-domain page are health indicators first. A couple of cases where a setup/availability message was overriding a real health problem are fixed:

• SPF card: if your SPF record has a problem (over the 10-lookup limit, missing, invalid, or soft-fail) while Managed SPF is pre-built, the card now leads with that problem — e.g. "SPF lookup limit exceeded" — and offers Managed SPF as the fix, instead of showing only "Ready to activate."
• DMARC card: a malformed _dmarc record now shows as "Malformed record" even when Managed DMARC has been pre-provisioned — the "Available" setup pill no longer hides a broken record.

When SPF/DMARC are healthy, the calm "Ready to activate" / "Available" framing still leads, as before — this only changes things when there's an actual problem to surface.

Why

Those cards exist primarily to tell you the health of each record. A pitch to activate a managed service shouldn't outrank "your record is broken right now." This also makes the cards agree with the advisor banner above them, which already leads with the real problem.

What changed

The per-domain record cards (MX / SPF / DKIM / DMARC) now use a clearer, three-state management badge:

• Managed — mxio publishes and maintains this record for you.
• Self-managed — you maintain the record; mxio monitors it for changes. (This replaces the old "Unmanaged" label.)
• No badge at all — when there's no record in DNS, the card simply states that fact instead of attaching a label.

The DMARC card's no-record state was also reworded. Where it used to read "Not set up," it now reads "No DMARC record" with a neutral line: "No DMARC record found. A domain can run fine without one — add DMARC when you want to see who sends mail as you." And if you already have a DMARC record published but haven't turned on mxio's DMARC reporting, the card now says "Reporting off" and keeps the "Self-managed" badge — it no longer incorrectly claims you have no record.

Why

"Unmanaged" read like a broken or unfinished state — as if you'd forgotten something — when it actually just meant "you maintain this record yourself, and we watch it for you." That's a normal, healthy configuration, not a deficiency. "Self-managed" says what's true without the negative undertone, and dropping the badge entirely when there's no record keeps the label honest: it speaks to who manages a record, and only when one exists.

The DMARC wording follows the same principle — state the DNS reality plainly and offer DMARC as an option, never as a chore you're behind on.

What changed

Two pieces of copy on the Managed SPF and Senders surfaces were re-worded so that Managed SPF reads as a complete product on its own, and DMARC-report sender discovery reads as an optional add-on rather than a dependency:

• Senders header. Was: "After activation, new senders must be added explicitly here or surfaced from your DMARC reports." Now: "After activation, add new senders explicitly here. If you use DMARC reporting, we'll also surface new senders we see in your reports."
• Managed SPF focused-page pitch. Was: "…folds in new senders as you authorize them from your DMARC reports." Now: "…folds in senders you add here. If you use DMARC reporting, it also surfaces new senders it sees in your reports."

Why

The old wording led the auto-sender-discovery value with "from your DMARC reports," which framed Managed SPF — a product a customer may have bought specifically to avoid DMARC — as working better only if they adopt DMARC. Leading with the explicit "add senders here" path and making the DMARC clause conditional keeps the discovery feature fully visible for customers who do use DMARC reporting, while removing the implication that an SPF-only setup is incomplete.

You can now share your mxio account with your team.

What changed

• Invite teammates from the new Team page. Account owners on Pro and Business see a Team item in the dashboard nav (Account section). From there you can invite a teammate by email, see who's on the account and which invites are still pending, and remove members or revoke invites.
• Members manage everything except billing. An accepted teammate sees and manages the owner's domains, SPF, DKIM, DMARC, Managed SPF, Managed DMARC, reports, activity, and notification settings — exactly as the owner does. Billing, plan changes, and seat management stay owner-only.
• Seats are included in your plan price. Pro includes 3 seats (you + 2 teammates); Business includes 10 (you + 9). There's no per-seat charge and no Stripe quantity to manage — the cap is enforced in the account. The Team page shows "Seats: used of total" and disables the invite form when you're full.
• Downgrades show the impact before you confirm. If you downgrade to a plan with fewer seats, the change-plan preview now lists exactly which team members will lose access. As with domains over the new limit, excess members are suspended automatically (least-recently-active first) — they keep their login and simply revert to their own account until you upgrade again.
• Invitation accept flow. Teammates click the link in their invite email, sign in (or sign up) with the same passkey-first flow, and land on a confirmation that they've joined the account.

Why

mxio is the place a business manages its email authentication. For anything past a one-person shop, that's a team job — the person who owns the Stripe relationship usually isn't the only one who needs to add a domain, authorize a new sender, or check why a newsletter is going to spam. Team seats let the people doing the work do it directly, while keeping the billing relationship with one owner.

What's NOT in this change

• No account switcher yet. A teammate operates in exactly one account. If your email already manages its own domains on mxio, joining another account isn't available yet (the underlying design is built for it; the switcher UI is a later step).
• No per-member notification inboxes. Notifications, channels, and the in-app inbox are shared at the account level — a member manages the same notification settings the owner does.
• No new charges. Seats are part of the Pro and Business price you already pay.

What changed

1. Managed SPF activates for records built from any sender — recognized provider or not. Previously, auto-provisioning only kept the include: mechanisms it recognized from its provider catalog (SendGrid, Mailchimp, etc.) and discarded everything else. A domain whose SPF record was, say, a chain of custom include: mechanisms — the classic "too many DNS lookups" record the SPF flattening funnel exists to fix — ended up with zero recognized senders, so provisioning quietly no-op'd: no managed record was created, and there was no way to activate it from the UI. Managed SPF now builds your flattened record from your entire SPF record (every include, a, mx, ip4, ip6), using the catalog only to put friendly names on the senders it recognizes.

2. Your -all / ~all enforcement stays exactly as you set it. A separate bug meant the provisioning path didn't persist your record's all qualifier, so a strict -all record could be silently rebuilt as a softer ~all. Your disposition is now preserved verbatim.

3. Managed SPF is worth turning on even when you're under the lookup limit. Provisioning is no longer gated on being over the 10-lookup budget — Managed SPF maintains your record in concert with your sender list (including senders surfaced from DMARC reports), so it's useful as ongoing management, not just as a one-time flatten.

4. Honest states instead of a spinner that never finishes. When there's genuinely nothing to do yet, the SPF page now tells you why instead of showing an indefinite "setting up…":

• If your SPF record uses something we don't auto-flatten yet (an exists: mechanism, a redirect=, a qualified mechanism, or a CIDR a/mx), you'll see a clear note saying so — and your record is left completely untouched. We never rewrite a record we can't flatten faithfully.
• If there are no senders to build a record from yet, you'll get an "add your first sender" link to the Senders page.

5. The "Set up Managed SPF →" link now goes to the right place. It previously dropped you on the domains list with no setup surface. It now opens the domain's focused SPF page, where activation actually happens.

Why

The records that benefit most from SPF flattening are, almost by definition, the ones full of include: mechanisms — and many of those point at services outside any fixed provider catalog. Refusing to flatten what we don't recognize by name defeated the feature for exactly the customers it's built for. Flattening resolves an include to its IP addresses; it doesn't require us to know the sender's brand name.

What changed

1. Cross-domain /dashboard/activity no longer shows long-running health streaks or incident events. Rows like "Fail for 6 days (1388 runs)" were dominating the feed — single events that kept re-jumping to the top as their streak continued. They're useful per-domain (the per-domain hub still shows them on the Monitor strip + Advisor), but in a cross-domain rollup they hide everything else. Incident events similarly: useful as backend triggers for the email-ack mute flow, but as in-app UI rows they were vestiges of the retired Incidents page.

2. Every record_change row now actually says which domain it's for. Previously, when MailRoute rotated IPs and five of your domains' MX records re-resolved at the same time, you'd see five identical "MX mail server IPs changed" rows with no attribution. They now read e.g. "terramar.net — MX mail server IPs changed", "mailroute.net — MX mail server IPs changed", etc. Root cause: the label lookup was filtering on a user-supplied display-name column that's usually NULL; fallback to the domain/host identifier was missing.

3. Transient DNS lookup failures stop being recorded as DNS configuration changes. When an upstream resolver returned empty data for a transient reason (timeout, recursive lookup glitch), the change detector compared the new empty result to the prior populated result and emitted "MX IPs changed: 199.89.1.120 → (empty)" — then the next cycle resolved fine and emitted "MX IPs changed: (empty) → 199.89.1.120" again. Forever flapping. The detector now suppresses these asymmetric empty↔populated transitions for MX, SPF, DKIM, and DMARC — real config changes (non-empty → different non-empty) still emit normally.

4. The "Health" tab on the cross-domain Activity page is gone (it would have been an always-empty bucket after #1). The per-domain Activity page keeps all four tabs unchanged.

Why

The Activity feed had become noise: long-running streak rollups crowded out fresh activity, identical rows with no domain attribution couldn't be acted on, and resolver flakiness in dev (and customer environments with intermittent NS lookups) was generating false "your records changed" notifications that customers had to ignore.

mxio's on-ladder vocabulary is Advisor (active issues) + Activity (history). The cross-domain Activity feed should be a portfolio-wide audit trail of real changes, user actions, and managed-service deployments — not a re-surface of per-domain check-run aggregates that already have better homes in the hub and Advisor.

What's deferred

• Persistent record-removal audit rows. With the change-detector fix, a customer who actually removes their SPF record gets the failure alarm from the status path, but the granular "SPF record changed from v=spf1 … to (empty)" timeline row is suppressed. Status notifications still fire; the audit row will return when we add debouncing (N consecutive cycles of the new state confirm it's real, not transient).
• Category dropdown ("show only DMARC events", "show only Managed SPF events"). Backend supports it; UI was descoped because the existing filter semantic doesn't include spf_change_log/incident_events rows under their natural categories. Proper version needs per-category source mapping.
• Resolver-layer retry on transient empty responses. Stacks with #3 above as a second line of defense. Reduces how often the change detector even sees a degraded result.

Two related dashboard fixes surfaced while auditing a customer's per-domain page.

What changed

• The per-domain health timeline (and the small history pips on the domain list) now exclude informational checks — delegation, MTA-STS, DNSSEC, and domain expiry. Until today, those checks could flip a cycle's overall status to "fail" even though they're explicitly excluded from your domain's health score. The most visible symptom: a domain that scored 93 or 100 still showed a wall of solid-red bars on the 1h / 24h / 7d / 30d timeline, with no way to tell whether something was actually broken. The timeline now mirrors the score: green when your email auth is healthy, amber/red when something genuinely needs attention.
• The "Set up DMARC" advisor no longer asks you to add a record you already have. If your _dmarc record is already pointing at mxio's reporting address but the corresponding settings row went missing (a rare orphan state — usually post-deletion or manual re-publishing), the advisor now says "DMARC record found — enable monitoring to receive reports" instead of the misleading "No DMARC record — add one."

Why it mattered

The contradiction was real and confusing: the score said "you're fine," the badge on the "Delegation" hygiene chip said "fail," and the timeline said "you've been failing every check for a month." A customer reading that page had no path to a coherent story. Now all three surfaces are sourced from the same exclusion set (store.InformationalCheckTypes on the backend), and they can't drift apart.

Where to see it

Open any domain at Dashboard → Domains → [your domain] and expand "Monitoring & DNS hygiene." The 1h / 24h / 7d / 30d history bar should now show real cycle history, not a flat color.

What changed

The Associated Hosts panel on each per-domain page now renders every monitor inline — there's no 5-host cap and no "View all hosts →" link.

Why

The cap and the View-all link were both vestiges of when mxio surfaced generic host/uptime monitoring as a top-level feature. In the email-auth model, the per-domain host count is tight (typically 2-3 MX IPs plus a handful of SPF-derived IPs), so capping the inline list almost never helped. The "View all" link itself pointed at /dashboard/hosts — which we removed from the left nav as part of the off-ladder trim. Sending customers there was wrong on both counts.

What remains: each monitor row (IP + source badge + monitor type) still links to its own host detail page, and the "Discover Hosts" button still works for re-detecting MX/SPF IPs after a DNS change.

What changed

The Incidents page is gone. In its place is Activity — a cross-domain merged timeline showing check changes, health-status transitions, sender authorizations, Managed SPF deploys, and DMARC enforcement moves. The nav item now reads "Activity" and points at /dashboard/activity. Filter by tier (actions / changes / health), days (7 / 30 / 90), and domain. The per-domain timeline you already have on each domain hub is unchanged.

Behind the scenes, nothing about alerts changed. The same checks fire on the same cadence, the same 24-hour and 7-day reminder cycle runs, the same noise-suppression rules apply. What moved is the in-app vocabulary: "Incidents" was uptime-vendor framing borrowed from generic monitoring, and it never fit email authentication — a ~all SPF record or a DMARC policy at p=none isn't an outage, it's a posture. Activity is what monitoring an email-auth surface actually produces: a history. If you want to mute a repeating reminder for a known-ongoing issue, the Acknowledge link in the reminder email still works the way it did — that's the canonical mute path now.

Why

mxio's Monitor rung is continuous email-authentication observation, not endpoint reachability. The Incidents framing was a vestige of the earlier generic-monitoring positioning; pulling it out lines the dashboard up with what the product is. Active issues already live on the Advisor (per-domain hub banner + portfolio domain list); history now lives on Activity. Two surfaces, two jobs.

When you run a free email-auth check on mxio and the result is a Fail, the page now leads with a single Manage-rung fix — Fix with Managed SPF, Fix with Managed DMARC — instead of competing Monitor-flavored CTAs scattered across the result.

What changed

• DMARC checker: a "no DMARC record" result now points to Managed DMARC. The bottom action card carries the single CTA; the per-finding inline boxes and the top action bar coordinate so you never see three competing "Monitor this domain" buttons.
• SPF checker: failing SPF (over the 10-lookup limit, record too long) keeps routing to Managed SPF — unchanged.
• Header analyzer + domain health: DMARC-fail results now route to Managed DMARC instead of DMARC Reporting. The free-tool arrival's "fix this for me" intent is best served by the Manage rung.
• Per-finding inline upgrade boxes (the small "fix with…" panels inside each finding card) only appear for findings that have a Manage product available — SPF and DMARC. Findings for MX, DKIM, blacklist, and delegation no longer carry their own inline CTA, because there's no Manage product to recommend; the bottom action card handles those cases with a single Monitor CTA.
• Generic "Track this domain to catch changes and regressions" fallback is gone. The action bar at the top of a result no longer competes with the bottom card when a Manage product applies.

Why

We pivoted from an email-monitoring product to an email-authentication-management platform a while back, and the marketing surfaces ratified the new product order in May (the Diagnose → Monitor → Manage ladder in docs/reference/BRAND-VOICE.md §6.1). But the tool-result pages were still mostly Monitor-framed — three or four "Monitor this domain" buttons per result, no clear path to the Manage product that would actually fix the customer's problem.

A persona walkthrough as a small-business owner with a newsletter going to spam surfaced this clearly: the page told her what was wrong but every CTA asked her to "watch the problem continue" rather than "let us fix it." Wave 6 corrects that.

What's NOT in this change

• DMARC Reporting (the Monitor-rung product for DMARC) still exists and is still available — it just isn't the automatic CTA off a diagnostic failure anymore. Customers who specifically want a reports-only product can reach it via the marketing nav or /services/dmarc-reporting directly. A small "or just want reports? →" subordinate affordance on the bottom card is a possible follow-up.
• The DMARC Wizard (/tools/dmarc-wizard) — the "build a DMARC record yourself" tool — is unchanged. A separate change will add a "Don't want to configure? Let us do it for you" Managed-DMARC entry point inside the wizard.
• Logged-in dashboard surfaces — the per-domain hub, focused pages, and advisor are unchanged. Wave 6 is specifically about the free-tool result pages and the diagnostic-to-Manage handoff.

What changed

The expanded Monitoring & DNS hygiene panel on each domain (Dashboard → Domains → [domain] → "View detail" on the hygiene strip) now lists each check with status, label, and a plain-English verdict — sourced from the analyzer summary the backend already produces. Previously, that panel showed colored chips at the top and then jumped to uptime/incidents/hosts/config, skipping the one thing the chips were pointing at.

Each row covers one check:

• DNSSEC — pass/info/warn/fail with framing like "Active and validating" or "Not configured. Informational — not required for email."
• MTA-STS — same shape, with "Strengthens TLS for inbound mail" framing when absent.
• Delegation — when the customer hasn't delegated DNS to mxio, this now reads "NS records don't match parent delegation. Informational unless you're using mxio for DNS." instead of just a red chip with no explanation.
• Domain expiry — analyzer's expiry date and remaining days when healthy; "Renew at your registrar" when warn.
• Blacklist — listing details when applicable.

Why

Audit followup: customers were seeing a red "Delegation" chip with no way to learn what it meant or whether they needed to act. The chips alone gave no signal about severity context — delegation: fail is a real DNS observation but it's informational for the vast majority of customers (who haven't delegated DNS to mxio, and don't need to). The detail rows close the loop: chip is the glance, row is the explanation.

Where the analyzer summary comes from

The backend per-check summary field has always existed; it just wasn't on the wire for hygiene checks. The list and anchor endpoints now carry it on checks[].summary (optional — pre-existing rows that never wrote a summary serialize the field as absent). Frontend falls back to per-check informational copy when the summary is missing.

What changed

Per-domain page → "Monitoring & DNS hygiene" (expanded view) is now three quieter, more useful blocks:

• Removed the uptime % pills (1h/24h/7d/30d) and the 30-day pip history bar. They were applying a generic "endpoint uptime" model to email authentication, which never really fit — a DMARC record in warn status isn't "downtime," your email is still flowing. Treating it as 0% uptime created the dashboard contradiction where a domain could score 100/100 but show a wall of orange bars.

• Added a "Last change" line. Replaces the pip chart with a single sentence: "Last change: MX mail servers changed (3 days ago). View activity →" — or "Steady for 30 days. No changes." when nothing has happened in the window. The "View activity →" link opens the cross-domain activity log pre-scoped to this domain.

• Associated Hosts now lists monitors inline (for counts ≤ 5). Previously the panel said "2 monitors associated with this domain" and forced you out to a separate hosts page to actually see them. You now see each IP, its source (MX/SPF), monitor type, and a link to the host detail — right in the panel. For accounts with more than 5 monitors per domain, the count-summary + "View all hosts →" fallback still applies.

Why

mxio's "Monitor" rung is continuous email authentication observation — DMARC reports flowing, SPF not drifting, DKIM keys still valid. It's not "is this HTTPS endpoint reachable?" generic uptime monitoring. The dashboard had vestiges of the earlier generic-monitoring positioning; this trims them out so the surface matches the product.

Three small follow-ups to the Wave 6 tool-result CTA work earlier today.

What changed

• "Or fix it yourself" disclosure on every tool result page. Findings (the per-issue technical details) and DNS-host-aware fix instructions (the Cloudflare / Namecheap / etc. guidance panel) are now grouped under a single disclosure at the bottom of every tool result page. When a Managed service is available for the failure (Managed SPF or Managed DMARC), the disclosure is closed by default — the primary fix lives in the Managed CTA above and the DIY path is one click away for power users. When no Managed service applies to the failure (MX, DKIM weak key, blacklist, delegation), the disclosure is open by default because DIY is the only path.
• Disclosure features the matching wizard tool as the recommended DIY path. For the DMARC checker, the disclosure leads with "Use the DMARC Record Builder →" linking to /tools/dmarc-wizard?domain=…. For the SPF checker, it leads with "Use the SPF Record Generator →" linking to /tools/spf-builder?domain=…. This makes the "this is how complicated it is" alternative explicit instead of dumping raw DNS instructions on the user.
• DMARC checker: the "No DMARC record published" warn-tinted banner is folded into the action card. Previously the page showed two stacked panels saying overlapping versions of "no DMARC record": a warn-tinted banner ("anyone can spoof your domain") and an action card ("Managed DMARC publishes the record"). Now it's one warn-tinted card with both the consequence framing and the Managed DMARC CTA.
• DMARC Record Builder gets a Managed DMARC upsell at the top. A small "Don't want to configure all this yourself?" panel sits above the wizard form, pointing to /services/managed-dmarc. Users who arrived at the wizard but realize they don't want to make 6+ configuration decisions can opt out without backing all the way up to the checker page.
• AI Explain: the "≈$0.02" cost estimate is gone. That number was mxio's internal AI cost, not anything customers pay for. Showing it created the wrong impression. Removed from both the collapsed and expanded variants of the AI Explain affordance.

Why

These three came directly out of a persona walkthrough as a small-business owner who arrived at the DMARC checker frustrated about a newsletter going to spam. She read top-to-bottom and saw: "Managed DMARC will fix this for you" → "update your DNS records at Cloudflare" → "add a DMARC record at _dmarc.your-domain.com". Three mental models stacked vertically — "we do it for you," "go to Cloudflare yourself," and "here's the literal record to publish yourself." She couldn't tell which path the page actually wanted her to take.

The disclosure separates the choice cleanly: pick the Managed product (recommended), or expand the disclosure to see the DIY instructions. Diagnosis (the score, the failure summary) stays visible above so users always see what's wrong, regardless of which fix path they choose.

The cost estimate fix is even simpler — that label was just wrong. Customers don't pay for AI Explain. Showing them an internal cost estimate was a confusing artifact of an early experiment.

What's NOT in this change

• The Managed DMARC, Managed SPF, and DMARC Reporting marketing pages are unchanged.
• The dashboard (logged-in surfaces) is unchanged. This is a free-tool result-page polish, not a dashboard change.
• AI Explain itself still works the same way — same content, same quota, same model. Only the cost-estimate label was removed.

The DMARC record card on the per-domain hub now surfaces report flow as a distinct pill, separate from the Managed/Unmanaged badge.

What changed

• New Reports: pill on the DMARC card. Sits next to the existing Managed/Unmanaged badge and answers a different question: not "who publishes this record" but "are aggregate reports actually showing up?" Four states:

  • Reports: Pending — DMARC is enabled and our RUA address is in your record, but no reports have arrived yet (the first batch lands within ~24 hours of enable for most senders).
  • Reports: Not Published — DMARC is enabled on our side, but your published _dmarc record does not include our RUA address. Reports are not flowing to us and won't until the record is updated.
  • Reports: Stale — reports were flowing but have stopped for 14+ days. Usually means a sender or rua tag changed and needs a look.
  • Reports: On — recent reports observed within the freshness window. No action needed.

• Visual harmonization. The Managed/Unmanaged badge and the new Reports pill now share the same shape, font size, and border treatment — they read as a pair of sibling pills rather than two different components stacked together.

• Tighter subtitle copy on stale reports. When the DMARC card surfaces a stale-reports gap, the subtitle is shorter and more action-oriented so the next step is obvious.

Why it matters

DMARC reporting failure is silent by default — your record stays published, your policy stays enforced, but the visibility you signed up for quietly evaporates. The Reports pill puts that on the surface of the domain hub instead of buried two clicks deep.

What stays the same

• No DNS or policy changes — your published _dmarc record, your enforcement state, and your RUA destinations are untouched.
• The reporting axis is DMARC-only — MX, SPF, DKIM, and Senders cards don't render a Reports pill.
• The focused DMARC page is still the place to investigate why reports are stale or not published. The pill links you there.

Three improvements to the Managed DMARC voluntary-deprovisioning path, landing as part of the Phase U functional-test fix sprint.

Audit history survives deletion

Previously, deleting a domain cascade-deleted the dmarc_managed_domains row. The grace-period and tombstone records carried partial state (DNS label + Cloudflare record IDs), but the customer's stage, cadence, preserved tags, original DMARC record, and observation history were lost. Hard to reconstruct after a dispute.

We migrated the foreign-key behavior from ON DELETE CASCADE to ON DELETE SET NULL. Deletion of the underlying service now leaves the managed row in place with service_id IS NULL — a read-only snapshot. Store reads that look for live state filter snapshots out automatically.

IngestionGuard tombstone classification

When a customer deprovisions, we tombstone the DNS label and the RUA hash together. If a delayed DMARC aggregate report arrives for the tombstoned hash days later, the IngestionGuard's Layer 5 lookup now finds it and classifies the drop as ReasonDropTombstoned instead of falling through to ReasonUnknownHash. Same outcome — the report is dropped — but the classification is correct and the activity is observable.

managed_dmarc_deprov_entered activity event

Deprovisioning now emits a structured activity event with the domain, DNS label, preserved stage, cleanup-after timestamp, and reason. Visible in Reports → Activity. Symmetric with the existing managed_dmarc_provisioned and managed_dmarc_activated events.

What this means for you

Mostly: nothing changes day-to-day. If you delete a Managed DMARC domain, you'll see the new event in your activity timeline. If you later need to audit what you had configured before deletion, the snapshot is queryable for the 30-day grace window and beyond.

If your existing _dmarc record contains a tag that Managed DMARC can't silently inherit — t= (testing mode), psd= (public suffix marker), partial pct=, or any unknown tag — we now show you a per-tag review form on the focused DMARC page. Pick Accept to preserve the tag or Strip to drop it from the Managed DMARC record, then click Continue activation.

Before this fix, customers in that state saw "Loading tag details…" forever and the Continue activation button stayed disabled. The reason data was computed at provision time but never persisted — so the page had nothing to render and the customer had no path forward.

We now persist the full list of flagged tags + values + reason codes at provision time (migration 111), surface them on GET /v1/dmarc/domains/{domain}/managed/status, and validate the decision set when you submit so you can't accidentally leave a tag unaddressed or pick a decision for a tag that wasn't flagged.

For pct= decisions: choosing Strip drops the percentage cap entirely (your policy applies to all mail); choosing Accept holds the record at your existing pct= value indefinitely.

If your Managed DMARC enrollment surfaced a manual-review gate — flagged tags (t=, psd=, partial pct=, or unknown tags) in your existing _dmarc record that couldn't be silently adopted — you can now see exactly when you cleared the gate and what decisions you made on the Activity timeline under Reports.

Each event captures the domain plus the per-tag accept-or-strip choices: decisions: {t: "strip", pct: "accept"}. Filter the timeline by the managed_dmarc category to see the full Managed DMARC lifecycle — provision, manual-review resolution, activation, advance, rollback.

Previously the manual-review resolution was invisible in the audit log; only the subsequent policy advances showed up. Support couldn't reconstruct what was decided. Now they can.

No action needed from you — the event fires automatically on a successful clear.

Managed DMARC is live — for staff accounts first, then a staged rollout to customers. Here's what it does.

What it is

You point your _dmarc.<domain> record at mxio with a CNAME:

_dmarc.yourdomain.com. CNAME <label>.dmarc.mxdns.io.

From that point on, mxio controls what receivers see. We start you at p=none (monitoring-only) and advance your policy on a schedule — tracking your email volume, sender alignment, and report coverage at each step before we move. The progression goes: none → quarantine → reject.

How the progression works

We enforce dwell times at each stage before advancing. On the standard cadence:

• None → quarantine: 14 days of reports, ≥ 50 authorized messages in the last 30 days, ≥ 98% pass rate, no anomalies.
• Quarantine → reject: 7 days at quarantine, same readiness gates. You explicitly approve the quarantine→reject step before we move.

You can also choose a cautious cadence (double the dwell at each stage) or a fast cadence (half the dwell) — or set fully custom dwell times.

Pre-existing DMARC records

If your domain already has a _dmarc record, we read it first. Policy tags we recognize (p=, pct=, sp=, adkim=, aspf=) are preserved where safe; your RUA destinations are migrated so you don't lose existing reports; tags we don't manage are kept verbatim. Records with partial pct= values, psd markers, or unknown tags are flagged for manual review — we won't silently change a record we can't fully reason about.

What you keep control of

• You flip DNS, not us. We provision the managed sub-record, but the CNAME is your change to make.
• The quarantine→reject step requires your explicit approval — no automatic jump to the strictest policy.
• You can reset the cadence, change the pace, or disable Managed DMARC at any time. Disabling removes our record from Cloudflare; what you had before is yours to restore.

Current rollout status

Managed DMARC is live behind a feature flag. Staff accounts see it first; we'll open it to customers on Pro and Business plans once we've done a full staff walkthrough. The Pro plan minimum mirrors Managed SPF.

If you're a staff member and don't see the Managed DMARC option on your domain's DMARC page, ping the team to get your account added to the allowlist.

Two issues caught in Phase U functional testing of Managed DMARC. Both ship together because they shared a code path.

What changed

• Verify CNAME works within seconds, not 30 minutes. Previously the "Verify CNAME" button could keep saying "DNS not propagated yet" for up to 30 minutes after the customer had set the CNAME correctly. The probe was going through the OS recursive resolver, which negative-cached the pre-CNAME NXDOMAIN for the full SOA-min TTL — and the reconciler's background polling kept re-priming that cache. Verify now queries the customer's authoritative nameservers directly via miekg/dns, bypassing recursive caches entirely. Reconciler polling on ready rows is also paused until the user has confirmed the CNAME, so it can't re-prime the cache during setup.

• Live cache countdown when DNS is still propagating. When the resolver does return a cached-negative response, the API now returns the live SOA TTL as cache_ttl_seconds. The activation surface renders a countdown — "DNS cache clears in 0:42 — we'll re-check automatically when it does" — instead of the vague "give it a few minutes" copy. When the countdown hits zero we re-probe immediately.

• Third-party DMARC providers are no longer silently inherited. A customer whose _dmarc.<domain> was a CNAME pointing at another DMARC provider (dmarcian, PowerDMARC, etc.) previously had that provider's full DMARC policy — including their RUA / RUF reporting endpoints — published into our zone. Customer DMARC reports would have flowed to a third party they may have no contract with. We now detect the wrong CNAME at provision time, refuse the import, and flag the domain for manual review with the observed target captured.

Why this matters

Both issues affected first-touch onboarding. The verify delay was a real-world blocker; the foreign-CNAME adoption was a data-exfiltration risk masquerading as a smooth "we found your existing DMARC policy" experience. Customers should now have a faster, safer first run-through of Managed DMARC activation.

Who it affects

Customers on Pro+ plans where Managed DMARC has been enabled. Existing active customers are unaffected (the reconciler skip only applies to ready rows that haven't yet been verified; once activated, drift detection runs as before).

A small round of cleanup on the per-domain pages, surfaced during Phase U functional testing.

What changed

• Hub DMARC card respects Managed DMARC state. Pro/Business customers on Managed DMARC now see "Pending activation" + "Set the CNAME at _dmarc to activate" on the hub the moment we provision, instead of the misleading "Self-managed / Awaiting reports" framing carried over from the legacy DMARC Reporting state machine.
• Hub SPF card no longer claims "Setting up" when nothing is in flight. When auto-provisioning Managed SPF no-ops because we couldn't catalog-match any senders (typical for a brand-new domain with no SPF record), the card now mirrors its MX/DKIM siblings with SPF-health framing — "Attention — No SPF record found" — instead of an alarming "Setting up" pill with nothing for the customer to do.
• DMARC focused page suppresses conflicting setup cards. When Managed DMARC is enrolled, the legacy "Publish this _dmarc TXT record at your DNS provider" card and the "Setting up — we're publishing your DMARC record" banner are hidden. The Managed DMARC block carries the authoritative next step (set the CNAME) without competing instructions that would have asked the customer to set both a TXT and a CNAME at the same DNS name (impossible per DNS rules).

Who it affects

Customers on Pro+ plans where Managed DMARC has been enabled. Non-eligible users are unaffected (the response was already correct for them).

Two related improvements to the Managed DMARC activation experience.

What changed

• Intermediate "Activating" state on the focused DMARC page. Verifying your CNAME with the inline check button tells you mxio detected the change — but full activation only flips on the reconciler's next 5-minute tick. Previously the page went straight from "Pending activation" to "Active" with no signal in between, which led to a reasonable "did I break something?" reaction when the page kept showing "Pending activation" five minutes after a successful verify. The focused page now renders a 4-step progress display during that window:

  1. CNAME verified
  2. Confirming with our reconciler
  3. DMARC reporting handshake
  4. Active

  The page polls our status endpoint every 30 seconds and auto-advances as each step completes. You can leave the page; we keep working in the background.

• In-app notification + email when Managed DMARC goes active. Once the reconciler confirms the delegation and flips your service to active, you now get a bell-dropdown notification and a transactional email — "Managed DMARC is active for <your domain>" — so you can close the loop without checking the dashboard.

Why it matters

Activation is the moment you actually get the value of Managed DMARC — ongoing policy progression and aggregate reporting. The progress UI makes the 5–15 minute handoff window legible rather than mysterious, and the notification + email mean you find out the moment we're done.

What stays the same

• No DNS or policy changes — this is pure UX + notification.
• Manual review, wrong-CNAME, and DNS conflict surfaces still take priority over the activation progress display when they fire.
• N3 invariant preserved: customers not eligible for Managed DMARC see no UI change.

The seven comparison pages on /compare/* used to position mxio as a Monitor platform with extras stacked on top. They now position mxio as what it actually is: a Manage-rung platform — we publish your SPF record (Managed SPF), we publish your DMARC policy (Managed DMARC), and we monitor everything around them.

What changed. Across all seven pages:

• Endpoint-monitoring framing dropped. The HTTPS / Ping / TCP Port bullets that appeared on every page are gone. They were off-ladder for what mxio actually does — manage email authentication, not monitor arbitrary endpoints. MX SMTP reachability stays as on-ladder substrate (it's email-specific and runs on every tier including Free).

• "Honest Caveat: Managed DMARC" sections retired. The PowerDMARC and DMARCLY pages used to carry sections conceding that Managed DMARC wasn't available. It is now. The pages flip to head-to-head: both vendors offer CNAME-delegated Managed DMARC; the differentiator is bundling and price tier.

• MXToolbox page re-lede. Previously "built for continuous monitoring" — that framing concedes Monitor positioning to a vendor who already owns it. Now: "built to manage email authentication, not just report on it."

• Valimail page rewritten as a Manage-rung peer. Both vendors operate the email-auth layer. The differentiators are the delegation model (selective record delegation vs full namespace handover), the audience (SMB vs enterprise), and the pricing model (published self-serve vs $5,000/yr sales-call entry).

• autospf page sharpens the full-platform-vs-single-feature framing. AutoSPF is a SPF flattener; mxio is the email-auth platform that includes Managed SPF alongside Managed DMARC and DMARC Reporting.

No new features in this update. The product changes (Managed DMARC, the five-plan ladder) already shipped. This is the marketing site catching up to the product.

The old lineup had two $19 starter plans — Monitoring Starter and DMARC Starter — that worked the same except for which feature was included. Customers found the symmetric-starter UI confusing, and we never saw a customer pick Monitoring Starter when DMARC Starter was right there for the same price.

New lineup. One linear ladder, five tiers:

DMARC Starter is the $19 entry. Core ($34) is "DMARC Reporting at scale" — more domains, faster checks, more email alerts. Pro and Business are the managed-services tier: Managed SPF + Managed DMARC + the full ops platform.

Always-on monitoring on every tier. MX, SPF, DKIM, and DMARC records are monitored continuously on every plan, free tier included. The "Monitoring Starter" plan that used to sell monitoring as a standalone product is gone — because monitoring is now substrate, not a product.

Managed DMARC arrives at Pro+. Symmetric with Managed SPF. We auto-provision your managed _dmarc record at domain-add time. You publish one CNAME at _dmarc.<your-domain> — the same single-DNS-change pattern as Managed SPF. We monitor reports, track enforcement readiness, and propose tightening from p=none to quarantine to reject when your senders are reliably aligning. You approve. We deploy.

The full Managed DMARC page is at /services/managed-dmarc.

Existing customers see no change. Owner verified zero monitoring_starter subscribers at cleanup time — there was nothing to migrate. Anyone on Pro or Business will see the new Managed DMARC surface alongside their existing Managed SPF. No price change, no feature loss.

What else moved:

• Nav dropdown renamed "Services" → "Managed Services". Order: Managed SPF, Managed DMARC, DMARC Reporting.
• Homepage subhead "Diagnose. Monitor. Fix." → "Diagnose. Monitor. Manage." — three nouns that match the three product rungs in order.
• /services/monitoring page retired — 301 redirect to /pricing. Anyone with a bookmark goes straight to the new lineup.
• Flatten packs eliminated. SPF flattening is now a hard plan benefit: Pro gets 10 flattened domains, Business gets 25. No add-on, no per-domain arithmetic.

Every free-tool result page used to end with the same suggestion: "Want continuous monitoring? Add this domain to your dashboard." Useful when the result was healthy. Less useful when it wasn't — a failing SPF check deserves a CTA that fixes the SPF, not a generic monitoring nudge.

What changed. The CTA below every tool result is now driven by the specific failure mode:

• SPF over the 10-lookup limit, near the limit, or failing → "Fix this with Managed SPF." Managed SPF flattens the include chain to IPs and stays under the limit automatically.
• DMARC missing or p=none → "Start with DMARC Reporting." Reporting classifies your senders so you can tighten the policy safely.
• DMARC enforcing (p=quarantine or p=reject) → "Keep it that way with Managed DMARC." Brand-new CTA surface — the enforcing-DMARC result used to fall through to the generic monitoring substrate, now it routes to the right service.
• Weak DKIM key (1024-bit) → "Rotate to 2048-bit" with a link to the learn hub. We don't manage DKIM rotation yet — no fake CTA.
• Healthy results → still "Add this domain to your dashboard," because monitoring is the right move when nothing's broken.

What this fixes. The old "Want continuous monitoring?" CTA appeared 12 times across the tools surface and on the public /report/<domain> page. Every appearance now picks the right destination per failure mode. A logged-in customer viewing a tool result for a monitored domain gets a deep-link straight to the relevant focused page (/dashboard/domains/N/spf, /dashboard/domains/N/dmarc) — no more "go to dashboard, find the domain, find the right tab."

No behavior change for anyone viewing healthy results, and no behavior change inside the dashboard itself — the dashboard already had per-domain focused pages.

The domain advisor now detects DKIM selectors using short RSA keys — typically 1024-bit keys that predate modern security guidance — and surfaces a "Weak DKIM key detected" advisory action.

What it checks: When a DKIM health check finds a selector using an RSA key between 513 and 2047 bits, the advisor flags it. Keys of 512 bits or fewer are already treated as invalid (broken, not just short); this new signal covers the in-between range that is technically valid but increasingly considered insecure.

Provider-aware guidance: The advisor identifies which email provider each affected selector belongs to (Google Workspace, Microsoft 365, and others in the provider catalog) and tailors the advisory body accordingly:

• Single known provider: "Your Google Workspace DKIM key uses a short RSA key (under 2048-bit). Rotate it to 2048-bit in the Google Workspace admin console."
• Multiple providers or mixed: Lists all affected providers and routes you to the DKIM focused page for a full selector review.
• Unknown selector: Shows the selector name and advises contacting your email provider.

The action appears at priority 2.92 in the advisor — after dkim_invalid (a broken key), before DMARC setup steps — and routes to the DKIM focused page via "Review DKIM selectors →".

The per-domain page (Domains → your domain) used to hide two unrelated settings behind a single Edit button: monitoring check configuration and DKIM selectors. Each now lives with the thing it controls.

• Monitoring check configuration — which checks run for a domain — is now inside the Monitoring & DNS hygiene panel on the domain page. Expand the panel, then open Check Configuration.
• DKIM selector management — discover, add, and remove selectors — is on the domain's DKIM page, alongside DKIM status and CNAME setup.
• The Edit button is gone. Nothing was removed — both surfaces simply moved next to what they configure, so you no longer dig through a settings dialog to find them.

Managed SPF setup used to be a multi-step wizard — detect senders, configure the managed record, publish, wait, verify. If you started but didn't finish, the domain detail page would sit in a "resume to finish" limbo with no cancel path.

We've replaced that with auto-provisioning at domain-add time. When you add a domain on a Pro or Business plan, we read your existing apex SPF, identify the senders we can catalog-match, and pre-build the managed sub-record on Cloudflare. The domain detail page then shows a "Ready to activate" card with a copyable replacement record and a single "Check DNS" button.

Activation is one DNS change at your registrar:

v=spf1 include:<your-label>.spf.mxdns.io ~all

We preserve the all qualifier from your existing record — if you were running -all (hard fail), the copyable record uses -all too. No silent downgrade.

Drift panel: the domain detail page compares the managed record against your current apex SPF. If you have senders in your apex that we haven't added yet (or vice versa), the panel tells you so before you flip DNS — no surprise coverage gaps.

For domains already in the wizard's pending state: an ops backfill sweeps them safely. Domains that already have a working managed record transition to active without a re-deploy; the rest get re-provisioned.

Plan upgrades: crossing into a Managed-SPF-eligible plan now retroactively provisions all your existing domains via the same path. No manual setup required.

Downgrades: if your plan loses Managed SPF entitlement while a domain is in ready state, we check your apex DNS first. If you've already pointed at us, we transition to active then paused (standard billing flow). If you haven't, we delete the managed record cleanly. On DNS failure, we leave everything intact — your configuration is never destroyed on ambiguous DNS.

Tool results now lead with the answer. Run an MX lookup and the first thing you see is the actual record, mail.mailroute.net, not a score or a paragraph about it. The same applies across SPF, DKIM, DMARC, MTA-STS, blacklist, nameserver, DNSSEC, expiry, and the DNS-record lookups: the raw value sits at the top, copyable, with the health score and full breakdown right below it. The score you rely on has not changed; it just no longer hides the lookup result.

A full walkthrough of the dashboard turned up a cluster of issues on the per-domain DMARC page and in how SPF soft-fail was framed. They're fixed.

The DMARC focused page reads your record. It used to show "p=unknown" and a bare policy keyword where the published record should be. It now states your actual policy — p=none, p=quarantine, or p=reject — and shows the full _dmarc TXT record currently in DNS.

Malformed DMARC records are surfaced, not hidden. A _dmarc record that exists but has a syntax error used to be mislabeled "DMARC not enabled." The hub card now reads "Malformed record" and the focused page shows the broken record with a clear fix path — receivers ignore a malformed record entirely, so this matters.

No more internal error codes. A domain without DMARC enabled no longer renders raw backend codes or an empty "report evidence" section.

SPF soft-fail guidance is context-aware. An SPF record ending in ~all (soft-fail) is no longer labeled "Recommended". Whether ~all is adequate depends on your DMARC policy: with DMARC enforcing, ~all is fine and the page says so; without DMARC enforcing, ~all is flagged as a real gap on the SPF card, the domain list, and the advisor.

Clearer advisor and card copy. The advisor banner's eyebrow now reflects severity consistently. A DMARC enrollment stuck without reports for over a week reads "No reports yet" instead of a calm "Setting up". Managed SPF setup that's mid-flight is labeled "Setup in progress" on the domain hub.

A domain's status chips and its advisor verdict used to draw from different places — the chips from real DNS probes, the advisor from our internal records. They could disagree: a domain with a red SPF chip could still read "All clear." That's fixed. The advisor now reads the same observed-DNS signals the chips do.

Over-budget SPF is caught everywhere. An SPF record that exceeds the 10-lookup limit is now flagged on every domain, with the real count ("11/10 lookups"), not just on domains using Managed SPF.

Malformed DMARC is no longer mislabeled. A _dmarc record that exists but has a syntax error used to be reported as "No DMARC record." It now gets its own verdict — "Your DMARC record is malformed" — so you fix the record instead of adding a second one.

Missing reporting address is flagged. If a domain is enrolled in mxio DMARC reporting but its published _dmarc record doesn't actually include your mxio rua= address, the advisor now tells you — instead of showing "All clear" while no reports come in.

SPF soft-fail shows as a warning. An SPF record ending in ~all (soft-fail, which doesn't enforce) now renders an amber SPF chip, matching the advisor's existing soft-fail verdict.

The domain list advisor now covers the full email-auth lifecycle — not just DMARC setup and SPF budgets. Seven new recommendations surface the missing pieces:

SPF gaps — Missing SPF records, syntax errors, and soft-fail (~all) policies each get their own recommendation so you know exactly what's wrong and what to fix.

DKIM gaps — No selectors configured (so we can't monitor your DKIM signing) and invalid DKIM records both surface as actionable attention items.

DMARC enforcement readiness — When your DMARC policy is p=none and your alignment data looks healthy, the advisor surfaces "ready to start enforcing?" When you're at p=quarantine with strong alignment, it suggests moving to full rejection. Both fire only when the data supports it.

DMARC chip labels — The DMARC chip on each domain row now shows the observed policy: "DMARC: none" in amber (monitoring-only), "DMARC: qtn" (quarantine), or "DMARC: reject". You can see enforcement level at a glance without opening the domain.

Managed SPF drift — When Managed SPF is active but the domain's published record no longer includes the managed SPF record, the SPF chip turns amber immediately — no waiting for the staleness threshold.

Two checks gave wrong answers when you pointed them at a subdomain rather than a registered domain. Both are fixed.

Domain expiry now works for subdomains. Registries only hold a renewal date for the registered domain — example.com, never mail.example.com. The expiry check used to query the subdomain directly, get nothing back, and report a lookup failure. It now climbs to the registered domain, reports that renewal date, and labels the result clearly so you know whose expiry you're looking at.

DMARC now recognizes inherited protection. Under the DMARC standard (RFC 7489 §6.6.3), a subdomain with no _dmarc record of its own is still protected if the parent domain publishes a subdomain policy (sp=). The check used to ignore this and report "No DMARC record found" — a false alarm on a subdomain that was actually protected. It now climbs to the organizational domain and reports the real, inherited policy:

• Inherits quarantine or reject → the subdomain is protected.
• Inherits none → the subdomain is covered only by monitoring, flagged as a warning.
• The parent has no valid DMARC record either → still reported as missing, with guidance to fix it at the subdomain or the organizational domain.

The Reports page has a new Setup Guide tab. It groups every domain by its DMARC setup stage — not configured, ready to strengthen, collecting data — and gives you the exact _dmarc TXT record to publish for each one. Domains that still need their record published carry a Verify now button that checks DNS on demand. Export the whole guide as CSV to work through a portfolio at once.

The domain list verdict has always shown your single most important next step — the right call for keeping a long list scannable. But a domain can have more than one thing wrong at once, and until now the others were invisible.

Every issue, on hover. The row still shows the one primary headline; hover it to see the complete, priority-ordered list of everything the advisor found — missing SPF, an unconfigured DKIM selector, no DMARC record, and so on. Each entry gets its full explanation and a direct link to the page where you fix it. The verdict is now a link, and the whole row is clickable — no separate "Open" control.

A status column that earns its space. The short status text to the right of the verdict used to echo the headline — "No DMARC record" next to "No DMARC record — add one…", "Monitoring" next to "All clear — monitoring." It now carries only information the headline doesn't: lookup counts, senders to review, the day-of-14 baseline counter, alignment percentages. When the headline already says it, the column stays empty.

The domain hub (/dashboard/domains/[id]) now has a fifth card: Senders.

Authorized senders were previously accessible only through the SPF focused page or the DMARC slide-over — two separate entry points for one shared registry. The new card surfaces the registry at a glance and routes directly to the Senders page.

What the card shows:

• Authorized senders — the count of senders you've explicitly approved (source other than DMARC discovery, status authorized).
• Review needed — if senders appeared in your DMARC reports but haven't been authorized or dismissed yet, the card turns amber and shows the count.
• Mode-aware copy — when Managed SPF is active, the card notes that your SPF record is built from the list automatically. When you manage SPF yourself, it reminds you to make sure authorized senders are included in your record.

A round of dashboard improvements makes the everyday flow faster and the per-domain view easier to read.

• Straight to your domains. The dashboard now opens directly to your domain list — no separate loading hub in between. The platform status for Monitoring, DMARC, and Managed SPF sits right at the top of the list.
• Domain rows are real links. Open a domain in a new tab or middle-click it like any other link.
• Managed or Unmanaged, at a glance. Each record card — MX, SPF, DKIM, DMARC — now shows a Managed or Unmanaged badge, so you can see what mxio maintains for you versus what you maintain yourself.
• The SPF card leads with SPF health. The per-domain SPF card now opens with the state of your SPF record — like its MX, DKIM, and DMARC siblings — instead of only talking about Managed SPF.
• Calmer first day for new domains. When you add a domain, its DMARC page no longer shows the full enforcement roadmap before there's anything to act on. It stays calm until reports arrive and explains that DMARC monitoring is turned on automatically.
• Polish. Clearer billing copy, a "mark all read" action for notifications, and a tidier navigation sidebar.

The domains list now groups your domains by what needs you — Needs attention, Watching, Healthy — so the one that's broken is at the top, not buried in a sorted table. Each row shows SPF, DKIM, and DMARC at a glance plus a plain-English recommendation of the next move. The 0–100 health score and the dense column grid are gone — a number and eight columns never told you what to actually do.

When you authorize a sender from the DMARC Discoveries panel, a new "Include in SPF record" toggle appears on each row.

• Evidence-based default. The toggle defaults off when your DMARC reports show the sender is already DKIM-aligned — meaning it passes DMARC without an SPF entry. For senders without DKIM alignment, the toggle defaults on.
• Real lookup impact. When the toggle is on and you have Managed SPF active, the UI shows the exact lookup cost from your SPF engine — e.g. "+1 lookup -> 5/10" — not a local estimate.
• Always reversible. The toggle is a recommendation, not a verdict. Override it any time. Authorizing with the toggle off leaves your SPF record untouched.

The SPF page for a domain (Domains → your domain → SPF) used to be only about Managed SPF. Now it works whether you manage SPF yourself or let mxio do it.

• Your SPF record, in plain view. See the published record, a DNS-lookup budget meter (with a warning when you cross the 10-lookup limit), the default-policy explainer for ~all / -all, and any validation problems.
• Sender coverage gap analysis. mxio compares the services you've authorized against what your SPF record actually contains. It flags authorized senders that aren't covered — with the exact include: to add — and includes in your record that don't match any sender, so you can spot stale entries wasting lookups.
• Managed SPF, still one click away. If you'd rather not maintain the record by hand, the Managed SPF panel is right there — it flattens and maintains the record for you. When Managed SPF is active, mxio handles coverage automatically and the page says so.

The per-domain page is now a hub: one glance at MX, SPF, DKIM, and DMARC, with the Advisor's single next step up top. Each record opens its own focused page with room to work — no more scrolling one long stack. Old bookmarks and links redirect automatically.

The biggest change to the Domain page since we launched it. /dashboard/domains/<id> no longer has tabs at all. Everything you used to navigate between — uptime status, DMARC policy, Managed SPF, DKIM, senders, reports, infrastructure checks, recent activity — now lives on one page as eight sections in a single stack.

Why kill the tabs. Health / Reports / Configure was a useful first cut, but the tab labels were product-shaped, not customer-shaped. "Am I on the right tab?" is a question we asked you to answer that we should have answered for you. The new model: one URL per domain, sections morph based on what the domain needs right now. A fresh domain with three pending decisions looks different from a year-old domain in monitoring mode — but it's the same page, the same skeleton, the same scroll. No tab to land on.

Sections adapt to their state. Each of the eight sections — Mail Flow, Senders, SPF, DKIM, DMARC Policy, DMARC Reports, Infrastructure, Activity — can render in one of three modes:

• Conversational when a decision is pending. Accent left border, plain-English prose explaining what to do and why, the action button right there.
• Monitor when the section is settled. Compact one-line status, or a rich-monitor card with stats and a deep-link for forensic detail.
• Edit when you're actively configuring something. The section expands in place — the editor opens right where the status card was, and the sections above and below stay exactly where they are. No modal, no pop-up, no leaving the page. Click Save or Cancel and the section settles back to its monitor card. You can deep-link straight into an editor too (?edit=senders, ?edit=dmarc) — useful for "fix this" links in alert emails.

Persistent Advisor names the next move. A block above the section stack always tells you the one most important thing to do right now, and points you straight at the section that handles it — "Start with DMARC", "Start with Senders". It doesn't re-explain the problem; the section itself does that when you get there. When nothing's urgent and the domain has been healthy for two weeks, the Advisor goes quiet ("All clear — monitoring").

DMARC arrival framing. A new visual strip in the DMARC section shows where you landed when you first turned on mxio (p=none / p=quarantine / p=reject) — frozen at first observation, so the framing copy matches your actual journey. Customers who arrived at p=quarantine see different setup prose than customers who arrived at p=reject. We've watched too many people land on a generic "configure DMARC" screen that didn't match where they actually were.

Deep reports route to the cross-domain hub. The per-domain Reports tab is gone; "View full reports →" on the DMARC Reports section takes you to /dashboard/reports?domain=<your-domain>#senders — same data, but in the cross-domain UI where you can flip to comparing across all your domains mid-investigation. The URL contract is shareable: ?since=&until=&source= all preserved across navigations.

Old bookmarks still work. ?tab=health|reports|configure URLs automatically router.replace to the clean URL and smooth-scroll to the relevant section.

What this enables next. The section primitive (<DomainSection>) is the foundation for future managed services. Managed DMARC (Phase U) will add a configure section, not a new route. Pattern is locked.

This work shipped as Phase 6 of the Domain IA Redesign — the per-domain page rebuilt around a single morphing section stack. Local-only for now while we run visual regression and your final review before production deploy.

If you've used the DMARC surfaces over the last few weeks and felt like something was missing from the Configure tab, you were right. The enforcement journey — the vertical stepper that walks you from p=none through p=quarantine to p=reject, with stage badges, blocker cards, anomaly cards, and the AI Explain button on each source — went quiet when we collapsed the per-domain DMARC surfaces into the Domain page back on 2026-05-16. The page only kept the status header (which state you're in right now); the path (where you are on the journey and what's blocking the next step) went missing.

It's back.

Where it lives. /dashboard/domains/<id>?tab=configure#section-1-dmarc-policy. The status header (DMARC Policy) sits at the top of Section 1; the journey panel sits right underneath, separated by a border. Same panel you've seen since 2026-04-14, mounted in its proper home.

What it shows. Same as before:

• Stage badge — Discovery, Configuration, Readiness, Enforcement, or Steady state.
• Three-phase stepper — Phase 1 Monitoring → Phase 2 Quarantine → Phase 3 Reject, with seven sub-steps highlighting the one you're currently working on.
• Blocker card — when something is holding you back from advancing (most commonly: unclassified senders that need an Authorize/Dismiss decision).
• Anomaly cards — new sender detected, alignment dropped, country cluster — each with an inline AI Explain button that gives you a plain-English read on what's happening.
• Authorize / Dismiss / Skip — per-source decisions wired straight into the sender registry, so a click here updates the same data the Senders surface uses.

Sources → When the journey panel says "Review N more sources" or "Review senders," that affordance now takes you to the Reports tab (?tab=reports), where the full Sources / Timeline / Geography / Reports detail lives since the three-tab refactor. Same destination as the "Full evidence →" button on the Health tab.

Nothing else changed. The journey UI hasn't been redesigned. The state machine hasn't moved. The backend hasn't changed shape. This is purely a re-mount of the existing component into the live IA — what shipped on 2026-04-14, in the place it should always have lived.

If you've been wondering "where do I see what's blocking my next policy advance?" — that answer is back in your Domain page.

A small but meaningful refinement to the Domain page. /dashboard/domains/<id> now opens with three tabs instead of two: Health (default), Reports, and Configure.

Why split Report into two. The old Report tab was doing two jobs — it was both the at-a-glance snapshot (uptime pills, history bar, service health cards, hosts, timeline, incidents) AND the entry point for the deeper Sources / Timeline / Geography / Reports evidence viewer (which was buried behind a "Full evidence →" button that opened a modal). Putting the snapshot on its own tab — Health — lets it breathe, and promoting evidence to its own top-level tab — Reports — makes the forensic detail a first-class destination instead of a modal hiding one click away.

Reports is no longer a modal. Sources / Timeline / Geography / Reports now render inline on the Reports tab. Same data, same sub-tabs, same DMARC report drill-down — just without the dialog shell, no focus trap, no "where did the page go." You can deep-link directly to it: /dashboard/domains/<id>?tab=reports.

Health is now the default. Land on a domain page and you see the snapshot view first. The Authentication Report card (7-day DMARC aggregate) lives at the top of Health, with "Full evidence →" right under it — clicking now navigates to the Reports tab instead of opening a modal.

Your old bookmarks still work. Two legacy URL shapes redirect automatically on mount:

• /dashboard/domains/<id>?tab=report (singular, from the two-tab era) → ?tab=health
• /dashboard/domains/<id>?dmarc=evidence (the old "open the evidence modal" intent) → ?tab=reports

Both redirects happen in the URL bar — a refresh doesn't loop you back through the redirect.

Configure tab is unchanged. Sections 1–5 (DMARC Policy, DNS Pointing Status, Senders, External Reporting, Subdomains) all render exactly as they did last week. Deep links like ?tab=configure#section-3-senders still land at the right section.

Nothing about the underlying data, fetches, or service behavior changes — this is purely a layout and navigation refinement, building on Phases 1–4 of the Domain-Centric IA Redesign. With evidence now a real surface instead of a modal, you can leave it open, share the URL, refresh it without losing your place.

Phase 4 of the Domain-Centric IA Redesign ships today. Cross-domain reporting now has a real home at /dashboard/reports with four hash-routed sub-views — and the four legacy service hub URLs (/dashboard/services/{dmarc,spf,senders} and /dashboard/services/dmarc/usage) redirect to the new surface.

Why the move. Each per-domain service collapsed onto the Domain page in earlier phases (Phase 1: Senders, Phase 2: Managed SPF, Phase 3: DMARC Reporting). What was left at the hub level was a set of cross-domain summary pages. Those scatter the cross-domain view across 4 routes when it should be one place. Now it is.

Four sub-views, one route, hash-deep-linked.

• #email-insights — Cross-service activity timeline. Every DMARC alignment alert, SPF recommendation, sender authorization, domain change across your portfolio lands here as a categorized event row. Filter by category (DMARC / SPF / Sender / Domain / Other), filter by domain, set a date range. Expand any row inline to see the raw event metadata and a "View →" deep link to the per-domain surface that owns it.
• #senders — Cross-domain sender table. One row per domain showing total authorized senders, how many are in your published SPF, and how many discoveries are pending classification. Click into a domain row → goes straight to that domain's Configure tab → Section 3 Senders.
• #domains — Combined DMARC posture + SPF status + DMARC usage per domain. DMARC policy, alignment %, message count over the window, SPF flatten status, last deploy timestamp. Date-range picker drives the message count. Click a row → that domain's Report tab.
• #enforcement-status — DMARC enforcement matrix across your entire portfolio. Every domain you own appears as a row (even ones without DMARC enabled — those show "(none)" + an em-dash). Filter by Sending Status (active / reporting_only / blocked) and observed Policy (p=none / quarantine / reject). Click a row → that domain's Configure tab Section 1 to enable or change DMARC.

CSV export on every sub-view. The Export CSV button hits the same endpoint with ?format=csv and downloads the current filtered view as a CSV. The activity timeline export bypasses pagination — you get the full window in one file (capped at 10,000 rows + 90-day max range). The other three sub-views export the whole table.

Direct deep links to a sub-view. /dashboard/reports#senders jumps straight to Senders. /dashboard/reports#enforcement-status to the matrix. Browser back/forward walks your tab navigation — share links land on the right tab. Date-range and filter changes preserve the active tab in the URL.

Sidebar nav. The "Services" nav section is gone — every former child surface either moved onto the Domain page (Phase 1-3) or onto the new Reports surface (this phase). Reports is now a real top-level nav item, not the Phase 1 transitional stub.

Hub URLs still work. Bookmarks to /dashboard/services/dmarc, /dashboard/services/dmarc/usage, /dashboard/services/spf, and /dashboard/services/senders redirect to the matching Reports anchor. Bookmarks to /dashboard/services/dmarc/<domain>/legacy redirect to that domain's Report tab. The redirects are HTTP 308 permanents so browsers cache them.

What's next. Phase 5 (Overview redesign) is next on the Domain-Centric IA Redesign arc, and Phase U (Managed DMARC) is now unblocked.

After shipping the DMARC-into-Configure-tab move this morning, a targeted UX audit caught a handful of rough edges. Same-day fixes:

Awaiting-DNS now shows the record to publish. Earlier today the Configure tab's DMARC Policy block told you to "publish this _dmarc TXT record" without showing the record. Fixed — the expected TXT record name and value now render inline with copy buttons, sourced from your account's reporting destinations. No more clicking "Verify DNS →" hoping it reveals the record you're supposed to publish.

Active state shows your current configuration inline. Same screen, active state — was just "Policy: none — receiving aggregate reports." Added a "Current configuration" panel that shows your published _dmarc record, where reports are going (RUA destinations), when the last report arrived, and your sending status. You no longer have to click "Customize policy" just to see what's currently published.

p=none clarified. "none — receiving aggregate reports" misread as "no policy at all." Now reads "Policy: p=none (monitoring mode) — receiving aggregate reports for example.com."

Stale state no longer renders the badge label twice. Visible render bug — fixed.

DMARC and Managed SPF health cards on the Report tab no longer render two "View config" links side by side. The Slice 14 / Phase 2 "View configuration →" deep link is the one that goes to the canonical home; the legacy duplicate is removed.

Authentication Report empty-state copy differentiates "newly enabled — reports incoming" (under 48 hours since enable) from "no recent traffic — check your rua= destination" (enabled over 48 hours ago with zero messages).

Nothing about the backend changes. Same DMARC handlers, same anchor state machine, same authentication-summary endpoint. Just a closer-to-finished UX on the new DMARC home.

Phase 3 of the Domain-Centric IA Redesign ships today. Everything you used to do at /dashboard/services/dmarc/<your-domain>/{advisor,override,dns-records,setup,how-it-works} now lives on a single screen: /dashboard/domains/<id> → Configure tab → Section 1: DMARC Policy.

Why the move (again). If you're managing a domain, the natural place to check what mxio is publishing for it is on that domain's page — not buried under a per-service hub. Last week Managed SPF moved into Configure tab Section 2. Today DMARC Reporting takes Section 1. One Domain page, all the dials. The Configure tab is now your full DMARC + SPF + Senders + External Reporting workbench.

A new way to see "what's happening" on the Report tab. The Report tab on every Domain page now shows a new Authentication Report card up top: 7-day snapshot of message volume, aligned SPF pass-rate, aligned DKIM pass-rate, disposition breakdown (Allowed / Quarantined / Rejected), and a 5-bucket sender rollup (mostly passing / partially passing / mostly failing / unidentified / internal). The "Full evidence →" button opens a focused modal with the Sources / Timeline / Geography / Reports tabs you're used to, without losing your place on the Domain page.

Eleven states the DMARC Policy block can be in. Active (showing your published DMARC record + Customize policy + Refresh status). Awaiting DNS (you haven't published the _dmarc TXT yet — instructions + Verify DNS button). Awaiting reports (DNS is published, no aggregate reports yet — give it a day). Awaiting provision (we're publishing your record to our delegated zone — under a minute). Stale (reports stopped arriving for 14+ days — check your rua= mailto). Provisioning failed (publish failed; Retry button + Contact support after 3 retries). Not enabled (Enable DMARC CTA). Loading + plan-locked round out the set. Paused and Grace are billing-enforcement states: if you ever see them, it means your account is over your plan's domain limit and the least-recently-used DMARC services have been paused or are about to pause. Recovery is a click — Upgrade plan or Manage your domains — both linked directly from the card.

Direct-link URLs to specific actions. Want to send a customer straight to the enable flow for a domain? /dashboard/domains/<id>?tab=configure&dmarc=enable#section-1-dmarc-policy. Same pattern for &dmarc=override (opens the policy customization modal), &dmarc=evidence (opens the Sources/Timeline/Geography/Reports modal directly), &dmarc=verify-dns (kicks off the "we'll check your DNS now" flow). The intent param strips itself out of the URL after the modal opens, so a refresh doesn't loop you back in.

Your old bookmarks still work. Five legacy /dashboard/services/dmarc/<domain>/* URLs all redirect to the new home — your saved tabs, your email-link bookmarks, anything pointing at the old advisor / override / dns-records / setup pages lands at the right Configure section with the right modal pre-opened. The old how-it-works explainer becomes a polished "moved" note linking back to your domain list.

The Report tab on the Domain page now has a "View configuration →" link on the DMARC health card that jumps straight to Section 1 — handy when you spot an attention badge on the dashboard and want to dig in.

Phase U (Managed DMARC) is now unblocked. With both Managed SPF (Phase 2) and DMARC Reporting (Phase 3) collapsed into the Configure tab, the IA infrastructure can host the next managed service: mxio publishing your DMARC record on your behalf, with the same operational model as Managed SPF. Plan drafted; ship date when you greenlight.

Nothing about the actual DMARC report ingestion, aggregation, advisor logic, or enforcement journey changes. Same backend, same reports, same alerts. Just a much shorter path from "I want to check DMARC on example.com" to actually being on that screen.

Phase 2 of the Domain-Centric IA Redesign ships today. Everything you used to do at /dashboard/services/spf/<your-domain>/{setup,config,status,history} now lives on a single screen: /dashboard/domains/<id> → Configure tab → Section 2: DNS Pointing Status.

Why the move. If you're managing a domain, the natural place to check what we're publishing for it is on the domain's own page — not buried four clicks deep under a per-service hub. The Configure tab is where every per-domain managed service ends up: Senders moved here in Phase 1, Managed SPF moves here today, DMARC Reporting and Managed DMARC follow in upcoming phases. One Domain page, all the dials.

Setup, edit, and history open as modals. Click Enable Managed SPF and the multi-step setup wizard opens inline — no route change, no losing your spot. Same for Edit SPF record (the mechanism builder with live preview and the diff-before-publish confirmation modal) and Version history (the forensics view of every published version with full content diffs). Close the modal and you're back on the same Section 2 view with the latest status refreshed.

Eight states the SPF block can be in. Active (showing your apex include hint + the current published managed record + lookup count + last deployed). Drift detected (the managed include is gone, extra mechanisms appeared, or your policy doesn't match — with the specific findings spelled out). Not configured (Enable CTA). Setting up (Resume button). Paused — important: if you ever see this, it means your account is over its plan's domain limit and the least-recently-used Managed SPF deployments have been paused for billing enforcement. The recovery is to upgrade your plan or remove some domains, both of which the page now links to directly. Error states surface the worker's error message and offer Refresh + Contact support. Loading + plan-locked states fill out the set.

Direct-link URLs to specific actions. Want to send a customer straight to the setup wizard for a domain? /dashboard/domains/<id>?tab=configure&setup=spf#section-2-dns-pointing. Same pattern for &edit=spf (opens the editor modal) and &history=spf (opens the history modal). The intent param strips itself out of the URL after the modal opens, so a refresh doesn't loop you back in.

Your old bookmarks still work. The five legacy /dashboard/services/spf/<domain>/* URLs all redirect to the new home — your saved tabs, your email-link bookmarks, anything pointing at the old routes lands at Section 2 with the right modal pre-opened. The redirect chain resolves in under a second.

The Report tab on the Domain page now has a "View configuration →" link on the Managed SPF health card that jumps straight to Section 2 — handy when you spot drift on the dashboard view and want to dig in.

Nothing about the actual SPF flattening, polling, or deployment behavior changes. Same backend, same Cloudflare-side record publishing, same DMARC report ingestion. Just a much shorter path from "I want to check my Managed SPF for example.com" to actually being on that screen.

The domain detail page (/dashboard/domains/[id]) now has two tabs.

Report contains everything the page showed before — health checks, MX, SPF, DKIM, DMARC status, anchor cards. Nothing moved; the tab just makes it the explicit default.

Configure is a new structured layout for per-domain service config. Right now it contains the Senders surface (the same one that used to live at its own separate route). The remaining sections — DMARC Policy, DNS Pointing Status, External Reporting, and Subdomains — are placeholders that Managed SPF, DMARC Reporting, and other services will fill in over the next few phases. Deep links work: /dashboard/domains/[id]?tab=configure#section-3-senders goes straight to Senders on the right domain.

The old /dashboard/services/senders/[domain] URLs redirect automatically to the Configure tab, so any bookmarks or external links continue to work.

Nav changes: Hosts and Incidents are now top-level nav items alongside Dashboard and Domains — the "Monitoring" sub-group label is gone. The separate Senders nav item is also gone (Senders is now inside Domains). The discoveries count badge moved to the Domains item where it still shows when new senders need attention.

New Reports section: A top-level "Reports" nav item points at /dashboard/reports. For now it's a hub with links to the existing service-level reporting surfaces (Senders, Managed SPF, DMARC Reporting). A unified cross-domain reporting surface is planned for a later phase.

The learn library had the full email-authentication surface covered — fifty-plus guides across SPF, DKIM, DMARC, MTA-STS, DNSSEC, RFC walkthroughs, error fixes, and per-provider setup. What it didn't have was a front door for someone arriving cold.

Two new pages fix that.

Email Authentication 101 is a curated reading path. It frames the material in order — Why → SPF → DKIM → DMARC → Adjacent protocols (BIMI, MTA-STS, TLS-RPT, ARC) → Operate and Maintain — and each section is a short orientation followed by links into the existing deeper guides. Read top-to-bottom on your first pass; come back to individual sections when you're working a specific problem.

Email Authentication Glossary defines the 25 terms that make up the working vocabulary — SPF mechanisms, the 10-lookup budget, DKIM selectors and key sizes, DMARC alignment and the p=/sp=/pct=/rua/ruf tags, ARC, BIMI, MTA-STS, TLS-RPT, DNSSEC, PermError vs TempError, and the forwarding break. Each term is short by design: definition, one line of "why it matters," and a link to the guide that covers it in depth. Every term gets a deterministic anchor ID so you can deep-link from chat, docs, or anywhere else.

Both pages are featured on /learn.

A pass over Managed SPF from a real customer's perspective surfaced more rough edges than we'd like. None individually catastrophic, but collectively the experience was confusing in ways that a careful test pilot would never tolerate.

Status page now tells you when your DNS is wrong. The "Active SPF Record" section was labeled as if it showed your DNS but actually showed our managed sub-record content — confusing because the two aren't the same thing. Now it leads with your apex DNS record at the top ("here's what's in your DNS") and "Resolves to" below ("here's what that expands to"). Above that, three new drift banners catch real failure modes: if your apex doesn't reference our managed include at all (broken — mail will fail SPF), if it has extra mechanisms alongside our include (defeats the lookup-budget benefit), or if your ~all/-all policy in DNS doesn't match what you've configured here.

Adding a sender now deploys immediately. Previously, authorizing Google Workspace from Discoveries or adding a custom IP range left your published SPF record stale until the next polling cycle (up to 5 minutes). The deploy worker now wakes on every sender mutation that changes what gets published — add a sender, toggle "IN SPF," delete a row, or repair an orphaned row, and the redeploy starts immediately.

Duplicate Google Workspace rows fixed. If you'd authorized a sender via DMARC discovery before its catalog mapping was enriched, then later tried to add it from the catalog picker, you'd end up with two rows for the same service — one with the DMARC traffic data and one with the catalog metadata. Adding from the catalog now detects the orphaned row and promotes it in place. New "Enable SPF" action button on orphaned rows resolves the catalog mapping server-side, in one click, without losing the DMARC linkage.

Config page cleanup. The "Senders in your SPF record" list and the "SPF Sources" sub-list were showing the same data twice — gone. Senders list now shows provider favicons. New + Add IP / hostname / include button surfaces custom mechanisms (ip4, ip6, a, mx, exists, include) without the previous three-clicks-and-a-buried-tab dance.

Save & Redeploy fixes. The button no longer claims a redeploy when nothing changed; it disables itself when the editor has no unsaved edits. If you click through anyway (or hit it from a fresh page open), the diff modal now says "Nothing to deploy" rather than rendering two identical record blocks side by side.

Change Log entries. History → Change Log was rendering blank pill badges with no text — a field-name mismatch between the backend and the frontend interface. Now displays human-readable event types ("Redeployed," "Drift repaired," "Initial deploy," "Rolled back," etc.) with relevant context from the deploy details.

Faster navigation. Jumping from Senders for {domain} to the Managed SPF surface for the same domain used to mean going back to the sidebar, opening Managed SPF, finding the domain in the picker. Direct cross-link in the Senders page header now.

If you've been bouncing off any of these — try again. They should all behave the way you'd expect.

If you'd added a brand-new domain and tried to set up Managed SPF, you would have hit a wall: the final "Enable Managed SPF" step returned "could not compile flattened record; please retry," and retrying never worked. Behind the scenes, your sender was authorized but flagged "not in SPF" — and the toggle to flip it the other way was greyed out because Managed SPF wasn't active yet. Activation needed senders in SPF; senders in SPF needed activation. Nobody could escape it from a clean account state. Fixed: first-time activation now includes every authorized sender you've added through the wizard or Senders, regardless of the toggle state. The "IN SPF" toggle is now a post-activation refinement (after Managed SPF is live, you can still flip individual senders off to exclude them from the record).

We also closed a related correctness hole. The "Publish" step previously instructed you to point your domain's SPF at <label>.spf.mxdns.io — but in some paths, that managed sub-record hadn't actually been created in our DNS yet. If you'd followed the instructions before we'd written the record, your live SPF would have pointed at NXDOMAIN. Now the Publish step only renders once we have proof we created the record on our side.

A few smaller things you'll notice on the way through:

• The Senders empty state now has a clear "Add your first sender" call-to-action instead of a passive "No senders configured yet" message.
• When you open Senders from inside the Managed SPF setup wizard, the "Set up Managed SPF →" banner is suppressed — you're already in the middle of doing exactly that.
• The "IN SPF" column header explains what it means (a click on the info icon), and the disabled toggle explains why it's disabled rather than just sitting there greyed out (screen-reader accessible).
• Adding a domain that doesn't resolve yet no longer flashes an orange warning one frame before the page navigates.

If you hit any of these last week and bounced off — we owe you the next attempt working. It should.

The "What will publish" preview on the Managed SPF wizard and the Config sub-page used to load fine the first time you typed something — but if you arrived on the page with an existing config, it just sat at "(computing…)" forever because nothing had triggered a preview fetch. Fixed: preview now fires on mount, retries on transient failure, and falls back to a stamped "as of HH:MM" view if the fetch fails after a successful load.

Same change adds a diff modal that opens when you click Save & Redeploy. You'll see a token-by-token diff of the managed record we publish behind your include host — current vs proposed — plus the lookup-count delta and any senders being added or removed. Your apex SPF (v=spf1 include:<your-managed-host> ~all) doesn't change; only what we publish behind it does, and the modal makes that explicit. Cancel still works; nothing publishes until you confirm.

The Upgrade flow used to make you click "Upgrade Plan", then a slide-over appeared with plan cards, then clicking a plan card opened ANOTHER modal asking you to confirm, and only then did Stripe Checkout load. Fixed: plan cards now live directly on /dashboard/billing. Click a plan card and you go straight to Stripe — no in-between confirmation. The active card shows "Opening checkout…" while we hand you off, and any error surfaces inline above the cards instead of silently failing.

Deep links into the billing page now work: clicking "Upgrade plan →" on the anchor DMARC card or Managed SPF card scrolls you to the right plan and highlights it before you click. Previously the URL params were dropped on render. The ?interval= param also pre-sets the annual/monthly toggle to match the link.

While we were in there, the DMARC card's "Upgrade plan" link used to point at Pro ($59/mo). For most users wanting DMARC, DMARC Starter ($19/mo) is the cheapest plan that does the job — so that's where the link goes now.

Paid users on /dashboard/billing keep the Change Plan slide-over (with its preview modals for downgrades and lateral switches) — those modals warn you about real consequences and stay.

The per-domain anchor page used to silently downgrade DMARC and Managed SPF cards to "Not configured" when the domain had no MX record. For sending-only subdomains (transactional mail, marketing identity, ESP-fronted subdomains), this meant the page would tell you the service was unconfigured immediately after you'd configured it — a trust killer we heard about repeatedly.

The fix removes the downgrade entirely. Cards now derive their state from your actual service config, regardless of MX presence. If your domain has no DNS records at all (a brand-new registration before propagation), we render a separate banner explaining why checks fail — without lying about your service state.

Same change also wires the anchor to re-fetch automatically after you enable DMARC reporting, so you no longer need to refresh the page to see the new state.

Five fixes to the DMARC Advisor surface, all from the Managed SPF + DMARC new-user audit.

• Recommended action inline after Authorize. The backend has been returning a structured recommended_action from POST /v1/domain-senders/<domain> for a couple of weeks; the slide-over treated authorize as fire-and-forget and dropped the payload. Now the just-authorized sender renders a dismissible card right under the Discoveries panel with the headline, body, and next-step buttons. Stops the "ok, what now?" cliff that hit immediately after the most important action on the surface.

• In-app DKIM CNAME records — no more hop to /providers. When the recommendation is "configure DKIM," click "View the exact CNAME records you need to publish" and see the records inline — name, target, and a Copy button per row. Templated for the major catalog providers we know algorithmically: Google Workspace, Microsoft 365, Mailroute, Mailgun, SendGrid, Amazon SES, Mailchimp, Postmark. The external /providers/<x> guide stays as a secondary "Full guide →" link.

• "Proposed policy" vs "current policy" on the status pill. Before your first report arrives, the Advisor reads "proposed policy: p=none" — because mxio hasn't yet seen confirmation that your _dmarc TXT is live at DNS. Once reports start flowing, it flips to "currently at p=…." Stops the ambiguity where a pre-DNS-verification surface looked the same as a verified-at-DNS surface.

• Stale-warning color escalation on reports flowing. At ≥7 days since the last report, the "reports flowing (last: Nd ago)" pill colors amber. At ≥10 days, red. Beyond 14 days the lifecycle has always flipped to "stale" with the "reports stopped" copy — this just gives you earlier eyes on a slowdown.

• RUA hash tooltip in the setup surface. The rua=mailto:<hash>@rua.mxdns.io value gets a ⓘ tooltip explaining the per-customer routing key. A curious admin Googling the hash and finding nothing is no longer a thing.

Closes audit findings M47, M48, M49, M52, M54.

Customers in the Setting Up DMARC state — RUA address provisioned, TXT record handed to them, waiting on DNS publication — used to have no way to confirm that we saw their record after they published it. The internal reconciler runs hourly. Managed SPF auto-detects DNS changes within 15 seconds; DMARC asked the same admin to wait up to 60 minutes for the next tick.

This release closes that gap:

• Check now button. A new "Check now" button sits next to the suggested TXT record on the DMARC Advisor's "What we need from you" block. Clicking it performs an on-demand DNS lookup for _dmarc.<your-fqdn>, parses the rua= mailbox, and verifies it matches the address we provisioned for you. Result renders inline: ✓ DNS publication verified, or a diagnostic explaining what's still missing.
• Auto-check every 30 seconds. While the Advisor surface is open and the verification is still pending, we silently re-check every 30 seconds. Walk away, come back five minutes later, and the verified state will already be on screen if your DNS has propagated.
• No-op on already-verified domains. Once we've confirmed your TXT is live, polling stops — no extra requests for domains that are already past this milestone.

This doesn't change report delivery timing — DMARC aggregate reports still arrive on the report sender's schedule (typically 24–48h after first publication). It only closes the visibility gap between "I published" and "mxio agrees I published."

Customers who added domains before upgrading to a DMARC-eligible plan had no working path through the dashboard to enable DMARC reporting on those existing domains. The anchor's "Enable DMARC monitoring" link landed on an empty portfolio. The per-domain DMARC page rendered "we can't load your assessment" — a transient-error message for what's actually a "you haven't set this up yet" state. The only working path was the raw API.

This release closes that gap end to end:

• Anchor enable, inline. The DMARC card's "Enable DMARC monitoring →" button on /dashboard/domains/<id> now opens a confirmation modal. Confirm, and we provision the RUA address and route you to the per-domain DMARC page — no extra hops.
• Per-domain page knows the difference between 404 and 500. Visiting /dashboard/services/dmarc/<fqdn> on a domain that isn't enabled now shows an "Enable DMARC for <fqdn>" empty state with an inline Enable button. Transient backend errors still show the existing degraded fallback.
• Portfolio empty state surfaces your existing domains. If you have domains but none are DMARC-enabled, the portfolio now lists each one with its own Enable button — instead of suggesting you add another.
• Welcome card targets the right place. The "Set up DMARC reporting" card now links to your most-recently-added domain's anchor with #dmarc-card (or to Add Domain when the account is empty), instead of redirecting to the empty portfolio. The anchor page watches the hash and scrolls to the DMARC card once its data resolves, so the deep-link works even though the page renders async.

No changes to billing, plans, or report ingestion.

If you added a domain to mxio while on the Free plan and later upgrade to Pro, Business, Core, DMARC Starter, or add a DMARC tier, every existing domain you own now gets DMARC reporting enabled automatically — the same one-step setup our auto-enable hook fires when you add a new domain.

What you'll see right after upgrade:

• Each of your existing domains shows DMARC Setting up — awaiting first reports on the DMARC Advisor.
• A bell notification per domain telling you the _dmarc TXT record to publish.
• No more dead-end where the upgrade succeeded but the dashboard pretended DMARC wasn't part of the deal.

Previously this hook only fired the moment you added a domain. If you added domains first and upgraded later, DMARC stayed quietly disabled until you walked through the setup wizard per-domain. That dead-end is closed.

If you set this up the long way before today's release, you're already done — nothing changes for you.

Disabling Managed SPF is one of the few customer-facing actions that can break mail flow if taken without a follow-up DNS edit. The previous flow guarded it with a single "Are you sure?" inline button — easy to misclick, no record of what you were giving up. This release replaces that with a typed-confirmation modal modeled after the same safety pattern we use for DMARC policy overrides.

What changed:

• Typed-confirm gate. Clicking "Disable Managed SPF" on the per-domain Status page now opens a modal that requires you to type the domain's FQDN before the destructive button enables. The body explains that your apex SPF record currently includes our managed entry and that you have 24h to re-publish your original record at your DNS host before new sender IPs start failing.
• Original SPF surfaced on success. On confirm, we fire a success toast that includes the exact original SPF record we stored when you enabled Managed SPF — so you can copy it back to your DNS host without digging through history. The toast text is locked: Managed SPF disabled. Your original SPF record is preserved at <record> — re-publish it at your DNS to restore mail flow.
• Portfolio redirect. After a successful disable we return you to the Managed SPF portfolio (/dashboard/services/spf) instead of leaving you on a page describing a service you no longer have.

No changes to billing, polling, or Cloudflare cleanup — the underlying disable endpoint behavior is unchanged.

Three Managed SPF surface polishes, one release.

Wizard step 1 — explicit "Add your first sender" CTA. When a customer starts the Managed SPF setup wizard on a domain with no detectable SPF record and no authorized senders yet, the wizard previously landed them on a blank editor with the helper text "use Senders" — a buried link, no path forward, no momentum. The wizard now renders an explicit empty-state panel: "No senders configured yet. Managed SPF publishes your record from your Senders list. Add the first sender that should be allowed to send mail as <your domain>." The "Add your first sender →" button opens the Senders slideover inline (modal-style) over the wizard, so the customer never leaves the setup flow. After adding a sender and closing the slideover, the wizard refetches the SPF configuration and the new sender appears as a configured source — ready to Save & Redeploy.

Status page — labeled Copy button on the active SPF record. The Copy affordance next to the active SPF record on the Status page was icon-only, easy to miss. It now reads "Copy" alongside the icon — mirroring the affordance on the wizard's Publish step.

Setup-time-only detection rule, made explicit. The Senders page header and the Status page caption now spell out: "We only detect new senders during setup. After activation, new senders must be added explicitly here or surfaced from your DMARC reports." This codifies a long-standing architectural property (Managed SPF polling is read-only against the senders registry) into user-facing copy so customers can plan around it.

Closes audit findings M28, M66, M67.

Two clusters of surface fixes, one release.

Managed SPF wizard — replace-not-add diff. Step 2 of the Managed SPF setup wizard previously read "ADD THIS TO YOUR SPF RECORD" with an example that replaced the customer's existing includes. A literal-reading admin would have appended our managed include on top of their existing three — landing back over the 10-lookup limit, the exact failure mode Managed SPF is supposed to solve. The wizard now renders a single LEFT/RIGHT diff: the customer's current apex SPF on the left (with strike-through), the proposed replacement on the right, a single Copy button, and a clear caption: "Don't append — replace. We've already brought the senders behind our managed hostname." Step 1 gains the same always-visible diff panel so customers can see what they're replacing before they save. The Status page now explains the versioned-hostname indirection (<label>.spf.mxdns.io → CNAME → <label>-v1.spf.mxdns.io) so the hostname the customer published and the active record they observe match up. Marketing copy on /services/managed-spf updated to use the per-customer <label>.spf.mxdns.io pattern instead of the misleading bare spf.mxdns.io.

Domain anchor — agrees with the Advisor and Status page. The domain anchor's DMARC card previously said "Not configured" for domains whose DMARC Advisor correctly said "Setting up — awaiting first reports." The cards now read the same dmarc.Compose() assessment as the Advisor itself, so both surfaces always agree. The Managed SPF card subtitle now mirrors the Status page exactly: "Active · X/10 lookups · last deployed Nm/h/d ago" — instead of a bare metric line with no provenance.

Together these close audit findings M02, M27, M30, M56, M57, and M60.

A batch of polish across two adjacent surfaces — anonymous marketing pages and the per-domain anchor — closes eight audit findings from the Managed SPF + DMARC new-user walkthrough.

Anonymous marketing surfaces

• Per-tier CTAs on /pricing for anonymous visitors. Every paid tier card now has its own "Start with <plan name> →" button that routes through /login?next=/pricing?plan=<slug> so the chosen plan survives signup. Previously every card said "Get Started" and the only differentiated CTA lived at the bottom of the page.
• Header nav signals signup is welcome. The right-side auth control reads "Sign in or sign up" on both desktop and mobile — previously just "Login," which obscured the unified-auth flow for first-time evaluators.
• "Need help choosing?" answers the combined case. Added a fourth row: "Managed SPF + DMARC reports → Pro." Evaluators who want both no longer have to infer Pro from the comparison table.
• Beta banner copy softened. Replaced "Beta Preview — Accounts may be reset at launch" with "Active development — Existing paid plans bill in production. New trial signups run in test mode." Honest framing for paying customers; transparent framing for evaluators.
• /login browser tab now reads "Sign in — mxio." Previously fell back to the site-default title.
• Authenticated-from-/ redirect: documented behavior, no change. Authenticated visitors still get pushed to /dashboard; the sidebar still uses ?view=marketing as the marketing-content escape hatch.

Per-domain anchor empty-state

• Fresh-domain banner replaces the wall of red. A newly-added domain shows a single inline banner above the check table — "<domain> is freshly added. Failures are expected until you publish DNS records." — instead of six simultaneous failure rows. The banner derives from a backend fresh_domain boolean (≤10 minutes old AND no positive record observation yet) so the frontend doesn't re-derive the boundary.
• Failure rows default to collapsed for the first 24 hours. A "Check details" disclosure wraps the table; you can expand on demand. After 24 hours the disclosure auto-expands so an established domain's failures stay visible.
• Pro/Business users see their future Managed SPF hostname before they enter the wizard. The Managed SPF card on the anchor surfaces "Your future managed hostname: <label>.spf.mxdns.io" when the service isn't configured yet — dns_label is generated at domain creation and stable, so you can pre-prepare your DNS host's UI without re-opening the wizard later. Hidden for Free users (the card is plan-locked).

Two improvements landed on /dashboard/notifications to close out the new-user UX audit:

• Managed SPF failures now enumerate their cause. The "SPF flatten failed" notification group used to be a single bucket. The "What triggers alerts" reference now lists the four specific failure modes under it: Cloudflare API error, pointer record NXDOMAIN, upstream resolution timeout, and DNS publish-budget exceeded. Routing is unchanged — the parent toggle still controls all four — but the email body and bell-tray entry will now tell you which one fired, so you can stop guessing when a job 502s.

• DMARC alignment drops and recoveries get their own notifications. Until now the Advisor surfaced "alignment is dropping" only in the dashboard mood — there was no email. Two new events join the DMARC Reporting group: "DMARC alignment dropped below 90%" (warning) and "DMARC alignment recovered above 95%" (info). Both fire at most once per domain per 24 hours; a recovery only fires if a drop was emitted first. The 90/95 hysteresis band keeps a domain that hovers at 92% from oscillating between the two events.

No action required. Existing notification preferences keep their current settings; the four flatten sub-bullets ride on top of your existing "SPF flatten failed" toggle, and the two alignment events default to enabled for the DMARC Reporting group.

Three fixes shipped from the recent Managed SPF + DMARC new-user audit:

• Annual billing now reads as annual everywhere. The billing page renders "$49/mo billed annually ($590/yr)" for Pro annual customers — previously the surface showed "$59/mo" regardless of interval.
• Savings calculator stays in sync with the pricing toggle. Flipping the /pricing toggle between Monthly and Annual now moves the Pro number in the savings block alongside the tier table — no more $49 vs $59 contradiction on the same screen.
• Managed SPF is on the welcome surface for everyone. After signup, the welcome cards include "Fix your SPF lookup limit" — Pro/Business users get a direct "Set up Managed SPF" link, Free users get an "Available on Pro — Upgrade" CTA. Visitors arriving from the Managed SPF marketing page no longer wonder where the product went.

Also fixed a backend bug: the notifications unread-count endpoint returned HTTP 500 on every first dashboard load for brand-new accounts when the queue was empty. The bell badge silently dropped the count; now it returns 0 cleanly.

The polish batch from the Managed SPF + DMARC new-user audit landed. Twenty-nine small but trust-shifting items, plus two carry-overs from PR 2 R2 (focus trap on the DMARC enable modal + a regression test for the #dmarc-card deep-link scroll).

Marketing & pricing

• /services now redirects to the homepage services anchor instead of 404'ing.
• /services/managed-spf "Get started on Pro" deep-links to /login?next=/pricing?plan=pro to match its DMARC sibling.
• /pricing hides "Get Started Free" for signed-in users and surfaces "Go to Dashboard" instead.
• Homepage and service-page fade-in animations honor prefers-reduced-motion and never trap content invisible if the IntersectionObserver fails to mount.

Dashboard anchor & welcome

• Upgrade-plan CTAs on locked anchor cards drive into /dashboard/billing?plan=pro&interval=annual instead of the public pricing page (one click to checkout, full context preserved).
• The welcome card's faux example.com monitoring table is gone — Sam no longer reads a sample failure as a real one.
• Managed SPF portfolio auto-routes ?domain=<fqdn> to that domain's setup wizard.

Managed SPF status & wizard

• Status page "Size: 848B / 512B limit" is reframed as "Size: 848B · split into 2 DNS strings" with an RFC 1035 §3.3.14 hover.
• Wizard char counter reads "80 / 255 chars (display)" with a tooltip explaining DNS-string concatenation.
• "Original SPF Record" disclosure has an explicit Show/Hide label.
• Save & Redeploy now shows a success indicator after the network call completes.
• Step 2 "Include record detected" surfaces "Verified at DNS just now" plus the literal include: value.
• "Continue later" is captioned with the URL where progress resumes.
• "Reconfigure" button explains it doesn't take the published record offline.

DMARC advisor & sources

• "Showing last known assessment" preamble is suppressed when no snapshot exists (was misleading on first visits).
• "Clean streak" panel renamed to "Senders aligned" (label describes what's measured even when no streak number renders).
• "Why?" exclusion link gets proper aria-expanded / aria-controls semantics.
• "Rename" buttons on sources/advisor explain the use case in a tooltip.

Accessibility (TASK 12)

• Avatar trigger gets aria-label="Account menu for <email>" plus aria-haspopup/aria-expanded.
• Domain header "Pause" button explains what pausing does and doesn't pause.
• All wizard steps inherit the new cancelHelp caption from the shared ServiceSetupWizard.
• New shared useFocusTrap hook constrains Tab/Shift+Tab inside modal dialogs (WCAG 2.1 AA). Applied to the DMARC enable modal; future modals get it for free.

Account menu (TASK 18)

• Billing joins the avatar dropdown alongside Profile and Security. Security stays in both the avatar and the sidebar — explicit duplication for a low-traffic but security-sensitive surface.

Add Domain hygiene

• Inline DNS resolution probe on blur. If the domain doesn't resolve, a non-blocking warning surfaces; you can still proceed (pre-DNS / split-horizon domains are valid).

Magic-link login

• The "Check your email" panel now has "Resend email" (client-side rate-limited to 5 per 15 min, server-side cap remains authoritative) and "Use a different email" — no more dead-end if Sam fat-fingered his address.

Backend changes

• internal/platformapi/anchor_handlers.go buildDmarcCTA / buildSpfCTA route plan-locked CTAs into the in-app billing flow.

Tests

• New useFocusTrap hook + 5 unit tests.
• New #dmarc-card deep-link regression test (carry-over from PR 2 R2): asserts the wrapper exists AND that scrollIntoView is called on it once the anchor settles.

We swept through ten interrelated bugs in Managed SPF setup. The biggest user-visible wins:

• No more "awaiting first deploy" stuck state. Hitting Enable now publishes your record in the same request — no wait for the next polling cycle.
• No more NXDOMAIN window. The setup wizard now refuses to advance to step 2 if the include record didn't publish — so customers never get a hostname that returns NXDOMAIN.
• Senders you add during setup just work. Toggle is on by default, deploys on the next cycle automatically.
• The Config page now clearly separates the record you publish at your DNS host (publish once, never changes) from the record we maintain for you (we publish, updates as senders rotate).
• Re-enabling never clobbers your sender choices — your authorized senders survive any future enable/disable cycle.

If you set up Managed SPF before this release and noticed any of the above, your account is unaffected; the fixes apply forward.

Until now, your authorized senders lived in two places: the catalog picker on Managed SPF, and the Sources tab on DMARC Reporting. Both wrote to the same list, but they showed it differently and let you do different things from each. If you wanted to add Mailchimp via the catalog and then dismiss a spoofing source from DMARC, you were managing two lookalike inboxes.

Senders is now its own surface at /dashboard/services/senders. One registry, one set of actions, one place to add a custom sender (an ip4, ip6, include, or mx mechanism with a name you'll recognize later). DMARC's "Discoveries" inbox shows post-enrichment senders that aren't in your list yet — authorize or dismiss in one click. Managed SPF and DMARC Reporting both publish into the same registry; you don't have to think about which "list" you're editing.

What you'll notice in the dashboard:

• A new "Senders" item in the sidebar, above Managed SPF and DMARC Reporting. The number badge counts unaddressed discoveries.
• DMARC Reporting Sources tab — every actionable row now has one Manage button (instead of separate Authorize / Dismiss / Revoke buttons). Clicking it opens the Senders panel scoped to that source so you can authorize, classify, toggle the "in SPF record" switch, or remove — all in one place.
• Managed SPF Config page — moved off the slide-over. Each domain now has dedicated Status, Config, and History tabs at /dashboard/services/spf/[domain]/.... The Config page shows a read-only summary of the senders currently in your SPF record, with a Manage senders → button that opens the same Senders panel. The raw record editor (policy ~all/-all, lookup budget, source preview) is still inline.
• The catalog picker is gone from Managed SPF. Adding senders happens on Senders. The SPF page is now record mechanics only — review what's in the record, edit policy, remove existing entries.

If you've been using the catalog picker to add senders, the same workflow now starts from Senders → "+ Add a sender" → catalog tab. Custom senders (named mechanisms) get their own tab next to the catalog.

Three small things that came along for the ride:

• The "Manage in Managed SPF →" link at the top of the DMARC Sources tab now reads Manage senders → and points at the Senders page for that domain — works for every plan tier, not just customers with Managed SPF active.
• Tab navigation between Status / Config / History is faster — we now resolve the domain ID once at the layout level and share it across tabs, instead of re-fetching the entire domain list on every tab click.
• The free SPF Builder tool at /tools/spf-builder is unchanged — it still has the catalog picker. The dashboard's editor was the surface that needed the change.

No accounts to migrate, no settings to touch — your existing senders, deploy decisions, and SPF record are unchanged. The only difference is where you find and edit them.

Your domain detail page now shows DMARC and Managed SPF status side by side. Brand-new domains get a setup-mode view ("no records detected yet") instead of the wall-of-red diagnostic table — the page knows when you're setting up versus running steady, and shows you the right thing at the right time.

We also moved Domains to the top of the sidebar, out from under Monitoring. Domains are platform-wide; they shouldn't have lived under a single service category. Same domains, same data — just easier to find.

If you've added a domain in the last few days and saw a page full of red diagnostics for records you hadn't published yet, that's the issue this release fixes.

Several rough edges in the DMARC Advisor are gone today.

The anomaly card now tells you what the anomaly is. When the Advisor flags "something needs your attention," it now names the actual signal — a new high-volume sender that isn't in your authorized list, a sharp drop in alignment, or a sender that's been failing for over a week — and points you straight at the Sources tab to fix it. Phase 2 placeholder copy ("populated by the anomaly classifier") is gone.

Authorizing a sender refreshes the Advisor card immediately. No more reloading the page to see the "Authorized senders configured" count update.

The override flow stops second-guessing you when you're following the recommendation. Picking the recommended policy on a domain with no aggregate reports yet no longer makes you check a box that says "I understand this overrides the Advisor's recommendation" — it doesn't. The copy now matches what's actually happening: we can't project the per-sender impact yet, but the suggested record is safe to publish. The CTA in manual mode now says "Review & confirm" instead of the misleading "Copy DNS record," and the confirm button reads "Confirm — I'll publish this" so it's clear the system isn't changing your DNS.

Sender authorization is now undoable. A new Revoke button on authorized and dismissed senders moves them back to Needs Review where you can re-classify. Inline two-step confirmation, no native browser dialog. The native "Authorize? This can't be undone" prompt is gone — the action was always reversible via API; now the UI matches.

Smaller fixes. "Open Sources →" links no longer trigger a full page reload. Clicking a tab no longer scrolls aggressively when the tab is already on screen. The empty placeholder box that sometimes appeared beneath authorized sender names is gone.

Setup state now shows you the actual DMARC record to publish. When DMARC reporting is enabled but you haven't published the _dmarc record yet, the panel now shows the exact record — type, name, value, and a copy button — so you can paste it directly into your DNS host. Previously it told you to publish "the _dmarc CNAME" with a "Show me how" link that went nowhere.

When you authorize a sender from your DMARC reports — say, Microsoft 365 or Google Workspace — the recommendation card with the appropriate next step (Open DKIM setup guide, Preview SPF change, etc.) now renders correctly on the Sources tab. A serialization bug had been silently swallowing the card's content since the action layer first shipped.

Symptoms you may have seen: a row's explanation text said "See the setup guide for configuration steps" but provided no actual button or link. That setup-guide link is now where it should be — on a button right next to the explanation, opening the relevant provider's setup page in a new tab.

If you authorized senders earlier and didn't see a recommendation card, refresh the DMARC sources tab. The card now flows for every authorized or recognized-unauthorized sender that has a recommendation.

When you authorize a sender from your DMARC reports, the row now shows a recommendation card with the specific next step — a button to open that provider's DKIM setup guide, or to preview-and-apply the matching SPF record change in one click. Previously the recommendation was computed but didn't surface in the UI for senders authorized through the normal flow.

Both surfaces now explain how they relate. The Managed SPF setup wizard tells you that senders you authorize from DMARC reports can flow into your SPF record automatically (with your approval). The DMARC sources tab links back to your Managed SPF settings so you can manage both in one round trip.

If you authorized senders in the past few days and didn't see a recommendation card, refresh the DMARC sources tab — most should now have recommendations flowing.

Update 2026-05-06: the Open DKIM setup guide button described above required a follow-up fix to surface in all cases — see the DMARC and Managed SPF integration fixes entry for the full story.

When the DMARC Advisor recommends DKIM for a sender, the Open DKIM setup guide button now points to that provider's setup page directly — Google Workspace, Microsoft 365, SendGrid, Mailgun, Klaviyo, and 13 others. Less hunting for the right doc.

For domains without Managed SPF active, the SPF preview modal now shows a publish-yourself flow: the exact record to publish at your DNS host, a one-click copy, a warning if you're getting close to the 10-lookup budget, and a link to the provider guide. The Apply button is hidden because there's nothing for us to apply on your behalf — you're publishing this one yourself. If you'd rather we managed it, Managed SPF is one switch away on the domain settings page.

And on the quieter front — when mxio's own apply flow updates your SPF record, the health monitor no longer pages you about the change. Your phone gets quieter when you take an action with us. False-positive "SPF record changed" alerts after every Managed SPF update are gone.

Each apply now also writes an audit-trail entry to your activity log with the provider name, the before-and-after record hashes, and the change ID — useful when reviewing what mxio published on your behalf.

The /dashboard/services/dmarc page is now a triage view rather than a reporting table. Domains are grouped by Advisor mood with the most-actionable sections first. Stable domains collapse below the fold once you have more than five. Paused domains live in their own section so they don't compete for attention.

The bulk DNS export affordance is now first-class — you can copy or download records for every domain that needs DNS setup in one place.

Per-row actions stay on the per-domain Advisor page — no inline approve/apply in the list.

We rebuilt the readiness signal that drives the "Ready to advance" recommendation — and the panel that explains why we're not recommending advancement yet.

Specific gates, not vague bullets. When the Advisor is still in the Learning mood, it used to say generic things like "we're watching for enough volume to make a confident recommendation." Now it shows the four gates by name, with your actual numbers and the thresholds: authorized senders configured, authorized aligned messages over 30 days (need ≥50), authorized pass rate over 30 days (need ≥98%), and no recent anomalies. Each row gets a check or an X so you can see at a glance which one is blocking you and what to do about it.

Only your authorized senders count. Readiness used to be sensitive to any failure on the domain, including forgeries from unknown senders showing up in your aggregate reports. That made low-volume SMB domains nearly impossible to clear — one forged spam blast from an unknown IP would reset the clock. The new model counts only traffic from senders you've explicitly marked as authorized in the Sources tab. Forgeries are still surfaced — they show up in the unknown-traffic chip — but they no longer hold up your rollout.

What this means for you. If you're a small business with a few hundred legitimate sends a month from Google Workspace and one transactional ESP, you can now reach Ready. You couldn't before — the bar was tuned for higher-volume domains and didn't separate "your mail" from "everyone forging your domain."

Backwards compatibility. Pre-recalibration assessment snapshots that don't carry the new diagnostic field render with the prior generic copy. You'll see the new per-gate panel as soon as your domain produces a fresh assessment (which happens automatically on every Advisor view).

The DMARC Sources tab now knows what each authorized sender still needs. Instead of classifying a sender and leaving you to figure out the next step, the Advisor computes a specific recommendation for each one.

For senders missing DKIM configuration, you'll see an amber card pointing to the provider's setup guide. For senders not yet in your Managed SPF record, you'll see a blue card with a preview-and-apply flow — review the proposed record change, confirm it, and the update queues immediately. Senders that are fully configured (SPF and DKIM both in place) show no card.

SPF include: mechanisms are now matched automatically against the sender catalog in the background, so recognized providers start appearing in the Sources tab without requiring a manual add.

We ran our first end-to-end audit of the DMARC Advisor through a customer's eyes — IT lead, inherits the email auth setup, manages it as one of fifteen things — and shipped fixes for eight of the nine cross-cutting findings.

The headline read what's actually happening. When you're already at p=quarantine; pct=25 and ready to move to pct=100, the headline now says "advance from pct=25 to pct=100 on p=quarantine" — not "advance to p=quarantine," which you already are. The risk panel matches: "If pct=100 on p=quarantine takes effect" instead of pretending quarantine starts today. Same for r-partial → r;100 ramps.

Sharper safety on enforced domains. If a fully-enforced domain (p=reject; pct=100) drops below 95% authorized alignment, the Advisor now switches to "attention needed" with a direct read: "Authorized alignment for [domain] dropped below 95%." Until automatic anomaly detection ships, this catches the worst class of failure — a tool confidently saying "nothing to do" while real mail is leaking.

The actual record, not a placeholder. Every "Ready to advance" recommendation now shows the literal current _dmarc TXT record we read from your DNS, alongside the proposed record we're suggesting. No more "Phase 2 populates the diff" placeholder text. This is the trust surface for hosted DMARC — you see exactly what changes before you commit.

The grace deadline is on the card. When you pause a domain into grace, the Advisor now says "Grace expires 2026-05-17 (in 14 days)" right above the holding panel — answering the "am I losing data?" question with a date, not a hand-wave.

Header verbs match reality. A stale domain says "reports stopped (last: 21d ago)" instead of "reports flowing (last: 21d ago)." The chip no longer claims "100% alignment / 7d · clean" when the 7-day window has zero data — it says "no recent data" or hides itself entirely.

Sources tab pointer. On the Learning mood (when we're still figuring out your mail flow), there's a short hint card pointing at the Sources tab: "Tell us which senders are yours. Open Sources to mark senders as authorized — we use that to compute alignment."

Chip math reads coherently. "N of M senders aligned" is now numerator-≤-denominator by construction. Both numbers come from the same observed-traffic population — so no more 5/3 or 10/6 reads.

The audit and remediation plan are tracked in docs/audits/2026-05-03-dmarc-advisor.md and docs/audits/2026-05-03b-dmarc-advisor.md (the verification re-run). Two minor scaffolding bugs surfaced during the re-audit (an empty warning card on paused/grace, and a dmarc_not_enabled debug string in the Sources tab on those states) — they're queued as follow-ups.

DMARC customers can now apply any policy override directly from the per-domain advisor. Before you commit, we show exactly which senders would be affected, how many messages, and what would happen — projected from your last 30 days of report data. PCT fallback semantics are explained on every screen so you always know what happens to mail outside the percentage.

How it works. From the DMARC Advisor in the Ready mood, click "Apply this change" to open the override route. You pick from seven standard rungs: no policy, quarantine at 10%/25%/100%, or reject at 10%/25%/100%. We show you the projected impact per sending service, a before/after record diff, and the appropriate confirmation friction for the risk level. Submit, then publish the computed record at your DNS host. We check DNS every five minutes and update your status automatically when the record is live.

Confirmation friction scales with risk. Small incremental steps (recommended next hop) need only a single click. Larger jumps require checkboxes. Moving to reject at full volume requires typing your domain name to confirm you've thought about it.

"We can't model the impact" is honest, not a blocker. If you're on a freshly-enabled domain with no reports yet, we tell you we can't model the impact rather than refusing the override. You can still proceed — we ask for one extra confirmation step and show you what data would tell you once reports arrive.

Manual mode only. Records are published at your DNS host. Managed publishing — where mxio handles the DNS change on your behalf — is coming with Managed DMARC (Phase U).

The DMARC Advisor page now includes Sources, Timeline, Geography, and Reports tabs directly below the Advisor card. No more switching to a separate detail view to inspect senders, message volume over time, country breakdowns, or aggregate reports — it's all one scroll away.

"Detailed evidence →" goes straight to Sources. The evidence chips link in the Advisor card now anchors to the Sources tab in the same page, so the connection between "what the Advisor sees" and "the underlying senders" is one click instead of one navigation.

Tab state is in the URL. ?tab=sources|timeline|geography|reports — bookmarkable, shareable, back-button friendly. The range picker (7d/30d/90d) shows on Sources, Timeline, and Geography. Reports paginate independently of the date window.

The legacy detail view stays available at /dashboard/services/dmarc/{domain}/legacy as a URL-typeable fallback during the transition.

If you've been clicking through DMARC dashboards trying to figure out what does this all mean?, your domain pages just got a lot clearer.

The new DMARC Advisor reads your reports, names your situation in plain English, and tells you exactly what to do next. No more interpreting charts. No more wondering whether you're ready to advance. The Advisor will tell you.

What you'll see now:

• A short, plain-language read at the top: "You're ready to advance to p=quarantine." Or "We're not yet recommending advancement." No jargon, no ambiguity.
• Evidence behind every claim: alignment rates, sender counts, unknown traffic — all visible inline.
• A clear next action: clear these blockers, approve this change, keep watching, or just stay calm — depending on where your domain is.

The journey from p=none to p=reject is a multi-step process, and we're here to coach you through every transition. More improvements coming — including approval flows for one-click record changes and a weekly digest for security-conscious teams.

Open your DMARC dashboard →

Where it appeared. On a DMARC domain detail page, when the domain is at p=reject and the advisor sees unclassified senders (Audit MR-4).

Before. Title: "Unclassified senders detected — legitimate mail may be rejected." Body: "These senders may be rejected by receivers under your current policy." Footer: "Advancement is blocked until unclassified volume is below the 1% reject-gate threshold." Title and body framed the work as ongoing maintenance; the footer framed it as gated promotion. The user couldn't reconcile.

After. At p=reject, the footer now reads: "Authorize these senders if they're yours, or dismiss them — your p=reject policy will reject any traffic you don't authorize." The pre-enforcement steps (monitoring, quarantine_partial, reject_partial) keep the existing reject-gate threshold copy unchanged — there, gating is the right framing because there's a next policy step to advance to.

Closes Phase 2 of the 2026-04-30 DMARC services pages UX audit.

Empty-state banner. A DMARC domain detail page at the 7-day or 30-day window with no reports in that window now shows an inline banner: "No reports in the last X days. View 90-day window →" — a single click switches the date range. Helpful for low-volume domains, post-incident lulls, or RUA mailbox breaks where the default window has no activity but historical data exists.

Sharper Recheck on stale and awaiting-DNS. When the lifecycle state is stale or awaiting_dns, the only concrete action that helps the user is "Recheck now". The button is now styled as the primary action (was secondary), with a tooltip that names what gets re-verified — the _dmarc TXT record and the reporting receiver.

Child records placement. The "Child DMARC records" inheritance summary used to sit between the status row and the tab bar — a loud slot for a single line of info. Moved below the tab content so the journey-to-reject UX is the page's primary vertical axis.

Tab dot tooltip. The Timeline tab's status dot (green = has data in the last 7 days, gray = no data) now carries a tooltip describing what it means.

Clearer p=none copy in DENIED rows. A sender marked "not yours" on a p=none domain used to read: "this sender will be subject to your DMARC policy when enforcement is active." Distancing future-tense. Now: "your p=none policy is letting these through for now. They'll be quarantined or rejected once you advance." Present-tense for the current state, concrete future-tense for what changes on advancement.

Closes Phase 4 of the 2026-04-30 DMARC services pages UX audit. All four phases of the audit followup are now shipped.

Status row truth. On /dashboard/services/dmarc/<domain>, the collapsed one-liner above the journey panel previously read "Setup complete · awaiting first report" with a green dot regardless of state — even on domains with hundreds of messages of report data flowing. The local "reports row pending" predicate that drove the copy ignored the backend-derived lifecycle state.

Now driven by lifecycle_state. The same dmarc.LifecycleStateForRow derivation already used by the overview list (active | stale | awaiting_dns | grace | paused | …) is exposed on the per-domain GET /v1/dmarc/setup/status/{domain} response and consumed by the detail page:

• active with reports in last 72h → green dot + "Reporting · N reports in last 72h"
• active without 72h count (low-volume / weekend lull) → green dot + "Reporting"
• stale (reports stopped >14d ago) → amber dot + "No reports recently"
• Other states (awaiting_dns, grace, etc.) reach the expanded checklist view as before.

Closes Phase 1 of the 2026-04-30 DMARC services pages UX audit.

Last Report empty token. On /dashboard/services/dmarc, the Last Report column rendered never for domains with no reports yet (e.g. a freshly-provisioned example.com) while every other empty cell in the same column read —. Now — everywhere.

Add a domain at the top of the table. Populated accounts had the + Add a domain trigger only below the table — below the fold for users with many domains. A second instance now sits next to the Export CSV button on the filter row, so the action is reachable without scrolling.

Honest alignment on no-data. The DMARC domain detail page header used to read 0% authorized alignment when the active date window contained zero sources — a divide-by-zero rendered as 0%, easy to misread as "everything failing." It now reads — authorized alignment. The source count fragment folds into the same line when there's data.

What changed. On /dashboard/services/dmarc, a p=quarantine row whose authorized_alignment_rate has crossed the pass threshold (95%) now renders Ready to advance → in the same shape p=none rows have always rendered it. The link routes to the domain detail page where the per-domain advisor surfaces the next concrete action (advance to p=reject).

The fine print. The advance-readiness check on the detail page is stricter than the overview affordance — it also looks at alignment streak, active problem sources, and unclassified-traffic ratio. The overview list payload doesn't carry those inputs (yet), so the affordance-level check uses the alignment threshold alone. If you click Ready to advance → on a row where the stricter detail-page check has more to say, you'll see the actual blocker and remediation steps. Never produces a false action.

Closes audit OVR-1.

Reported Policy column. The "Policy" column on /dashboard/services/dmarc is now labelled "Reported Policy" with a tooltip clarifying that the value is observed in aggregate reports — it can lag the published DNS record if the record was changed recently.

Last-known policy preserved for stale domains. When a domain stops receiving reports (more than 14 days), its policy badge no longer collapses to an em-dash. The most recent policy seen in reports is now stored on the domain settings and rendered dimmed/italic so you can still see what the policy was the last time we heard from a reporter.

Last Report column accuracy. The Last Report column now reads MAX(received_at) from the reports table, the same source the 30-day report count uses. Previously it read the report's covered period end-date and only for domains that had aggregated daily summaries — domains with reports but no rolled-up summary showed "never" alongside a non-zero report count. Both columns now agree.

Export CSV. A new "Export CSV" button on the domain table downloads every managed domain with its lifecycle state, reported policy, alignment percentage, last-report date, source count, and 30-day report count.

DMARC awaiting DNS (3 emails). When DMARC is auto-enabled on your account, a _dmarc TXT record needs to be published on your DNS provider before reports can flow in. If no reports arrive within 24 hours of auto-enable, a reminder email explains what's missing and links directly to your DMARC setup page with the exact record to publish. A follow-up arrives after one week, and a final nudge after one month — at which point it also mentions disabling DMARC reporting if you've decided not to use it.

DMARC reports stopped (1 email). If your domain was previously receiving DMARC reports and they stop for more than 14 days, a transactional alert fires. The most common cause is a DNS change that removed or broke the _dmarc TXT record — a provider migration, an accidental edit, or a record that got dropped during DNS import. The email links to your DMARC setup page to compare the expected record against what's currently published.

When you add a domain on a DMARC-eligible plan, the platform silently enables DMARC reporting in the background. That was invisible until now.

Activity log entry. A DMARC Reporting set up for <domain> event appears in your activity log immediately after domain creation. No action required — it's informational, confirming the auto-enable ran successfully.

Bell notification. The notification bell adds an entry with a direct link to the DMARC DNS setup page, where you'll find the _dmarc TXT record to publish.

Onboarding email on first report. The DMARC Reporting Onboarding email series now fires when your first aggregate report arrives, not when DMARC is enabled. Since DMARC is enabled automatically on eligible plans, the old "you just enabled DMARC" email didn't reflect anything you did — this one celebrates a real milestone you can act on.

Old enable-nudge campaign retired. The "Enable DMARC Reporting" nudge campaign that prompted eligible users to turn on DMARC is disabled. Auto-enable handles that now; the campaign returned near-zero candidates.

Admin alert on provisioning failure. If the EDV authorization record fails to publish to Cloudflare on two consecutive reconciler passes, an alert routes to the admin team for investigation. A 24-hour suppression key prevents repeat notifications for the same domain.

Three changes targeted at customers managing more than a handful of DMARC-monitored domains.

Bulk DNS-record export. Multi-select domains on the DMARC Reporting list, hit "Copy DNS records," and you land on a page that shows the _dmarc TXT record for each one — copy each, copy all, or download as markdown. There's also a per-row "Copy DNS record" entry in the row menu. This is the immediate fix for customers running 5+ domains who were copy-pasting records one at a time. The bulk endpoint preserves any advanced tags already on your existing _dmarc record (adkim, aspf, ruf, fo, ri, sp) — only the rua= reporting address is added or rewritten. The downloaded markdown includes a per-domain NOTE so a DNS admin reading the file knows whether the suggested record merges with an existing one, replaces an absent record, or is already in place.

Auto-enable on domain add. When you add a domain on a DMARC-eligible plan (Pro, Business, DMARC Starter, or any plan plus a DMARC tier add-on), DMARC reporting is now turned on automatically. No per-domain Enable click. Plans without DMARC entitlement skip silently — domain creation still succeeds either way. The Cloudflare-side EDV record is published asynchronously by the reconciler within ~5 minutes; you'll see the lifecycle state advance from provisioning to awaiting_dns once that completes.

Lifecycle status states on the DMARC list. The old binary "Disabled / Active" pill is replaced with eight derived states: provisioning, provisioning_failed, awaiting_dns, active, stale, grace, paused, and not_provisioned. Each comes with a state-aware row CTA so you know what action, if any, is on you — typically "publish your _dmarc TXT" during awaiting_dns, "check DNS" during stale, or "re-enable" during paused. State is computed from existing columns plus the most recent report timestamp; no schema change.

Three user-visible fixes from a fresh-eyes audit of the DMARC first-time-user flow.

DMARC domain detail now shows the setup checklist on a brand-new domain. When a new DMARC Starter subscriber added their first domain and clicked through to its detail page, they previously saw "Domain not found. Back to overview." — a dead end. The detail page now recognizes the "new domain, no settings row yet" case and renders the setup checklist in place, so the user can click Enable monitoring and continue through the flow without backtracking.

Pricing page no longer leaks raw backend errors or auto-fires a broken plan change. When a logged-in user landed on /pricing?plan=X&interval=Y with the URL matching their current plan and interval, the page auto-fired a change-plan API call that could fail in certain Stripe-linkage edge cases, surfacing an internal error string ("no active Stripe subscription to downgrade") in a red banner. The auto-fire now skips same-plan same-interval (it's a no-op) while still firing for legitimate interval switches (monthly ↔ annual). If the underlying API call does fail, the backend returns a plain-language message and the URL params stay intact so the user can retry.

DMARC domain detail tab bar scrolls horizontally on narrow mobile viewports. At 375px, the five tabs (Journey, Sources, Timeline, Geography, Reports) pushed the page sideways by 72px. The tab bar now scrolls within its own container, keeping the rest of the page aligned to the viewport.

Three additional internal / dev-environment fixes shipped alongside but aren't user-visible: a CSP tweak so competitor favicons render on compare pages in dev (production was unaffected), a platform-api startup warm-up that reduces the cold-load spinner on /dashboard/services/dmarc after a deploy, and a verified-as-working closure on a speculative broken-anchor finding that turned out to be fine.

DMARC Reporting launched 2026-04-14. This update amplifies its visibility across the marketing site.

DMARC Reporting is now the first proof-point on the homepage. The hook has been sharpened — "Ready for p=reject. Without the guesswork." replaces the previous headline, and the supporting copy emphasizes the data-driven enforcement story.

The /services/dmarc-reporting page links to the full setup guide. The product setup guide at /learn/product/dmarc-reporting-guide was orphaned; it's now linked under the setup steps and surfaced in the Learn More list.

DMARC tool pages have stronger bodies and metadata. /tools/dmarc-checker (the biggest-volume DMARC query at ~6,600/mo) gained detailed education content covering what DMARC checking validates, policy levels, what a record check cannot tell you, and when to use the checker vs the wizard. /tools/dmarc-report-viewer added a benefit-list body for crawlable SEO signal. /tools/dmarc-wizard got a tightened title and a short intro paragraph.

Pricing page now surfaces DMARC Reporting above the plan grid. A new callout explains what's included on paid plans and links to the service page.

spfflatten.net DMARC cross-sell now has dual CTAs. SPF flattening visitors get two clear paths: the free DMARC analyzer for one-off reports, and the paid DMARC Reporting service for ongoing coverage.

Three new long-tail guides:

• "DMARC Aggregate Report Explained" — field-by-field walkthrough of the XML, with a worked example, what the report tells you, and what it doesn't.
• "Setting Up DMARC on Office 365" — M365-specific deployment guide covering Exchange Online, hybrid deployments, relay connectors, tenant DKIM vs shared signing, and a safe path from p=none to p=reject.
• "Free DMARC Analyzers Compared" — honest comparison of what mxio, Postmark, Dmarcian, EasyDMARC, MxToolbox, and PowerDMARC offer for free. Competitor details verified 2026-04-23.

Cross-linking and hub updates. Six DMARC articles (error guides plus the RFC 7489 reference) now link the DMARC Reporting service page in-body. All five vendor comparison pages now link to the service page. The /learn/dmarc hub surfaces the product setup guide and the two new articles. Sitemap lastModified dates updated for all touched pages so search engines know to recrawl.

Three content fixes found in a post-launch audit of the DMARC pages.

Two broken article links fixed on the DMARC Reporting service page. The "Understanding DMARC Aggregate Reports" and "DMARC Policy Progression" links in the Learn More section of /services/dmarc-reporting pointed to articles that had been renamed during the content build. Both now resolve to the correct articles.

Gmail 550 5.7.26 error article now shows the DMARC Reporting service panel. The article on fixing Gmail's 550 5.7.26 rejection error was missing its service association in frontmatter, so the "Get started with DMARC Reporting" panel at the bottom of the page wasn't rendering. It does now.

DMARC comparison pages now share correctly on social. The five DMARC comparison pages (/compare/dmarcian, /compare/valimail, etc.) were missing og:type: article in their metadata — they were being shared as generic website links rather than articles. Fixed. The comparison pages also now appear in the sitemap.

Five improvements to how the billing UI handles plan and interval changes, addressing issues found in the 2026-04-16 UX re-audit.

Change Plan modal defaults to your current interval

When you open Change Plan from the billing page, the monthly/annual toggle now matches your active subscription instead of always defaulting to Annual. If you're on Pro monthly, the modal opens with Monthly selected.

"Switch to monthly/annual" CTA on same-plan cards

Previously, if you were on annual Pro and flipped the modal's toggle to Monthly, the Pro card showed a disabled "Current Plan" button — there was no way to request an interval switch from the UI. Now the Pro card shows an active "Switch to monthly" CTA wired to the existing backend endpoint. Works in both directions (annual→monthly and monthly→annual).

Plan-change banner reads the real backend message

The success banner after a plan change used to hard-code "Your plan change is scheduled. It will take effect at the end of your current billing period." regardless of what actually happened. It now renders the backend-supplied message — so an immediate upgrade says "Plan upgraded" and a scheduled downgrade says "Plan will change at the end of your current billing period" with the effective date.

Interval-switch warning before Stripe handoff

When a tier upgrade would also flip your billing interval (e.g., monthly Pro upgrading to Business with the pricing toggle on Annual), a confirmation modal now flags the interval change before redirecting to Stripe. Stripe still shows the exact prorated charge; the modal's job is to make sure the interval flip was intentional.

Pricing toggle persists in URL

Flipping the monthly/annual toggle on /pricing now updates the URL to ?interval=month or ?interval=year. If you back-nav from Stripe Checkout, your interval choice is restored instead of resetting to the default. Only the public pricing pages do this — the in-app Change Plan modal does not alter the dashboard URL.

Internal scope: five findings from the UX-P1.3 re-audit (PAY-10, PAY-11, PAY-12, PAY-13, PAY-15). Source: docs/audits/2026-04-16-p1.3-payment-upgrade.md. Implementation: docs/tasks/2026-04-17-ux-p1.3-followup-plan.md Batch 1.

Six improvements to mxio's transactional email. Customer-facing emails that were either missing or broken are now reliable, and deliverability headers are in place for Gmail and other major inboxes.

Welcome / receipt email after subscribing

When you subscribe or upgrade, you now get an email confirming the plan, billing interval, amount, and next billing date, with a link to the billing page. Previously, only admin got notified; the paying customer got no email.

Plan-change confirmation email

When your plan or billing interval changes — immediate upgrade, scheduled downgrade, monthly↔annual switch — you receive an email summarizing the old plan, new plan, and effective date. Scheduled changes show the effective date; immediate changes are marked effective now.

Ack-from-email button actually works

The "Acknowledge this incident" button (previously "This was intentional") in every alert email had been pointing at a URL that 404'd. Fixed. One click on the email now acknowledges the incident and takes you to the incident detail page.

List-Unsubscribe + Feedback-ID on alert emails

Alert emails now carry List-Unsubscribe and List-Unsubscribe-Post: One-Click headers (per RFC 8058) plus a Feedback-ID that identifies mxio, your account, the alert type, and the sender domain. This matches what the digest email already had, and lines up with Gmail's 2024 bulk-sender requirements for maintaining inbox placement.

Verification email sends a plain-text part too

Notification channel verification emails used to be HTML-only, which hurts deliverability and makes the email unreadable in plain-text clients. They now ship as multipart/alternative with both HTML and plain-text parts.

Internal scope: six findings from the UX-P1.3 re-audit (NOT-15, NOT-18, NOT-19, NOT-20, PAY-8, PAY-14). Source: docs/audits/2026-04-16-p1.3-notifications.md and docs/audits/2026-04-16-p1.3-payment-upgrade.md. Implementation: docs/tasks/2026-04-17-ux-p1.3-followup-plan.md Batch 3.

Deployment note for operators: production requires MXIO_PLATFORM_API_BASE_URL set to the platform-api public URL (e.g., https://api.mxio.io or equivalent) before deploy. Without it, ack URLs default to the frontend origin and will not resolve. See docs/reference/DEPLOYMENT.md.

Five accessibility and mobile polish fixes on the dashboard.

Header icon buttons are now 44×44. The bell, theme toggle, and avatar buttons in the dashboard header used to be ~24px tap targets — too small for reliable thumb use on a phone, and below WCAG's Target Size guideline. They're now 44×44 each, with icon sizes unchanged. Easier to hit, easier to scan.

The mobile sub-nav fades at the right edge when there's more. The dashboard's secondary navigation (the row of section tabs) scrolls horizontally on narrow screens, but there was no visual cue that content continued off-screen. A right-edge fade gradient now subtly suggests "keep scrolling" when there are more tabs.

Each dashboard page has its own browser tab title. Previously, every dashboard route shared the generic "mxio" tab title. You now get "Billing | mxio", "Incidents | mxio", "Activity | mxio", "DMARC Reporting | mxio", and so on — useful when you have several tabs open.

Uptime bars on mobile group into larger, readable chunks. Domain and host detail pages used to render uptime history as ~80 individual 3-pixel bars. Each was technically tappable but nowhere near the size needed for a phone. They're now grouped into 20px chunks of 5 buckets each, with the worst status across the group setting the color and an aggregate label like "Apr 17, 14:00–14:25, 3 issues" for screen readers. Clicking a group still navigates to the activity view filtered to that time range.

Notification bell already announces the unread count. The bell button's tooltip and screen-reader label now name the unread count ("12 unread notifications") — this one shipped earlier in Batch 6; listed here for completeness with the other a11y touches.

Four fixes to the DMARC advisor and journey surfaces — part of the UX-P1.3 polish pass.

AI Explain shows the cost up front. A small ≈$0.02 badge now sits next to the AI Explain button so you know the approximate cost before you click. The badge hides while the explanation is generating and when you're out of monthly AI quota.

AI Explain loading is no longer an 8-second silent wait. The previous spinner blocked interaction and told you nothing. The new loading state is non-blocking (the rest of the page stays readable), with status text that rotates every 2.5 seconds — "Reading your DNS records", "Analyzing configuration", "Drafting explanation" — so you know work is in progress and roughly where we are. No backend protocol change; the cycling is purely client-side feedback.

The reject-gate threshold is now explained. On the DMARC journey progression-blocker card, the "X% reject-gate threshold" text is now a click-to-open popover that explains what the threshold means: "Advancement to the next policy step is blocked while unclassified traffic exceeds {N}% of total volume." Keyboard users can Tab to it, Enter to open, Escape to close.

Setup checklist is announced correctly by screen readers. The Show/Hide details toggle now has aria-expanded and aria-controls attributes so assistive tech announces the state transition correctly.

"Can take 24-48h" is no longer a hidden parenthetical. On the Reports received step of the setup checklist, the timing disclaimer used to sit inside parentheses at the end of the detail line. It now lives as a clear secondary line below the step — visible at a glance, sets expectations on first read.

Per-subdomain alignment in the subdomain inventory is tracked as a follow-up — it requires a backend aggregation query that's out of scope for this polish batch.

Five fixes to the DMARC dashboard surfaced in the UX-P1.3 re-audit.

New domains open to a setup checklist, not an error. Previously, clicking into a domain that hadn't finished DMARC setup showed a raw "domain not found or DMARC not enabled" error. The backend now distinguishes between truly-missing domains and domains that exist but haven't published a DMARC record yet; the latter case opens the same setup checklist customers see elsewhere in the flow, so the path from "I added this domain" to "I see what to do next" is continuous.

"Recheck now" confirms the recheck happened. The button used to silently re-query with no feedback. It now disables during the fetch, flips its label to "Checking…", and fires a toast when the result is in — success or failure. Errors no longer display both a red banner and a green toast at the same time.

Headline stats no longer overstate alignment. The dashboard headline used the total domain count as the denominator for alignment percentage, but the percentage was actually computed only over domains receiving reports. The label now foregrounds the active (receiving-reports) count alongside the percentage, and surfaces any awaiting/disabled domains separately — so "97% aligned" never gets credit for domains that aren't reporting at all.

Duplicate rows collapse to one. In rare cases (legacy data inconsistency, specifically across the monitor_targets UNIQUE KEY that was dropped in migration 052), the same domain could appear several times in the DMARC dashboard and in admin views. The store now dedupes these at the query boundary, keeping the most-recent row. This also protects the admin domain list and the DMARC setup endpoint.

One CTA per row, phase badge for context. Each DMARC domain row used to rotate between three different actions ("Set up reporting", "Continue DNS setup", "View status") depending on setup state, with no legend. Each row now has a single "View" action plus the existing phase badge that already labels the state (Disabled / Needs DNS setup / Awaiting reports / Receiving reports), so the row reads the same way regardless of state and the action is always predictable.

Five fixes to the DMARC overview and setup surfaces — part of the UX-P1.3 polish pass.

Overview is now grouped by status. Domains on the DMARC overview list used to scroll as one flat list. They're now split into three sections with counts: Active (domains actively receiving reports), Awaiting setup (configured but no reports yet), Disabled (explicitly paused or off). Headers appear when there's more than one non-empty section, so small accounts don't see noise.

"Awaiting reports" explains itself. A click-to-open info popover next to the "Awaiting reports" badge now explains the two most common causes: reports dated today roll up overnight, and some domains only receive subdomain traffic. Users no longer have to guess whether something is broken.

"Recheck now" is a real button. Previously it was a small inline text link easy to miss on the setup checklist. It's now a secondary button sitting next to the status badge where users actually look.

Add-a-domain catches typos before the network call. The inline Add-a-domain form now validates the domain format client-side and shows an inline error for invalid input. Below the field, a one-line preview describes what we'll probe: MX · SPF · DKIM · DMARC · Delegation · Blacklist — and sets expectations that RUA reports arrive only after the TXT record is published.

Authorize on subdomain sources shows a passive scope note. A small sub-line below the Authorize action clarifies that authorizing a subdomain source updates classification, not the headline alignment metric (which reflects ESP-level traffic). The note is scoped to subdomain sources only — root/ESP sources don't see it.

Four fixes across the DMARC detail tab bar, filters, and policy badges — part of the UX-P1.3 polish pass.

p=none policy badge is age-aware. A brand-new DMARC setup with p=none is normal and expected — the policy should ramp to quarantine and reject over weeks, not minutes. The badge now renders neutral gray for the first 14 days after DMARC enable, then flips to amber. Long-term p=none (the dangerous state) is now visually distinct from brand-new p=none (the healthy state). Re-enabling a domain resets the grace window, which is the right behavior — a re-enabled domain is functionally a fresh setup.

Tab headers carry data indicators. The DMARC detail tab bar now shows inline counts and status dots: Sources count, Timeline green dot (if there's activity in the last 7 days) or gray dot (if empty), Geography countries count, Reports count. Users can tell at a glance which tabs have content before clicking. Dots and counts are marked aria-hidden since the tab label alone already conveys the destination.

Timeline x-axis ticks adapt to viewport. On narrow viewports (<640px) the x-axis now shows a tick every 5 days instead of every 3 days, so labels don't overlap.

DMARC CTA capitalization standardized. Grep of DMARC UI surfaced two remaining title-case CTAs ("Add Rule", "Setup Guide") — both now sentence case ("Add rule", "Setup guide") per brand voice. Proper nouns (DMARC, SPF, DKIM, DNS) remain capitalized.

Geography tab top-10 default + "Show all" toggle was already implemented in an earlier batch; spec verified and no changes needed.

Six fixes across the marketing site, login page, learn hub, tool pages, and pricing page — part of the UX-P1.3 polish pass.

Provider logos no longer flash alt text. The FaviconImg component previously rendered the <img> immediately, so on slow connections the alt text (e.g., "Goo" for Google Workspace) was visible until the image arrived. The component now keeps the image hidden until onLoad fires.

Login form renders first on mobile. At <lg breakpoints, the marketing/value panel used to sit above the form, forcing returning users to scroll past the pitch every visit. The form is now first in the DOM and visually, with the value panel below — so screen readers, keyboard users, and scroll-reluctant users all land on the form. Desktop visual layout (value-panel-left, form-right) is preserved via lg:order-*.

Test-account buttons breathe on phones. The dev test-account grid used to cram plan label and slug on one line. Label now sits on its own line; slug hides below 640px.

Article TOC + bottom CTA hit 44px tap targets. Learn-hub article TOC links bumped from py-0.5 to py-2. The bottom-of-article "Browse all guides" affordance is now a full-width bordered block with min-h-[44px]. Inline prose citations stay dense — they're acceptable at reading density.

Tool page titles keep "Free" for SEO and add a brand suffix. Tool pages previously varied between "Free SPF Record Checker" (no brand) and inconsistent treatments. They now consistently render as "Free SPF Record Checker — mxio" via an explicit absolute title so the root template doesn't double. The "Free" keyword stays because it carries real CTR weight on high-intent queries like "free spf checker".

Pricing toggle chip stable across re-renders. The "Save 17%" chip used to conditionally render, causing layout shift when toggling Monthly/Annual. The chip is now always rendered; inactive state fades it with opacity-0 and aria-hidden.

Ten mobile rendering fixes across the dashboard, pricing page, and free tools. Phone experience is now on par with desktop for the surfaces most buyers see first.

Dashboard no longer overflows horizontally on phone

A single missing CSS rule on the dashboard's main content area caused every dashboard page to overflow horizontally at phone width — incidents had 45px overflow, domain detail 107px, DMARC overview 326px. Adding min-w-0 to the flex container eliminates all four Critical overflow issues at once.

Incident list stacks into cards on phone

The incidents list rendered as a desktop table at phone width, clipping the "View" CTA on every row. It now stacks into readable cards on phone while preserving the full table layout on tablet and desktop. The Ack and View actions are always reachable.

DMARC overview stacks into cards on phone — and you can still take actions

The DMARC overview table similarly stacks into cards on phones and small tablets. Critically, the Action menu (Enable dedicated reporting, Copy RUA record, Disable, Remove, Dismiss) is preserved on the phone cards — you can manage your DMARC configuration from your phone, not just read it.

Pricing feature-comparison table scrolls within its own container

The full feature-comparison table at the bottom of /pricing used to push the entire page sideways on phone, hiding three of the five plan columns off-screen. The table now scrolls horizontally within its own container, keeping the rest of the page aligned to the viewport.

Tool result content now full-width on phone

Free tool result layouts (SPF checker, DMARC checker, headers, MTA-STS, IP geolocation, IMAP, ping, DMARC report viewer) stacked to full-width on phone instead of rendering in a narrow right-hand column. The SPF checker result narrative that was appearing in a ~136px-wide strip is now full-viewport.

Long domain names wrap cleanly in headings

Domain detail page headings like ops.dmarc-parent.test.mxdns-test.us were clipping mid-word at phone width. They now wrap across two lines.

Other fixes

• Home page DMARC section no longer clips body copy at phone width.
• /services/dmarc-reporting plan summary table scrolls within its container on phone.
• React duplicate-key warnings on the DMARC overview list are fixed by using a composite key that correctly disambiguates root and subdomain rows.

Internal scope: ten findings from the UX-P1.3 re-audit (MOB-1, MOB-2, MOB-3, MOB-11, MOB-13, MOB-14, MOB-15, MOB-16, MOB-17, MOB-22). Source: docs/audits/2026-04-16-p1.3-mobile-sweep.md. Implementation: docs/tasks/2026-04-17-ux-p1.3-followup-plan.md Batch 2.

Seven fixes to the notifications settings page, the notifications history page, and the digest defaults — part of the UX-P1.3 polish pass.

The expanded edit row is now visually framed. When you expand a channel to edit which alert groups route to it, the expanded section used to sit flush against the row above it with no visual boundary. It now has an accent left-border frame and a small heading "Editing alert groups for [Channel]" so the scope of the edit is unambiguous.

Info tooltips are keyboard-accessible. The ? icons next to each alert group used to be browser-native title= hover tooltips — invisible to keyboard users and screen readers. They're now proper popovers: Tab lands on them, Enter or Space opens, Escape closes, click-outside closes. Hover still works for mouse users.

Webhooks and SMS rows are hidden until shipped. We were showing "Coming soon" rows for channels we didn't have a concrete ship date on. Hidden until they actually ship — less noise, fewer unmet expectations.

"What triggers alerts" opens itself on first visit. The disclosure that explains which events fire alerts used to always default closed. On a first visit it now opens so new users see what's in scope; subsequent visits remember your last state.

Notifications history defaults to the last 7 days. Previously the history page loaded with no filter — showing all time, paginated. Most people want to see "what happened recently," so we default to the last 7 days. The filter is still user-adjustable and your selection persists via URL.

New Business-tier subscribers get weekly digests. Daily digests are fine for smaller accounts but get noisy at Business scale. New Business subscribers now default to a weekly digest instead of the system default. Existing users who customized their digest cadence are never overwritten — we only set the weekly default when the current cadence is still the system default. Covers initial checkout and in-portal plan upgrades.

Digest tracking-pixel disclosure moved into an info popover. We always disclosed that digest emails include a tracking pixel for deliverability monitoring. The disclosure used to live as inline copy in the digest section; it now lives behind a ? popover beside the digest label, so the zone is less cluttered without losing the transparency.

Ten fixes to the notifications system — both in the bell dropdown and around destructive actions across notifications and DMARC.

The bell badge is honest again. Every notification you'd ever received counted toward the unread badge, so the badge climbed to 99+ and stayed there forever. The unread count now caps at a 30-day rolling window — anything older than that stops counting. When you have older notifications, the dropdown shows a small banner at the top ("N older notifications not shown here") with a link to the full history, so nothing is hidden, just moved off the nagging badge.

Unread-state and severity are now separate signals. The bell dropdown previously used row tint for read-state and colored dots for severity. Both used color — so a skim felt noisy. Unread now gets a single left-edge accent border on the row; severity stays on the dot. Two axes, two visual channels.

Bell dropdown has an Unread/All filter. Default is Unread. The Unread label shows the count inline. Your choice persists across sessions.

Bell button announces the unread count. Screen readers and hover tooltips now say "N unread notifications" when there are any, not just "Notifications".

Channel toggle-off gets an Undo toast. Flipping a verified channel off used to fire instantly with no way back except re-enabling through settings. Now disabling a verified channel shows an Undo toast for 5 seconds — click Undo to re-enable immediately.

"Mark all as read" confirms before firing. The mark-all action asks "Mark N notifications as read?" before it wipes your inbox unread state, since there's no way to bring it back.

Verified channels with no subscribed alert groups show a warning. If you verified a channel but haven't ticked any alert groups, the settings page now shows a warn badge on that row — "No alerts subscribed — this channel will receive nothing". Click the badge to jump straight to the editor.

Unverified channels can't be toggled on. The enable switch on a notification channel is now disabled until verification completes, with an explanatory aria-label. Previously you could flip it on before verification even started, creating a confusing partial state.

DMARC Authorize confirms before firing. There's currently no way to revoke an authorized sender from the UI (revoke needs support), so Authorize now asks you to confirm with a warning that the action can't be undone from the UI.

Alert email ack button matches the dashboard vocabulary. The "This was intentional" link on health-alert emails now reads "Acknowledge this incident" — the same word the dashboard uses.

Four fixes across the notifications bell, the verify-channel landing page, and the history page — part of the UX-P1.3 polish pass.

Bell popover is wider. Long domain names (anything beyond ~30 chars) were truncating in the bell dropdown. The popover is now 384px instead of 320px, which comfortably fits survey-tracking.example.com and similar.

Verification no longer auto-fires on landing. Corporate mail gateways — Mimecast, Proofpoint, Barracuda, and similar — prefetch links in inbound email to scan them for malware. Our verify-channel link used to run the verification automatically on page load, which meant a gateway fetch would silently confirm the channel without the real user ever clicking. The verify page now shows an explicit "Verify this channel" button. Verification only happens after the button is clicked, which gateways don't do. The backend endpoint was already POST-only; the fix was entirely on the landing page.

Verification tokens are invalidated on use. This was already the case, but we added a regression test so a future refactor can't silently break it. Tokens now have a guaranteed single-use lifecycle: generate → email → confirm → token deleted from Redis.

Export CSV on notifications history. The history page has a new "Export CSV" button that downloads a CSV of the currently-displayed rows with event time, channel, domain, event title, summary, and status. RFC 4180 escaping handles commas, quotes, and newlines in data.

A full-range CSV export (beyond the current page) and a free-text search across all history are tracked as follow-ups.

Six fixes in the payment, pricing, and first-paid-dashboard surfaces.

Starter plans no longer advertise "Free to start · no card required". The Monitoring Starter and DMARC Starter cards on /pricing are $19/mo — they're not free. That badge used to appear on both of them alongside the actual Free tier, which was dishonest. Now only the Free tier shows the no-card-required hint.

The fresh-account dashboard preview is obviously a sample. New paying customers used to land on a dashboard showing example.com and mail.example.com rows with red/amber status dots — some of them confused it for their own monitoring data coming back broken. The preview now has a "Sample" badge in the card header, the rows are desaturated with neutral gray dots, and the accessibility tree skips the table entirely. It reads as "this is what your dashboard will look like," not "your domains are failing."

Annual billing now shows the full pricing picture. If you're on an annual subscription, the billing page used to say "$59/mo billed annually," which left you guessing at the actual monthly rate and yearly total. It now shows $49/mo · billed annually · $590/yr — the monthly equivalent you're effectively paying, plus the yearly total you see on your invoice. No more mental math.

The "Billed yearly" subline on /pricing is readable. The small text under each plan card that noted the annual savings was rendering at ~12px, so small it was easy to miss. It's now at 14px with the full annual total ($590/yr on Pro, for example) shown prominently next to the "Billed yearly" label.

The login page welcomes new users. The heading used to say "Sign in to your account" — fine for returning users, unwelcoming to first-time visitors who might also land on /login. It now reads "Sign in or create your account," with a subline explaining that we'll email a magic link and create an account automatically if you're new.

Browser tab titles no longer double up the | mxio suffix. Several marketing pages had their own | mxio in the page-level title, and the site's root layout adds one automatically, which produced tab titles like "Monitoring — mxio | mxio". Fixed across the services, blacklists, and managed-SPF pages.

Four fixes along the signup → checkout → dashboard path.

Your plan choice survives signup. If you hit "Get Pro / Monthly" on the pricing page before you had an account, you used to come back after magic-link signup and have to pick the plan and interval all over again. The choice is now preserved in the URL through the whole signup chain. When you land back on /pricing post-setup, Stripe Checkout opens automatically with the plan and interval you originally selected. If something goes wrong on the checkout side, the URL state stays intact so you can refresh and retry.

First-time paid subscriptions see a quick preview before Stripe. When an existing Free-tier account upgrades to a paid plan for the first time, a small modal now summarizes what's about to happen: plan name, annual or monthly, and a reminder that Stripe will show the exact amount on its side. Cancel dismisses, proceed hands you off to Stripe. (Upgrade-across-interval and downgrade previews were already in place — this fills the free → paid gap.)

DMARC report rows now deep-link. Expanding a report on the DMARC dashboard used to be per-tab state only — if you wanted to share the view with a teammate, you couldn't. The expanded row is now reflected in the URL as ?report=<id>, so copying and pasting the URL lands them on the same pre-expanded report. Clicking to collapse clears the query.

"Skip for now" on MFA setup remembers for 2 days. Clicking "Skip for now" on the /setup page used to do nothing persistent — next login, you'd get bounced right back to /setup. Now a skip is recorded and we respect it for 48 hours. After two days, we nag again. The skip also honors whatever destination you were trying to reach: if you came in via /pricing?plan=pro&interval=month, you land there after skipping, not on the dashboard.

The DMARC Sources tab now lets you classify senders that appear only in subdomain traffic, not just root-domain traffic.

Authorize and Dismiss actions on subdomain sources

• Senders listed under the Subdomain Traffic section now show Authorize and Dismiss buttons for sources that have a recognized ESP but haven't been classified yet — the same workflow available for root-domain senders.
• Authorized subdomain senders are split into passing (≥95% DMARC pass rate) and failing buckets, so sources that are authorized in name but misaligned in practice stand out rather than blending into the clean group.
• Discovered domains remain read-only. Pages for domains discovered automatically from your DMARC reports (rather than explicitly added) don't show action buttons, since you haven't claimed ownership of those domains.

Bug fixes

• Fixed a crash when expanding the subdomain accordion on domains where no subdomain source data had been collected yet.
• Fixed a "No source data" false negative on domains where all traffic arrives via subdomains and the root domain has no volume. The subdomain traffic card now surfaces first in these cases rather than showing a misleading empty state.

Seven fixes to the dashboard in response to a fresh-eyes usability audit:

• DMARC card no longer contradicts the health table. On newly-added domains there was a window where the health table said "DMARC pass · p=reject" while the DMARC card beneath said "no DMARC record." The card now waits for a definitive health result before rendering any negative message.
• Alignment percentages render as whole numbers. No more 88.55305466237941% aligned — every surface rounds the same way.
• Managed SPF rows show a visible next-step button. Previously setup depended on guessing that a row was clickable. Every row now shows a labeled action (Set up, Continue setup, Open, etc.) that varies by state.
• DMARC overview setup buttons are visible affordances, not microcopy. Set up reporting, Continue DNS setup, and View status now render as small pill buttons with proper padding, border, and focus rings.
• DMARC detail loads quieter. The advisor panel and setup checklist now default to collapsed on first visit, letting the tab bar and sender table be the page's primary content. Your expand/collapse choice persists per browser.
• Host-type picker explains itself. The add-host page now maps SMTP / IMAP / HTTPS / IP / TCP to real-world monitoring purposes before asking you to pick one.
• Sidebar Home renamed to Dashboard. Makes the distinction from Monitoring Overview unambiguous.

Behind the scenes: keyboard focus rings added to every new interactive element, tri-state rendering for loading data states, and regression tests covering each fix.

We shortened the gap between a DMARC report arriving and it showing up in the dashboard.

What changed

• Rollup runs hourly, not nightly. The background job that turns raw aggregate reports into the per-source breakdown now runs every hour instead of once a day. For reports covering previous UTC days (the overwhelming majority — Gmail, Yahoo, Microsoft, and other major reporters all send reports for the prior day), the delay between receipt and dashboard drops from up to a day to roughly an hour. Reports covering the current UTC day are still held until the next UTC midnight — unchanged from before — so that today's in-flight data isn't aggregated mid-collection.
• Automatic multi-datacenter coordination. The job is safe to schedule on all of our hosts simultaneously — a shared lock ensures only one host actually runs the aggregation per hour, with automatic failover if one host is unavailable.

Why

Previously, a customer who enabled DMARC reporting in the afternoon could see "Awaiting reports" on the dashboard for up to 24 hours even though the first report had already arrived — the aggregation that populates the dashboard only ran at 02:00 UTC each night. That was an uncomfortably long feedback loop for a feature where "is this working?" is the main question during setup.

Impact

No action required. If you just turned on DMARC reporting, your first sources breakdown should appear within an hour of the first report arriving — assuming that report covers a previous UTC day, which is how essentially every major reporter sends them. The badge will still read "Awaiting reports" during that window — honest labeling of the "report received, aggregation pending" state is tracked as a separate follow-up.

The DMARC domain detail page has been reorganized to make your enforcement journey easier to follow.

Tabbed layout and journey tracker

• Five focused tabs replace the single long-scroll page: Journey (default), Sources, Timeline, Geography, and Reports. The Journey tab opens first — it's where most of the actionable work happens.
• Vertical enforcement tracker runs down the Journey tab and shows your current step in the progression from monitoring to full enforcement (none → quarantine → reject). Each step shows what it requires and where you stand.

Less noise, better signal

• Redundant warning cards consolidated. Multiple overlapping "attention" cards that were firing at once have been replaced with a single contextual advisory, so you're not trying to prioritize three alarming messages at the same time.
• Subdomain Traffic surfaces first when it dominates. If the bulk of your DMARC reports is coming from subdomains rather than your root domain, that card now floats to the top of the page rather than appearing below less-relevant information.
• "Subdomains" card renamed to "Child DMARC records." Clearer label for what the card actually shows: whether your subdomains have their own DMARC policies or inherit yours.

Overview improvements

• Each domain now shows its journey stage inline on the DMARC overview list — no need to open each domain to see where it stands.
• "Skip for now" is explained. The skip action now includes a tooltip that describes what it does and when the item will resurface, so it's a deliberate choice rather than a mystery button.
• "Explain" renamed to "AI Explain." Makes it unambiguous that clicking it generates an AI-written explanation, not static documentation.

What's new

DMARC Reporting is now available. Point your DMARC RUA address at mxio and we'll parse every aggregate report your domain receives, identify every sender, and guide you from p=none to p=reject without breaking legitimate mail.

What you get

• Full aggregate report pipeline. Every DMARC aggregate (RUA) report that arrives in our mailbox gets parsed, enriched (ESP identification, geolocation, ASN), and stored. No uploads, no manual work.
• Source Viewer with classification buckets: Authorized & Passing, Needs Review, Denied, Unknown/Threat, Unclassified. Rename senders with local labels, recategorize when we get it wrong.
• Advisor panel on every domain: journey-stage detection, anomaly cards, authorized-senders roll-up, missing-config warnings, on-demand AI explanations.
• Enforcement journey guidance — know when you're ready to advance p=none → p=quarantine → p=reject, and why.
• Subdomain grouping, geography map, CSV export for portfolio review.
• Free DMARC Report Viewer at /tools/dmarc-report-viewer — upload any aggregate XML, get the same visualization, no signup required.

Pricing

Annual billing is available on every tier at a 2-month discount.

Setup

Go to Dashboard → DMARC Reporting → Add domain. We'll give you a RUA record (one TXT, one CNAME). Publish them; we handle the rest. First reports arrive within 24 hours on Google, typically within hours on Microsoft and Yahoo.

Existing customers on Monitoring Starter can switch to DMARC Starter laterally at the same price. Existing Pro and Business customers get DMARC included automatically.

What we deliberately don't do

• No forensic (RUF) reports — ecosystem unreliable, privacy-fraught, not worth it.
• No managed DMARC policy publishing yet. You control your _dmarc record. Managed DMARC (CNAME delegation with auto-advance) is coming in a future phase.

Read the setup guide · Try the free Report Viewer · Compare to dmarcian / EasyDMARC / DMARCLY / PowerDMARC / Valimail

The DMARC setup page now shows a 4-row status panel that reflects current state:

• Is monitoring enabled?
• Is our reporting authorization published?
• Does your DMARC record point to us?
• Are reports arriving?

Each row shows live state. The panel collapses to a one-liner when setup is complete, so you can see at a glance that everything is working.

Behind the scenes: a reconciler runs every 5 minutes to verify that our reporting authorization is still live on DNS, and republishes automatically if something drifts.

On /dashboard/services/dmarc, disabled domain rows (including the placeholder rows for domains you haven't enrolled yet) were rendering an em-dash in the Actions column instead of the usual ⋯ menu. That left no way to re-enable a domain from the menu, and no way to delete a disabled domain without enabling it first.

What changed:

• Disabled rows now render the Actions menu with state-appropriate items: "Enable reporting" (opens the setup wizard) and "Remove domain" (when a stored settings row exists).
• Placeholder rows for active domain targets that haven't been enrolled in DMARC yet show only "Enable reporting" — there's nothing in the DMARC tables to remove, so "Remove domain" is intentionally omitted there. Those domain targets are managed from /dashboard/domains.
• Enabled rows are unchanged (View details, Configure DNS, Copy RUA address, Disable reporting, Remove domain).

The inline "Set up reporting ›" link on the row stays — the menu adds a second, more discoverable path to the same flow.

A second fresh-eyes audit of the DMARC launch readiness work surfaced 27 new findings; a follow-on plan-consistency sweep caught five more factual drifts between the website and the shipped plan configuration. Everything's fixed.

Critical fixes that would have hit real customers:

• DMARC domain detail no longer crashes on empty state. Any domain with zero reports (which every new DMARC customer has for the first 24–48 hours) was throwing a runtime TypeError in the sources rounding helper. Guarded the helper against empty and zero-sum input, added regression tests.
• Setup wizard now protects your existing DMARC policy. Step 2 previously handed everyone a naked v=DMARC1; p=none; rua=... template. If you were migrating from another DMARC provider with p=reject in place and followed the wizard verbatim, you would have downgraded your enforcement. The backend already merged correctly when it could read your current record; added an explicit "replace your current record" framing, plus a prominent warning on the no-record branch that catches transient DNS lookup failures.
• AutoSPF competitor pricing corrected. The savings calculator and competitor matrix on /pricing used a flat $37/domain/month estimate for AutoSPF. Their actual pricing is tiered — a 10-domain customer's cheapest configuration is $127/mo (AutoSPF Plus + 9 add-ons), not the $370/mo we were claiming. New competitor-pricing module picks the cheapest fitting tier; matrix, calculator, cost-comparison, and compare/autospf.md all updated.

Dashboard and billing polish:

• Monitoring card renders as an upsell, not a red alarm, on plans without monitoring alerts. DMARC Starter users were seeing a red "1 failing" monitoring card for a capability their plan doesn't include. The card now renders as "Add monitoring" with a link to pricing when the plan excludes alerts.
• Grace-period banner stops telling top-tier users to upgrade. Customers on Business were seeing "Upgrade to restore DMARC reporting" banners for grace domains that Business could easily absorb. The banner now detects when the current plan has headroom and switches to "Re-enable in DMARC settings."
• Advisor sender counts stop contradicting themselves. The "X unrecognized senders" warning and the actual sender list now use the same 50-message threshold, so the numbers always agree.
• Subdomain summary matches the expanded row totals. The headline "X messages from Y subdomains" line and the detailed group rows now come from the same raw-record query; the ~4× discrepancy that appeared when daily aggregates drifted is gone.
• Billing meter label corrected from "DMARC reports this period" to "DMARC emails this period" — matches the value and the cap unit.

Competitor and pricing page accuracy:

• Added mxio Core as a third highlighted column in the /pricing competitor matrix, plus a new DMARC aggregate reporting row.
• valimail.md table now shows actual annual prices (applying the real 17%-off discount) instead of monthly × 12.
• dmarcian pricing consistency: /pricing and service pages both use the $24/mo monthly rate now.
• Five DMARC competitor compare pages (easydmarc, dmarcly, dmarcian, powerdmarc, valimail) are gated behind NEXT_PUBLIC_DMARC_DISABLED until launch — filtered out of the compare hub, sitemap, and Next.js static params.
• Business plan's health check interval is 5-min, not 15-min (corrected on valimail.md, dmarcly.md, powerdmarc.md).
• Setup wizard acknowledged-sender copy now says "is rejecting these messages at receivers" on p=reject domains instead of the future-tense "will be subject to your DMARC policy when enforcement is active."

DMARC overage cap on starter plans:

DMARC Starter and Core are now capped at the 100k overage tier. If you need 500k or 2M emails per month, upgrade to Pro or Business. Reports continue processing regardless of cap state — we never drop aggregate reports; the cap just gates automatic billing upgrades and the Stripe tier change endpoint. /pricing overage disclosure labels 500k and 2M rows as "Pro or Business only" with an added explanation block.

Plan-consistency sweep:

• Fixed dmarc-reporting-guide.md claiming Pro has 5 domains and Business has 20 — real values are 25 and 50.
• Managed SPF availability now noted on dmarc-deployment-guide.md and spf-flattening-explained.md so Free/Core readers aren't surprised at the paywall.
• spfflatten.net pricing FAQ clarifies "25 domains total, up to 10 with SPF flattening" instead of bare "10 domains."
• /pricing FAQ no longer implies Core is a starter plan.

Internal: new shared constant anomalyMessageThreshold = 50 keeps advisor warning counts consistent; new competitor-pricing.ts module centralizes AutoSPF tier math; DMARC setup wizard backend has regression tests for spliceRUA covering every tag combination; DmarcGraceInfo carries a new can_absorb field that backends compute from activeDomainCount + graceCount <= MaxDomains.

If you deleted a DMARC reporting domain and then re-added it, the setup wizard would jump straight to the final "Reports Flowing" screen — past the DNS update step — and hide the new reporting address you needed to publish. Reports from the prior setup survive a delete (intentional, so history isn't lost), and the wizard was treating any non-zero report count as proof the current DNS was correct. It isn't — after a re-add, the reporting address changes but old reports remain.

What changed:

• Step 2 of the wizard now only auto-advances when a live DNS check confirms your current _dmarc.<domain> record points at our reporting address. Historical report counts are no longer a trigger.
• The initial step is determined by enabled state alone. If you're enrolled, you land on the DNS step; the async DNS check advances you to step 3 within a second when the record is correct.
• Added a regression test that mocks the delete-and-re-add case (100 historical reports, live DNS shows a stale RUA address) and asserts the wizard stays on step 2.

The fix closes two related symptoms:

1. The domain row showing "Awaiting reports" while the wizard simultaneously claimed "Reports Flowing" — two sources of truth disagreeing on the same screen.
2. Your unique reporting address being hidden behind a skipped step, with no other path to find it.

If you're mid-migration and need to wipe old report data for a re-added domain, reach out — we can clear it server-side.

DMARC advisor now considers unclassified sender volume — the most critical safety fix in this release. Previously, the advisor could recommend advancing to p=reject while simultaneously showing unrecognized senders whose mail would be dropped by that policy. The advisor now gates advancement on the ratio of unclassified traffic:

• p=reject gates: advancement blocked until unclassified traffic is below 1% of total volume
• p=quarantine gates: blocked until below 5%
• p=none advisory: no hard block, but a warning appears when unclassified traffic exceeds 5% — advancing is still your choice

When the gate is active, the advisor shows a "Unclassified senders detected" card with a message count, sender count, and a "Review senders" link that jumps directly to the affected sources. Acknowledged senders (those you've already reviewed and dismissed) are excluded from the ratio — classifying a sender actually removes the block.

The enforcement journey stepper is now visible at every policy state, including p=none domains in discovery and configuration stages. Previously, domains early in the onboarding flow showed no progression context.

Plan changes now show a confirmation preview before committing. Downgrading or switching plan tiers opens a modal showing:

• Feature losses (what you'll give up)
• Domain impact (which domains will be paused and how many)
• DMARC grace period disclosure ("You'll keep DMARC reporting for 30 days")
• SPF flattening impact (if applicable)
• Effective date ("takes effect at end of your billing period — no credit issued")

The downgrade button is now amber rather than the same neutral style as an upgrade, matching the visual hierarchy: upgrade (teal) → lateral switch (neutral) → downgrade (amber) → cancel (red).

A persistent grace-period banner appears on the dashboard and billing page after a plan change is scheduled or DMARC grace is active. The banner shows the type of grace (domain limit or plan loss), affected domain count, expiry timeline, and a Restore CTA.

Competitor comparison pages have been corrected — several pages contained false feature-absence claims that we used as competitive arguments. EasyDMARC has SPF flattening (EasySPF). DMARCLY has SPF flattening (Safe SPF) and blacklist monitoring. MXToolbox's $129 plan is called Delivery Center, not Monitor, and includes additional monitoring capabilities. All prices updated to match current published rates.

The DMARC setup wizard now correctly waits for DNS proof before advancing to the verified state. Previously, the wizard could show "DNS verified · awaiting reports" as soon as we published the redirect TXT record — even if you hadn't yet added the DMARC record pointing to our RUA address. The wizard now stays on step 2 until either reports start flowing (proving your DNS is correctly configured) or a live DNS check confirms your _dmarc record contains our RUA address.

The DMARC domain overview now shows all your domains, including those awaiting first reports and disabled domains. Previously, domains with no report data were silently hidden — if you added a domain and didn't see it in the list, that was the reason. Disabled domains now show a "Disabled" badge; domains awaiting first reports show "Awaiting reports."

The billing dashboard now correctly shows the DMARC Reporting usage meter for DMARC Starter customers. It was previously hidden due to a plan-detection logic error that checked for endpoint monitoring access instead of DMARC reporting access.

The DMARC volume meter no longer shows the add-on tier price — it now shows only the tier name and billing reset date. The plan price belongs on the billing page, not the dashboard usage widget.

You can now remove a domain from DMARC reporting. The domain action menu includes a "Remove domain" option with an inline confirmation step.

The /pricing toggle now defaults to your current billing interval when you're signed in — annual if you're on annual billing, monthly if you're on monthly. Anonymous visitors still see annual pricing by default.

Four new DMARC lifecycle campaigns that guide users from activation through enforcement:

• Activation nudge — DMARC-entitled paid users who haven't enabled DMARC Reporting receive a 3-email sequence explaining the blind spot between monitoring and visibility.
• Onboarding — after enabling DMARC Reporting, a 4-email sequence covers what to expect, how to read sources, and when to move toward enforcement.
• First report milestone — a transactional notification when your first DMARC aggregate report arrives and data populates your dashboard.
• Enforcement milestone — celebrates when your DMARC policy advances to p=quarantine or p=reject, with guidance on what comes next.

Six existing campaigns updated with DMARC-aware content — welcome emails, upgrade confirmations, educational drips, and win-back sequences now mention DMARC Reporting where relevant, gated by plan entitlement so users only see features they can access.

All milestone emails use event-specific metadata stored at enrollment time, so the domain and policy referenced in the email always match the event that triggered it — even on multi-domain accounts.

What changed

The second phase of the UX polish sweep — 39 fixes from the April 9 dual-surface audit, covering the dashboard, marketing site, and content templates.

Dashboard

DKIM summaries are readable. Health rows with 30+ DKIM selectors now show at most 3 provider groups with a "N more checked" count instead of dumping every selector name into one cell.

Health summaries name the problem. DMARC, MX, Blacklist, and Delegation checks now surface the actual error or warning message on failing rows instead of neutral metrics.

Hub page is actionable. The headline is now dynamic ("2 domains need attention" / "All systems healthy"), failing domain names appear in the Monitoring card, and activity rows link to their source domain or incident.

Incidents default to Open. The incidents list now opens on the "Open" tab instead of showing all 700+ resolved incidents first. Duration color-escalates (amber >24h, red >7d), and failure counts are labeled "Current streak."

Slide-over panels fixed for screen readers. Closed panels no longer announce a phantom dialog in the accessibility tree.

Small fixes. Uptime pills labeled "UPTIME". Incident count is a clickable link. Duplicate "Add Domain" heading removed. Domain list header visually separated.

Notifications

Alert groups explained. Each notification group now has a tooltip showing which events it contains (SPF fail, DKIM fail, blacklist hit, etc.).

"What triggers alerts" section. A new collapsible reference section lists every notification event type and its group — so you can see what you'll actually receive, not just where it goes.

"Tips & updates" clarified. The toggle now explains what's included: product updates, feature announcements, and email auth tips. No marketing emails.

Billing

Billing cadence is explicit. Annual plans now show "billed annually" and use "Renews" instead of "Next billing date."

Active Checks defined. A tooltip on the usage bar explains what counts as an active check.

DMARC usage meter. Plans with DMARC Reporting now show a progress bar of current-period email volume against the plan cap.

"Manage Billing in Stripe →" — the button now says where it goes.

Pricing page

One global billing toggle. Monthly/annual pricing is now controlled by a single toggle above the plan grid instead of five per-card switches.

"Need help choosing?" A new callout with three buttons ("I need SPF flattening → Pro", etc.) scrolls to and highlights the relevant plan card.

CTA micro-copy. Plan cards now show "Free to start · no card required" below the Get Started button.

Core card SPF callout. Core's card now links to Pro for visitors who need SPF flattening.

New FAQs. "Can I switch from monthly to annual billing?" and "What counts as a managed domain?"

Content & comparisons

Buy CTAs on comparison pages. All 7 comparison articles now include a ServiceCta linking to the relevant mxio service.

Managed SPF CTA on provider pages. Provider pages with SPF includes now show a Managed SPF callout after the Common Issues section.

Author bio. Articles now show the author's role alongside their name.

"Last reviewed" dates. Articles can now display a review date for freshness signals. Three key articles seeded.

Standards tool links. The SPF RFC 7208 Quick Reference table now links each row to the SPF checker tool.

Related providers expanded. "Often Used Together" sections expanded from 2 to 6 providers across all 21 provider pages.

Category pill links. Provider category badges now link to the filtered provider directory.

When a DMARC source shows up in your sources tab that doesn't match what you expect, you can now rename it and change its category for your account. Your labels don't affect other customers. They don't change alignment math or authorization status. They just make your dashboard read the way you think. Renamed sources show a small "Local label" badge so it's always clear what's your naming and what's verified by mxio.

A note on what's not yet renamable: if a source shows up as "Unknown senders" (no ESP match), we can't yet let you rename it individually — our daily report groups every unmatched sender on a domain into a single bucket, so naming one would relabel them all. We're widening that grouping in a follow-up so you can name unfamiliar senders too.

What's new

The "Security" link in your account menu now goes to a dedicated security management page instead of the account setup flow.

Passkeys — See all registered passkeys, rename them to something memorable (like "YubiKey" or "MacBook Touch ID"), remove old ones, or add a new passkey from any device.

Authenticator app — Set up or remove TOTP two-factor authentication. Removing requires your current authenticator code.

Recovery codes — Check how many codes you have left, or generate a fresh set. Useful if you've used most of your codes or switched authenticator apps.

Active sessions — See every device and browser currently signed in. Revoke individual sessions or sign out everywhere else at once.

What changed

Four small fixes that were causing unnecessary dead ends.

/signup redirects to /login. Old bookmarks and external links pointing at /signup no longer land on a 404 — they go straight to the login page.

/learn/errors/spf-permerror is fixed. The article link was broken after a URL change. It now resolves to the correct page.

Tool CTAs preserve your domain. The "Activate Managed SPF" button on free tool result pages now passes the domain you checked through the login flow. After authenticating, you land on the add-domain page with the domain pre-filled instead of an empty form.

Dashboard 404 stays in the dashboard. Navigating to an invalid /dashboard/... path used to drop you out to the marketing site. It now shows a proper not-found page within the dashboard chrome, with navigation intact.

What changed

Five display fixes from our UX audit.

Scroll animations respect your OS reduced-motion setting. If you have "Reduce Motion" enabled in your system preferences, page animations no longer play — all content appears immediately. Previously, the CSS media query was the only guard; JavaScript-driven animations (scroll reveals, pricing table, feature matrix) could still fire.

MTA-STS and DNSSEC no longer show green "pass" when absent. If your domain doesn't have MTA-STS or DNSSEC configured, health checks for those features now show a neutral gray badge instead of a green pass. Not having these set up is informational — it's not something to celebrate, but it's also not a failure.

SPF failures show the actual error message. When an SPF check fails, the health summary now reads the first error message (e.g., "Included domain d1.mxdns.io has no SPF record") instead of reporting the lookup count ("8/10 lookups used"), which only makes sense when SPF is passing.

Info checks display as gray and group separately from passes. Informational check results on the domain health tool page now use a gray neutral style and appear in their own section alongside inconclusive results — not mixed in with green passing checks.

DMARC panel reads from live health data. The DMARC configuration panel in domain detail now uses the live health check result to determine whether a DMARC record is present, rather than a stale snapshot from the domain list.

What changed

A set of UX polish fixes targeting price consistency, inline fix paths, and accurate tool counts.

Prices are consistent site-wide. All plan prices now come from a single source so they can't drift out of sync between pages. Every CTA, pricing card, comparison page, and article shows the same number.

SPF checker CTAs include pricing. The "Activate Managed SPF" action bar on SPF lookup limit and SPF record too long results now shows "from $59/mo" so you know what you're clicking into.

Error articles link to the service that fixes the problem. Six error articles now include an inline CTA after the article body pointing to the relevant mxio service with the plan price: spf-too-many-lookups, multiple-spf-records, no-dmarc-record, dmarc-policy-none, dmarc-failing, and dmarc-alignment-failure.

Tool count corrected to 22. Outdated "18+" and "30+" claims have been replaced with the actual count across the site, including seven comparison pages.

spfflatten.net add-on copy removed. References to a $15/domain flatten pack that no longer exists have been replaced with current Pro/Business plan pricing.

Hero subhead updated. The homepage hero now reads "Diagnose. Monitor. Fix." — a tighter summary of what mxio does.

What changed

• Pricing pages now respect the DMARC launch flag on both mxio.io and spfflatten.net, so DMARC plan cards and feature rows stay labeled Coming soon while NEXT_PUBLIC_DMARC_DISABLED is still enabled
• Pricing metadata is now consistent with the visible UI on mxio.io, so structured data no longer advertises live DMARC pricing before launch

Why it matters

• Visitors no longer see mixed signals where DMARC looks purchasable in one part of the pricing page but gated in another
• The pricing page source now matches the launch state shown in the product UI

What's new

DMARC Reporting — full aggregate report ingestion, source classification, and enforcement readiness analysis for your domains.

Aggregate report ingestion

Enable DMARC Reporting for a domain and mxio generates a unique RUA address (rua+<token>@rua.mxdns.io). Add it to your DMARC record's rua= tag. Reports from Gmail, Microsoft, Yahoo, and other major receivers start arriving within 24–48 hours. No XML parsing on your end.

Source classification

The Sources view groups every sending IP into one of five buckets:

• Authorized & Passing — senders you own, passing DMARC alignment
• Authorized & Failing — senders you own, misconfigured
• Forwarded — traffic from forwarders or mailing lists breaking SPF as expected
• Unknown — unrecognized sources that need review
• Misconfigured — recognized services without a working auth setup

Authorized Senders engine

mxio identifies sending infrastructure by reverse DNS, ASN, and known ESP patterns. When a source maps to a recognized provider — Mailchimp, SendGrid, Postmark, Google Workspace, Microsoft 365, and others — it shows the provider name and logo alongside the IP. Unrecognized sources are surfaced for manual classification.

Enforcement journey

The Enforcement advisor tracks your readiness to tighten policy. It shows your current alignment rate, flags any sending sources that would be blocked if you moved from p=none to p=quarantine or p=reject, and guides you through the progression step by step.

Geography tab

Sending infrastructure plotted on a map by data center location — useful for spotting unexpected sending regions.

Subdomain grouping

Subdomains discovered through reports can be organized with pattern-based grouping rules. Rules are matched top to bottom; first match wins.

AI explain on anomaly cards

Unusual traffic patterns surface as anomaly cards. Each card has an AI explain button that gives a plain-language analysis of what the anomaly likely represents and what to investigate.

New-sender notifications

When a high-volume unrecognized sender appears (1,000+ emails in a 7-day window), you get an email alert with the IP, hostname, message count, and first-seen date.

Availability

DMARC Reporting is included in:

• DMARC Starter — $19/mo, 2 domains, 100k records/mo
• Core — $34/mo, 5 domains, 100k records/mo
• Pro — $59/mo, 5 domains, 150k records/mo
• Business — $129/mo, 20 domains, 500k records/mo

For setup, see DMARC Reporting in mxio: Setup, First Data, and What To Do Next.

New DMARC Reporting notification group — a dedicated group in notification settings for DMARC-specific events. Available when your plan includes DMARC reporting. Covers three alert types: subdomain discovery, subdomains reporting outside mxio, and the new unrecognized sender detection.

Unrecognized sender detection — mxio now scans DMARC report data for high-volume sources that aren't in your authorized sender list and aren't known forwarders. When a source exceeds 1,000 emails in a 7-day window, you get an email alert with the IP address, hostname, email count, and first-seen date. Alerts are suppressed per domain for 7 days after each notification to avoid noise.

What changed

Three new free tools and three new domain monitoring check types ship together — each tool doubles as both a standalone lookup and an automated health check when you add a domain to monitoring.

MTA-STS Checker

Validates your _mta-sts TXT record and fetches your /.well-known/mta-sts.txt policy file. Checks mode, max_age, and whether your MX hosts are covered by the policy. If you have MTA-STS configured, monitoring now alerts you when the policy expires, MX coverage drifts, or the policy file becomes unreachable.

DNSSEC Validator

Walks the DNSSEC chain of trust from the root, verifying DS/DNSKEY agreement, RRSIG expiry, and algorithm strength at each level. Monitoring alerts you if signatures expire, the chain breaks, or a weak algorithm is detected.

Domain Expiry Checker

Queries RDAP (the modern replacement for WHOIS) to find your domain's registration expiry date, registrar, and renewal status. Monitoring checks this daily and alerts you before your domain expires — preventing the kind of outage that takes down everything at once.

SMTP banner verification

The existing SMTP check now compares the mail server's 220 greeting hostname against the expected hostname. A mismatch shows up as an informational finding — a common deliverability issue that's easy to miss.

Why it matters

MTA-STS, DNSSEC, and domain expiry are infrastructure concerns that sit underneath email authentication. A lapsed domain registration or a broken DNSSEC chain can take down email delivery regardless of how well your SPF and DMARC are configured. These checks close that blind spot.

What changed

We updated the dashboard's in-flight waiting states so they communicate progress more clearly, especially when your system has Reduce Motion enabled.

Clearer active-waiting states

• Domain and host health checks now use a shared pending indicator instead of a generic pulsing dot
• Blacklist streaming rows now show a compact pending shimmer while providers resolve one by one
• DMARC setup and other long-lived waiting states now use the same pending treatment for a more consistent feel

Better reduced-motion behavior

• Pending scan bars now fall back to a static striped treatment when motion is reduced
• Pending dots now fall back to a visible resting ring instead of looking like a stuck animation frame

Why it matters

The previous behavior could look broken when animations were intentionally suppressed by the OS. These states now read as intentionally pending whether motion is enabled or reduced.

New DMARC Starter plan — a dedicated entry point for customers who need DMARC reporting but not full monitoring. $24/mo, $240/yr. Includes 2 domains, 100,000 DMARC records/mo, full reporting dashboard, enforcement journey tracker, AI explanations (50/mo), and free-tier health visibility. No email alerts — add monitoring for $10/mo to upgrade to Basic+DMARC at $34/mo.

DMARC included in Pro and Business — DMARC reporting is now bundled into the Pro ($59/mo, 150k/mo) and Business ($129/mo, 500k/mo) plans. No separate add-on required. Volume overages continue to auto-bump on monthly plans.

Two paths to the same ladder — DMARC-first customers start at $24/mo, monitoring-first at $19/mo. Both converge at $34/mo (Basic + DMARC). From there the upgrade path to Pro ($59/mo) and Business ($129/mo) is the same for everyone.

What changed

The DMARC dashboard now closes several first-use gaps that showed up in the March cognitive walkthrough.

Safer sender review

• Needs Review rows now have actions in place so you can authorize, dismiss, or skip a sender without bouncing between tabs
• Consequence copy is now visible before you decide, so it is clearer what authorize and dismiss actually mean
• Provider descriptions appear in review-needed rows to make recognition easier
• "Skip for now" leaves the sender in review instead of forcing a low-confidence decision

Better DNS and status feedback

• The setup wizard now stays open after enablement so DNS setup and verification steps remain reachable
• DNS polling now rechecks automatically and advances once your RUA is detected
• EDV status labels now match reality: needs setup, awaiting reports, receiving reports, and failure states are clearer
• Status badges open the setup flow directly instead of acting like passive labels

More concrete enforcement guidance

• Ready-to-advance guidance now includes a copyable DMARC record
• You can preview a merged version of the next record that keeps tags from your current DMARC record when available
• Advisor overflow links now jump to the Sources tab so review work stays connected

Why it matters

The old flow made a few important things harder than they should have been: deciding whether a sender was legitimate, knowing whether DNS changes had been seen yet, and figuring out the exact next DMARC record to publish. The updated walkthrough keeps those steps in one place and makes the next action much more explicit.

What changed

The "Add by provider" section in the DKIM selector picker now uses a more reliable icon treatment.

Better provider logos

• Fastmail now has a real provider icon instead of a plain fallback initial
• MailRoute now uses a local icon override instead of the washed-out harvested favicon
• Transparent logos now sit inside a neutral icon chip so they stay legible in both light and dark mode

Where this shows up

This update applies to the DKIM selector flows in the dashboard, including the provider cards and the selector discovery rows.

Why it matters

The old approach treated harvested favicons like stable product icons. That worked for some providers, but it broke down for transparent or low-contrast assets. The new treatment keeps the picker readable and consistent without relying on brittle third-party favicon artwork.

What changed

The dashboard and admin side panels now use a more consistent slide-over pattern, with a cleanup to saved-state handling in host and profile editors.

Save-state fixes

• Host editing no longer shows a discard warning immediately after a successful save
• Monitor editing now re-bases correctly after save before you navigate away
• Profile settings now treat the saved value as the new baseline right away
• Host and domain detail pages now reload their primary snapshot after an in-place save so the detail view stays in sync with the list view

Better slide-over behavior

• Focus now moves into the panel when it opens and returns to the trigger when it closes
• Keyboard navigation stays inside the panel while it is open
• Dialog semantics are now explicit for assistive technologies
• Mobile sizing is safer for narrower screens

More consistent admin panels

The admin drawers for DNS host providers, SPF catalog providers, Managed SPF service detail, and partners now share the same panel shell instead of each using a separate hand-rolled implementation.

Why it matters

The old behavior could tell you a save succeeded and still act as if the form was dirty, which is contradictory and undermines trust. The new behavior makes saves feel final, and the shared drawer implementation reduces UI drift across the product.

What changed

The dashboard landing page (/dashboard) is now a platform hub instead of a monitoring-only overview.

Service gauge cards

Each active service gets a compact card showing status, key metrics, and a link to its detail section:

• Monitoring — domain count, host count, open incidents
• DMARC Reporting — monitored domains, email volume, aggregate pass rate (visible when DMARC is enabled)
• Managed SPF — managed domain count, flatten limit (upgrade prompt if plan doesn't include it)

Cards show setup guidance when a service is available but not yet configured.

Monitoring overview

The full monitoring detail — attention table, open incidents, key numbers, activity feed — now lives at /dashboard/monitoring. Everything that was there before is still there, just at a dedicated address.

Updated navigation

The sidebar has a new top-level "Home" link for the hub. Monitoring gains its own "Overview" entry. All other links (domains, hosts, incidents, services, account) are unchanged.

What changed

A free DMARC aggregate report viewer is now available at /tools/dmarc-report-viewer. No account required.

How it works

Drag and drop (or paste) a DMARC aggregate report XML file. The viewer parses it entirely in your browser — the file never leaves your machine. Supports raw XML, gzip-compressed, and zip archives.

What you see

• Summary stats — reporting organization, date range, published policy, total message count
• Source table — every sending IP with volume, SPF result, DKIM result, and DMARC alignment. Sortable by any column.
• Auth detail rows — expand any source to see the specific SPF and DKIM authentication results with domain and selector detail
• Privacy banner — clear confirmation that parsing happens client-side only

Why it matters

DMARC aggregate reports are XML files that mailbox providers (Google, Microsoft, Yahoo) send to your RUA address. They tell you who's sending email as your domain and whether those senders pass authentication. Most people never read them because the raw XML is dense and hard to parse. This tool makes them readable in seconds.

Upgrade path

The free viewer handles one report at a time. For continuous monitoring across all your domains with source identification, alignment tracking, and enforcement guidance, enable DMARC Reporting in the dashboard.

What changed

Service setup consistency

• Managed SPF and DMARC Reporting now use the same setup wizard pattern: numbered stepper with clickable completed steps, consistent DNS verification flow, and shared cancel behavior
• Plan gates use a shared component across both services — Free-tier users see what the service does, which plan unlocks it, and the starting price
• Status badges follow a universal vocabulary (Active, Setting up, Awaiting, Paused, Error, Not configured) across all service pages
• Basic plan pricing now shows the $15/domain/month add-on cost upfront on the Managed SPF page

Dashboard improvements

• Welcome panel shows mini preview tables with status dots instead of text-only description cards, giving new users a visual preview of what monitoring looks like
• Host detail shows an "Awaiting first check" panel with sub-check badges when a host is newly added, instead of empty timeline tabs
• Hosts empty state explains what endpoint monitoring offers with check-type badges and a clear CTA

Bug fixes

• Fixed login page hydration mismatch caused by localStorage read during server-side rendering
• Fixed setup page hydration mismatch from evaluating WebAuthn support at render time
• Fixed DMARC setup table not refreshing after inline domain creation

What changed

The Domains and Monitored Hosts list pages now support multi-select with bulk operations.

Selection

• Checkbox column on every row
• Select-all checkbox in the table header (with indeterminate state for partial selection)
• Selection clears automatically after a successful bulk action

Bulk action toolbar

When one or more items are selected, a toolbar appears above the table with context-aware buttons:

• Pause — only visible when active items are selected
• Resume — only visible when paused items are selected
• Check Now — runs health checks on all selected items
• Delete — with confirmation dialog (domains note that child monitors will be kept as standalone monitors)

Partial failure handling

If some items in a batch fail (e.g., plan limit reached during bulk resume), the toolbar shows how many succeeded and keeps the failed items selected so you can see which ones need attention.

Backend

Two new batch endpoints (POST /v1/domains/batch and POST /v1/monitors/batch) handle pause, activate, and delete operations with per-item results. Plan limits are enforced — bulk resume won't exceed your plan's domain or monitor quota.

What changed

A systematic sweep across every dashboard page to standardize conventions, adopt shared components, and eliminate inconsistencies.

Inline delete confirmations

Delete actions on domain and host list pages now show an inline confirmation row instead of a browser dialog. You see the warning in context with Cancel and Delete buttons — no more jarring popup.

Shared action menus

The three-dot action menus on domain and host lists are now powered by a shared ActionMenu component with smart positioning that flips above the button when near the bottom of the screen.

Consistent page headers

All dashboard list pages (Domains, Incidents, Billing, Settings, Notification History) now use a shared PageHeader component for consistent title, description, and action button layout.

Destructive button styling

Delete and disable buttons across detail pages and the Managed SPF panel now use the standard destructive button style — subtle red border with tinted background — instead of varied hand-rolled styles.

Additional improvements

• Managed SPF panel tabs use the shared TabBar component
• Navigation arrows animate on hover in health cards
• Keyboard focus rings on interactive table rows
• Internal links use Next.js <Link> for instant SPA navigation
• Timestamps use consistent relative formatting ("5m ago", "3d ago")

What changed

We completed a full OWASP Top 10 security audit and shipped fixes for every finding. These changes harden authentication flows, API endpoints, and infrastructure across both mxio.io and spfflatten.net.

Authentication hardening

• Magic link and passkey login flows now have brute force protection with automatic rate limiting
• Per-email rate limiting prevents magic link spam (3/min per address)
• Admin impersonation sessions are now read-only — diagnostic operations work, but billing changes and data mutations are blocked

API protection

• All outbound connections (favicon fetching, HTTPS probing, network diagnostics) now validate resolved IPs against private and reserved ranges, preventing server-side request forgery
• Email headers are sanitized against CRLF injection
• Global request body size limits prevent resource exhaustion
• Auth redirect URLs are validated against an origin allowlist on both backend and frontend

Infrastructure improvements

• Content Security Policy headers added to both frontend applications
• HSTS headers strengthened with includeSubDomains across all services
• Structured authentication event logging for all login methods
• Sensitive values removed from startup logs

What changed

Free tool results now bridge the gap between diagnosis and action. When a tool finds a problem, it tells you what to do about it — right in the diagnostic panel where you're already reading.

Action bar in diagnostic results

Every tool result with errors or warnings now shows an action bar below the diagnostic narrative. The action matches the problem type:

• Structural problems (SPF over the lookup limit, record too long) surface Managed SPF as a fix
• Approaching limits (8-9 lookups, record getting long) link to SPF flattening education
• Operational issues (blacklisted, weak DKIM key, DMARC p=none) suggest domain monitoring

The action bar picks the highest-priority issue and shows one clear next step — not a wall of buttons.

Domain health "Next Steps" card

Domain health results now include a Next Steps summary after the check rows. Service-lane items (Managed SPF) get prominent buttons. Monitoring covers all remaining issues in a single line. If you're already monitoring the domain, the monitoring line doesn't appear.

Smarter CTA de-duplication

When the action bar is already showing a monitoring pitch, the standalone monitoring card below the fold suppresses its anonymous rendering to avoid repeating the same message. Logged-in users still see their monitoring status. The SPF lookup budget bar hides its CTA button when the action bar already offers Managed SPF — the gauge and count remain, just not a duplicate button.

Upgrade hooks visible on grouped errors

Error-severity items in the findings list (3+ identical issues grouped together) now show their upgrade hook immediately, without expanding the group. You see the fix option right away instead of having to click "Show 3" first.

What changed

Domain health checks probe 8 common DKIM selectors (google, selector1, k1, etc.). Previously, if none matched, DKIM scored as a hard fail — dragging your entire health score down to 20/100 even if SPF, DMARC, and MX were perfect.

Now, when no common selectors match, DKIM shows as inconclusive instead of failed. Your overall score is calculated from the checks we can actually verify.

Provide your own selector

The domain health form now includes a "DKIM Selector (optional)" field. If you know your selector (e.g., s1024, mail, or a provider-specific name), enter it for a definitive check.

Re-check from results

When DKIM comes back inconclusive, an inline prompt appears: "We couldn't find a common DKIM selector. Know yours?" Enter your selector and re-check without leaving the page.

Scoring improvements

• Inconclusive checks are excluded from the overall health score — we don't grade what we can't test
• Real DKIM problems (revoked keys, malformed records) still score as failures, even during the common-selector sweep
• Delegation checks no longer affect the overall score — they provide useful context but aren't email authentication checks

What changed

mxio's free tools now have memory. Every time you check a domain, we fingerprint the result and compare it to the last check. No account required.

Change detection badge

A subtle indicator appears in every tool result:

• First check — this is the first time we've seen this domain+tool combination
• Stable · N checks since [date] — configuration hasn't changed across multiple checks
• Changed since [date] — something is different from the previous check

What gets tracked

The system fingerprints meaningful DNS data (records, policies, key sizes) while ignoring volatile fields (response times, geo data, timestamps). A change means your actual configuration changed, not that a server responded 2ms slower.

Privacy

Snapshots are anonymous — no account, no cookies, no tracking. We store a fingerprint hash and key metrics per domain+tool combination. Results older than 12 months are automatically pruned.

Coming next

Field-level change details ("SPF lookup count went from 6 to 11") and integration with diagnostic narratives are planned follow-ups.

What changed

Every free tool result now tells you what the data means, not just what the data is.

Diagnostic paragraphs

Each tool (SPF, DKIM, DMARC, MX, Delegation) generates a 2-4 sentence diagnostic paragraph that appears at the top of the result. It explains the findings in plain language — what's healthy, what's broken, and what to do about it.

For example, an SPF result might say: "This SPF record uses 9 of 10 DNS lookups, approaching the limit. Adding more services could push it over. The ~all (softfail) qualifier marks unauthorized senders but doesn't reject them. Consider -all for full enforcement."

Cross-protocol diagnostics

Domain Health now connects SPF, DKIM, and DMARC into a single diagnostic story. Instead of five separate traffic lights, you get one paragraph that explains the relationship: "Your SPF passes with 6 lookups and -all enforcement, and DKIM is active with a 2048-bit key. However, DMARC is set to p=none — receivers aren't enforcing authentication results."

This is the paragraph you screenshot for your boss.

Key metrics at a glance

Domain Health check rows now show key numbers inline — SPF lookup count and qualifier, DKIM key size, DMARC policy level, MX server count, and nameserver status. No drill-through needed for the basics.

Dynamic browser tab titles

Tool results update the browser tab to show the domain and score — useful when you have 12 tabs open checking different domains.

Basic plan users can now add Managed SPF to individual domains without upgrading their plan.

Per-domain pricing — Each SPF Flattening pack covers one domain at $15/month. Add packs from the Billing page as you need them, up to your plan's domain limit. Remove packs anytime — enforcement automatically pauses flattening on excess domains.

Pro-equivalent polling — Domains with an active flattening pack get the same 30-minute polling interval as Pro plan users. Your flattened SPF record stays current with upstream provider changes.

Billing integration — Packs appear as line items on your existing Stripe subscription. Add or remove packs instantly from the Billing page — no plan change required.

Pro and Business plans include Managed SPF for all domains at no extra cost. The add-on is designed for Basic users who need flattening on one or two domains without the full Pro upgrade.

Every free tool result page has been redesigned to communicate data visually, not just textually.

DMARC Checker — A policy progression bar shows where you are on the none → quarantine → reject journey, with contextual guidance at each stage. Domains without DMARC now see a structured empty state with a direct link to the DMARC Record Generator.

MX Lookup — Response times render as proportional bars (like Ping results), making it easy to spot slow mail servers. Primary and backup MX hosts are visually distinguished by priority.

SMTP & IMAP Tests — A port comparison summary shows all tested ports at a glance with connection status, TLS version strength badges (color-coded by version), and certificate expiry indicators.

Delegation Health — Nameserver response times now display as proportional bars. SOA serial consistency gets a compact pass/fail indicator that only expands details when serials differ.

DNS Lookups — Record types are grouped with summary counts, and TTL values now display with human-readable labels (e.g., "TTL 5m - Short" instead of raw seconds).

Shared components — Three new reusable visualization components (ResponseTimeBar, CertExpiryBadge, TLSStrengthBadge) ensure consistent data presentation across all tools.

The notification settings page has been redesigned from the ground up. Instead of a 50-event preference matrix, you now configure 4 alert groups per channel.

Alert groups — Errors & Outages, Warnings & Degradation, Recoveries, and Managed SPF. Toggle each group on or off per notification channel. The groups map to the right event types automatically.

Channel-centric layout — Each notification channel (email, in-app) gets its own section with clear enable/disable controls and per-group toggles.

Notification history — Extracted to its own dedicated page at /dashboard/notifications/history with improved display, keeping the settings page focused on configuration.

Every monitored entity now has a dedicated activity page showing its full timeline — health status changes, configuration updates, re-checks, and incident events in a unified feed.

Three new pages:

• /dashboard/activity — cross-entity activity feed for your entire account
• /dashboard/domains/{id}/activity — per-domain activity with tier and date range filters
• /dashboard/hosts/{id}/activity — per-host activity

Health history bar — Domain and host detail pages now show interactive health history as colored pips. Each pip represents a time bucket — click one to jump to the activity page at that point in time. Uptime pills above the bar let you select different time windows.

Timeline improvements — Flapping health checks are collapsed into single events. Streak events show human-readable durations. The timeline uses a compact table format instead of bordered cards.

The dashboard has been redesigned for density and clarity across all major pages.

Overview page — Status headline telling you what needs attention, key numbers (domains, hosts, incidents, managed SPF), health breakdown bar, and a unified attention queue replacing the old sparse layout.

Domains list — Each row now shows health score, overall status, per-check status dots, and last checked time. No more clicking through to find out if a domain is healthy.

Domain detail — Stat cards (checks passing, 30-day health, open incidents, last checked), health section with sub-check pills, associated hosts discovery, and tabbed layout for Timeline and Incidents.

Host detail — Same stat card pattern, sub-check results with expandable detail, and tabbed navigation.

Monitors have been renamed to Hosts throughout the dashboard for clarity. The A/AAAA and IP Ping checks have been removed from domain health — they're infrastructure concerns, not email authentication.

When a hostname resolves to multiple IP addresses (load balancers, failover configurations, round-robin DNS), mxio now checks each IP independently — up to 4 per monitor.

Per-IP results appear in the monitor detail page, so you can see exactly which server is failing SMTP, which IP has a certificate issue, or which endpoint isn't responding to ping. IP set changes (new IPs appearing, old ones disappearing) are tracked and surfaced in the activity timeline.

Endpoint monitoring has been redesigned from the ground up. Instead of one monitor per hostname with all check types enabled, you now create typed monitors — SMTP, HTTPS, Ping, or Port — each as its own billable slot with only the relevant checks.

What's new:

• 4 monitor types — SMTP (port connectivity, STARTTLS, TLS certs), HTTPS (uptime, cert expiry), Ping (ICMP reachability), Port (TCP connectivity on any port)
• Per-monitor billing — one monitor = one slot against your plan limit. Only pay for what you monitor.
• TCP port checks — monitor any TCP port (database, custom services, mail submission)
• Type-picker creation — 4-across card selector when adding a new monitor, with type-specific inputs and sub-check toggles
• Redesigned detail page — denser layout, aggregated check history with cycle grouping, mini-history pips, incidents section

A common source of confusion: your SPF checker says "fix your SPF record," but where do you actually make that change? It's not your email provider — it's your DNS host, and they're usually different companies.

Now, every domain-based tool (SPF, DMARC, DKIM, MX, Domain Health, Delegation, DNS Lookup) shows a guidance card when issues are detected. If we recognize your DNS host, you get the provider name and a link to their setup guide. If we don't, you see your raw nameservers so you know who to contact.

Unrecognized DNS hosts are tracked internally so we can expand our provider directory over time.

Previously, adding a domain meant your first Domain Health check would show a DKIM warning because no selectors were configured yet. Now mxio automatically checks ~25 common DKIM selectors during domain creation and saves the ones that resolve.

New domains are also immediately scheduled for automated health checks — no more waiting for a manual trigger to enter the monitoring rotation.

If you arrive at mxio.io from spfflatten.net, a MailRoute referral, or an ad campaign, the login page now shows value props relevant to your context instead of a blank form. Returning users see a streamlined "Welcome back" layout.

New free tool at /tools/dmarc-wizard. Enter your domain to pre-fill from an existing DMARC record, or start from scratch.

Deployment stage selector — pick a rollout strategy and the wizard sets your policy and percentage automatically:

• Monitor first — p=none (observe without affecting delivery)
• Quarantine (gradual) — p=quarantine; pct=25 (test on a slice of traffic)
• Quarantine (full) / Reject (gradual) / Reject (full) — step through enforcement at your own pace
• Custom — full manual control over every tag

Reporting — add multiple aggregate (rua) and forensic (ruf) addresses, comma-separated. The wizard validates each address and assembles the mailto: URIs for you.

Server-side validation — click Validate to run the same checks our DMARC Record Checker uses. Catches missing tags, invalid policies, and spec violations before you touch DNS.

The generated record includes full DNS setup instructions: hostname (_dmarc.yourdomain.com), record type (TXT), and a copy button for the value. Your configuration is assembled in-browser and never stored.

When you run a blacklist check or MX lookup, each IP now shows a Monitor button inline. Click it to start tracking that IP — no need to navigate to the dashboard first.

Notification preferences now display severity badges (High, Medium, Info) alongside each event category, with recommended action timeframes so you can prioritize what matters.

Guides cover GoDaddy, Cloudflare, Route 53, Namecheap, Network Solutions, Google Domains, Azure DNS, IONOS, Hover, DreamHost, DNS.com, and DNS Made Easy. Each guide includes exact field values, platform-specific conventions, and troubleshooting tips.

The Add Monitor page now opens with a visual type picker — four cards showing SMTP, HTTPS, Ping, and Port with descriptions of what each monitors. After picking a type, the form adapts: hostname input for all types, a port field for Port monitors, and sub-check toggles for SMTP and HTTPS.

The monitor list is now a compact table with status dots, type badges, health summaries, and an actions menu. Failures sort to the top so problems are visible at a glance.

Partners can now embed email authentication health checks directly in their products using a self-contained iframe widget or JSON API. The system includes partner credential management (embed tokens and API keys), per-partner rate limiting, HMAC-signed referral attribution with conversion tracking, and a full admin panel for partner review, credential rotation, and funnel analytics. Visit the integration guide to get started.

Previously, every "Explain this" request counted against your monthly quota — even if the results were identical to a previous check. Now, when your results match a previous explanation, we serve the cached response instantly without deducting from your quota.

Monitors are now organized by type instead of generic profiles:

• SMTP — mail server health: SMTP connectivity, PTR records, IP blacklists, ping
• HTTPS — web endpoint health: TLS certificate, IP blacklists, ping
• Ping — basic reachability checks
• Port — TCP port connectivity on any port (1–65535), plus ping

Each monitor uses one slot regardless of how many sub-checks it includes. Toggle individual sub-checks on or off without affecting your quota.

Monitor packs are available as add-ons for paid plans (+25 monitors for $5/mo).

Available on all 20 diagnostic tools for signed-in users. Each explanation is tailored to your specific results, not generic advice. Usage is included with your plan — quota resets monthly.