标签：#dev

Working With Massive JSON Responses Without Losing Performance Every developer eventually encounters it. You make an API request expecting a few hundred objects, and instead receive a response that's tens—or even hundreds—of megabytes. Suddenly your browser freezes, your editor becomes sluggish, and your application consumes gigabytes of memory. Large JSON responses aren't unusual anymore. Analytics platforms, cloud providers, search engines, AI services, ecommerce catalogs, IoT systems, and data export endpoints routinely generate enormous payloads. The good news is that handling massive JSON efficiently is mostly about choosing the right techniques. This guide covers the best practices that help you inspect, process, and optimize large JSON datasets without overwhelming your tools or your users. Understand Why Large JSON Is Expensive Before optimizing, it's helpful to know where the cost comes from. When an application receives JSON, it usually goes through several stages: Download the response. Store it as a string. Parse it into objects. Allocate memory for every property. Traverse the resulting object graph. For a 100 MB JSON file, peak memory usage can easily exceed 300 MB because both the raw string and the parsed objects coexist temporarily. This explains why applications often run out of memory long before reaching the actual file size. Don't Pretty-Print Gigantic Responses Immediately Pretty-printing is useful—but formatting a huge document all at once can consume significant CPU time and memory. Instead: inspect only the sections you need collapse large objects expand nodes on demand search before formatting If you need to examine a large payload in the browser, using a dedicated formatter designed for large documents can make navigation much easier. Tools like JSON Formatter allow you to validate, format, collapse, and inspect JSON without manually editing thousands of lines. Stream Instead of Loading Everything One of the biggest mistakes is reading an

Debugging JWT authentication usually means copying tokens between tabs and tools. I built a free, browser-only JWT Creator & Signer — create, sign, and verify JWTs entirely in your browser using the Web Crypto API. Live Tool 👉 https://devnestio.pages.dev/jwt-creator/ What it does Create JWTs — edit header (alg, typ) and payload (any JSON) Sign with HMAC — HS256, HS384, or HS512 Quick claim buttons — insert sub , name , exp (+1h), iss with one click Generate random secrets — 256-bit hex secret via crypto.getRandomValues() Verify existing JWTs — paste any token and verify signature + expiry Color-coded output — header in red, payload in green, signature in blue 100% client-side — Web Crypto API, no server, your secrets stay local How signing works (Web Crypto API) const key = await crypto . subtle . importKey ( " raw " , new TextEncoder (). encode ( secret ), { name : " HMAC " , hash : " SHA-256 " }, false , [ " sign " ] ); const sig = await crypto . subtle . sign ( " HMAC " , key , new TextEncoder (). encode ( header + " . " + payload ) ); The output is base64url-encoded (replacing + → - , / → _ , stripping = padding) to form the final JWT. Why browser-only matters for a JWT tool JWT secrets are sensitive. Any tool that sends your signing secret to a server is a liability. This tool never sends anything — the Web Crypto API runs entirely inside your browser tab. Testing 77 tests, all passing ✅ Tests cover: Base64url encoding edge cases JWT structure (3-part dot-separated) HMAC algorithm mapping (HS256 → SHA-256 etc.) Expiry check (expired vs. valid tokens) Error states: invalid JSON payload, malformed JWT UI: claim insertion, secret toggle, copy, clear Web Crypto API usage verification All tools at devnestio.pages.dev — free browser-only developer utilities. Feedback welcome!

