Privacy policy

• No account, no sign-up, no cookies, no advertising, no tracking pixels, no third-party trackers.
• We count, on our own server, which tools are used and by what kind of program, and which pages are visited. The counters keep the name you check but never your IP address, and they are deleted after 395 days (see cookies, counters and third parties).
• Your browser loads nothing from other companies: every script, style and image comes from this site.
• When you run a check, the name you check and a counter tied to your IP address are held in the site's memory for minutes, then forgotten there; the counters above keep the name, not your IP address. Our DNS resolver may keep the DNS answers for that name for up to a day, without knowing who asked. The web server's access log also records the page address, which includes the name, for 14 days, with the IP address that connected to us: normally a Cloudflare server's, because every visit passes through Cloudflare (see who else handles data). The blacklist checker and the email domain check ask public blocklists, run by other organizations, about the address or domain you check. The DNS propagation checker also sends the name you check to 9 public DNS services run by other companies. Check results are not written to a database; the usage log keeps only the name and the verdict.
• If you use the deliverability test, the message you send to our test addresses and its report are kept in our database for 7 days, then deleted. Copies also reach our Google Workspace and Microsoft 365 mailboxes and are deleted from them within 14 days (see below).
• DMARC report files you open in the analyzer are read by your browser and never sent to us.
• Email headers you paste or open in the email header analyzer are read by your browser and never sent to us. Its result links to our other checks; if you open one of those links, only that address or domain is sent, as an ordinary check.
• We never send email to the domains or addresses you check.

A check runs on our server. Your browser sends it the name you entered (for example example.com) as part of the page address or of a request to our API. The server then asks DNS resolvers about that name, and some tools also fetch files over HTTPS from the addresses the domain's records name (the MTA-STS policy, the BIMI logo and its certificate, which can be on another company's server, such as a certificate authority's) or greet its mail servers (see the methodology). Those servers see requests from our server, not from you.

If you enter a whole email address, the check uses only the part after the @. With JavaScript on, your browser removes the rest before sending, so it never reaches us. With JavaScript off, your browser sends the whole address as part of the page address: Cloudflare sees it, and our access log keeps it for 14 days.

Our code uses your IP address for one thing: counting your checks so that nobody can use the tools to flood our server or someone else's servers. For IPv6 we count per /64 network, not per single address, and also per /56 network (the larger block that contains it), with 4 times the limit. The visit counter (see “Cookies, counters and third parties”) is separate software on our server that also reads it, for each page view, for a moment. The web server's access log records the IP address that connected to us, to find faults and stop abuse: for a normal visit that is the address of a Cloudflare server, not yours (see the table below).

AI assistants can run the same checks through our MCP server at https://mxverdict.com/mcp. There the assistant sends us the name to check in the body of a request to that address. If the assistant runs in its provider's cloud, the request comes from the provider's server, not from your device. Everything on this page applies to these checks in the same way: the same result in memory for the same minutes, and the same counters, tied to the IP address the request came from (for an assistant in the cloud, its provider's server, shared with its other users). The access log records the address /mcp, not the name, which is in the request body, and the log does not keep request bodies. Each call is noted in the usage log (the tool, the name checked, the outcome and the verdict, the time, and the name the assistant announces for itself or its User-Agent). The report link in the answer carries the tags utm_source=mcp and utm_medium= with that name, so that opening it can be counted as a visit that came from an assistant. What the assistant and its provider keep of your conversation is up to their own policies.

The SPF, DMARC and BIMI record generators build the record in your browser while JavaScript is on, and then send nothing to us. With JavaScript off, pressing the button sends the form to our server once: the server builds the record from your fields and sends the page back. It does not store the fields; the access log below records only the page address (such as /spf-generator), not what you typed. The DKIM generator creates keys only in your browser and has no such fallback. One exception: the SPF generator shows a Count lookups now button for includes we have not measured. Pressing it sends only those include names to our SPF checker, one check per name, and nothing else you typed; each check is counted and kept like any other check on this site.

