An email deliverability checker helps you answer a question that a “sent” status cannot: did your message authenticate correctly, reach the receiving provider, avoid spam filtering, and land where a subscriber can actually see it? The best approach is not one score from one tool—it is a repeatable system for checking identity, infrastructure, recipient quality, and provider feedback.

What an email deliverability checker should actually check

“Email deliverability” is often used to mean inbox placement, but it covers several distinct stages. A message can be accepted by a receiving server yet still land in spam, be placed in a secondary tab, be deferred, or be rejected later because of a policy or reputation issue.

A useful email deliverability checker therefore needs to examine five layers:

  1. Domain authentication: Whether SPF, DKIM, and DMARC are present and passing.
  2. Sending infrastructure: Whether DNS, reverse DNS, TLS, and sending-domain configuration are valid.
  3. Message construction: Whether headers, From addresses, unsubscribe mechanisms, links, and content are technically sound.
  4. Recipient quality: Whether you are sending to valid, opted-in, reasonably current addresses.
  5. Mailbox-provider signals: Whether Gmail, Outlook.com, Yahoo, and other providers report complaints, reputation problems, authentication failures, or delivery errors.

A tool that checks only whether an address exists is an email verifier, not a complete deliverability checker. A tool that sends one test message to a seed inbox is an inbox-placement test, not a reputation monitor. Both are useful, but they solve different problems.

The practical goal is not to chase a universal “deliverability score.” Mailbox providers do not publish a single shared score, and each provider evaluates mail differently. Your goal is to remove deterministic technical failures, monitor provider-specific evidence, and send mail that recipients expect and want.

Start with the four checks that catch the biggest failures

Before buying an inbox-testing platform or redesigning an email template, check the basics that are most likely to produce hard failures.

1. Confirm the visible From domain is yours

Your From address should use a domain you control, such as updates@example.com or hello@example.com. Avoid sending commercial email from a consumer mailbox address such as Gmail, Yahoo, or Outlook.com through an unrelated platform.

The visible From domain is especially important because DMARC evaluates alignment with the domain shown to the recipient. If your message says it is from news@example.com, but SPF and DKIM authenticate only a vendor domain, the message may fail DMARC alignment.

Use a dedicated sending subdomain when you want to separate email streams. For example:

  • notify.example.com for application notifications
  • news.example.com for newsletters
  • billing.example.com for receipts and payment notices

This separation can make troubleshooting clearer, but it does not erase responsibility for the underlying brand or list practices. Do not create subdomains merely to escape a poor sending reputation.

2. Check SPF without creating multiple SPF records

SPF is a DNS TXT record that authorizes systems to use a domain in the SMTP envelope sender, commonly called the return-path or MAIL FROM domain. Receiving servers query that record to determine whether the sending system is permitted to send on the domain’s behalf.

A simple SPF record might look like this:

example.com. IN TXT "v=spf1 include:spf.email-provider.example -all"

The include value is vendor-specific. Your email provider should supply the exact include domain or another approved mechanism. Do not copy a provider’s example record unless it is actually the provider that sends your mail.

The common failure is publishing two separate SPF TXT records:

example.com. IN TXT "v=spf1 include:provider-a.example -all"
example.com. IN TXT "v=spf1 include:provider-b.example -all"

That is invalid for SPF evaluation. Merge the authorized mechanisms into one SPF record instead:

example.com. IN TXT "v=spf1 include:provider-a.example include:provider-b.example -all"

SPF evaluation also has a DNS lookup limit. Complex chains of include, a, mx, exists, redirect, and ptr mechanisms can exceed the protocol’s limit and return a permanent SPF error. An email deliverability checker should identify both duplicate records and excessive lookup depth.

3. Confirm DKIM is signing your actual messages

DKIM adds a cryptographic signature to each message. The sending platform signs the email with a private key, while receiving systems retrieve the corresponding public key from DNS.

A DKIM DNS record is commonly published at a selector hostname such as:

selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY"

The selector (selector1) and public key are generated by the mail platform. Do not invent the value after p=. Copy the key exactly from your provider, publish it in DNS, and then send a fresh test message.

A DKIM record existing in DNS is not enough. Check an actual message’s headers for a result such as:

dkim=pass header.d=example.com

If the header instead shows dkim=fail, the cause may be a missing DNS record, a wrong selector, a key that has not propagated, or a message modified after signing. If it shows dkim=pass for a vendor domain rather than your domain, it may still be insufficient for DMARC alignment.

