Privacy Policy

1. What XGM is

XGM is a public utility and guide platform for DNS lookup, domain health, SSL/TLS checks, HTTP headers, redirects, developer utilities and related technical workflows. The platform is designed to be useful without unnecessary data collection.

2. Tools that run in your browser

Developer, text, converter and builder tools such as JSON Tools, Code Formatter, Encoder / Decoder, JWT Decoder, Regex Tester, Hash Generator, Password Generator, Record Builders and the Email Header Analyzer process your input only in your browser. That input is not sent to XGM, not stored and not added to the URL; only the selected mode (for example ?mode=base64) is. One exception you trigger yourself: “Check nested lookups” in the SPF builder resolves the include domains you listed through the XGM DNS API.

3. Who is contacted when a server tool runs

Server-backed checks are run by the XGM server, which contacts the systems needed to answer: DNS resolvers and the name servers of the domain you check (DNS Lookup also sends the checked name and record type to the public resolvers of Cloudflare, Google, Quad9, OpenDNS, AdGuard, Level3 and Yandex to compare their answers); the website, mail servers or ports of the host you check (MX & SMTP opens an SMTP session on port 25 with each of the domain's mail servers, reads the greeting, starts TLS and tests relaying with example addresses without sending a message; Email Security fetches the MTA-STS policy from mta-sts.<domain>); the IANA RDAP bootstrap list and the registry RDAP server, or the registry WHOIS server, for WHOIS lookups; the regional internet registries ARIN, RIPE NCC, APNIC, LACNIC and AFRINIC, which receive the IP address when you look one up in WHOIS or in IP Intelligence, where the allocation (prefix, registry, allocation date) and the abuse contact are read over RDAP, and which receive your own address if you press “Show my IP”; hstspreload.org, which receives the host name checked by the TLS Checker to look up its HSTS preload status; crt.sh, which receives the domain name when the Subdomain Takeover Scan asks the public certificate transparency logs which subdomains have ever had a certificate, and the hosting providers a dangling CNAME points at, which receive one ordinary request from the XGM server so their own “no such site” answer can be recognised; 77 DNS blocklists, which receive the checked IP address (an IPv6 address reaches only the 27 lists that publish an IPv6 zone) and, for a domain, the domain name and its A and MX addresses, in their DNS query: Spamhaus, SpamCop, Barracuda, PSBL, UCEPROTECT, Mailspike, SpamRATS, JustSpam, blocklist.de, DroneBL, 0spam, NordSpam, Backscatterer, GBUdb, InterServer, Fabel, Anonmails, Suomispam, dan.me.uk, s5h.net, SPFBL, ZapBL, Validity, VirusFree.cz, abuse.ro, BlockedServers, Nosolicitado, JIPPG, SpamEatingMonkey, Kempt.net, TTK PTE, SWINOG, SURBL, URIBL, RFC-Clueless and ScientificSpam; and ipwho.is, which receives the IP address for IP lookup, ASN and reputation context, the scanned address for the Port Scanner result header, and the addresses of the public routers on a traceroute path (private and reserved addresses are not sent; ping and traceroute also ask it once about the XGM server's own address, to print where the probe sits). Map tiles for the IP map are fetched by the XGM server from CARTO, so your browser does not contact the tile provider. The public API and the MCP server work the same way.

4. The one tool that receives a message

Email Delivery Test is the single place on XGM that receives your data instead of reading public records, and it is built to hold as little of it as possible. It hands you a throwaway address at check.xgm.ro; when you send a message to that address it is delivered to Brevo, the mail provider whose inbound service receives mail for that subdomain, and Brevo passes the parsed message to the XGM API. Brevo therefore sees the message as any mail provider would, under its own privacy terms; XGM keeps only what is described here. The headers and the subject are stored so the page can show them to you, and they are deleted one hour after the message arrives. The body is discarded the moment the message is received and is never written to disk. The address itself stops accepting mail 30 minutes after it is issued, and nothing links it to you - there is no account, and the page holds the token that reads it. Because the address is public as soon as it exists, do not send anything to it that you would not put on a postcard, and do not use it as a mailbox: there is no inbox, nothing can be forwarded or replied to, and everything is gone within the hour.

5. Watches: telling you when something changes

