# Warmy email deliverability test > What a Warmy email deliverability test measures, how to read its placement result, and which evidence to check before changing a sender's configuration. A Warmy email deliverability test is a placement snapshot for the message and providers included in that test. Warmy's documentation says its tests report where copies land for selected providers, including inbox, spam, unreceived, and promotions states. Use that outcome to choose the next evidence check, not as proof that every recipient will see the next campaign in the inbox. Authentication, sender history, and real-recipient signals can still differ. ## Quick takeaways - A Warmy result describes the tested message, provider set, and time of the test. - Inbox and spam outcomes are useful provider-specific evidence, not a guarantee for every recipient. - Compare a placement concern with message authentication and the sender's own delivery data before changing configuration. - Keep the sender, content, and delivery path representative when you retest. - Make one evidence-backed change at a time so the next result remains interpretable. ## What a Warmy test records Warmy's [Email deliverability test documentation](https://support.warmy.io/knowledge/the-inbox-deliverability-checker) says its tests send a personalized message to mailboxes outside its warm-up network and show results by provider. The same documentation describes four outcomes: inbox, spam, unreceived, and promotions. Those labels tell you what happened to the copies the service observed. They do not disclose a mailbox provider's private filtering formula or establish a result for all recipients. The free [Warmy deliverability-test page](https://www.warmy.io/free-tools/email-deliverability-test/) describes its output in terms of sender reputation, spam score, and inbox placement. Treat any score as a summary of that service's evidence at that point in time. A score alone does not identify whether a DNS record, a sending service, a complaint pattern, or message content caused a placement outcome. This is the same general limitation described in the [inbox placement test guide](/learning/inbox-placement-test): a placement test is useful for a representative copy, but it is not a campaign-wide delivery guarantee. The broader concept of [email deliverability](/learning/what-is-email-deliverability) includes the receiver's acceptance and folder decision, not just one test result. ```text WARMY RESULT REVIEW RECORD Tested message: representative sender, content, and delivery path Observed outcome: inbox / spam / unreceived / promotions by tested provider Evidence not supplied: every recipient's future folder decision or a root cause Next check: message authentication, public DNS, or sender-owned campaign evidence Retest rule: change one documented variable, then compare the same path ``` ![Warmy result review checklist](/images/editorial/warmy-email-deliverability-test/warmy-email-deliverability-test-review.webp "1200x582") *Source: Palisade.* ## How to interpret a Warmy result ### 1. Preserve the test context Save the test time, sender identity, message version, and provider outcomes before changing anything. A placement result has more value when you can compare it with the same message type and sending route later. If the tested message was not representative of the campaign, use the result as a lead for investigation rather than a verdict. ### 2. Separate placement from message-level evidence If a provider outcome raises an authentication, alignment, blocklist, or content question, send the same representative message to Palisade's [email deliverability test](/tools/email-deliverability-test). It examines a received message for those signals. It does not reproduce Warmy's provider-placement result or show the folder used by every mailbox provider. ### 3. Check the public authentication posture When the remaining question is whether the visible domain publishes the expected SPF, DKIM, and DMARC records, run the domain through the [Email Security Score](/tools/email-security-score). It is the narrowest useful follow-up for public record evidence. A DNS check cannot prove the exact sending path, fix a sender configuration, or explain a particular recipient's folder decision. ## What a low placement result does and does not show A low inbox outcome is a reason to inspect the tested provider, sender, and message path more closely. It is not proof of a single cause. The result may be consistent with an authentication problem, a sender-history issue, a content concern, or evidence that is not visible to the test. That conclusion is an inference because mailbox providers do not publish a complete one-to-one explanation for each folder decision. Start with evidence that can distinguish the possibilities. Keep a delivered copy of the representative message, its authentication results, the public DNS records, and the sender's own complaint and bounce trends. For a separate message-level spam-risk workflow, see [test spam email](/learning/test-spam-email). Do not treat a better retest as proof that a tool repaired the sender. It only confirms a changed result for the path you tested. ## Check the public records behind the result If the test result leaves you with a public authentication question, inspect the domain's published posture before changing policy. The Email Security Score can show the current records, while the delivered-message test can show whether a representative message authenticated on arrival. Together, those checks narrow the gap between a placement snapshot and an evidence-backed sender investigation. [Check the Email Security Score](/tools/email-security-score) The score does not reproduce Warmy's test, see private recipient signals, change DNS, or guarantee inbox placement. ## Keep recurring sender evidence together One provider-placement result and one public DNS check cannot show every legitimate sender using a domain or prioritize a recurring alignment issue. Palisade's [DMARC Agent remediation guide](https://docs.palisade.email/guides/fixing-authentication-issues/) explains that DMARC reporting can identify sending sources and authentication or alignment problems, then create remediation work for human review. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_deliverability&utm_content=warmy-email-deliverability-test) Palisade does not change DNS, control receiver filtering, reproduce a Warmy result, or guarantee delivery. ## Sources and further reading - [Warmy Email deliverability test documentation](https://support.warmy.io/knowledge/the-inbox-deliverability-checker) - [Warmy free email deliverability test](https://www.warmy.io/free-tools/email-deliverability-test/) - [Amazon Pinpoint inbox placement test documentation](https://docs.aws.amazon.com/pinpoint/latest/userguide/channels-email-deliverability-dashboard-pipt.html) - [Palisade DMARC Agent remediation guide](https://docs.palisade.email/guides/fixing-authentication-issues/) ## Frequently asked questions ### Does a Warmy email deliverability test guarantee inbox placement? No. It reports the outcome for the message and providers included in the test. Real recipients, later sending conditions, engagement, and receiver-specific filtering can differ from those observed copies. ### What does an unreceived result mean in Warmy? It means Warmy documents a problem with sending the email or detecting the result for that provider. Keep the provider outcome with the message evidence, then investigate the sending path before assigning a single cause. ### Should I change my DNS after one low placement result? Only when the result and separate evidence support a public authentication problem. First compare the test with a representative delivered message and the published SPF, DKIM, and DMARC records so a DNS change addresses an observed issue. ### Can a good Warmy result prove that every campaign recipient will get the inbox? No. A good result describes the tested copies at that time. It cannot establish inbox placement for every mailbox, later campaign, recipient audience, or receiver-specific filtering decision. ### What should I retest after fixing an authentication issue? Use the same sender identity, representative content, delivery path, and relevant provider set. Record the change you made, then compare the new result with the earlier result instead of treating different tests as directly comparable.