4. Publish DMARC and inspect alignment

DMARC tells receivers how to evaluate the domain in the visible From header against SPF and DKIM. It also lets a domain owner request aggregate reports about authentication results.

A cautious starting record is:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100"

This record asks receivers to monitor rather than quarantine or reject unauthenticated mail. The rua mailbox receives aggregate reports, usually as XML attachments. Use a mailbox or reporting service that can receive and process those reports; a normal shared inbox becomes difficult to manage quickly.

The crucial condition is alignment. In simplified terms, DMARC passes when either of these is true:

  • SPF passes and the authenticated SPF domain aligns with the visible From domain.
  • DKIM passes and the DKIM signing domain aligns with the visible From domain.

For example, a message from newsletter@example.com with dkim=pass header.d=example.com normally passes aligned DKIM under relaxed alignment. A message from newsletter@example.com signed only as header.d=email-provider.example does not align.

How to run a practical deliverability test

A reliable test has two parts: inspect the message before a campaign, then review production evidence after recipients receive it. Testing only before send misses real reputation and complaint signals. Monitoring only after send makes preventable configuration errors harder to isolate.

Build a small testing matrix

Send a representative production-like message to mailboxes you control at major providers. At a minimum, include:

  • A personal Gmail account
  • An Outlook.com or Hotmail account
  • A Yahoo Mail account
  • An iCloud Mail account, if it represents a meaningful segment of your audience
  • One work mailbox, if your audience is mainly business recipients

Use the actual sender, sending domain, tracking configuration, link domains, and unsubscribe setup you will use in production. A plain-text message sent from a developer’s desktop does not validate a marketing campaign sent through a different provider and domain.

Open each message and record:

  • Was it delivered, deferred, or rejected?
  • Did it land in Inbox, Spam/Junk, Promotions, or another category?
  • Does the visible From address look correct?
  • Do the links resolve to the intended domain and secure HTTPS pages?
  • Does the unsubscribe flow work?
  • Do the authentication results show SPF, DKIM, and DMARC passing?

Seed inboxes are diagnostic samples, not a statistically complete verdict. Mailbox placement can vary by recipient history, engagement, local filtering, device, and provider. Treat a seed test as a smoke test for defects and a way to compare changes—not proof that every subscriber will see the same placement.

Inspect raw message headers

Headers are the most concrete evidence in an email deliverability check. In Gmail, use Show original. Other providers offer similar options such as viewing message source or internet headers.

Look for an Authentication-Results header resembling this:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=bounce.example.com;
       dkim=pass header.d=example.com;
       dmarc=pass header.from=example.com

The exact hostname and formatting vary by receiving provider, but the interpretation is consistent:

  • SPF pass means the sending IP was authorized for the envelope-sender domain.
  • DKIM pass means the signature validated for the signing domain.
  • DMARC pass means the visible From domain aligned with a passing SPF or DKIM identity.

If the message enters spam but all three pass, authentication is not your immediate problem. Investigate reputation, complaints, abrupt volume changes, list quality, recipient engagement, content patterns, or an unfamiliar tracking domain.

If DMARC fails, do not assume a DNS change alone will fix it. Compare the three domains visible in the headers: the From domain, the SPF smtp.mailfrom domain, and the DKIM header.d domain. One of the latter two must pass and align with the From domain.

Use mailbox-provider dashboards, not just third-party scores

Third-party checkers are convenient, especially for DNS, header parsing, blocklist checks, and seed testing. But providers’ own dashboards offer the best available evidence of how those providers see your mail.

Google Postmaster Tools

Google Postmaster Tools provides qualified senders with dashboards for outgoing mail sent to personal Gmail accounts. Available data can include spam rate, domain and IP reputation, authentication, encryption, delivery errors, feedback-loop data, and sender-guideline compliance.

Add and verify each sending domain you use. Then review the data on a schedule appropriate to your volume—weekly for steady programs, and more frequently during a migration, launch, or reputation incident.

Important limitations apply:

  • Dashboard data is not real time.
  • Low volume can result in limited or missing data.
  • Some views rely on DKIM-authenticated traffic.
  • Gmail data describes personal Gmail recipients, not every mailbox provider.

For Gmail, keep the spam rate reported in Postmaster Tools below 0.3%. That is a ceiling, not a target. A team that waits until it approaches the maximum has little room for a bad campaign, a compromised form, or a list-quality failure.

Microsoft SNDS and junk reports

