Email Deliverability Check: How to Test, Diagnose, and Fix Inbox Placement

An email deliverability check tells you whether your messages are technically valid, reach mailbox providers, avoid spam filtering, and arrive where subscribers are likely to see them. The practical goal is not a vanity score: it is to find the specific failure—authentication, infrastructure, list quality, message structure, reputation, or recipient complaints—then verify the fix with a controlled send.

What an email deliverability check actually measures

Many teams treat delivery as a binary event: the email API accepted the request, so the campaign must have worked. That is incomplete. A message can be accepted by your sending provider, rejected by the recipient server, delivered to spam, routed to a Promotions-type category, or accepted but later hidden from prominent placement because the recipient has low engagement.

A useful email deliverability check separates four outcomes:

1. Submission: your application or email platform accepted the message for sending.
2. Delivery: the receiving mail server accepted the SMTP transaction.
3. Inbox placement: a delivered message appears in the primary inbox or another visible inbox category instead of spam.
4. Recipient response: the message generates the expected safe signals—opens where measurable, replies, clicks, saves, or other positive engagement—rather than bounces, unsubscribes, and spam complaints.

Mailbox providers evaluate multiple signals rather than a single “spam score.” Google’s sender guidance explicitly connects authentication, PTR records, TLS, message formatting, and reported spam rates with successful delivery to personal Gmail accounts. Yahoo likewise calls out authentication, low complaints, forward and reverse DNS, standards-compliant messages, easy unsubscribe, and audience relevance. (support.google.com)

That means a deliverability check must test both the message and the sending system. A polished email with broken DMARC alignment can fail. A fully authenticated email can still land in spam if the list is stale, recipients complain, or the campaign is abruptly sent at a volume that is out of character for the domain.

Start with the right diagnosis: delivery, spam, or reputation?

Before changing DNS records or rewriting copy, classify the symptom. Each symptom points to a different part of the mail pipeline.

Messages bounce or are rejected

A bounce is an SMTP-level failure. It may be permanent, such as a nonexistent recipient address, or temporary, such as a mailbox that is unavailable, a rate limit, or a receiving server that asks you to retry. Save the full SMTP response, not just a dashboard label like “failed.” The response often identifies the mailbox provider and category of problem—authentication, policy, reputation, recipient unknown, or throttling.

If a new campaign causes rejection at one provider but not another, investigate that provider’s requirements and your sending pattern first. Gmail’s guidelines, for example, say that noncompliance can lead to rate limiting, blocking, or spam classification; Yahoo also publishes sender requirements and SMTP error-code guidance. (support.google.com)

Messages are delivered but go to spam

Spam placement normally means the receiving system accepted the message but judged it risky or unwanted. Start by checking authentication results in the received message headers, then inspect list source, complaints, unsubscribe behavior, recent volume changes, and campaign relevance.

Do not conclude that the email body alone caused spam placement. Content can matter, particularly malformed HTML, misleading links, or heavily promotional patterns, but a mailbox provider can make different decisions for different recipients based on its own filtering and user-level signals. A single testing tool can expose technical defects, but it cannot promise inbox placement everywhere. (reception.mail-tester.com)

Messages are delivered to the inbox, but results are weak

This is not necessarily an infrastructure problem. Check whether the subject line accurately sets expectations, whether the email is useful to the segment receiving it, and whether the call to action matches what people subscribed to receive. A low-engagement campaign sent to a large inactive segment can eventually become a deliverability problem, because disengaged recipients are more likely to ignore, delete, unsubscribe from, or report future mail.

A test works, but production fails

This is common. Your own Gmail and Outlook inboxes are not a representative sample of your audience, and a small personal test does not reproduce a large campaign’s volume, recipient mix, or historical behavior. Treat personal inboxes as a smoke test, then use mailbox-provider telemetry, seed-list placement tests, bounce logs, and controlled production sends to establish what is actually happening.

The deliverability baseline: authenticate every sending domain

Authentication is the first gate in an email deliverability check. It proves that the systems sending a message are allowed to use the domain and helps receivers associate the visible sender identity with a verifiable domain.

For messages sent to personal Gmail accounts, Google requires all senders to use SPF or DKIM; senders above its bulk threshold must use SPF, DKIM, and DMARC. Google defines that threshold as more than 5,000 messages per day to Gmail accounts. Yahoo’s published bulk-sender requirements likewise call for SPF, DKIM, DMARC, and alignment between the visible From domain and an authenticated SPF or DKIM domain. (support.google.com)

