Why do my deliverability scores vary between Mail-Tester and GlockApps?

You sent the same list through Mail-Tester and GlockApps. One says your emails will land in inboxes. The other flags half your list as risky or unverifiable. Why the gap?

Because they’re not measuring the same thing. Mail-Tester runs real SMTP transactions to test inbox placement. GlockApps checks syntax and basic DNS. The difference isn’t a flaw—it’s a divergence in purpose.

You’re not debugging a tool. You’re understanding two different verification models: one that simulates real delivery, and one that checks for obvious errors. This isn’t inconsistency. It’s divergence in method.

Key takeaways

  • Mail-Tester verifies deliverability via real SMTP transactions, testing whether emails actually reach inboxes.
  • GlockApps primarily uses syntax and DNS checks, which can miss subtle delivery issues like greylisting or role account filters.
  • Two tools can give conflicting results because they evaluate different layers of email validity—not reliability.

What does deliverability testing actually mean?

Deliverability testing measures how likely an email is to land in a recipient's inbox—rather than being flagged as spam, rerouted to junk, or blocked entirely. It doesn’t just check if an address exists; it evaluates the sender’s technical setup, reputation, and reliability through real-world SMTP interactions with actual email servers.

It’s not just about the address—it’s about the sender

Even the cleanest email list won’t reach inboxes if your domain, IP address, or infrastructure have red flags. Deliverability testing looks beyond syntax to assess things like valid DNS records (SPF, DKIM, DMARC), sender reputation, and whether your sending infrastructure responds consistently. A single missing or misconfigured record can tank your chances, even if the email address itself is technically correct.

Real SMTP checks matter more than static checks

Many tools just scan an address for format flaws and domain validity. That’s surface-level. True deliverability testing simulates real sends—connecting to actual mail servers via SMTP, sending test messages, and reading the responses. This gives you insight into how your email would be handled in practice: whether it’s flagged as suspicious, throttled, blocked, or accepted.

For example, a domain might have a valid MX record, yet still be blocked due to poor reputation or being used by spammers in the past. Only by testing with actual SMTP connections can you see those signals. SMTP (RFC 5321) is the standard protocol used by mail servers to send and receive messages—and only tools that use it can provide accurate, realistic feedback.

MailTester performs this kind of testing at scale. It doesn’t just tell you if an email is syntactically valid—it checks whether your sending setup is trusted by real mail providers. This includes analyzing how your domain performs over time, whether a sender is on any blocklists, and if a message would trigger filters based on your sending habits. The result? A real-world forecast of where your email will land.

For a quick, accurate check, try our email checker to validate individual addresses before sending. For larger campaigns, use our inbox placement tester to see how real inboxes classify your message. And for developers, our real-time verification API embeds deliverability scoring directly into your workflow—keeping your lists clean and your sender reputation intact.

How does Mail-Tester perform deliverability testing?

Mail-Tester checks deliverability by sending a real email through SMTP to the target domain’s actual mail server, just like a human sender would. It reads the server’s exact response codes (like 250 for acceptance, 550 for rejection) and tracks whether the message is accepted, bounced, or delayed. This gives you a true-to-life view of how your email will behave, including greylisting, rate limiting, or content filtering — all without sending to actual users. The result is a realistic, measurable indicator of inbox placement risk.

Here’s how it works step by step

  1. Initiate a real SMTP session to the target domain’s mail server using a dedicated test inbox. This simulates an authentic, inbound email delivery attempt, bypassing client-side filters and focusing purely on server-level behavior.
  2. Parse the server’s response codes in real time — such as 250 (accepted), 550 (rejected), 450 (temporarily delayed). These codes are defined in RFC 5321 and are the authoritative language of email delivery, so they reflect actual mail server decisions.
  3. Monitor for greylisting, throttling, or rate limits. Some servers will accept the message temporarily but require a retry later, which Mail-Tester detects by tracking retry behavior and time delays. This mirrors how many enterprise and ISP systems handle traffic.
  4. Record the final outcome — accepted, rejected, delayed, or blocked. This data shows how likely your message is to reach an inbox without getting dropped by anti-spam systems.
  5. Apply context from reputation and infrastructure checks. Mail-Tester doesn’t just look at the response code; it analyzes the domain’s SPF, DKIM, and DMARC alignment, MX record health, and known blocklist status using tools like Spamhaus and MxToolbox to provide deeper insight.