Opening hook It happened during a quiet afternoon at the mosque. The imam was mid-sentence when a rhythmic, high-pitched ringtone cut through the silence like a knife. Every head turned. It was my phone. My heart sank as I scrambled to silence it, only to realize I had forgotten to flip the physical toggle before walking in. That moment of collective, disappointed glares burned. It wasn't just an annoyance; it was a total breakdown of my focus and a social failure I had accidentally caused because my phone couldn't manage itself. The problem We live in an era where our devices are supposedly 'smart,' yet they are remarkably bad at knowing when to keep quiet. We carry computers in our pockets that can calculate the exact position of the moon or stream 4K video, but they cannot inherently tell that we are in a meeting, a lecture, or a place of worship. You could argue that setting a manual schedule works, but life isn't static. Meetings run over, prayer times shift by a minute each day based on astronomical calculations, and spontaneous plans happen. I found myself constantly juggling the physical volume buttons. If I remembered to mute it, I inevitably forgot to unmute it afterward, missing urgent calls from family. If I didn't mute it, I was the person disrupting the room. I wanted a solution that respected the context of my location and the specific time of day without requiring me to touch my screen. The core friction is that Android is designed to restrict background processes to save battery, which is exactly what a silent-automation app needs to thrive. Getting the app to reliably trigger a volume change while the phone is sitting in a pocket, deep in Doze mode, became my primary development hurdle. The technical decision / implementation When I started building Muffle, I initially tried a standard Service with a Handler loop to check conditions. It worked fine while the screen was on, but as soon as the phone entered Doze mode, the OS aggressively throttled my

As a final-year Software Engineering student, I wanted my Final Year Project to be more than just another CRUD application. That's how Invesmal came to life a Laravel-based platform that connects startups, investors, and mentors using AI-driven matching. The Problem Finding the right investor or mentor is hard. Startups struggle to identify investors whose interests align with their industry, while investors sift through hundreds of pitches manually. I wanted to solve this with smart, automated matching instead of a simple directory listing. What Invesmal Does Invesmal supports four user roles Student, Investor, Mentor, and Admin and includes 12 AI-driven features built on top of a Laravel backend, including: A core matching engine connecting startups with relevant investors Skills and personality analysis for founders Goal-based matching between mentors and mentees Compatibility scoring between startups and investors A funding readiness score to evaluate startup preparedness A startup health score for ongoing progress tracking A recommendation engine surfacing relevant connections Each feature is built as an independent service class connected through dedicated controllers and routes, keeping the codebase modular and easy to extend. Technical Approach The platform is built entirely on Laravel , using: Service-oriented architecture for AI features (separating business logic from controllers) Blade components for dynamic role-based dashboards Livewire for real-time, reactive UI elements without heavy JavaScript A structured chat/messaging system for communication between users One of the more interesting engineering challenges was migrating a working chat and messaging system from an older version of the project into a redesigned Laravel structure while preserving functionality and fixing layout issues (like a tricky sidebar CSS opacity bug) along the way. What I Learned Building Invesmal taught me how to: Structure a large, multi-role Laravel application without the

AI is great at writing tests fast, and good at writing tests that look real but verify the wrong...

AI is great at writing tests fast, and good at writing tests that look real but verify the wrong...

SpaceX reportedly showed investors a "handset-like" AI device before going public. It could be another signal SpaceX wants to expand into wireless.

Vendor onboarding usually starts with one clean request and then turns into a messy thread. Procurement asks for a W-9, security asks for a SOC 2 report, finance asks for remittance details, legal asks for an executed agreement, and the vendor replies with four attachments across three messages because different people own different parts of the process. That is exactly the kind of workflow where a generic "AI email assistant" gets risky. You do not want a model improvising legal language, requesting bank details in the wrong channel, or forwarding a confidential report to the wrong internal alias. You want the agent to own the repetitive coordination while your application keeps the state machine, policy, audit log, and approvals. The pattern I reach for is a dedicated Nylas Agent Account: vendors@yourcompany.com . It is a real mailbox the onboarding agent owns. It receives the vendor's replies, detects what is attached, updates your vendor record, sends safe reminders, and escalates missing or sensitive items to a human. The agent is not borrowing an employee's inbox, and it is not scraping a shared procurement mailbox. It has a grant, an email address, webhooks, threads, folders, and the same Messages API you would use for any other mailbox. I work on the Nylas CLI, so the terminal examples below use the commands I would use while building and debugging this flow. I also include the raw API calls because the production version belongs in your service, not in a shell script. What the agent should own Start by drawing the boundary tightly. A vendor onboarding agent should own message handling and coordination, not business approval. Good responsibilities: Receive vendor replies at a stable address. Read message bodies and attachment metadata. Match a reply to an existing vendor record. Detect which onboarding items are complete, missing, expired, or unreadable. Draft reminders and status updates. Schedule handoff calls when the vendor asks for help. Escalate sensit