SPF: authorize the envelope sender

Sender Policy Framework (SPF) is a DNS TXT record that identifies which sending systems may use a domain in the SMTP envelope sender, commonly called MAIL FROM or return-path domain. It is useful, but SPF alone is often not enough for a modern sending program because the envelope domain may differ from the address recipients see in the From: header.

A simplified SPF record might look like this:

example.com. TXT "v=spf1 include:spf.emailvendor.example -all"

This is only an example. The include value must be the value supplied by the specific email provider you use. Do not copy it literally into DNS.

Use one SPF TXT record per domain. The SPF standard also limits DNS-querying terms during evaluation to 10, so repeatedly adding include: mechanisms for every SaaS tool can eventually produce a permerror. Before adding a new sender, inventory every system that sends with the domain: workspace mail, transactional email, CRM, support desk, invoicing tool, ecommerce platform, and marketing platform. (rfc-editor.org)

DKIM: sign each message

DomainKeys Identified Mail (DKIM) adds a cryptographic signature to outgoing email. The public key is published in DNS under a selector; receiving systems use the selector in the message’s DKIM-Signature header and the signing domain to locate that key.

A typical DNS name and record shape is:

s1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

The selector, key type, and key value are provider-specific. Your platform may ask you to create a TXT record directly, or it may give you CNAME records that point to its managed DKIM records. Use exactly the hostname and value it supplies. DKIM’s d= value is the signing domain, while s= is the selector used to find the public key. (rfc-editor.org)

For a deliverability check, verify that the received message shows dkim=pass and that the header.d= domain aligns with the visible From domain for DMARC. A DKIM record merely existing in DNS is not proof that your messages are signed correctly.

DMARC: verify alignment and collect evidence

DMARC connects the visible From: domain with SPF and DKIM. A message passes DMARC only when SPF or DKIM passes and the domain involved is aligned with the author domain in the visible From address. The current DMARC standard describes two alignment modes—relaxed and strict—and a valid aligned SPF or DKIM result is required for DMARC pass. (rfc-editor.org)

Start with a monitoring record rather than enforcing a policy before you understand every legitimate sender:

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

What each part means:

• v=DMARC1 identifies the DMARC record.
• p=none asks receivers to monitor rather than quarantine or reject messages that fail DMARC.
• rua= requests aggregate reports at the stated address.
• adkim=r and aspf=r use relaxed alignment; these tags can be omitted because relaxed alignment is the common default, but including them makes the intended setting explicit.
• pct=100 applies the stated policy to all applicable mail. With p=none, it does not enforce rejection.

DMARC is not an inbox-placement bypass. Its purpose is to publish authentication policy and request reporting; authenticated mail can still be filtered for reputation, content, or engagement reasons. The current DMARC standards are RFC 9989 for the core protocol and RFC 9990 for aggregate reporting; they supersede the older RFC 7489 reference that still appears in many setup guides. (rfc-editor.org)

After reviewing reports and confirming that every legitimate sender authenticates and aligns, consider an enforcement rollout such as p=quarantine and then p=reject. Do not make that change because a generic checklist says you should: enforcement can block your own forgotten systems, including customer-support replies or finance software.

Check DNS, TLS, and sending identity before testing content

Authentication works alongside basic mail-server hygiene. Google and Yahoo both require valid forward and reverse DNS for sending domains or IP addresses, while Google also requires TLS for messages sent to Gmail. (support.google.com)

If you use a reputable email API or managed transactional provider, it usually manages the outbound IP, TLS, and reverse DNS layer. You still need to configure the domain records it requests and ensure that the visible From domain, DKIM signing domain, return-path domain, and branded tracking domain make sense together.

What to inspect in a real message header

Send an email to a test mailbox, open the original or raw message source, and locate Authentication-Results. A healthy result might resemble this:

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

The exact formatting varies by receiver. What matters is the result:

• SPF pass means the envelope sender was authorized for the connecting sender.
• DKIM pass means the signature validated against the public key in DNS.
• DMARC pass means an SPF or DKIM pass also aligned with the visible From domain.