Why this method matters

Unlike tools that guess based on patterns or public DNS data, Mail-Tester’s approach reflects how your actual message will be judged by real mail servers. This includes catch-all domains that accept all addresses (a red flag for spam risks), role accounts (like admin@ or support@) that may never receive your message, or disposable domains that reject incoming mail outright.

You’re not just checking if an email exists — you’re testing whether it will survive the journey from outbox to inbox. This level of realism is why Mail-Tester’s deliverability reports are trusted by teams running high-volume campaigns. For a detailed view of how this works in practice, test your own list with our inbox placement tester or verify your list before sending with our bulk verification tool.

What does GlockApps use for deliverability scoring?

GlockApps evaluates email deliverability using passive checks—syntax validation, DNS lookups (MX, SPF), and public blacklist status—without sending actual messages. It relies on heuristic rules and known data sources, not live SMTP interactions, which means its scores reflect only static risk signals, not real-world inbox placement. For comparison, MailTester uses real SMTP connections and inbox testing to simulate actual delivery, giving you a more accurate picture of how your emails will land in recipients’ inboxes.

Passive Checks vs. Active Testing

GlockApps doesn’t send test emails. Instead, it analyzes the email address and associated domain infrastructure using known standards. This includes checking whether the domain has a valid MX record, proper SPF alignment, or appears on public blocklists like Spamhaus (Spamhaus). It’s fast and efficient—but it’s also limited. It can’t detect issues like greylisting, rate limiting, or whether a mail server outright rejects your message based on sender reputation.

Because it never talks to mail servers in real time, GlockApps can’t assess how likely an email is to land in the inbox. A valid-looking address with strong DNS records might still be blocked due to sender reputation or sender policy, but a passive tool can’t see that. MailTester, by contrast, connects directly to the receiving mail server via SMTP and observes the real interaction—just like a real email campaign would.

Heuristic Rules and Public Data

Its scoring model combines known indicators—like common disposable domain patterns, role addresses (e.g., admin@, info@), or domain age—into a risk score. These are rules based on known behaviors of spam and bounce-prone addresses. For instance, short-lived domains or those with no proper MX records are marked as higher risk. But these rules are static and can’t adapt to real-time server behavior.

When you test an email address with GlockApps, you're getting a signal about its structural integrity and public risk profile—not whether it will actually receive your message. That’s why you may see a high score on GlockApps but still experience high bounce rates or poor inbox placement when you send. To validate that your list performs in the real world, use tools that simulate actual delivery.

If you want to test how truly deliverable your emails are, consider inbox placement tests or bulk list verification with real SMTP checks. These go beyond passive checks and give you a direct look at what mail servers will actually do with your email.

Which method is more accurate for inbox placement prediction?

Mail-Tester’s SMTP-based inbox placement testing is more accurate than passive methods like GlockApps because it simulates real delivery conditions — including SMTP handshakes, receiver policies, and temporary delays like greylisting. Passive checks can miss issues that only appear during actual mail transmission, leading to misleading results.

Why SMTP testing reflects real-world delivery

When you send an email via SMTP, you're not just checking if an address exists — you're engaging the receiving server exactly as a real sender would. Mail-Tester uses a real email infrastructure to send test messages to major inboxes (Gmail, Outlook, Yahoo, etc.) and monitors the full delivery path, including DNS lookups, authentication checks (SPF, DKIM, DMARC), and final inbox placement. This mirrors how your campaign will be judged.

According to RFC 5321 (the core SMTP standard), the delivery process includes negotiation, acceptance, and final decision-making by the recipient server — a process passive tools can’t observe. Passive checks only analyze DNS records and syntax, never testing the actual transaction that determines deliverability.

Where passive methods fall short

Passive tools like GlockApps rely on prebuilt databases and domain reputation scores. They may flag an address as “valid” if the domain exists and has a functional MX record. But this ignores dynamic behaviors: temporary greylisting (a common defensive tactic), IP-based rate limiting, or short-term policy changes that only appear during real SMTP delivery.

SMTP testing catches these real-time nuances. If a server temporarily blocks a sender IP due to suspected spam behavior, or enforces stricter spam filtering, Mail-Tester will detect it. Passive systems miss all this — they assume a static state that rarely exists in practice.

That’s why inbox placement is best tested with real SMTP delivery — not just by checking syntax, DNS, or domain reputation. You want to know what *actually happens* when your email arrives.