The first five rows live only in the memory of our server processes, and a restart erases them. The access log and the mail server log are kept on the server and deleted after 14 days. The usage log and the visit counter are kept on the server and deleted after 395 days. The deliverability test itself is in our database, deleted after 7 days; its copies in our Gmail and Microsoft mailboxes are deleted within 14 days.

Stored check results contain no information about you: not your IP address, not your browser. The site's own code keeps no log of requests, apart from the usage log in the table, which holds the names checked but not your IP address. If the server hits an unexpected error, the error message is printed to the server console, and it can include the name that was being checked. These console messages are deleted after 14 days, like the access log. When the web server hits an error with a request, for example while the site restarts or when a request is too large, it writes a line to its error log with the time, the IP address that connected to us, the address requested and the page you came from; that log is also deleted after 14 days.

Like every resolver, our DNS resolver, which runs on the same server, keeps the DNS answers it receives in its memory for as long as each record's time-to-live allows; ours keeps them at most one day. It does not know which visitor asked and keeps no log of the names it looks up.

When you press Start test, your browser asks our server for a new test; it sends nothing you typed. Our server counts the tests started from your IP address (in memory, as in the table above) and gives you two addresses. The test is yours to use: you send one message to those addresses from your own mail system.

Our mail server keeps that message exactly as it arrived, with the facts of its delivery: the address it was sent to and the return address, the sending server's IP address and the name it greeted us with, and the encryption used. If you send from a server of your own, that IP address can be yours. We analyze the message on our own server. The spam filter (rspamd) runs there too, with every feature that would send the message's text, or fingerprints of it, to other services turned off, so the spam check sends nothing of the message's text to anyone else. rspamd does download its own reference lists (for example, lists of free email providers) from rspamd.com; that tells rspamd.com our server's address, nothing about your message. Two kinds of DNS questions do carry names from your message. To check SPF, DKIM, DMARC and the sending server's name, our server looks up the DNS records of the domains the message names, so the DNS servers of those domains see these lookups. To check blocklists, our server asks the blocklist operators about the sending server's IP address and the domain names in the message (its From, return address, signatures and up to a few link domains), the same way it does for our other checks. We never open the links in your message, never answer it and never forward it.

Our mail server also writes a line to its log for each connection: the time, the sending server's IP address, the test it was for, the size of the message with a fingerprint of it, and the encryption used, but never an address, a subject or the text. That log is deleted after 14 days.

The message, the facts of its delivery and the report are kept in our database for 7 days from the start of the test and then deleted; our cleanup runs every 15 minutes, and the report is no longer shown once its time is up. They are left out of our nightly database backups. The report is at a link with a random, unguessable part: anyone you give the link to can see it, nobody else can find it, and search engines are asked not to index it.

The Gmail address belongs to our own Google Workspace mailbox. Your mail system delivers a copy there, and Google stores it for us as our service provider. Our server reads that mailbox with read-only access and looks only at where the copy was filed and a few of its headers: the addresses it was delivered and sent to, its date and ID, and the sender checks (SPF, DKIM, DMARC) recorded in it. That access cannot delete anything, so we delete test copies by hand once a week, from every folder, Spam and Trash included: each copy is removed from our mailbox within 14 days of your test. After we delete it, Google can still restore it for us for up to 55 days, and its terms with us then give it up to 180 days to erase it from all its systems. If you want your copy deleted sooner, write to support@mxverdict.com with the link to your test.