A frequent surprise is spf=pass, dkim=pass, and dmarc=fail. That can happen when both authentication domains are unrelated to the visible From: domain. In that case, change the provider’s custom return-path and DKIM configuration, or use a From domain that aligns with a configured signing domain.

Run a fast email deliverability check before every important send

A preflight check should take minutes for a routine send and become more extensive for new domains, new sending platforms, major template changes, or large campaigns.

The 10-minute preflight checklist

1. Confirm the actual From address. Use a domain you control, not a free consumer mailbox address.
2. Verify SPF, DKIM, and DMARC in DNS. Check the record names and values against your email provider’s setup page.
3. Send a production-like test. Use the same provider, From domain, reply-to address, links, and template that the real campaign will use.
4. Read the received headers. Confirm SPF, DKIM, and DMARC all pass where possible.
5. Check the visible experience. Review desktop and mobile rendering, preheader, plain-text fallback, sender name, reply-to address, footer, and unsubscribe link.
6. Open every important link. Check that HTTPS works, redirects are expected, and tracking parameters do not lead to broken pages.
7. Test the unsubscribe path. Ensure the recipient can leave the relevant list without having to sign in, and that suppression is written to your sending system.
8. Review the audience. Exclude hard bounces, prior unsubscribes, known complaints, and recipients who should not receive this message.
9. Check recent sending changes. A new domain, new IP pool, new list source, or sudden volume increase should trigger a smaller staged send.
10. Save the test evidence. Keep headers, test results, and campaign identifiers so you can compare before and after a fix.

For a quick technical analysis, Mail-Tester generates a temporary address, accepts a message sent to it, and reports on the message, sending server, and IP. Its own documentation warns that even a perfect score cannot guarantee inboxing at every provider, which is exactly why a score should be treated as a diagnostic, not a delivery promise. (reception.mail-tester.com)

Test inbox placement with seed mailboxes—not only one personal inbox

Inbox placement testing sends the same email to a controlled group of addresses at multiple mailbox providers, then records whether it appears in inbox, spam, or is missing. You can build a small internal seed list with real accounts you control, or use a specialist deliverability platform that maintains a larger seed network.

A practical starter seed list can include:

• Two personal Gmail accounts with different histories.
• Two Outlook.com accounts.
• One Yahoo Mail account.
• One iCloud Mail account.
• A work mailbox on Microsoft 365 or Google Workspace, if those resemble your customers’ environments.
• A mailbox at your own domain, to check how your inbound security layer handles the message.

Do not use one seed run as a statistical verdict. Its best use is comparison: run the same seed list before and after a DNS, template, list, or sending-platform change. If the same email moves from inbox to spam at one provider after a change, inspect the altered factor before changing five unrelated things.

For high-stakes messages, test the exact final MIME email rather than a simplified preview. A preview may omit message headers, click-tracking rewriting, unsubscribe headers, attachments, merge data, or the sender domain that the production mail uses.

Monitor the metrics that reveal a real deliverability problem

Open rate alone is not a reliable deliverability metric. Privacy features and image loading behavior mean it is an imperfect proxy for readership. Instead, use a dashboard that joins sending, delivery, complaint, bounce, unsubscribe, and mailbox-provider data.

Essential metrics and what they mean

Gmail Postmaster Tools provides dashboards for outgoing mail sent to personal Gmail accounts, including spam rate, reputation, authentication, and delivery errors. Google’s sender guidance says to keep spam rates reported in Postmaster Tools below 0.3%; treat that as a ceiling, not a target. (support.google.com)

At Microsoft, SNDS is useful for organizations that own or control sending IP space. It is an IP-focused service, so it is less useful when a shared sending provider owns the infrastructure and does not expose a dedicated IP to you. Yahoo provides Sender Hub resources and domain-level delivery insights, subject to its service’s available data and access conditions. (sendersupport.olc.protection.outlook.com)

List hygiene: validate intent, not just address syntax

A syntactically valid address can still be risky. It may be abandoned, a role account with unclear consent, a spam trap, a destination that rejects your message, or a recipient who never asked to hear from you. Address verification reduces obvious errors, but it does not establish permission or future engagement.

Use email validation at the point of signup to catch malformed addresses and obvious domain issues, then maintain suppression lists for hard bounces, unsubscribes, and complaints. If you need a quick pre-send check for individual contacts, use an email address verification tool before importing them into a campaign audience.