Outlook.com’s Smart Network Data Services (SNDS) provides reputation-related data for IP addresses used to send to Outlook.com. It can also be used alongside Microsoft’s junk-reporting program to receive reports when users mark messages as junk.

SNDS is primarily IP-focused. That matters if you use shared sending infrastructure: the email platform controls the IP, so you may not have direct access or may receive an incomplete view. Ask your provider what reputation and feedback data it exposes for shared versus dedicated IPs.

SNDS should not be used as a universal inbox-placement checker. It is one source of Outlook.com-specific operational evidence. Pair it with message-header checks, your delivery and bounce data, and Google Postmaster Tools if Gmail is material to your audience.

Yahoo sender requirements

Yahoo’s sender guidance emphasizes authentication, low complaint rates, valid forward and reverse DNS, message-format compliance, and easy unsubscribe mechanisms. For bulk senders, Yahoo requires SPF and DKIM, a valid DMARC policy at least at p=none, and DMARC alignment between the From domain and SPF or DKIM.

That makes Yahoo an important reason not to treat SPF, DKIM, and DMARC as one-time DNS chores. They must work on the messages that your platform sends every day.

Check unsubscribe headers and consent flows

Deliverability is affected by recipient behavior. When recipients cannot easily stop unwanted mail, they are more likely to use the spam button. That complaint becomes a provider-level signal about your sending program.

Marketing and subscription mail should include a clear body unsubscribe link. Bulk senders should also support list-unsubscribe headers. A typical implementation is:

List-Unsubscribe: <https://example.com/unsubscribe/abc123>, <mailto:unsubscribe@example.com?subject=unsubscribe>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The List-Unsubscribe-Post header supports the one-click method defined by RFC 8058. The endpoint must process the request correctly; adding a header that points to a broken page is worse than omitting it because it creates a misleading compliance signal and frustrates recipients.

Test unsubscribes as part of every major template or provider change:

  1. Send a test message to a real address you control.
  2. Use the mailbox provider’s unsubscribe interface if shown.
  3. Use the footer link as well.
  4. Confirm the address is suppressed in your sending system.
  5. Attempt to send to that address again only in a safe test environment, or inspect the suppression record rather than sending another promotional message.

Yahoo states that unsubscribes should be honored within two days. Operationally, faster is better: immediate suppression prevents accidental sends during imports, campaign scheduling, or segment syncs.

Validate recipient lists before you send

A flawless DNS configuration cannot compensate for mailing nonexistent, abandoned, mistyped, or unconsented addresses. Invalid recipients create bounces; disengaged or unexpected recipients can create complaints.

Use address validation at the point of collection and before importing an old, purchased, partner-supplied, or manually assembled list. A validation tool can detect syntax issues, malformed domains, missing mail exchange records, obvious disposable addresses, and—in some cases—whether a mailbox can plausibly receive mail.

Use an email address verification tool as a screening layer, but do not interpret “valid” as permission to email someone. Validation checks technical deliverability; consent and relevance are separate requirements.

Treat risky results carefully

Some mailbox providers intentionally make mailbox-level verification uncertain to protect users. Catch-all domains can accept mail for any local part, and privacy-oriented providers may not reveal whether a specific mailbox exists. A verifier may classify these addresses as risky or unknown rather than definitively valid or invalid.

Do not repeatedly probe those addresses or force them into the main campaign simply because they are not an obvious hard bounce. For an old or uncertain list, use a conservative re-engagement approach, suppress non-engagers, and avoid sudden large-volume sends.

A sensible list-hygiene policy includes:

  • Rejecting malformed signups immediately.
  • Using double opt-in where it fits the acquisition flow and risk profile.
  • Suppressing hard bounces as soon as they occur.
  • Respecting unsubscribes and spam complaints permanently unless a recipient actively re-subscribes through a documented process.
  • Segmenting by recent engagement rather than continually mailing inactive contacts.
  • Investigating sharp bounce-rate changes by source, form, integration, country, and campaign.

Run DNS and infrastructure checks yourself

Browser-based checkers are helpful, but command-line checks make it easier to confirm what public DNS actually returns. Replace example.com with your domain.

Query TXT records

dig TXT example.com +short
dig TXT _dmarc.example.com +short
dig TXT selector1._domainkey.example.com +short

You want to see one valid SPF record at the sending domain, a DMARC record at _dmarc, and a DKIM public key at the selector hostname configured by your provider.

Check mail routing and reverse DNS

dig MX example.com +short
dig -x 203.0.113.25 +short