The Microsoft address belongs to our own Microsoft 365 mailbox. Your mail system delivers a copy there, and Microsoft stores it for us as our service provider. Our server reads that one mailbox with read-only access and looks only at where the copy was filed (the folder, and Focused or Other in the inbox) and a few of its headers: the addresses it was sent to, its date and ID, and the checks Microsoft recorded in it (SPF, DKIM, DMARC and its spam filter's report). That access cannot delete anything, so we delete test copies by hand once a week, Junk Email included: each copy is removed from our mailbox within 14 days of your test. After we delete it, Microsoft keeps it recoverable for us for 14 days. If you want your copy deleted sooner, write to support@mxverdict.com with the link to your test.

The DMARC report analyzer reads the file you choose inside your browser. The file, its contents and its name are never sent to our server or anywhere else. When you open a file, your browser may download the analyzer's program code from this site; that request contains nothing from your file. The JSON download on that page is created in your browser as well.

The email header analyzer reads the header you paste, or the .eml or .txt file you open, inside your browser. The text, the file and its name are never sent to our server or anywhere else, are not put into the page address and are not stored. When the page opens, your browser downloads the analyzer's program code from this site; that request is the same for every visitor and contains nothing from your header. The result shows the addresses of the sending server and the domains from the header as links to our other checks. Nothing is looked up until you open one; then only that address or domain is sent, and it is handled like any other check (see what happens when you run a check).

The site sets no cookies and stores nothing in your browser. There are no advertising scripts, no analytics services run by other companies and no embedded content from other sites; the browser security policy we send allows scripts, styles, images, fonts and connections from this site only. That is also why there is no cookie banner: there is nothing to consent to.

We do count, on our own server. The usage log in the table above records each check with the tool, the name checked, the kind of program that asked, the outcome and the verdict, never the IP address you connect from. It shows us which tools are used, for which names, and where they fail, and it is the only way we can see that AI assistants use our MCP server, because no counter in a web page can see them. It is kept for 395 days.

We also count visits with Umami, open-source software that runs on our own server: no outside service receives anything. Its script is loaded from this site's own address and sets no cookie. For each page view your browser sends it the details listed in the table above. Your IP address reaches it with the request; it uses the address to look up your country, region and city and to make the anonymous code, and does not store it. The page address and its title are sent with the name you checked in them; of the rest of the address only the utm_ tags are sent. The details are kept for 395 days.

• Our hosting provider runs the server the site is on; the memory and logs described above are on that server.
• Cloudflare sits in front of our website as our service provider. Every page you open here and every request your browser sends to us, including a deliverability test report, passes through Cloudflare's network, so Cloudflare sees your IP address, the addresses you open and the pages we send back. The test messages themselves come straight to our mail server, not through Cloudflare. Cloudflare may process this data outside the EU. For the United States, Cloudflare takes part in the EU-U.S. Data Privacy Framework, and its data processing terms with us also include the EU standard contractual clauses.
• DNS resolvers. Every check result names the resolver that answered. When that is a public resolver (such as 1.1.1.1 or 8.8.8.8), its operator sees the names our server looks up, but not who asked. The DNS propagation checker always sends its question straight from our server to 9 public resolvers, so the name or IP address you check there, with the record type, goes to each of their operators (Cloudflare, Google, Quad9 Foundation, Gcore, AdGuard, CIRA, DNS4EU, DNS.SB, Control D). The question carries nothing about you, not even part of your IP address: they see only our server's address. What each operator logs, and for how long, is up to its own privacy policy, and some keep the names they are asked about for a long time: Google, for example, keeps the name and record type in its permanent logs, without the address that asked. Their own policies: Cloudflare, Google, Quad9 Foundation, Gcore, AdGuard, DNS4EU, DNS.SB, Control D. CIRA is not linked: its page did not open for us when we checked.
• Google Workspace hosts our mailbox; Google handles it for us as our service provider, under its Cloud Data Processing Addendum. If you write to support@mxverdict.com, your message and address are stored there, and so is the copy of a deliverability test message you send to our Gmail test address (see above). Google may store and process this mail outside the EU, including in the United States. For the United States, Google relies on the EU-U.S. Data Privacy Framework, which the European Commission found to give adequate protection in its decision of 10 July 2023.
• Microsoft 365 hosts our second test mailbox; Microsoft handles it for us as our service provider, under its Products and Services Data Protection Addendum. The copy of a deliverability test message you send to our Microsoft test address is stored there (see above). Microsoft may store and process this mail outside the EU, including in the United States. For the United States, Microsoft relies on the EU-U.S. Data Privacy Framework, under the same decision.
• DNS blocklist operators receive the questions our server asks them in the blacklist checker, the email domain check and the deliverability test: the IP addresses and domain names being checked. Our DNS resolver sends each question to the list's own DNS servers from our server's address; it carries nothing about you, not even part of your IP address. The lists we ask are named on the blacklist checker page, and what each operator logs is up to its own policy.

If you write to support@mxverdict.com, we receive your email address and whatever you put in the message, and use them only to answer you. The same mailbox receives the Gmail copies of deliverability tests, so our test reader also looks at a few headers of your email (its addresses, date and ID, and the sender checks recorded in it) for a moment, only to see whether it is a test copy. It writes nothing from your email down; in memory it keeps only Gmail's reference for the email and a scrambled fingerprint of its ID, so that it does not fetch it again. We keep the conversation while it is useful for that and delete it on request.

We process the names and IP addresses you check to run the check you ask for (Article 6(1)(b) of the EU General Data Protection Regulation, GDPR). We process the message you send to our test addresses, the facts of its delivery and where the copy landed, to run the deliverability test you ask for (Article 6(1)(b)). A test message can also contain other people's data, such as names and addresses in its headers or text. We handle that data only as part of the same test and delete it with the test; our basis for it is the legitimate interest, yours and ours, in checking how an email is delivered (Article 6(1)(f)). Telling each of them directly is not possible for us or would take a disproportionate effort (we never send email, and a message often names people without an address), so we tell them here, on this public page (Article 14(5)(b)). Our code uses your IP address only to count your checks and tests, so that nobody can use the tools to flood our server or other people's servers: this is our legitimate interest in protecting the service and those servers from abuse (Article 6(1)(f)). Our counters (the usage log and the visit counter) serve our legitimate interest in knowing which tools are used and whether the service works (Article 6(1)(f)). The web server's access log and error log and our mail server's log serve the same interest and also help us find faults (Article 6(1)(f)). We process emails you send us to answer them, which is also our legitimate interest (Article 6(1)(f)).

Under the GDPR you can ask what we hold about you (Article 15) and ask us to correct it (Article 16), delete it (Article 17), restrict its use (Article 18) or send you what you gave us in a machine-readable file (Article 20). Write to support@mxverdict.com. Check results are kept only for minutes, and so are the rate-limit counters, except the counter of the deliverability tests you start, which lasts at most 24 hours; none of them is kept under your name.

To have a deliverability test deleted before its 7 days are up, send us its link: we delete the message, its report and the copies in our Gmail and Microsoft mailboxes (from spam, junk and trash too), and tell you when it is done, within one month at the latest (Article 12(3)). The link is all we need: it is the key to the test. Our mail server's log line for the test holds no email address and no text, and it is deleted on its own after 14 days.

The access log keeps page addresses, with the IP address that connected to us, for 14 days. A normal visit reaches us through Cloudflare, so your own IP address is not in it. If you want us to look there anyway, tell us roughly when you used the site and which pages you opened; we will tell you what we could check.

Your right to object: you can object at any time to the processing we base on our legitimate interest (Article 21): our use of your IP address for abuse protection and fault finding, our server logs, our counters, our handling of other people's data in test messages, and our handling of emails you send us. Write to support@mxverdict.com.

You can also complain to a data protection authority, in particular the one in the EU country where you live or work (Article 77). Ours is the Estonian Data Protection Inspectorate (aki.ee).

MX Verdict is built and run by Jevgeni Simonov, a solo developer based in Estonia, in the European Union, who is also the controller of the personal data this site processes. Contact: support@mxverdict.com.

When what we keep changes, this page changes with it before the change goes live, and the date below moves. Checks currently stop after 20 seconds at most, so no request keeps data about you beyond the times listed above.