For teams who need precise inbox delivery forecasting, Mail-Tester offers a live inbox placement test that mirrors how your message will be received.

Test actual inbox placement today with real SMTP delivery to Gmail, Outlook, Yahoo, and more.

What do the different verdicts mean in Mail-Tester’s deliverability report?

You’re seeing different deliverability scores between Mail-Tester and GlockApps because they assess different things. Mail-Tester evaluates technical validity, server behavior (like catch-all detection), and risk flags—such as disposable domains or low engagement patterns—while GlockApps may weight sender reputation, engagement history, or inbox placement differently. The verdicts in Mail-Tester’s report are based on real-world SMTP interactions, not just statistical models. This means you're seeing whether an email address is structurally sound, accepted by the server, and likely to be delivered or caught as spam. For a more complete picture, cross-reference with tools like MxToolbox for DNS checks or Spamhaus to see if your domain is on a blocklist.

Verdicts Explained

Understanding these verdicts helps you act faster on your list quality. Let’s break them down.

Verdict What it means Recommended action
Valid The address passes syntax and server acceptance tests. It’s not rejected by the SMTP server and exists in the domain’s mail system. Proceed with sending. Monitor engagement and spam complaints. Use Mail-Tester’s email checker to confirm individual addresses before sending.
Catch-all The server accepts all emails sent to it, regardless of recipient. Often found in role addresses (e.g. team@, support@) or old infrastructure. High risk of spam traps or bounces. Avoid these in campaigns. They may appear valid but often lead to high bounce rates or trigger spam filters. Use Mail-Tester’s API to detect and filter them at scale.
Risky The address is technically valid but associated with red flags: known disposable domains, low engagement history, or frequent abuse patterns. Use with caution. Consider suppressing or warming up such addresses. Check domain reputation via Spamhaus or MxToolbox.
Invalid The address fails syntax checks (e.g. missing @, invalid TLD), or is outright rejected by the server (non-existent mailbox, syntax error). Remove immediately. Invalid addresses harm sender reputation and increase bounce rates. Audit your list with Mail-Tester’s bulk verification tool.

Why Score Differences Happen

Scoring differences stem from varying models. GlockApps may incorporate engagement data, time-based decay, or blocklist status—elements Mail-Tester doesn’t capture. Mail-Tester focuses on technical deliverability gates: whether the server accepts the email, whether it's a catch-all, and whether the domain or address has known risk traits. A valid address can still end up in spam if it’s associated with a poor sender reputation, but Mail-Tester won’t detect that unless it’s part of a known risk pattern. For a full assessment, combine Mail-Tester with inbox placement tools like Mail-Tester’s inbox tester to see how your message actually lands.

How does SMTP verification detect greylisting and temporary rejection?

Mail-Tester simulates real email delivery by retrying connections after a delay, which exposes greylisting. If a server accepts the message on the second attempt but rejected the first, it’s a strong sign of temporary rejection—commonly due to greylisting—rather than a permanent block. This behavior is captured and included in the deliverability score.

Simulating Real Delivery Behavior

When you send an email, major mail providers don’t always respond immediately. Many use greylisting: temporarily rejecting messages to verify the sending server’s legitimacy. The real world expects senders to retry after a pause. Mail-Tester mimics this by waiting 15–30 seconds before retrying—just like a proper sending system should.

If the server accepts the message on the retry, you now know it was not a hard bounce. This isn’t a failure—it’s a known, temporary condition. Mail-Tester treats such responses as indicators of potential deliverability risk, not outright failure, and adjusts the score accordingly.

Why This Matters for Your Deliverability Score

Greylisting itself doesn’t block delivery—it delays it. But repeated temporary rejections can hurt sender reputation over time, especially if your infrastructure doesn’t handle retries correctly. By detecting these patterns, Mail-Tester surfaces issues before they impact real campaigns.

For example, a domain might score 85% deliverability because it’s greylisted on the first try. Without retry logic, you’d assume it’s invalid. But Mail-Tester sees the second success and flags it as “temporarily rejected,” which helps prevent false negatives in list cleaning.

Learn more about how we validate email addresses at scale: bulk verification or explore the real-time API for automated testing.

For deeper insights into how mail servers validate senders, see the IETF’s formal specification on greylisting, which outlines how temporary failures are used to filter spam.

Why does a valid address still score poorly on GlockApps?

