spam score / reports
What is a spam score and how should you read it?
A spam score is useful only when it explains the inbox placement signals behind the number.
Published 2026-06-20
Why this check matters
Spam score matters because teams deciding whether a campaign is ready to send need evidence before they make sending decisions. The practical question is not whether an email looks good in a preview pane. The practical question is whether the same message, sent through the same route, reaches enough real inboxes to justify a larger send. A useful Sendlander report keeps that decision tied to observable signals: inbox percentage, spam hits, pending seeds, authentication results, domain health, content warnings, and link risk. That makes the work concrete instead of theoretical.
The intent of this guide is to understand what a score can summarize and what it cannot prove. That framing is important because deliverability advice often collapses into generic checklists. A checklist can be useful, but only when each item is connected to the message path being tested. If a team tests one sender, one template, and one tracking domain but sends a different combination later, the report cannot carry much confidence. The test has to match the operating reality.
The main risk is treating a single number as a guarantee while ignoring the inboxes, providers, and checks behind it. That risk shows up in different ways across teams. Marketing teams may read a good-looking template and assume it is safe. Sales teams may see a delivered event in their sequence tool and assume the recipient saw the message. Product teams may focus on authentication and forget that links, content, and provider-specific filtering still affect placement. The report should prevent those shortcuts.
What the report should show
A useful report should separate the headline from the evidence. The headline can be a score, an inbox percentage, or a simple pass/warn/fail label, but it should never stand alone. Sendlander reports are designed around the evidence below the headline: provider cards, segment summaries, seed rows, analysis sections, and a fix list. For spam score, the evidence that matters most is inbox percentage, spam hits, pending seeds, authentication results, domain health, content warnings, and link risk.
Provider-level detail is especially important. A message can be acceptable at one mailbox provider and risky at another. It can land in personal Gmail inboxes while professional Outlook inboxes classify it differently. If the report hides that split, the team may fix the wrong problem. Provider cards, seed-level evidence, and latency details make it easier to decide whether a result is broad, provider-specific, delayed, or tied to one seed segment.
The report should also keep pending results visible. Pending is not the same as spam. Some seed inboxes match slowly, some providers delay classification, and some messages arrive after the first report load. A good workflow keeps polling and marks the report as incomplete when confidence is low. That prevents teams from treating an early partial result as a final verdict.
Authentication and setup checks
Setup checks answer a different question from placement checks. Placement tells you where the message landed. Setup tells you whether the sender identity and domain configuration gave the message a fair chance. For this topic, the setup checks to review are SPF, DKIM, DMARC, visible From alignment, sender domain DNS, and reverse-DNS evidence where available. If any of those are missing, failing, or misaligned, the first fix should happen before the team rewrites copy or changes the offer.
Authentication should be read from both DNS and delivered headers when possible. DNS can say that a record exists, while delivered headers show whether the real message actually passed and aligned. That distinction matters when a CRM, ESP, or SMTP relay uses a separate bounce domain, a different DKIM selector, or an unexpected subdomain. The delivered email is often where the mistake becomes visible.
Not every warning has the same priority. A missing DMARC policy may be a strategic domain governance issue, while a failed DKIM result on the actual campaign is urgent. A PTR warning may be relevant when the sending IP is visible and stable, but less useful when a managed provider handles the infrastructure. The report should show enough detail for the operator to decide what is truly blocking the next send.
Content and link checks
Content checks should be grounded in the actual email that was sent. For spam score, the content side is mainly about risky wording, short or image-heavy copy, tracking-like domains, shortened links, redirects, and missing image alt text. These checks do not claim that one word or one image causes spam placement by itself. They highlight patterns that make the message harder to trust, harder to parse, or harder to debug when placement is poor.
Links deserve separate attention because they often carry reputation signals outside the sender domain. Tracking links, redirect chains, URL shorteners, and unfamiliar domains can all change how a message is interpreted. Even when every link is legitimate, the report should tell the operator what domains appeared and which ones looked tracking-like or redirect-like. That makes remediation possible without guessing.
The safest content changes are usually boring. Add readable body text. Use clear sender identity. Remove unnecessary shorteners. Keep the number of links reasonable. Make image-heavy designs usable without images. Avoid exaggerated claims and misleading urgency. Then rerun a comparable test. The point is not to make every email plain; it is to make the message understandable and defensible to mailbox filters.
A practical workflow
The recommended workflow is: run one real seed-list test, read the provider breakdown, fix the highest-risk items, then run a comparable follow-up test. That order matters. If the team starts by changing the template before reading provider placement, it may hide the original issue. If the team starts by buying a new tool before checking authentication, it may spend time around a simple DNS failure. A placement report should narrow the next action, not create a larger list of guesses.
Run the first test as close to production as possible. Use the real sending domain, the real From address, the same ESP or CRM, the same link tracking behavior, and a campaign-style message. Include the required tracking token so the result can be matched cleanly. If the test is only a rough sample, label it as such and avoid using it as proof that the production send is safe.
After the first report, fix only the highest-risk issues first. If authentication fails, fix that before changing copy. If one provider is poor and the rest are fine, keep the investigation provider-specific. If the content section shows obvious link or template problems, simplify the message and retest. A controlled second test is more useful than a broad redesign with no clear cause.
Common mistakes to avoid
The most common mistake is comparing scores from different tools without checking the underlying seed set, weighting, or scoring model. It feels efficient in the moment, but it weakens the result. Deliverability work depends on comparing like with like. When the seed set, sender, subject, template, tracking domain, and sending route all change between tests, the team no longer knows which variable moved placement.
Another mistake is overreacting to one row. Seed inboxes are diagnostic instruments, not your entire audience. One spam result is worth investigating, especially if it appears beside a clear warning, but it should be read with the provider summary and confidence level. Conversely, a good aggregate number should not hide a serious issue in a provider that matters to the business.
Teams also confuse remediation with proof. Publishing a DNS record, removing a shortener, or changing a subject line is not proof that placement improved. The proof is a follow-up test through the same path. Sendlander should make that retest easy: save the report, document the change, run the next test, and compare the result against the original.
How to prioritize fixes
A sensible fix sequence is: first confirm delivery, then fix authentication, then clean obvious content and link issues, then retest before increasing volume. This sequence keeps effort aligned with risk. Authentication and sender-identity failures can poison every message. Broad spam placement can indicate reputation or infrastructure issues. Content and link problems can often be resolved quickly once the report makes them visible. Lower-severity warnings can wait until urgent blockers are clear.
Prioritized fixes should be written as actions, not vague diagnoses. "DKIM failed for the delivered message" is useful, but "enable DKIM signing for this ESP and retest the same template" is better. "Tracking domains detected" is useful, but "replace the unknown shortener with a branded tracking domain or direct URL" gives the operator something to do. The report should push toward operational steps.
The fix list should also explain when not to act. If a check is informational, if the test is still pending, or if a provider-specific issue needs more evidence, the right move may be to wait, rerun, or gather another sample. That restraint is part of a good deliverability workflow. Not every warning deserves an emergency change.
Monitoring and retesting
Monitoring should focus on track the score beside raw provider placement so a trend is not mistaken for a one-off mailbox delay. The strongest signal is not a single score on a single day. The strongest signal is whether comparable tests improve or degrade over time. A recurring monitor can catch authentication drift, provider-specific spam movement, blacklist changes, or low-score reports before a major campaign exposes the problem publicly.
Retest when there is a meaningful trigger: template edits, sender-domain changes, new tracking domains, ESP migrations, and any sudden placement drop. Retesting after every tiny edit creates noise, but retesting after a sender or template change creates evidence. For campaign teams, a good habit is to test before high-value sends and after any infrastructure change. For outbound teams, test before ramping a domain or mailbox.
Keep the raw report history. A dashboard trend is useful, but the individual reports explain why the trend moved. If the score improves because pending seeds finally matched, that is different from improvement after authentication was fixed. If Gmail improves but Outlook worsens, the aggregate trend may hide the provider that still needs work.
Operational checklist
Before acting on a report, write down the exact sender, domain, platform, subject, template, tracking setup, and seed segment that were tested. That record keeps the team honest when it compares later runs. If a stakeholder asks whether spam score improved, the answer should reference a comparable report rather than memory, a screenshot, or a dashboard metric that has lost the original context.
During remediation, assign each action to one owner. DNS fixes usually belong with whoever controls the domain. Template and link cleanup usually belongs with marketing or revenue operations. Sending-volume changes may belong with the campaign owner. This division matters because deliverability problems linger when every team can see the report but no one owns the next step. A concise fix list turns the report into work that can actually be completed.
After the next test, record what changed and what did not. If placement improves, keep the change and continue monitoring. If placement is flat, avoid stacking several new changes on top without a hypothesis. If placement worsens, roll back the most likely change and retest. Treat the process like production debugging: one clear observation, one controlled change, and one follow-up measurement.
Where warmup fits
Warmup can support reputation later, but a score should first expose broken setup or content problems. Warmup can be useful in the right context, but it should not be treated as the first answer to every placement problem. If the delivered message fails authentication, uses suspicious links, or lands in spam because of the actual campaign content, warmup is working around the wrong issue.
A measured approach starts with diagnostics. Run a placement test, read the report, fix the issues that are clearly under your control, and establish a baseline. If the sender is new, quiet, or recovering from low reputation after those fixes, warmup may become a reasonable next tactic. Even then, it should be monitored with placement reports rather than assumed to work.
The end goal is not a perfect checklist. The goal is a sending system that produces consistent, explainable inbox placement for the messages you actually send. A long-form guide, a report, and a monitor all serve that same practical purpose: reduce guessing, make the next fix obvious, and avoid scaling a sender before the evidence supports it.