Last updated October 31, 2026.
Who is responsible
Serhii Tanichev runs email-spam-tester.com and is the data controller for everything described here. Questions and requests go to hi@email-spam-tester.com.
There are no accounts
The site has no signup and no login. It sets no cookie of its own, and the analytics cookies described below only with your permission where the law asks for it. Nothing you do here is tied to a name unless you write to me.
When you reserve a test address
The service records the IP address the request came from and keeps it for 30 days, to limit abuse. After that the address is erased from the record while the record itself stays, because the report link hangs on it. It also records the language you chose, so the report can be written in it.
With the IP address it notes where the request came from, so I can tell which pages and tools bring people to the test: the user agent of your browser or script, the campaign tags (utm_source, utm_medium, utm_campaign) of the link you followed, which page of this site you started on, and the domain of the site that linked you here. Only the domain, never the full address of that page. All of this is erased on the same day as the IP address. Nothing is stored in your browser for it.
When you send a message to that address
The message is stored in full, source, headers and attachments included, because the checks need it and because the report offers a "message as received" view. Once the checks have run, the message is deleted an hour after it arrived; if they run late it waits for them, two days at most. While it is stored, anyone who has the report link, or the code at its end, can read the whole message: headers, bodies and attachments. If the email carries a real customer's data, test a copy without it.
The report itself is kept indefinitely at its permanent link. A report contains the results of every check, the subject line, the sender address, the bounce address, the links found in the message and short quoted excerpts where a finding needs one. Anyone who has the link can open it. There is no other access control on a report, so treat the link the way you would treat the message.
Producing the report involves other parties, the same ones any receiving mail server talks to:
- DNS resolvers and the public DNS blocklists. Your sending IP address and the domains in your message are looked up there.
- The servers behind the links in your message. The tester fetches them from its own server to check where they lead and how they answer.
- A language model, reached through a third-party API, which writes the fix plan. It receives a fact sheet: measurements and finding texts with sender addresses redacted. It never receives the body, the raw headers or the subject.
Infrastructure checks through the API
A domain check through the API stores the domain, any IP addresses, selectors and HELO name you pass, and the result, which holds the domain's public DNS records and what its mail servers answered. A run made without a key also stores a keyed hash of your IP address, never the address itself, so that your runs can be told from everyone else's. Such a run is deleted after 30 days, and anyone who has its id can read it. A run made with an API key is tied to that key, has no hash, opens only with that key and is deleted after 365 days. With a key that serves many people, the account value you pass is stored too.
The check talks to the same DNS resolvers and blocklists as a test. From this server it also fetches the domain's MTA-STS policy and BIMI files, asks the registry's RDAP service for the registration date, and may connect to port 25 on the domain's own mail servers.
Optional Gmail inbox placement test
This is separate from the email score. If you choose it, you send a test campaign directly to public GMass seed inboxes from your own sending service. GMass receives the full message. Its public tester displays the subject, sender name, a partially masked sender address and the folder it landed in. Do not use confidential content. Read GMass's explanation of public results before sending.
We send a random subject marker to GMass to retrieve matching results. We store the marker, the seed addresses, observed folders and timestamps for 30 days. We do not copy your message body, subject or sender from GMass into this report. Anyone with the report link can read it. The public subject marker is different from the private report link. The IP-based daily quota is removed after seven days; server logs follow the policy below.
Using Email Spam Tester in ChatGPT
The ChatGPT plugin reaches this service through its MCP server at email-spam-tester.com/mcp. For each tool call ChatGPT sends me the arguments the tool needs (a report slug, a domain, a language code) and an anonymous user identifier that OpenAI generates. I don't receive your name, your email address or the conversation, and the requests come from OpenAI's servers, so your IP address doesn't reach me either. The identifier is never stored as it arrives. The server turns it into a keyed hash and keeps only that, which is enough to count your daily tests and keep your mailboxes apart from everyone else's.
A one-hour test started from ChatGPT follows the sections above, except that the daily limit is counted against that hash rather than an IP address. The report is public at its link, as on the site, and provider placement, if you ask for it, works as the placement section above describes.
A series mailbox is a permanent address for your own domain, meant to be subscribed to your newsletter or welcome series. Letters sent to it are checked like a test message, with three differences: only you can read their reports, through the plugin, and there is no public link; the raw message is deleted two days after it arrives; the report is deleted after 90 days. The fix plan for a letter is written only when you ask for one. Closing the mailbox stops it keeping anything, and letters that arrive afterwards are dropped unread. To have the reports removed sooner, write to me with the address.
Using Email Spam Tester from Claude and other MCP clients
Claude, Cursor and other clients reach the same MCP server. They don't tell it who you are, so a test started from one of them works as on the site, with one difference: its daily limit is counted per MCP session, which the server records only as a keyed hash of the session id the client sends. Permanent mailboxes aren't available there, since nothing in the request says whose they would be.
Using Email Spam Tester with Mailchimp
Connecting Mailchimp on the Mailchimp page gives the service an access token for your account. I keep the token encrypted, together with the account's id, its name, the email address of the login that connected it and the Mailchimp data centre it lives in. The browser you connected from gets a cookie that keeps it signed in for 30 days; I store only a hash of that cookie.
With the token the service reads your drafts, audiences and campaign summaries to show them to you, copies a draft to send a test from and deletes the copy, and adds or archives its own contact in an audience you choose. It reads nothing else and changes nothing else. A test of a draft is an ordinary test as described above, and its report is public at its link.
Letters sent to a permanent address in one of your audiences are checked like a test message, but their reports are visible only on the Mailchimp page to your account. The raw message is deleted two days after it arrives and the report after 90 days. Disconnecting archives our contacts in your audiences, deletes the token and signs out every browser; the account's id and name stay so that a later connection finds its old permanent addresses.
Using Email Spam Tester with HubSpot
Connecting HubSpot on the HubSpot page installs the app in your HubSpot account and gives the service an access token and a refresh token. Both are kept encrypted. Next to them I store the account's id, its domain, the email address of the user who connected it and the HubSpot data centre it lives in. The browser gets a cookie for 30 days, and I keep only its hash.
With the tokens the service reads your marketing emails and contact lists to show them to you, makes a copy of an email for a test and deletes it afterwards, and creates its own contact, adds it to lists you choose and removes it. It reads nothing else and changes nothing else. A test is an ordinary test as described above, and its report is public at its link; for the history I keep which email each test was of.
Letters sent to our contact are checked like a test message, but their reports are visible only on the HubSpot page to your account. The raw message is deleted two days after it arrives and the report after 90 days. Disconnecting deletes our contact in your account and revokes the tokens at HubSpot. It also deletes them here and signs out every browser. The account's id, domain and the connecting user's address stay, so that the history of its tests is still there if you connect again.
Using Email Spam Tester with Zapier
The Zapier page gives out API keys. For each key I store the email address you typed, a hash of the key (never the key itself), its first characters so you can tell keys apart, and when it was made. The IP address it was asked for from is kept for 30 days, like a test's, and then erased. Zapier keeps the key in your connection and sends it with every call; Zapier's own handling of your data is covered by its policy, not this one.
A test address created from a Zap is an ordinary test as described above, and its report is public at its link. Emails sent to a permanent mailbox are checked the same way, but their reports open only with your key. The raw message is deleted two days after it arrives and the report after 90 days.
Using Email Spam Tester with n8n
The n8n page gives out the same API keys, stored the way the Zapier section above describes. n8n keeps the key in a credential on your n8n instance and sends it with every call; on n8n Cloud, n8n's own policy covers how it holds that credential. Test addresses and permanent mailboxes created from a workflow work exactly as the ones created from a Zap.
The Chrome extension
The Email Spam Tester extension talks to this service and nothing else. It does what the site does, from your browser: it asks for a test address (and the placement test, if you tick that box) and reads the report, so the sections above apply unchanged and your IP address reaches me exactly as it does when you use the site.
Each request also carries the language your browser is set to, so the fix plan is written in it, and the tag utm_source=chrome-extension, which the server log keeps like any campaign tag (see below).
What the extension keeps stays in your browser: your last 20 tests (the address, the report link, the subject, the score, the placement recipients and marker if you asked for placement, and whether the plan and the placement were still filling in) and whether you left the placement box ticked. None of it is sent anywhere else. There is no analytics in the extension, and it cannot read your mailbox, your email drafts or the pages you visit. It asks Chrome for three permissions: storage, for that list; alarms, to look for your report every 30 seconds while the popup is closed and a test is still open; notifications, to tell you the report is ready. Removing the extension removes the list.
The WordPress plugin
The WordPress plugin sends nothing until an administrator presses Connect. Connecting registers the site under an id made from its address and a secret that stays in the site's database; the service gets the WordPress and plugin versions, the number of sites and, if given, a contact email.
A test from the plugin is an ordinary test as described above, and its report is public at its link. With it come the sending domain, the From and Return-Path addresses, how WordPress sends (PHP's mail() or SMTP, the SMTP host and the SMTP plugin's name, never a password) and, if the mail server refused the email, its answer with addresses removed. The site's own emails the plugin can test are filled with sample data, not with a real customer's.
Monitoring is off until an administrator switches it on. Then the plugin tells the service the sender and subject of each email the site sends, so that it can say which kinds are new, and sends a copy of the first email of each new kind to a private address. The copy has the original's From and headers, no Cc or Bcc recipients, no attachments, and links without their query strings. For emails the site failed to send, the plugin reports their number, which plugin sent them and the server's answer, without addresses. Monitoring reports are visible only to the site. The raw copy is deleted two days after it arrives and its report after 90 days. Switching monitoring off or uninstalling the plugin closes the private address.
Server logs
The web server and the API each write one line per request: IP address, user agent, referrer, browser language, the path requested, the response status and timing, and, when they are present, the campaign parameters (utm_source, utm_medium, utm_campaign, utm_term, utm_content, utm_id) and the click identifiers advertising platforms add to their links (gclid, gbraid, wbraid, dclid, msclkid, fbclid, li_fat_id, rdt_cid, twclid, ttclid). No other query parameters are logged. API lines can include the report identifier. Log files are rotated daily and deleted after 30 days.
Headers pasted into the email header analyzer travel in the body of the request, so none of these logs sees them: they are processed in memory to build the result and are not stored, cached or logged, and the request only counts toward the same per-IP limit as the other free tools.
Cookies and analytics
The site uses Google Tag Manager and Google Analytics 4 to count page views and a handful of events, such as an address being reserved or a report being opened. Report identifiers are stripped from the page address before anything is handed to Google, so an analytics record can never open a report.
If you are in the European Economic Area, the UK or Switzerland, the site asks first. Until you answer, neither Google script is loaded, and after a "Decline" it stays that way. The page works out where you are from your browser's time zone, and that guess never leaves the browser. When it is wrong, Google makes its own check by IP address and, for those countries, measures without setting cookies. Visitors from everywhere else get analytics by default and have the same button to turn it off.
Allowing it lets Google set its cookies, _ga and _ga_ followed by an identifier, which last up to two years. Google processes that data under its own terms. Your answer is kept in your browser's local storage, not in a cookie, and is never sent to me. To change it, use "Cookie settings" at the bottom of any page. Declining after you had allowed deletes those cookies and reloads the page.
If your browser blocks scripts, nothing is sent and the site works exactly the same.
Fonts are served from this server. The interactive API sandbox at /api-docs/try/ is the one page that pulls code from another host: its interface comes from the jsDelivr CDN, which sees your IP address when you open it.
Backups
The database, including reports and any message that has not yet expired, is backed up three times a day. Backups are kept for five days on the same server and then deleted.
Removing a report
Write to me with the report link, or from an address at the domain that sent the message. I will delete the report and whatever is left of the message. If you want to know what the service holds about you, the same address works, and the answer is almost always "one report and nothing else".
Changes
When the retention periods or the third parties above change, this page changes with them and the changelog notes it.