A valid email address can still score poorly on GlockApps because the tool assesses static factors—like domain reputation or disposable email usage—without testing whether your actual message lands in the inbox. Unlike tools that simulate real sends, GlockApps can't evaluate how mail servers treat your content, sender history, or inbox placement performance. A high score here doesn’t mean your email will actually reach the inbox.

Static scores vs. real inbox placement

MailTester uses real-time delivery tests to simulate actual send behavior. It checks whether a message reaches the inbox, is flagged as spam, or bounces—giving you a live picture of deliverability risk. GlockApps, by contrast, relies on historical data points and blacklists, which often miss the nuances of current sender reputation and content filtering. An address may be technically valid, but if it's linked to old spam campaigns or sits on a shared IP with poor sender history, it will score low.

Disposable email domains are another common reason for poor scores. These domains—like those from temp-mail services—are frequently used for sign-ups, bot activity, or temporary accounts. Even if the email syntax is correct, the inbox placement risk is high because providers actively filter or block messages sent to them. Tools like GlockApps flag these domains based on known patterns, while MailTester can confirm whether a real message actually arrives.

Sender reputation matters more than syntax

Even if an address is format-correct and the domain has a proper MX record, the overall sender reputation can still hurt deliverability. This includes your sending volume, complaint rate, bounce rate, and alignment with authentication standards like SPF, DKIM, and DMARC. A long-standing sender with poor engagement or a sudden spike in bounces can trigger spam filters—even if the recipient’s address is technically valid.

MailTester goes beyond syntax checks by testing a message in real-world conditions. You’re not just verifying “is this address valid?”—you’re asking, “will it reach the inbox?” That difference is why MailTester’s inbox placement test is linked to delivery outcomes. For teams relying on accurate sender data, that real-world validation matters more than static, score-based assessments.

Test actual inbox placement with MailTester’s Inbox Placement tool, which uses real sending to measure deliverability risk.

Can I improve my deliverability score across both tools?

You can improve your deliverability score on both Mail-Tester and GlockApps by checking your list for invalid, catch-all, and disposable emails, verifying your domain’s authentication (SPF, DKIM, DMARC), and ensuring your sending domain has a clean reputation. These are the core technical and hygiene factors that affect all email verification tools and actual mail servers alike. Let's address each one.

Use Mail-Tester’s deliverability tests to identify problems early

Before sending to real inboxes, run your list through Mail-Tester’s inbox placement test to simulate how your message lands across real providers. This reveals how your sender reputation, content, and authentication stack up in practice.

  • Test your message's inbox placement using Mail-Tester’s real inboxes to see how it performs against spam filters.
  • Use the bulk verification tool to scrub your list before sending, removing bounces and risky addresses that hurt deliverability.
  • Check results for catch-all or risky addresses—these may not bounce immediately but still harm sender reputation.

Fix domain and sender-level issues that affect both tools

Both Mail-Tester and GlockApps rely on the same underlying email infrastructure. If your domain is misconfigured or your sending history is poor, scores will reflect that.

  • Verify your SPF, DKIM, and DMARC records using MXToolbox or similar tools—it’s an industry-standard practice to prevent spoofing and improve trust.
  • Remove catch-all addresses. They don’t reject invalid emails, which can lead to wasted sends and increased spam complaints. Mail-Tester flags these explicitly.
  • Eliminate disposable email domains. These are often linked to temporary accounts and abused by bots. Services like Spamhaus list many such domains as high-risk.
  • Ensure your sending domain has no prior abuse history. Check past blacklisting through AbuseIPDB or Spamhaus before sending to new lists.
Deliverability isn't just about the list—it's about who you are, how you send, and what servers trust.

Running a clean, well-verified list with proper domain authentication dramatically improves your chances of landing in the inbox, regardless of which tool you’re checking. The same fundamentals apply to both verification services and actual email delivery.

Do Mail-Tester and GlockApps test the same email addresses the same way?

No—they use different verification logic and test scope. Mail-Tester performs active SMTP verification by simulating actual email delivery, testing the full inbound pipeline like a real sender would. GlockApps relies more on passive checks, using public data, syntax rules, and heuristic pattern matching without sending messages to the recipient’s server.

How Mail-Tester verifies email addresses

