What we read, and what we did not
An earlier survey of 9,779 Pune businesses recorded which had a website and what condition it was in. It recorded no DNS at all. So this is new measurement over the same domains: 853 distinct hosts and 836 registrable domains, queried through public resolvers on 2026-09-03.
Two dates, 56 days apart, and the gap is the first thing to hold on to. The businesses and their websites were recorded on 2026-07-09. The DNS was read on 2026-09-03. Every figure here describes the state today of the domains that were on record in July. Nothing here describes what those zones looked like then.
The measurement distinguishes five outcomes rather than two, and that is not pedantry. A name that does not exist, a name that exists with no record of that type, and a query that failed are three different facts, and folding them together is how a survey like this ends up overstating whatever it set out to find. Every percentage below is computed only over the lookups that were actually answered, and the coverage travels with each figure.
| Check | Asked | Present | Absent | Present of answered | Coverage |
|---|---|---|---|---|---|
| A on the apex | 853 | 752 | 5 | 99.3% | 88.7% |
| AAAA on the apex | 853 | 183 | 572 | 24.2% | 88.5% |
| A on www | 853 | 726 | 31 | 95.9% | 88.7% |
| CNAME on www | 853 | 496 | 262 | 65.4% | 88.9% |
| MX on the registrable domain | 836 | 575 | 165 | 77.7% | 88.5% |
| SPF at the apex | 836 | 509 | 231 | 68.8% | 88.5% |
| DMARC at _dmarc | 836 | 343 | 397 | 46.4% | 88.5% |
Coverage sits near 89% throughout because 83 domains no longer resolve, and once that is established we stop asking about them rather than recording six absences each. That decision is the difference between "does not publish SPF" and "does not exist", and only one of those is a hygiene finding.
The first finding is that 83 of them are gone
83 of the 853 hosts return NXDOMAIN. The name does not exist. Fifty-six days earlier a survey recorded a working website at each of them, and the businesses behind them are, as far as anyone browsing is concerned, no longer online.
Some of those are businesses that closed. Most are more mundane than that: a domain renewal that did not happen, on a card that expired, for a business that is still trading and does not know. Nobody gets an alert for this. The site simply stops, and the owner finds out when a customer mentions it, or does not.
This is the cheapest thing on this page to check and the most expensive to miss. A domain lapse is recoverable for a short window and then it is not, and a domain somebody else registers is gone permanently along with every link and citation pointing at it.
A site can be up and down at the same time
Of the 757 hosts where both hostnames answered, 723 serve both the bare domain and the www form. 29 serve only the bare domain and 3 serve only www. That is 32 businesses whose site works or fails depending on how a visitor happens to type it.
The reason this is worth a section is that the owner almost never sees it. You type your own address the way you always type it, so you always get the working one. The broken half is only ever met by other people: somebody who copied the other form from an old business card, or a directory that stored it differently.
We are not writing this from a position of superiority. This exact defect was live on our own site until 2026-09-01. The www form returned a 404 for months while the bare domain served fine, and it was found by a crawler rather than by us, for precisely the reason above.
The larger finding is about mail
575 domains have an MX record, meaning they are configured to receive mail. 6 of those are a deliberate declaration that the domain handles none, which is a legitimate and slightly sophisticated thing to publish. That leaves 569 domains genuinely in the mail business.
- 79 of them publish no SPF record, so no receiver has been told which servers may send on their behalf.
- 254 publish no DMARC record, so no receiver has been told what to do when a message fails those checks.
- Of the 343 that do publish DMARC, only 182 set a policy that asks a receiver to act on a failure.
Put the last one plainly, because it is the finding. Out of 569 domains that accept mail, 182 have arranged for anything at all to happen when somebody forges a message from their address. Everybody else is relying on the recipient noticing.
That matters most for exactly the kind of business in this survey. An invoice that appears to come from a supplier, sent to a customer who has dealt with that supplier before, is the oldest fraud on the internet and it still works. The defence is a text record that costs nothing and takes ten minutes.
The records that exist and do nothing
A published record is not the same as a working one, and this is where the survey gets uncomfortable. 161 of the 343 DMARC records are set to the monitoring-only policy, which asks receivers to take no action whatsoever. It is the correct place to start and the wrong place to stop, and on this evidence most of the domains that started never finished.
| Policy | Domains | Share |
|---|---|---|
| p=none | 161 | 46.9% |
| p=quarantine | 106 | 30.9% |
| p=reject | 76 | 22.2% |
| Policy | Domains | Share |
|---|---|---|
| ~all | 309 | 60.7% |
| -all | 170 | 33.4% |
| redirect, no all | 12 | 2.4% |
| more than one SPF record | 12 | 2.4% |
| ?all | 3 | 0.6% |
| no all mechanism | 2 | 0.4% |
| +all | 1 | 0.2% |
The SPF split is less alarming than it looks. 309 end in a soft fail and 170 in a hard fail, and a soft fail is a defensible choice when you are not certain you have listed every sender. Two rows in that table are not defensible, though.
- 12 domains publish more than one SPF record. That is not twice the protection: the specification makes it a permanent error, and a receiver is entitled to treat the whole check as broken. These domains are worse off than the ones with no record at all, because somebody did the work and it does not run.
- 1 publishes a record whose final mechanism authorises every server on the internet to send as that domain. It is a legitimate syntax and it is an explicit statement that anybody may forge you.
The pattern across all three is the same and it is not laziness. Every one of these domains had somebody competent enough to open a DNS panel and add a record. The gap is not effort, it is that nothing tells you afterwards whether the thing you added works.
How to check your own, in about five minutes
Everything measured here is public, so you can read your own the same way. On any machine, replacing the example with your domain:
nslookup -type=A example.com # does the bare domain resolve
nslookup -type=A www.example.com # and does the www form
nslookup -type=MX example.com # do you receive mail
nslookup -type=TXT example.com # look for a line starting v=spf1
nslookup -type=TXT _dmarc.example.com- Both hostnames should answer. If one does not, that is the half of your traffic you never see.
- If MX comes back, you should have exactly one SPF record. One. Two is worse than none.
- If _dmarc returns nothing, you have no DMARC. That is the single largest gap in this survey.
- If it returns a record whose policy is the monitoring-only one, you have the report and not the protection. Moving off it is the step almost nobody takes.
- Check from a public resolver rather than your own network. A resolver on your router can answer differently, which is a mistake we made while building this.
What this does not cover
- The business list and the DNS reading are 56 days apart. The domains are those recorded on 2026-07-09; their DNS was read on 2026-09-03. A domain that changed hands, lapsed or was reconfigured in between is counted in the July cohort and measured in its September state, and nothing here describes what any zone looked like in July.
- This measures zones, not mail. We did not send anything, receive anything, or check DKIM, which cannot be surveyed from DNS alone because the selector is not discoverable. A domain with perfect SPF and DMARC can still have mail that fails in practice.
- The absence of SPF or DMARC is a fact about a zone, not a judgement about a business. Plenty of these domains send no mail at all, and for those the records are less urgent than this page's framing might suggest.
- Measured from one network through 1.1.1.1 and 8.8.8.8. A record served only to some resolvers, or a zone having a bad few minutes during the run, is reported as we saw it. 389 lookups were retried and 203 succeeded on the second resolver, which is the size of that effect.
- Resolvers cache. Two runs an hour apart would largely measure the same cache rather than any change, so this is one reading and not a trend.
- Grouping a host to its registrable domain uses a hand-maintained suffix list rather than the full public suffix list. It errs towards treating an unknown two-label suffix as registrable, which asks about a name that exists rather than one that cannot.
- These are businesses recorded in OpenStreetMap in one district of one city, and the survey inherits every limit of that: coverage varies by area and by sector, and a business that is not mapped is not here at all.
Sources
- Pune business survey, 836 registrable domains derived from 989 recorded websites. Each domain queried for A, AAAA, CNAME, MX and TXT records through the public resolvers 1.1.1.1 and 8.8.8.8, 5,951 lookups in total. Outcomes are classified into five states and every percentage is computed only over lookups that were answered, so failures and skips never enter a denominator. Business records from OpenStreetMap, licensed ODbL. Run: scripts/pune-dns.mjs, 2026-09-03 10:23 UTC.
- RFC 7208, Sender Policy Framework, including why two records is a permanent error, IETF. Retrieved 3 September 2026.
- RFC 7489, Domain-based Message Authentication, Reporting and Conformance, IETF. Retrieved 3 September 2026.
- RFC 7505, the null MX record, IETF. Retrieved 3 September 2026.
- OpenStreetMap copyright and licence, OpenStreetMap Foundation. Retrieved 23 August 2026.
Revisions
- 3 September 2026 First published.
This page is revised in place rather than replaced, so its address does not change.