Building an AI agent is fun. Fixing its production latency when it's juggling live data, RAG, and text-to-speech? Not so fun. In the latest episode of the AI Agent Clinic, we sat down with developer Sami Maghnaoui to debug PlaybackIQ, a football / soccer agent he built to provide pre and post match analysis with text to voice, and minute-by-minute match insights with interactive UI. The app was awesome, but under heavy "match day" data loads, the wait times were killing the UX. Here’s how we fixed it: The Bottleneck: We implemented OpenTelemetry on the Agent Platform to trace exactly where the LLM calls and data retrieval were hanging up. The Scale: We shifted the deployment to Cloud Run to properly handle concurrent traffic. The Result: We managed to slash the agent's latency by 80%. If you're dealing with sluggish LLM response times in your own apps and want to see what a production-grade fix looks like, we recorded the whole teardown and rebuild. 🎥 Watch the teardown here: [ https://youtu.be/G7olcqETSn8 ] (Let me know in the comments what your go-to stack is for tracing LLM latency!)

The problem no one was solving Every Algerian developer building with AI hits the same wall: an international payment card. OpenAI, Anthropic, Google — every major AI provider assumes you have one. Most Algerian developers don't, or don't want to deal with the friction of currency conversion, card rejections, and unpredictable billing in a foreign currency. That's not a minor inconvenience. It's a barrier that quietly excludes an entire generation of developers from building with the best AI models available — not because they lack the skill, but because of infrastructure that was never designed with them in mind. The vision: AI sovereignty, not just AI access Access alone isn't the goal. The goal is sovereignty — Algeria having its own AI infrastructure layer, controlled locally, billed locally, and built to local compliance standards, instead of depending entirely on foreign gateways with no local accountability. That's what DEVUP AI is: Algeria's first AI inference gateway, built from the ground up to remove every friction point between an Algerian developer and the AI models they need. What DEVUP AI actually does 170+ AI models — including DeepSeek V4, Llama 3.1 405B, Qwen 3, Gemma 2, Mistral, GPT, Claude, and Gemini — through a single API OpenAI-compatible and Anthropic-compatible — point your existing SDK at our endpoint, no code rewrite needed Local DZD billing via Edahabia/CIB — no international card required SATIM-certified payment infrastructure — full compliance with Algeria's national payment standards Scoped JWT authentication for production-grade security A dedicated SDK ( npm install devupai ) and full documentation, so integration takes minutes, not days The technical bar was non-negotiable: this had to be production-grade from day one, not a side project. SATIM certification alone meant building proper transaction validation, receipt generation, chargeback tracking, and rejection-rate monitoring — the same rigor a bank would expect from a payment pr

