Google Play Audit

Google Play requires a support email on every listing. All 225 listings sampled in July 2026 had one. Nobody ever checks them again.

This Actor does.

• Support addresses that bounce. The domain does not resolve, or resolves and publishes no MX. Either way, mail to the address the store shows your users goes nowhere.
• Support domains nobody has registered. The severe case. Anyone can register the domain and start receiving the app's official support address — which is where password resets and account recovery are sent.
• Developer websites that lead nowhere, and the registrations behind them.
• Apps left behind, with the base rate attached so the number means something.

The finding this exists for

com.succocloud.tipcalculator — a live app, last updated February 2026 — publishes admin@succocloud.com on its Play listing. That domain is not registered. Not lapsed, not parked: free.

com.communitycompass, run by a food-assistance non-profit and updated the day before this was written, publishes an address on indyhunger.com. Also unregistered.

Neither is unusual enough to be a coincidence and neither is common enough to be noise: of 108 developer-owned mail domains in the sample, 3 (2.8%) could not receive mail.

What comes out

One row per app: the listing metadata, what each check found, a list of issues with severities, and an overall riskLevel of critical / high / medium / low / ok.

Record	Contents
SUMMARY	Counts by severity, how many apps carried each finding, the base rates, and every caveat that applies to this run
ACTION_LIST	Findings ranked by severity, then by how many people rated the app
CONTACT_REPORT	Three lists, kept apart on purpose: addresses anyone could take, addresses that merely bounce, and dead developer sites

Input

{
  "apps": [
    "com.succocloud.tipcalculator",
    "https://play.google.com/store/apps/details?id=com.whatsapp"
  ],
  "searchTerms": ["flashlight"],
  "staleAfterDays": 1095
}

Package ids, Play store URLs, or search terms to survey a category.

What it will not do

It does not read Data safety pages. Those live under /store/apps/datasafety, which play.google.com/robots.txt disallows. robots.txt is re-read at the start of every run, and if Play ever disallows the listing path the run stops rather than continuing.

It does not contact a mail server. No SMTP connection, no address verification, no probing whether a mailbox exists. Only whether the domain is capable of receiving mail at all — which is a DNS question and answers the one that matters.

It does not pretend to be a browser. Some developer sites, whatsapp.com among them, answer an automated request with 403. That is a live server declining to talk to a program, and it is reported as developer_site_blocked, severity low — "the server is up and refused an automated request; that says nothing about whether a person clicking through from Play reaches a page."

It does not tell you why. Play answers the same way for an app that was removed, one that was never published, and one restricted to other countries.

Severities, and why they sit where they do

Measured on 225 live Play listings, July 2026:

• 100% published a support email. So a listing with none is reported as a probable change in the page, at low — not as an app without support.
• About half those addresses were free webmail. The developer does not run that mail server, so those are never flagged.
• 87% published a developer site. The other 13% are not a finding; Play does not require one.
• 2.7% had gone three years without an update.

A warning that fires on healthy input erases the ok rows, which is the only thing that makes the other rows worth reading.

Finding	Severity
app_not_found	critical
support_email_domain_unregistered — the address is free to take	critical
developer_site_domain_unregistered	critical
support_email_undeliverable — no MX, or the domain does not resolve	high
developer_site_dead	high
developer_site_domain_reregistered	high
no_update_in_years, developer_site_offsite, developer_site_error, developer_site_server_error, developer_site_invalid	medium
support_email_not_found, support_email_check_failed, developer_site_blocked, developer_site_insecure, update_date_unreadable, listing_not_read	low

A domain whose registration could not be read is unknown, never ok.

Cost and courtesy

One request per listing with a deliberate pause between them, one DNS check per distinct mail domain (a developer with forty apps has one domain, not forty), one probe per distinct developer URL, and a registry lookup only where it changes a verdict. RDAP runs two at a time because registries operate those servers as a public service.

Verification

33 unit tests and 21 live checks against the real store, real DNS and real registries. Every true positive in the live file has a negative control beside it.