Avoid the tempting “reactivate everyone” campaign. Old and unengaged contacts are not simply a revenue opportunity; they are a source of poor engagement, complaints, and bounces. If you must re-engage an inactive segment, send a smaller, clearly labeled permission-confirmation message first, remove recipients who do not respond according to your documented retention policy, and do not mix that test with your most valuable active subscribers.

Segment before you scale

The safest large send is usually not one large send. Begin with the most engaged, recently opted-in segment, evaluate delivery and complaints, then expand in stages. This gives you an early warning if a new template, domain configuration, or audience source is causing trouble.

For new sending domains and new IPs, increase volume deliberately rather than launching immediately at full scale. The exact ramp depends on the sender’s existing reputation, recipient engagement, mailbox-provider mix, and whether the IP is dedicated or shared, so no universal daily-volume schedule is responsible advice. The durable rule is to make incremental changes, observe results, and stop escalating when negative signals appear.

Make marketing email easy to identify and easy to stop

Every promotional message should make its origin, purpose, and unsubscribe option obvious. This is both good user experience and deliverability hygiene: people who cannot find a legitimate way out may use the spam button instead.

Google requires bulk senders to support one-click unsubscribe for marketing and subscribed messages. Yahoo requires bulk senders to implement a functioning list-unsubscribe header, recommends the RFC 8058 POST method, asks for a visible unsubscribe link in the body, and says unsubscribe requests should be honored within two days. (support.google.com)

Headers for one-click unsubscribe

A standards-based setup commonly includes both headers below:

List-Unsubscribe: <https://email.example.com/unsubscribe/u/8d5f0a...>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The URL must identify the recipient or subscription safely—normally with an opaque, signed token rather than an exposed email address. Your endpoint must process the POST request and unsubscribe the recipient from the relevant list. RFC 8058 defines the signaling method because mail software may fetch URLs in headers automatically; the additional header distinguishes intentional one-click unsubscribe behavior. (rfc-editor.org)

Keep a visible unsubscribe link in the email body too. It can lead to a preference center, but do not make the required one-click mechanism depend on asking the recipient to log in, solve a CAPTCHA, or select through multiple confirmation screens.

Transactional mail is different from marketing mail. Password resets, receipts, security alerts, and account-critical notices generally should not be made unsubscribable in the same way as a newsletter. The key is classification: do not disguise promotional content as a transaction simply to avoid marketing-mail requirements.

Worked example: diagnose a newsletter that lands in Gmail spam

Assume a SaaS company sends a weekly product newsletter from news@acme-example.com using an email platform. A team member receives it in Gmail spam, while the platform reports the message as delivered.

Step 1: preserve the exact message

Do not edit the template yet. Open the message source and save the headers. The team finds:

From: Acme Product News <news@acme-example.com>
Return-Path: <bounce@mg.emailvendor.example>
Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=mg.emailvendor.example;
       dkim=pass header.d=emailvendor.example header.s=ev1;
       dmarc=fail header.from=acme-example.com

This proves a key point: SPF and DKIM can pass while DMARC fails. Both passing domains belong to the vendor, but the visible From domain is acme-example.com, so neither result aligns with the author domain.

Step 2: configure the sending domain in the platform

In the provider’s domain-authentication page, the team adds the exact DKIM and custom return-path DNS records supplied by the platform. The values differ by provider, so the team does not substitute generic SPF or DKIM values from a blog post.

They also publish this initial DMARC record:

_dmarc.acme-example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@acme-example.com"

They wait for DNS propagation according to their DNS provider’s TTL and then send a new production-like test.

Step 3: verify the new headers

The next test shows:

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

Authentication is now correct. That does not prove inbox placement is fixed, but it removes a major, concrete defect.

Step 4: test unsubscribe and audience controls

The team checks the raw headers and finds no List-Unsubscribe field. Because this is a promotional newsletter, it adds a provider-supported one-click unsubscribe configuration, confirms the visible footer link works, and performs an unsubscribe test using a seeded recipient.

Next, it excludes contacts who previously hard bounced, unsubscribed, or complained. It divides the remaining audience into recently engaged subscribers and older inactive contacts.

Step 5: send in stages and measure outcomes

The first send goes only to recently engaged subscribers. The team checks Gmail Postmaster Tools, platform bounces, complaint reports, unsubscribe processing, and seed inbox placement after delivery. If those indicators are stable, it expands to the next engaged segment rather than immediately mailing every historical contact.