The first command checks the MX records for mail received by your domain. The second performs a reverse-DNS lookup for a sending IP. The IP in the example is documentation-only; use the actual IP shown in your message headers or supplied by your provider.

For direct or dedicated-IP sending, forward and reverse DNS should be valid and coherent. If you use a reputable shared infrastructure provider, that provider generally controls the sending IP’s reverse DNS, while you control your authentication and custom-domain settings.

Check transport encryption and hostname behavior

Gmail and Yahoo require TLS for relevant sender traffic. Most modern email providers negotiate TLS automatically, but it remains worth confirming from message headers or provider documentation—especially if you operate your own SMTP server or relay.

If you send mail directly, also check that the SMTP server’s HELO/EHLO hostname, forward DNS, reverse DNS, and TLS certificate setup match the infrastructure you operate. Inconsistent identity signals create unnecessary risk even when SPF is technically valid.

Worked example: fixing a DMARC alignment failure

Imagine a SaaS company, Northstar Analytics, sends newsletters from updates@northstar.example. Its delivery dashboard reports successful sends, but a Gmail test inbox puts campaigns in spam. The raw headers show:

spf=pass smtp.mailfrom=mailer.vendor-mail.example
dkim=pass header.d=vendor-mail.example
dmarc=fail header.from=northstar.example

The problem is not that authentication is entirely absent. SPF and DKIM both pass—but only for the vendor’s domain. Neither identity aligns with northstar.example, the visible From domain.

Step 1: configure a branded sending domain

Northstar creates mail.northstar.example and uses the email provider’s domain-authentication flow. The provider supplies vendor-specific DNS records, which might include:

  • A DKIM CNAME or TXT record for one or more selectors.
  • A custom return-path or MAIL FROM record under mail.northstar.example.
  • A tracking-domain CNAME, if click tracking is enabled.

Northstar copies those exact values into DNS. It does not replace the provider values with generic examples.

Step 2: publish one SPF record

If Northstar needs SPF for the custom MAIL FROM domain, it publishes the provider-provided value. If it sends from multiple authorized services, its DNS administrator merges them into a single SPF record instead of creating duplicates.

For the organizational domain, the final record could conceptually be:

northstar.example. IN TXT "v=spf1 include:spf.transactional-provider.example include:spf.marketing-provider.example -all"

The real include domains must come from the actual services Northstar uses. Before publishing, the team checks that the combined SPF policy stays within protocol lookup limits.

Step 3: publish DMARC in monitoring mode

Northstar adds:

_dmarc.northstar.example. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@northstar.example; adkim=r; aspf=r; pct=100"

The company leaves the policy at p=none while it discovers every legitimate service that sends mail as its domain. This is important: moving immediately to p=reject can block valid operational messages from a help desk, invoice system, CRM, recruiting tool, or website form if they have not been authenticated.

Step 4: test a real campaign message

After DNS propagation and provider verification, Northstar sends the same campaign to its controlled Gmail, Outlook.com, and Yahoo test addresses. Gmail headers now show:

spf=pass smtp.mailfrom=mail.northstar.example
dkim=pass header.d=northstar.example
dmarc=pass header.from=northstar.example

This is the technical success condition: at least one of SPF or DKIM passes with an identity aligned to the visible From domain. Northstar then validates the unsubscribe headers, checks that links use the intended branded tracking domain, and confirms recipients can opt out.

Step 5: monitor production, not only test mail

Northstar verifies northstar.example in Google Postmaster Tools and begins reviewing spam rate, authentication, delivery errors, and reputation data when enough Gmail volume is available. It also watches campaign-level bounces, complaints, unsubscribes, and engagement by acquisition source.

If the technical checks pass but inbox placement remains poor, the next change should be audience-focused: send first to recently engaged subscribers, remove problematic acquisition sources, reduce frequency where appropriate, and stop mailing recipients who do not respond over time. Changing subject lines alone does not repair a reputation or consent problem.

For teams implementing email sending in an application, keep the exact provider records, domain-verification steps, webhook setup, and suppression handling documented alongside the email API setup guides. That makes a future provider migration or incident much easier to manage.

Common email deliverability checker mistakes

Mistake: trusting a green score as an inbox guarantee

A score can reveal broken DNS, missing headers, or obvious content risks. It cannot reproduce every recipient’s engagement history or every mailbox provider’s private filtering logic. Use scores to prioritize technical fixes, then validate with headers and provider dashboards.

Mistake: testing from a different domain than production