Every data grid demo looks incredible with twenty rows. The columns line up. The hover state is tasteful. The checkbox has confidence. Someone scrolls three inches and everyone quietly agrees that software has advanced. Then the real product arrives. Fifty thousand rows. Twenty columns. Editable money. A custom status cell. Filters. Sorting. Horizontal scrolling. A user who pastes something suspicious from Excel. A product manager asking whether the total row can stay pinned while the server is slow. That is when a table stops being a table and starts becoming infrastructure. So we built a benchmark. Not a perfect benchmark. Those do not exist. A useful one. What we measured The fixture is intentionally boring: 50,000 deterministic rows 20 fixed-width columns 1,200 by 600 pixel viewport two editable columns sorting filtering virtual scrolling production bundles fresh browser contexts raw samples committed to GitHub No network requests. No paid-only feature tricks. No images. No grouping. No heroic demo code designed to make one library look blessed by destiny. The report measures: JS gzip : reachable JavaScript after gzip Ready median : navigation until the grid adapter mounts and two animation frames pass Scroll settle : one scripted vertical and horizontal jump plus animation frames Mounted cells : body cells in the DOM after the scroll Interaction health : heap, long tasks, estimated FPS, dropped frames Live benchmark: https://vitashev.github.io/react-data-grid-benchmark/ Source and raw samples: https://github.com/Vitashev/react-data-grid-benchmark The part most benchmarks get wrong Not every grid exposes the same surface. For example, MUI X Data Grid Community uses 100-row pagination for this workload. That is a valid product boundary, but it is not the same as continuously virtualizing 50,000 rows. So the ranked tables include only compatible continuous-scroll libraries. MUI remains in the fixture and raw data, but not in the leaderboard. That makes the benchma

A note before we start: this is about the machine, not the money. I'm not going to show you returns, positions, or a single "this strategy made X%." Partly because that's a regulatory minefield, and partly because the returns aren't the interesting part — the engineering is. If you came for a get-rich screenshot, this isn't that. If you came to see how one person ships production infrastructure with an AI, pull up a chair. The thing I built Over the last few months I built, with an AI coding agent as my pair-programmer, a fleet of ~35 automated trading bots. They run across five equity markets plus crypto. Each one is a long-running service. They share a single database, post to a live dashboard, fire alerts to my phone, and — the part that took the longest — they're built to survive restarts, reconcile against reality, and refuse to do anything stupid. I'm one person. I am not a team. The "team" is me plus an AI in a terminal, working the way you'd work with a very fast, very literal junior engineer who never gets tired and occasionally needs to be talked out of a bad idea. Here's how it's put together, and the handful of lessons that cost me the most to learn. The architecture, in one breath One Postgres database is the brain — every trade, signal, and piece of state lives there. Around it sit ~35 containerized bots, each isolated (its own tables, its own config, its own identity), orchestrated with Docker Compose. A Streamlit dashboard reads the database and renders the whole fleet — open positions, P&L curves, health. A notification layer pushes Telegram alerts on every meaningful event. Schema changes go through migrations so a new bot is never born with a stale database shape. Each bot is the same skeleton wearing a different hat: a signal module (the strategy logic), a trader that turns signals into orders, a storage layer that persists everything, a runner loop on a schedule. Strategies are swappable. The infra underneath them is identical. That sameness is

We started using Jira to manage our internal development workflow. At first it worked fine, but once we outgrew the free tier, the cost became hard to justify. At $15 per user per month, we were suddenly looking at a bill that did not match how we actually used the product. What we Built We created WannaTrack, a lightweight project management tool designed for small dev teams that do not need enterprise complexity. The goal was not to recreate Jira. It was to remove everything we did not use. Key ideas : minimal agile board with no clutter or heavy configuration simple issue tracking flow fast interface for daily development work minimal setup and no onboarding overhead Migration from Jira One of the biggest concerns was switching tools without breaking our workflow. So we built a Jira import tool that lets you migrate existing tickets into WannaTrack without manual effort. This allowed us to switch internally without downtime. Where it is now We now use WannaTrack daily for our own development workflow and are opening it up to other teams who feel the same pain with traditional tools. If you are a small dev team, indie hacker, or startup looking for a simpler issue tracker without overhead, you can check it out here: https://wannatrack.com