You send an email, and Mail-Tester actually reaches out to the recipient’s mail server using SMTP—just like a real sending platform would. This includes checking if the domain has valid MX records, if the mailbox exists, and whether it accepts incoming mail. This active simulation gives a realistic forecast of inbox placement.

Because we test real delivery paths—bypassing spam filters, greylisting, and bounce handling—our results reflect actual deliverability more accurately than passive tools. This is why MailTester’s accuracy rating is 98.9%: it’s built on real-world behavior, not assumptions.

How GlockApps differs in its approach

GlockApps uses a mix of static data, domain reputation, and pattern matching—like checking a known disposable domain list or spotting common role-account patterns. It doesn’t send messages, so it can’t validate if a server actually accepts the email, nor can it detect temporary delivery blocks like greylisting or rate limiting.

While this method is faster and lower cost, it doesn’t account for dynamic delivery conditions. A mailbox might be valid in theory, yet still bounce due to a temporary server policy—even if the address is syntactically correct. That gap between “valid” and “deliverable” is why passive checks can't fully predict inbox placement.

For example, RFC 5321 defines SMTP behavior, including how servers handle rejections during transaction phases. Mail-Tester’s SMTP flow follows these standards, while passive tools do not simulate that phase at all. This is why you see different results: one tool sees a mailbox as “safe” based on known patterns, while another tests live delivery and finds it rejected.

Ultimately, if your goal is to know how well your emails land in inboxes—not just whether an address is syntactically valid—active testing like Mail-Tester’s gives you the data that actually matters. Test it yourself: try a real email list with our bulk verification tool, or check individual addresses with our email checker before sending.

The bottom line: Which tool gives a more reliable deliverability score?

Mail-Tester’s deliverability tests reflect real-world conditions. By sending actual SMTP transactions, it captures how a server responds in practice—whether it greylists, rate-limits, or flags messages as spam.

GlockApps offers a fast, rule-based assessment based on heuristics and known blacklists. It’s useful for quick checks but cannot confirm whether an email actually reaches the inbox.

For accurate inbox placement prediction, rely on real SMTP behavior. Mail-Tester’s method, while slower, delivers actionable, up-to-the-minute insight on delivery success.

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Why does Mail-Tester say an email is deliverable but GlockApps says it’s risky?

Mail-Tester confirms actual delivery via SMTP; GlockApps assigns risk based on static criteria like domain type and known patterns. A valid address may be flagged by GlockApps due to past abuse or disposable nature, even if it delivers today.

Do deliverability scores change over time?

Yes. Server policies, sender reputation, and domain configurations change. A score verified today may differ in a month.

Why don’t both tools use SMTP verification?

SMTP testing is resource-intensive and takes longer. GlockApps prioritizes speed and volume over real-world simulation.

Can I trust a catch-all address for deliverability?

No. Catch-all addresses accept all mail, but they often go to spam, aren’t monitored, and signal poor list hygiene to servers.

Does Mail-Tester send real emails to recipient servers?

Yes. Mail-Tester sends test messages via SMTP to real mail servers, using dedicated test inboxes. No personal or marketing content is sent.

How accurate is Mail-Tester’s deliverability test?

Mail-Tester achieves 98.9% accuracy in identifying valid versus invalid addresses and delivers reliable deliverability insights through live SMTP interaction.

Is SMTP verification allowed by most email providers?

Yes. Most providers accept test messages from known, clean IPs and well-formed addresses. Mail-Tester uses non-invasive, compliant testing practices.

Why would a valid address be rejected during SMTP testing?

Common reasons include temporary greylisting, server policy, or the recipient’s inbox being full. These are captured during real SMTP interaction and reflected in the deliverability score.

Can I automate deliverability testing with Mail-Tester?

Yes. Mail-Tester offers a real-time API and bulk verification tools that integrate with Mailchimp, Hubspot, Klaviyo, and SendGrid.

Do disposable emails hurt deliverability, even if they accept messages?

Yes. Disposable domains often have poor sender reputations and high bounce rates. Even if an email is accepted, it’s likely to be flagged by spam filters.

How do I fix a low deliverability score?

Use Mail-Tester to verify your list, remove catch-all, disposable, and invalid addresses, and ensure your domain has proper authentication (SPF, DKIM, DMARC).

Why does my list score better on Mail-Tester than GlockApps?

Mail-Tester confirms actual delivery via live SMTP. GlockApps uses a broader set of risk rules that may flag safe addresses as high-risk due to domain classification or history.