Step 6: define success precisely

Success is not “the test score became 10/10” or “one employee saw the message in Gmail.” Success means:

• SPF, DKIM, and DMARC pass in received headers.
• DMARC aggregate reports show only known legitimate senders.
• The one-click and footer unsubscribe flows remove the test recipient correctly.
• SMTP acceptance and bounce rates remain normal for the list.
• Seed mailboxes show no new spam-placement regression.
• Gmail- and provider-level complaint signals stay safely below documented thresholds.

That process turns a vague “our emails are in spam” report into a sequence of observable facts and reversible changes.

Common email deliverability check mistakes

Treating a spam score as an inbox guarantee

A content scanner is valuable for catching broken markup, risky links, and missing authentication. It cannot model every mailbox provider’s reputation and per-recipient filtering decision. Use it to find defects, then verify with real headers, seed placement, and post-send telemetry. (reception.mail-tester.com)

Publishing DMARC with p=reject before inventorying senders

DMARC enforcement is powerful against spoofing, but it can also interfere with legitimate mail that a team forgot about. Start with reporting, inspect the data, fix alignment, then increase enforcement deliberately.

Adding multiple SPF records

Multiple SPF TXT records at the same domain are not a way to support multiple vendors. Consolidate authorized senders into one record and keep the DNS lookup limit in mind. (rfc-editor.org)

Fixing copy before looking at headers

If DMARC fails, a new subject line will not repair it. Check identity and authentication first, then audience quality, then template and offer quality.

Sending from a domain you have not authenticated

A domain visible in the From field should be configured in the provider that actually sends the mail. Do not assume that authentication for your company workspace automatically covers a separate CRM, support desk, or transactional email service.

Ignoring the reply-to address

A no-reply experience can make a legitimate message feel less trustworthy and prevents customers from responding naturally. Where operationally feasible, use a monitored reply-to mailbox or make the appropriate support route obvious.

Build a repeatable deliverability operating system

Deliverability is not a one-time technical project. It is an operating discipline that combines DNS ownership, sender configuration, consent records, segmentation, creative review, response handling, and ongoing monitoring.

Assign clear ownership for these controls:

• Engineering or IT: DNS, domains, DKIM keys, provider configuration, webhooks, suppression synchronization, and message-header troubleshooting.
• Marketing or lifecycle: permission language, segmentation, frequency, content relevance, preference center, and campaign QA.
• Support and compliance: unsubscribe handling, complaint investigation, consent evidence, and customer-response workflows.

If your application sends product emails, centralize sending logic where possible so every service inherits the same authentication, suppression, unsubscribe classification, and event tracking rules. Your email API setup guides should document which domain each message class uses, how it is authenticated, and which events must be stored.

The best time to run an email deliverability check is before a launch, but the best program makes checking continuous: validate each new domain, test every material template change, monitor every important campaign, and investigate anomalies while the exact message and logs are still available.

FAQ

What is a good email deliverability rate?

There is no single universal percentage that proves a healthy program. SMTP delivery rate can look high while inbox placement is poor, so assess delivery alongside spam placement, hard bounces, complaints, unsubscribes, authentication pass rates, and mailbox-provider telemetry.

How do I check whether SPF, DKIM, and DMARC work?

Send a real message through the same platform and domain used in production, open the raw message source at the receiving mailbox, and inspect Authentication-Results for SPF, DKIM, and DMARC. DNS lookup tools are useful, but message headers confirm what the receiver actually evaluated.

Why does DMARC fail when SPF passes?

DMARC requires alignment. SPF may pass for the return-path domain while the visible From address uses another domain. Configure a custom return-path or aligned DKIM signing domain with your sending provider, then test the headers again. (rfc-editor.org)

Can I check deliverability before sending a campaign?

Yes. Run DNS and header checks, send the final production-like message to seed mailboxes and a technical testing address, test links and unsubscribes, review the audience, and stage the production send. Pre-send checks reduce risk, but only real post-send data confirms broad placement and recipient response.

Does a perfect email test score mean my email will go to the inbox?

No. A strong test score indicates that the tool did not find certain technical or content problems. Mailbox providers still make their own decisions based on sender reputation, recipient behavior, message context, and other signals. (reception.mail-tester.com)