Key Takeaways You can't unit-test a coach agent the way you test a pure function — the output is non-deterministic and "good" is a judgment call, not an assertion. An LLM-as-judge harness lets you grade a whole test set automatically against a rubric, which is the only way solo-scale eval stays sustainable. But the judge is itself a fallible model. If you don't design around its known biases — position, verbosity, self-preference, and quiet drift when the judge model updates — you build a green dashboard that means nothing. The mitigations that actually work are mechanical, not prompt-magic: shuffle order on every pairwise call, pin the judge version, keep a small human-labelled anchor set, and re-check the judge against it. The problem I actually had FamNest's coach agent generates responses to parents — check-ins, encouragement, the occasional gentle redirect. I have a growing pile of these interactions, and every time I change a prompt, swap a model, or adjust the pipeline, I need to know one thing: did I just make it better or worse? For normal code, that's what tests are for. I change something, the suite runs, red or green, done. But there's no assertEqual for "was this an empathetic, useful response to a tired parent." The output changes every run even at temperature zero-ish, and the quality bar is a human judgment, not a fixed string. Two responses can be worded completely differently and both be good. One can match my "expected output" word for word and still be worse than a version that didn't. So the honest options were: read every response by hand every time I change something (does not scale past about week two), or build a harness where a model grades the outputs against a rubric. I built the harness. Then I spent an uncomfortable amount of time learning all the ways a harness like that can lie to you. What the harness actually is At its simplest, it's a loop: def evaluate ( test_cases , coach_agent , judge ): results = [] for case in test_cases : res

A few weeks ago I was in Copenhagen for my first Codegarden, and one quiet thought has stuck with me since. It didn't come from a keynote. It came from the bit the keynote leaves out. I've worked with Umbraco for years, but I'd never been to Codegarden, and I turned up without much of a fixed idea of what the two days would be. I kept that open on purpose. I wanted to take it in rather than measure it against something I'd decided in advance. What struck me most was that the value came from two places at once. The sessions were a fantastic source of inspiration; everything from keynotes to guest speakers all seemed to resonate in some way or another. The conversations in between the sessions - drifting around the event space and finding common ground with anyone and everyone - proved just as valuable. I came home more energised than I've been in a while, with a notebook full of half-formed ideas and a better feel for the community I'm part of. But the thing I kept turning over afterwards was that bit the keynote leaves out. That's what I want to write about. The easy half and the hard half Every major Umbraco release gets the same treatment. A polished keynote, a clean demo, a feature that looks effortless on stage. There's plenty in 18, and which part matters most depends on what you're building. For me it's Elements: a new Library section where you manage reusable content and reference it through a new element picker. Create once, use everywhere. It's a genuinely good direction. Reusable content has lived awkwardly in the content tree for years, and Library finally gives it a proper home. What the demos don't show you is the part I've been playing around with for the past few weeks. Taking a real Umbraco 17 site, with content pickers threaded through block lists, block grids, rich text blocks and base document properties, and getting all of it to point at the new Library without an editor ever noticing anything moved underneath them. The feature is the easy half.

Exam Guide: Developer - Associate 🏗️ Domain 3: Deployment 📘 Task 1: Prepare Application Artifacts To Be Deployed To AWS Before you can deploy anything to AWS, you need to package it properly. This task covers Lambda deployment packaging (zip vs container), managing dependencies, structuring projects for multi-environment deployment, and using AWS AppConfig for runtime configuration. 📘Concepts Lambda Deployment Packaging Options Option Max Size Build Complexity Cold Start Best For Zip Package (inline editor) 3 MB (editor limit) None Fastest Simple functions, no dependencies Zip Package (upload) 50 MB compressed / 250 MB uncompressed Low Fast Most Lambda functions Zip + Lambda Layers 250 MB total (function + all layers) Medium Fast Shared dependencies across functions Container Image 10 GB Higher Slower (first invoke) ML libraries, large dependencies, custom runtimes 💡 If a scenario is about a deployment package exceeding 250 MB, the answer is container images. If it mentions sharing dependencies across multiple functions, the answer is Lambda Layers. Zip is the default for most workloads. Lambda Layers Aspect Detail What They Are Zip archives containing libraries, custom runtimes, or other dependencies Max Layers Per Function 5 Size Limit 250 MB total (function code + all layers uncompressed) Versioning Each publish creates an immutable version Sharing Can be shared across functions, accounts, or made public Path Contents extracted to /opt in the execution environment Dependency Management Strategies Strategy How It Works Pros Cons Bundle In Zip Install deps into package directory, zip together Simple, self-contained Larger package, duplicated across functions Lambda Layers Package deps as a layer, attach to functions Shared across functions, smaller deploys Layer version management, 5-layer limit Container Image Install deps in Dockerfile Full control, large deps supported Slower cold starts, ECR management sam build SAM resolves deps from requirements.txt automatic