A test from founder@company.com says little about a campaign sent from news.company.com through a marketing platform. Test the same authenticated domain, message type, tracking configuration, and provider you will use in production.

Mistake: assuming delivery means inbox placement

An SMTP acceptance event means the recipient server accepted the message. It does not mean the message reached the inbox. Separate these metrics in reporting: accepted, deferred, bounced, spam/junk placement, inbox placement, and engagement are not interchangeable.

Mistake: changing everything at once

If you switch providers, change the From domain, rewrite content, upload a dormant list, and increase volume in the same week, you will not know which change caused an improvement or failure. Make a controlled change, observe the relevant data, and document the outcome.

Mistake: confusing low opens with a technical block

Open measurement can be limited by privacy features, image blocking, and client behavior. Do not diagnose a deliverability crisis from opens alone. Compare it with bounce codes, complaints, clicks, conversions, reply rates where relevant, Postmaster data, and controlled inbox tests.

A repeatable weekly deliverability checklist

For an active email program, use this lightweight operating rhythm:

  1. Before a major send: send a production-like test to controlled mailboxes and inspect headers.
  2. After DNS or provider changes: recheck SPF, DKIM, DMARC, custom MAIL FROM, tracking domains, and unsubscribe behavior.
  3. Weekly: review bounces, complaints, unsubscribes, volume changes, and campaign performance by list source.
  4. Weekly or monthly, depending on volume: review Google Postmaster Tools and Microsoft SNDS where you have access and sufficient traffic.
  5. At import time: validate addresses, document consent source, and quarantine unfamiliar or stale lists.
  6. After any anomaly: segment the issue by provider, domain, IP, campaign, signup source, template, and date rather than treating deliverability as one account-wide number.

The result should be a simple record of what changed, what the headers showed, which provider metrics moved, and whether the change improved the outcome. That operational history is more valuable than a one-off checker score.

When to use a deliverability consultant or specialist tool

Most teams can diagnose basic issues with DNS lookups, message headers, their email platform, provider dashboards, and controlled seed accounts. Bring in specialist help when you have persistent spam placement despite passing authentication, a sudden rejection or deferral pattern, suspected domain spoofing, a high-volume migration, dedicated IP infrastructure, or a regulated program where consent records and suppression handling require careful review.

Specialist inbox-placement platforms can be worthwhile for high-volume programs that need ongoing seed monitoring across many providers and regions. Evaluate them by asking what they measure directly, how often seed data updates, whether they distinguish inbox from spam and tabs, how they handle privacy, and whether their guidance can be verified in raw headers and provider dashboards.

The tool should make your sending operation more observable. If it gives only a mysterious score without exposing failed records, headers, provider results, or recommended remediation, it is not enough to run a serious program.

Conclusion

The best email deliverability checker is a workflow, not a single website. Start by verifying SPF, DKIM, DMARC alignment, reverse DNS, TLS, and unsubscribe headers. Then test real messages at major mailbox providers, inspect raw headers, validate the list you intend to mail, and monitor first-party dashboards where available.

When something goes wrong, identify the layer first. A DMARC failure needs alignment work; a hard-bounce spike needs list-source investigation; spam placement with clean authentication needs a reputation, consent, frequency, or engagement response. That discipline turns deliverability from guesswork into a measurable part of your email operation.

FAQ

What is an email deliverability checker?

An email deliverability checker is a tool or process that evaluates whether your email configuration and messages are likely to be accepted and placed appropriately by receiving mailbox providers. A complete check includes authentication, headers, DNS, list quality, inbox testing, and provider reputation data.

Can an email deliverability checker guarantee inbox placement?

No. No external tool can guarantee inbox placement for every recipient because mailbox providers use private filtering systems and recipient-specific signals. A checker can identify configuration failures, detect risk factors, and show evidence from controlled tests and provider dashboards.

What should pass in an email header?

Look for spf=pass, dkim=pass, and dmarc=pass. For DMARC, either the SPF domain or DKIM signing domain must align with the domain in the visible From address.

Does a valid email address mean I can send to it?

No. Address validation checks technical plausibility, not consent or relevance. You still need a lawful, permission-based reason to send and an effective way for recipients to unsubscribe.

Why do emails go to spam even when SPF, DKIM, and DMARC pass?

Authentication proves sending identity; it does not prove that recipients want the message. Spam placement can still result from complaints, poor list quality, low engagement, unexpected frequency, abrupt volume changes, weak sender reputation, or content and link patterns that filters consider risky.