Faham ZiaYou can test cold email for spam risk before sending, but only partially. Four checks give real signal: SPF, DKIM and DMARC alignment on the exact sending domain; blacklist status on the lists mailbox providers actually query; seed-list placement across Gmail and Microsoft; and a controlled low-volume ramp watched in Google Postmaster Tools. None of them predicts inbox placement reliably. The reason is structural, not a gap in the tools. Inbox placement is not a property of an email. It is the output of a decision a specific mailbox provider makes about a specific message, from a specific domain and IP, to a specific recipient, at a specific moment, weighted by that domain’s reputation history and that recipient’s own engagement patterns. A test can hold three of those variables constant. It cannot hold all of them. So the useful question is not “will this land in the inbox.” It is “which failure modes can I rule out cheaply before I put real domains at risk.” That list is longer than most people think, and this post walks through each test, what it actually measures, where it lies to you, and the order to run them in.
What a spam test can measure, and what it can’t
There are two categories of pre-send test, and conflating them is the single most common mistake. Deterministic tests check configuration: does this message authenticate, is this IP listed, is this header present. The answer is binary, repeatable, and true regardless of who receives the mail. Probabilistic tests check placement: where did this specific message land for this specific sample of inboxes right now. The answer is a snapshot with a short shelf life.
Most teams run only the probabilistic tests, see a green result, and treat it as a guarantee. Then they run the deterministic tests, see a pass, and treat that as a placement prediction. Both readings are wrong in the same direction: they turn a floor into a ceiling. Passing every deterministic check means you have removed the reasons a filter would reject you outright. It says nothing about whether a filter will choose to promote you.
The correct sequence is deterministic first, because those tests are free, binary, and fixable in an afternoon. Then probabilistic, to get a directional read on content and infrastructure. Then a small volume of real sends, because that is the only test where every variable is real. Skipping to step three without steps one and two is how people burn four domains in a week and then spend a month re-warming them.
Test one: authentication and alignment on the exact sending domain
This is the only test with a definitive answer, so do it first. Send one message from your configured sending domain to a Gmail address you control, open the message, and use Show original. You want three lines reading SPF: PASS, DKIM: PASS, DMARC: PASS. Repeat into a Microsoft 365 mailbox and read the Authentication-Results header there too, since the two providers evaluate independently.
The failure that slips through is alignment, not authentication. SPF authenticates the Return-Path, which is the envelope sender, not the From header your recipient sees. If your sending tool routes bounces through its own domain, SPF passes for that domain while DMARC still fails, because the authenticated identity and the visible identity do not match. DMARC passes when either SPF or DKIM produces an aligned result, so a DKIM signature with a d= value on your own domain rescues an unaligned SPF. Relaxed alignment, which is the default, only requires a shared organizational domain, so a From of @outbound.yourco.com and a DKIM d= of yourco.com aligns fine.
Test the domain you will actually send from, not the parent brand domain. Each sending domain carries its own DNS records and its own reputation, and a clean result on yourco.com tells you nothing about tryyourco.com. Per Google’s sender guidelines, senders above 5,000 messages a day to Gmail must have SPF and DKIM together plus DMARC with alignment, and Microsoft applied equivalent requirements to Outlook.com for high-volume senders from 5 May 2025. Cold email at 30 to 50 sends per inbox per day usually sits well under those thresholds, which people misread as an exemption. The thresholds define when the rules are enforced as hard requirements. The filters apply the same logic to everyone.
- Check the exact sending domain and subdomain, not the corporate domain
- Confirm DMARC alignment, not just SPF and DKIM pass results
- Verify forward and reverse DNS on the sending IP, which Google requires of all senders
- Re-test after any change to the sequencer, mail host, or bounce domain
Test two: blacklist checks, and which lists you can safely ignore
Two separate objects get listed: the sending IP and the domain. Check both, using the actual outbound IP taken from the Received headers of a test send rather than whatever IP range your tool’s documentation claims. Spamhaus is the family that matters, because the major mailbox providers query it. A listing on SBL or CSS is a present-tense delivery failure, not a warning, and it explains a sudden collapse better than any content change.
The domain side catches people out. Spamhaus DBL lists domains found anywhere in the message, including the body. That means a burned link shortener, a shared tracking domain, or a stale redirect domain can sink an otherwise clean sending domain. Check every domain that appears in your template, not just the one in the From line. This is one of the more common causes of a campaign that tests clean on config and still lands in spam.
Not every list is worth acting on. UCEPROTECT in particular is ignored by Gmail, Outlook and Yahoo for filtering purposes, so a listing there is not a placement problem. It is an infrastructure problem, because some hosting providers use it as a trigger for suspending port 25. Treat it accordingly rather than panicking. The harder case is shared sending infrastructure: if your IP is pooled, the reputation is not yours and you cannot repair it. Checking it tells you whether to move, not what to fix.
Why mail-tester style spam scores mislead
Tools in the mail-tester category run your message through SpamAssassin plus a set of configuration checks. SpamAssassin is a rules engine with published, static weights, which is exactly why the score feels satisfying: you can see which rule fired and watch the number climb when you remove the trigger. The problem is that Gmail and Microsoft do not run SpamAssassin. They run proprietary classifiers weighted heavily by sender reputation and recipient-level engagement history, neither of which a static rules engine can observe.
This produces two specific distortions. The first is score inflation, where you spend a week optimizing away rules that no major provider weights, adding a plain-text part or rewording a subject line, and feel progress with zero change in actual placement. The second is scope blindness: the score evaluates content and configuration only. Once you are past the first two weeks of sending, domain reputation is the dominant variable, and it is completely invisible to the score. A 10 out of 10 on a domain with a complaint history still lands in spam.
The tool is still worth ten minutes. It reliably catches the dumb, expensive mistakes: a missing DKIM signature, an image-heavy HTML body with almost no text, a listed link domain, a broken unsubscribe header. Run it once per template, fix anything that drops you below roughly 8, and then stop looking at it. Treat it as a linter, not a forecast.
Seed list testing: useful, but not for the reason people assume
Seed testing is the only pre-send method that observes real placement. You send your actual campaign message to a panel of accounts spread across Gmail, Google Workspace, Outlook.com, Microsoft 365 and Yahoo, and the tool reports where each copy landed. That is genuinely more informative than any simulated score, and it is worth doing. It just answers a narrower question than the dashboard implies.
The limits are worth naming plainly. Seed accounts have no engagement history with you, and Gmail placement is personalized by whether that recipient has previously opened or replied to your mail. A seed inbox that never replies to anything is not a neutral observer, it is an unusual one. Seed addresses also get identified over time by providers that can see they only ever receive test traffic, which decays the accuracy of the panel. And a seed test captures one message, from one domain, at one moment, while placement typically degrades as a function of accumulated volume and complaints.
The way to extract real value is to stop reading single results and start reading trends. Run the identical seed test at three fixed points and compare: before launch, after week one at low volume, and immediately after your first volume step-up. A drop between test two and test three is a strong signal that you have moved faster than your reputation can carry. Also seed-test the exact variants you will send, with real merge fields and real links, and test the version with your calendar link separately from the version without. Links move placement more than body copy does.
- Seed inboxes have no engagement history, so they represent a worst case, not your prospect
- Panels decay as providers identify addresses receiving only test traffic
- One clean result on day one says nothing about day thirty at full volume
- Compare three tests over time; a single score is noise
Google Postmaster Tools and Microsoft SNDS: the only view from the receiving side
Everything above is you inspecting your own mail. Postmaster Tools and SNDS are different in kind, because they report what the receiving provider concluded. Verify each sending domain in Google Postmaster Tools with a DNS TXT record and you get domain reputation, IP reputation, spam rate, authentication pass rates and delivery errors for mail sent to Gmail. That is the closest thing to ground truth available to a cold sender.
There is a catch that hits cold email specifically. Postmaster Tools suppresses low-volume data, and while Google does not publish the exact floor, domains sending under roughly a hundred messages a day to Gmail commonly see empty panels, with some panels populating before others. That creates a direct conflict: the reputation-safe architecture, meaning many domains and many inboxes each sending a small daily volume, is precisely the architecture that generates no Postmaster data. Verify every sending domain anyway so that history accrues, and read the authentication and delivery-error panels, which tend to show something before spam rate does.
Microsoft SNDS has a sharper limitation that is widely misunderstood. SNDS is IP-based, so on shared sending infrastructure you cannot register at all, and it reports only on the Outlook.com consumer network: outlook.com, hotmail.com, live.com and msn.com. It does not report on Microsoft 365 business tenants. In B2B cold email, almost every Microsoft recipient is an M365 tenant running Exchange Online Protection or Defender. Which means for the single largest slice of B2B inboxes, no first-party reporting exists at all. That is not a tooling gap you can shop around. It is the honest reason no test predicts placement, and it is why controlled real-volume sending is not optional.
What a good spam rate actually is
Google’s published guidance is specific: keep the spam rate reported in Postmaster Tools below 0.10%, and never reach 0.30% or higher. Cross 0.30% and you lose eligibility for Google’s mitigation until you hold below that line for seven consecutive days. Those are the numbers to plan against, and they are stricter than they sound once you convert them into cold email volumes.
0.10% is one complaint per thousand delivered messages. At 2,000 sends a week, that is two complaints. Cold email complaint rates are structurally higher than opt-in marketing for the obvious reason that nobody asked to hear from you, so the buffer between normal and dangerous is thin. In practice, treat any spam rate visible in Postmaster Tools at cold volumes as already serious, because at your volume a rate large enough to render is a lot of individual complaints. The working target is effectively zero.
Because complaint data is often invisible at low volume, watch the two indicators that are always measurable. Bounce rate is the first: above 3% and something in your verification stack is misconfigured, whether that is catch-all handling, stale data, or a verification step being skipped. Bounces damage reputation before complaints do and you can see them from your first send. The second is total reply rate including negative replies. When placement degrades, the “not interested” replies disappear along with the positive ones. A drop in total replies on unchanged list and copy is a delivery signal, not a messaging signal, and it usually shows up days before anything appears in a dashboard.
The test that actually works: a controlled low-volume ramp
Every simulated test holds something artificial constant. A low-volume ramp holds nothing artificial constant, which is why it is the only method that reflects reality. It costs you time instead of accuracy, and that is the right trade, because the alternative failure mode, burning a set of domains in week one, costs three to four weeks of re-warming plus the domains themselves.
The protocol is simple and most teams compress it, which defeats the point. Send 20 to 30 real messages to real prospects from a single inbox on a single domain. Not seeds, actual people who might reply. Mix three to five addresses you control into that same send, spread across a consumer Gmail address, a Google Workspace domain, an Outlook.com address and a real Microsoft 365 tenant, so they receive identical treatment to the live sends. Then watch for five business days before touching anything.
Define the stopping rule before you start, because that matters more than the test itself. If bounce rate exceeds 3%, or total replies go to zero across two consecutive sending days at steady volume, pause and diagnose rather than pushing through on the assumption it will settle. Only after a clean five-day window do you add the second inbox, then the third, doubling no faster than weekly. This ramp still does not predict placement. What it does is detect a problem while it is contained to one inbox instead of twelve, and detection speed is the achievable goal. If you want the config and blacklist layer checked properly before you spend five days on a ramp, that is exactly what an outbound audit is for.
Related reading
- SPF, DKIM and DMARC for cold email, explained properly
- How many cold emails per inbox per day in 2026
- Cold email deliverability in 2026: why your emails land in spam
Frequently asked questions
Can you test whether a cold email will land in spam before sending it?
Partially. You can definitively test configuration: SPF, DKIM and DMARC alignment on the exact sending domain, blacklist status on the sending IP and every domain in the message body, and forward and reverse DNS. You can get a directional read on placement with a seed-list test. You cannot get a reliable prediction, because inbox placement depends on your domain’s reputation history with each provider and on individual recipient engagement, neither of which any pre-send test can observe.
Is mail-tester accurate for cold email?
Mail-tester accurately reports what SpamAssassin thinks of your message, but Gmail and Microsoft do not use SpamAssassin. They use proprietary classifiers weighted heavily by sender reputation and recipient engagement, which a static rules engine cannot see. Use it as a linter to catch missing DKIM, image-heavy HTML, broken unsubscribe headers and listed link domains. Fix anything scoring below about 8, then stop optimizing the number, because past a certain point you are tuning rules no major provider weights.
What is a good spam rate for cold email?
Google’s sender guidelines say to keep the spam rate reported in Postmaster Tools below 0.10% and never let it reach 0.30% or higher; crossing 0.30% costs you eligibility for Google’s mitigation until you hold below it for seven consecutive days. For cold email the practical target is effectively zero, because 0.10% is one complaint per thousand delivered messages, and at typical outbound volumes any spam rate large enough to appear in the dashboard already represents a significant number of complaints.
Does Google Postmaster Tools work for cold email at low volume?
Often not, and this is a real constraint rather than a setup error. Google suppresses low-volume data, and domains sending under roughly a hundred messages a day to Gmail commonly see empty panels. The reputation-safe cold email architecture of many domains each sending small daily volume is exactly what produces no Postmaster data. Verify every sending domain anyway so history accumulates, and read the authentication and delivery-error panels, which tend to populate before spam rate does.
Does Microsoft SNDS show my Microsoft 365 deliverability?
No. SNDS reports only on the Outlook.com consumer network, meaning outlook.com, hotmail.com, live.com and msn.com. It does not cover Microsoft 365 business tenants, which is where nearly all B2B cold email actually lands. SNDS is also IP-based, so on shared sending infrastructure you cannot register at all. For M365 business recipients no first-party reporting exists, which is the main structural reason controlled low-volume testing cannot be replaced by a dashboard.
How many emails should you send to test deliverability before scaling?
Start with 20 to 30 real messages to real prospects from a single inbox on a single domain, with three to five addresses you control mixed in across Gmail, Google Workspace, Outlook.com and a real Microsoft 365 tenant. Watch bounce rate, total reply rate including negative replies, and manual placement checks for five business days. Add a second inbox only after a clean window, and double volume no faster than weekly.