For years I copied cron expressions off Stack Overflow, pasted them into a config file, crossed my fingers, and moved on. 0 9 * * 1-5 ? Sure, that "looks like weekday morning." */15 * * * * ? "Every 15 minutes, probably." I never actually read them. So I did the thing that always cures this for me: I built a tool that parses a cron expression, explains it in plain English, and shows the next five times it will fire. No library. About 50 lines of real logic. Here's everything I learned. The five fields (and the order that trips everyone up) A standard cron expression is exactly five fields separated by spaces: ┌──────── minute 0 - 59 │ ┌────── hour 0 - 23 │ │ ┌──── day - of - month 1 - 31 │ │ │ ┌── month 1 - 12 │ │ │ │ ┌ day - of - week 0 - 6 ( 0 = Sunday ) * * * * * The order never changes, and the number-one beginner mistake is swapping the first two. Minute comes first. If you write 9 30 * * * thinking "9:30am," you actually get "minute 9, hour 30" — which is invalid, because hours only go to 23. Say it out loud every time: minute, hour, day-of-month, month, day-of-week. Each field answers one question: which values of this unit does the job run on? An * means "every value." Most real schedules pin down a couple of fields and leave the rest as * . Daily at 9am is 0 9 * * * — minute and hour fixed, everything else "every." Lists, ranges, and steps Beyond single numbers, each field understands three operators, and they combine: Comma makes a list: 1,15 in the day field means the 1st and the 15th. Hyphen makes an inclusive range: 1-5 in the day-of-week field means Monday through Friday. Slash makes a step, taking every n-th value: */15 in the minute field means 0, 15, 30, 45 . Steps can apply to a range too, so 0-30/10 means 0, 10, 20, 30 . That's the whole grammar. Number, list, range, step. Once you can expand a field into the concrete set of numbers it matches, you understand cron. Here's the expansion function, which is the heart of the parser: function expandFie

Claude Code is mostly prose. Tool output, reasoning traces, permission prompts — I read paragraphs of this for hours every day. Most terminal themes are built around syntax highlighting: make keywords pop, dim punctuation, saturate strings. That's optimizing for the wrong thing when your screen is 80% English sentences. I built klein-blue to fix this for my own setup. Four variations, all built around Yves Klein's IKB pigment, all APCA-verified for body-size prose legibility in the specific ANSI slots Claude Code actually uses. The interesting constraint: pure IKB fails APCA contrast as text on a dark ground (Lc -12 — effectively invisible). So I split it across two ANSI slots. ansi:blue gets pure IKB for decorative borders and highlights where legibility doesn't matter. ansi:blueBright gets a lifted Klein-family value (A8BEF0) for readable permission-prompt text. You keep the color identity; you can actually read it. The four variations each answer the same question differently: how should Claude's brand colors live in your terminal? Claude Code uses ansi:redBright for its claude-sand brand color. That's the differentiating moment between the themes: Klein Void Refined — balanced, neutralizes brand competition Klein Void Sand & Sea — accepts claude-sand as a second hero alongside IKB Klein Void Prot — fully APCA-verified across every role (body >= 90, subtle >= 75, muted >= 45, accent >= 60); the only variation where every accent passes strict gates Klein Void Gallery — one-blue maximum void, everything else recedes One prerequisite that took me a while to document clearly: Claude Code's /theme picker must be set to dark-ansi , otherwise Claude Code ignores the Terminal.app ANSI palette entirely and falls back to its hardcoded RGB values. The theme does nothing without that. Ships as macOS Terminal.app .terminal profile files. Built from build.m with a variation-aware Objective-C builder, installed via install.sh , fully rollback-able via restore.sh . CommitMono-Re