A result can be watched: XGM re-runs that one check about once a day and tells you when something changes - a TLS certificate with fewer than 14 days left, the target appearing on or leaving a blocklist, an SPF or DMARC record changing, or a grade dropping. Nothing else counts as a change, and a check that fails is recorded as “could not check” rather than reported as one. There is no account and no e-mail: you either give a webhook URL of your own, or you take the RSS feed address XGM returns, which carries a key of its own so nobody can enumerate other people's feeds. What is stored is the target, which tool is watching it, the webhook URL if you gave one, the last result and the changes seen so far - no e-mail address, no name and nothing that identifies you. A watch expires 90 days after it is created and is deleted with it; you can delete it yourself at any time with the token you were shown when you created it, which is not recoverable and which nobody at XGM has. A webhook URL is a request XGM makes on your behalf, so it goes through the same checks as every other outbound request: private and internal addresses are refused, and a webhook that keeps failing is given up on rather than retried for ever.

6. Server tool inputs and snapshot links

Server-backed tools send the minimum required input, such as a domain, host name or IP address, to the XGM API so the result can be generated; the input is not saved with the result. If you create a snapshot link for a result, XGM stores the tool name, the domain or IP you checked, the verdict and the finding titles until the link expires (24 hours, 7, 30 or 90 days, as you choose); anyone with the link can view it. Share links created from the former report pages (before September 2026) stored the report text, including the checked domain and its findings, for 24 hours; the Full report tab uses snapshot links instead. A PDF export of a report runs the report again on the server and returns the file without storing the report or the PDF.

7. Analytics and service signals

Only after you choose Accept all, XGM records first-party page view and tool usage events (page path, tool name, timestamp) and loads Google Analytics. With Essential only, none of these are sent. Stored IP addresses in analytics are replaced by a keyed one-way hash. Visitor analytics are retained for up to 30 days and tool usage events for up to 90 days. The domain or IP you check is not part of these events.

8. Contact and feedback data

If you submit a contact form or feedback note, XGM may store the information needed to review and respond to that message, including name, email, message text, selected context, page path and timestamp. The contact form needs JavaScript, so nothing you type is sent, or added to a URL, when JavaScript is off. The Support page has no form and sends nothing to XGM. Support claims submitted on earlier versions of that page (display name, optional email, amount, channel, transaction reference and message) stay with administrators and are handled like contact records.

9. No accounts; saved reports stay in your browser

XGM does not offer accounts: every tool and report runs without one. Reports you choose to save are kept in your browser's local storage (xgm.history.v1; at most 20, with the full report data) and are listed, exported or deleted on the History page. XGM has no copy. Accounts created before September 2026 are no longer used; their saved data remains on the server until deleted, and you can ask for deletion through the contact page.

10. Cookies, local storage and preferences

XGM uses local storage in your browser for your consent choice (xgm_cookie_consent_v2), your theme (xgm.theme.v1) and similar interface preferences. Recent checks of server-backed tools (tool, domain or IP, verdict and time; at most 20 entries) are kept in your browser's local storage so you can rerun them, and can be removed with Clear history or on the History page; inputs of browser-only tools are never stored. A service worker caches the site's own files, including the pages of tools you open (the page itself, without the query string that may hold a domain or IP), so browser-based tools work offline; it does not cache API responses. These are used to improve the experience rather than to build sensitive profiles.

Branded PDF keeps the organisation name and logo you enter in local storage (xgm.brand.v1) so the next cover uses them; clear the name and remove the logo to delete them. They are never sent to XGM.

11. Advertising and external providers

Google Analytics may process limited technical and usage data only after analytics consent. XGM configures the integration without Google signals or advertising-personalization signals. The Support on Revolut button opens Revolut (revolut.me) in a new tab; if you pay, Revolut processes that payment under its own privacy policy. The QR code on the Support page is drawn in your browser and loads nothing from another service. Other advertising or infrastructure providers may process data according to their own policies when those integrations are enabled.

12. Security logs and abuse prevention

XGM may keep server, API and admin logs for security, rate limiting, debugging, backups, restore checks and abuse prevention. Web server logs can contain your IP address, the requested path (including a checked domain in API paths) and your browser's User-Agent. Rate limits hold your IP address in memory for a few minutes. To stop spam, the contact form keeps a one-way hash of each submitted message for duplicate detection, and a keyed hash of your IP address (never the address itself) when a submission is blocked. These records are access-restricted and retained only while operationally necessary.

13. Contact, feedback and support records

Contact messages, feedback and support records remain available to administrators until they are reviewed or deleted. Submit only the information needed for the request.

14. Data you should not submit

Do not submit passwords, private keys, API tokens, confidential documents, sensitive personal information or internal-only systems into public XGM tools or forms.

15. Deletion and privacy requests

Saved reports and recent checks can be deleted on the History page, or by clearing this site's data in your browser. To delete a former account or for another privacy request, contact XGM through the contact page so linked records can be reviewed and removed safely.

16. Changes

This policy may be updated when XGM changes its storage, analytics or external provider behavior.