Modern Angular Guards: Architecture, Best Practices & Enterprise Patterns A deep dive into designing lightweight, composable, and maintainable routing guards in modern Angular applications. Table of Contents Introduction Why Guards Exist The Golden Rule of Angular Guards Functional Guards: The Modern Standard CanActivateFn: Authentication Guard CanMatchFn: Permission-Based Route Matching CanDeactivateFn: Unsaved Changes Guard CanActivateChildFn: Nested Route Protection Signals + Guards: Reactive Permission State Feature Flags in Routing Guard Composition Patterns UrlTree Redirects vs Imperative Navigation Async Guards: When and How Permission Service Architecture Role-Based Access Control (RBAC) Permission-Based Access Control (PBAC) Route Data for Configuration Lazy Loading with Guards Standalone Routing with provideRouter Route-Level Providers Guards vs Interceptors Guards vs Backend Authorization Performance Considerations Navigation UX Best Practices Error Handling in Guards Testing Guards Common Mistakes Production Checklist Enterprise Routing Insights Conclusion Introduction In modern Angular applications, routing guards have evolved from class-based monoliths into lightweight, composable functions. This shift isn't just syntactic—it's architectural. As Angular applications become larger and more complex, the routing layer becomes a critical piece of the architecture. Guards are the gatekeepers of your navigation, but they should never become the orchestrators of your application logic. This article is for senior Angular developers, software architects, and team leads who are designing routing strategies for enterprise-scale applications. We won't explain what a route guard is—we'll explore how to architect them properly. Why Guards Exist Guards exist to protect navigation boundaries. They evaluate whether a transition should proceed, redirect, or be blocked. In modern Angular, this is achieved through functional guards that return: boolean — allow or block na

By the team at MailTester Ninja — a real-time email verification API that stores nothing. We verify a lot of email for a living. So we pointed our infrastructure at a representative panel of 50,000 of the world's most-linked domains and measured how email is actually configured in 2026 — MX providers, SPF and DMARC. Pure DNS, aggregate only, no personal data . Here's what the internet's mail setup looks like right now. Email is still (almost) everywhere 79.9% of these domains are mail-enabled (they publish MX records). Email isn't going anywhere. Authentication: adopted, but not enforced 75.8% publish an SPF record 64% publish a DMARC record …but only 22.6% actually enforce it with p=reject That last number is the real story. Of the domains that bother to publish DMARC, only 35.2% are on p=reject — the rest sit on p=none (37.2%, monitoring only) or quarantine (27.6%). Most of the web announces a policy it doesn't enforce. That's a deliverability and spoofing gap hiding in plain sight. Who runs the world's inboxes? Other / self-hosted — 32.6% Google Workspace / Gmail — 28.2% Microsoft 365 / Outlook — 22.5% Proofpoint — 5.5% Mimecast — 3.1% Tencent QQ — 2% Namecheap — 1.3% Cisco IronPort — 0.9% Self-hosted and the two hyperscalers (Google Workspace and Microsoft 365) dominate, but the long tail of providers is very real — which is exactly why deliverability is hard: every provider blocks, greylists and reputation-scores differently. Why we publish this We built an open, daily-updated dataset and a live dashboard because deliverability decisions should be based on data, not folklore. It's CC BY 4.0 — use it, cite it, build on it. Want to check a specific domain? Our free analyzer shows any domain's MX / SPF / DMARC in one click — no signup, nothing stored. Methodology: Live DNS scan (MX/SPF/DMARC). Aggregate only — no email sent, no personal data. Sample updated Wed, 01 Jul 2026 12:31:00 GMT.