Free Email Deliverability Test: How to Check Inbox Placement Before You Send

A free email deliverability test helps you catch the technical and content problems that can send a legitimate campaign to spam—or stop it from arriving at all. The fastest useful approach combines a message-scoring tool, seed inboxes at major mailbox providers, and a check of the message headers those providers add.

What a free email deliverability test can—and cannot—tell you

Email delivery means the receiving server accepted the message. Email deliverability is broader: it is whether the message lands where a person is likely to see it, such as the primary inbox, a category tab, or spam. A receiving server can accept an email while still filtering it away from the inbox.

That distinction matters because there is no universal inbox-placement score. Gmail, Yahoo, Outlook, and other mailbox providers evaluate a mixture of authentication, infrastructure, recipient feedback, engagement, message characteristics, and their own filtering systems. A free test can identify failures in the parts you control and provide directional evidence about placement. It cannot guarantee that every recipient will receive a future campaign in the inbox.

For a practical test, separate your questions:

1. Can the message be accepted? Check SMTP delivery and bounce responses.
2. Is the sender authenticated? Check SPF, DKIM, and DMARC results in message headers.
3. Does the message contain obvious technical or content defects? Use a scoring tool and inspect links, HTML, and headers.
4. Where does it land at major providers? Send to controlled Gmail, Outlook, and Yahoo test inboxes.
5. Do real recipients want it? Monitor spam complaints, unsubscribes, bounces, and engagement after sending.

Mailbox-provider guidance makes the same point in different language: authentication and low complaint rates are baseline requirements, not a shortcut around sending relevant email to people who expected it. Gmail’s sender guidance says it uses requirements and guidelines to reduce rate limiting, blocking, and spam placement; Yahoo similarly requires authentication and says senders should keep spam rates below 0.3%. (support.google.com)

The fastest free email deliverability test: a three-part workflow

Use the exact message you intend to send—not a simplified version. Deliverability can change when you alter the sending domain, From address, links, HTML, audience segment, or sending platform.

Part 1: send the exact email to a scoring address

Mail-Tester is a straightforward free option for a pre-send diagnostic. It generates a unique recipient address; you send your campaign or transactional email to that address, then retrieve a report that checks message configuration, content, authentication, and related signals. Its free service limits testing volume, so reserve it for meaningful before-and-after comparisons rather than every draft. (mail-tester.com)

Run the test this way:

1. Open Mail-Tester and copy the temporary address it creates.
2. Send the message from the same product, domain, sending IP or shared pool, and From address you will use for the real send.
3. Wait for the message to arrive, then retrieve the report.
4. Save the report URL or export the findings to your campaign checklist.
5. Fix one high-confidence issue at a time and resend the same test.

Treat a score as a diagnostic clue, not a grade that overrides mailbox-provider behavior. A score can flag a missing DKIM signature or malformed HTML immediately. It cannot know whether your actual list has opted in, whether people will report the campaign as spam, or how a particular provider will assess your domain’s reputation over time.

Part 2: send to your own seed inboxes

Create test mailboxes you control at least at:

• Gmail
• Outlook.com or Microsoft 365
• Yahoo Mail

Send the same email to all three. Record whether it appears in Inbox, Promotions or another category, Junk/Spam, or does not arrive. Also note how long it takes to arrive and whether the subject line, sender name, preheader, images, and unsubscribe controls render as intended.

A seed test is useful because it measures a real provider’s treatment of a real message. But three inboxes are not a statistically representative audience. Do not repeatedly move test messages from spam to inbox or mark them as “not spam” and then treat future placement as independent evidence; you have changed the test mailbox’s signals.

Part 3: inspect the received headers

Headers show what the recipient’s provider actually observed. This is often the most valuable free test because it distinguishes a DNS or sending-platform misconfiguration from a vague “spam problem.”

In the raw source or message details, find the Authentication-Results header. A healthy result often resembles this:

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

The exact wording varies by recipient provider. Microsoft 365 also adds an Authentication-Results header and can report SPF, DKIM, DMARC, and composite authentication results. (learn.microsoft.com)

If the message fails any authentication method, do not jump straight to copy changes. First identify the domain each check evaluated:

• SPF normally evaluates the SMTP envelope sender (smtp.mailfrom), not necessarily the visible From address.
• DKIM evaluates the signing domain shown after header.d=.
• DMARC evaluates whether SPF or DKIM passed and aligned with the visible From: domain.

That last point explains a common surprise: SPF can pass, DKIM can pass, and DMARC can still fail if neither authenticated domain aligns with the visible From domain.

What to test before every campaign

A reliable preflight check is more useful than trying to memorize “spam words.” Run this checklist on the exact message when you change infrastructure, templates, domains, or sending behavior.

Sender identity and authentication

Check all of the following:

• The visible From: address uses a domain you control.
• The return-path or envelope sender is intentional and belongs to your sending setup.
• SPF passes.
• DKIM passes.
• DMARC passes with the visible From domain aligned to SPF or DKIM.
• The From domain has a published DMARC record.
• Your sending platform has completed its domain-verification flow.

Google recommends using both SPF and DKIM, describing them as complementary signals: SPF identifies approved sending servers and DKIM protects the message from modification in transit. DMARC adds policy and reporting around authenticated use of the visible From domain. (support.google.com)

Message and rendering checks

Open the test email in desktop and mobile clients where possible. Verify:

• The From name clearly identifies the sender.
• The subject line accurately describes the message.
• The preheader adds useful context rather than repeating boilerplate.
• Every tracked and untracked link uses HTTPS and reaches the intended page.
• The plain-text version is readable and contains a usable unsubscribe path for marketing messages.
• Images have meaningful alternative text where needed.
• The email does not rely on one giant image for its message.
• The footer identifies the sender and includes required compliance details for your jurisdiction.

The goal is not to make a message look artificially plain. It is to make the email understandable, accessible, and credible even when images are blocked or tracking is limited.

Recipient and list checks

A technically perfect email can still perform badly when it is sent to an old, purchased, scraped, or poorly segmented list. Before a sizable send, suppress known hard bounces, prior unsubscribes, and recipients who complained. If your list has not been contacted for a long time, reintroduce it in carefully segmented batches rather than sending one large blast.

Address validation is not a replacement for permission, but it can reduce preventable bounces caused by malformed or non-deliverable addresses. Use an email address verification tool before importing a new list or sending to records collected through a form with weak validation.

How to read SPF, DKIM, and DMARC failures

Authentication problems are among the most fixable causes of poor deliverability. They are also easy to misdiagnose when several tools, domains, and DNS records are involved.

SPF: verify every authorized sender without creating multiple records

SPF is a DNS TXT record that declares the servers allowed to send mail for a domain. A basic real-world record for a domain that sends only through Google Workspace is:

Type: TXT
Host/Name: @
Value: v=spf1 include:_spf.google.com ~all

That exact include mechanism is specific to Google Workspace. Do not copy it if your mail comes from another platform. Your email provider should give you its required SPF include domain or IP mechanism. Google’s documentation specifically says that when you begin using a new mail server or third-party sender, you should update SPF to include that sender. (support.google.com)

The most frequent SPF mistakes are:

• Publishing two SPF TXT records at the root domain instead of merging authorized sources into one record.
• Forgetting a new sender, such as a help desk, CRM, invoice system, or transactional email API.
• Authorizing the sending platform in SPF but using a different, unaligned visible From domain.
• Exceeding SPF’s DNS-lookup constraints through too many nested include mechanisms.

SPF evaluation has a limit of 10 DNS-querying mechanisms and modifiers; exceeding applicable limits can result in a permanent error. That is why an SPF checker may flag a record that looks syntactically valid but is operationally fragile. (datatracker.ietf.org)

DKIM: make sure the actual outgoing message is signed

DKIM adds a cryptographic signature to an outgoing email. The recipient looks up the public key in DNS using the selector and domain in the signature. A passing header normally includes something like:

dkim=pass header.d=example.com header.s=s1

The DNS record name in that example would be s1._domainkey.example.com, but the selector (s1) and record value must come from your actual sending provider. Do not invent a DKIM key or replace a provider’s supplied value with a generic example.

Common DKIM failures include a missing DNS record, a wrong selector, a record pasted with broken quotation marks, DNS published under the wrong host name, or mail altered after signing. Google notes that outbound gateways which modify outgoing messages—for example by appending a footer—can interfere with DKIM. (support.google.com)

If DKIM says fail, compare the failing header.d and selector with the DNS record your sender expects. If the sender signs with its own platform domain rather than your domain, DKIM might pass but fail DMARC alignment. Configure custom-domain DKIM where your provider supports it.

DMARC: start with monitoring, then enforce only after reviewing reports

DMARC tells recipients how to handle messages that fail aligned SPF and DKIM, and it can request aggregate reports. A conservative starting record is:

Type: TXT
Host/Name: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100

This is valid DMARC syntax, but example.com must be replaced with a mailbox you control and can monitor. The p=none policy asks for monitoring rather than quarantine or rejection. It does not make unauthenticated email trustworthy, and it does not guarantee inbox placement.

Once reports show that every legitimate sender is authenticated and aligned, a domain owner can consider stronger policies such as p=quarantine or p=reject. Google’s DMARC documentation describes the possible policy actions as deliver, quarantine, or reject, and explains that reports help identify authentication problems and unauthorized use. (support.google.com)

Do not move to enforcement just because one test email passes. Include every system that uses your domain: marketing tools, transaction senders, customer-support software, invoices, calendar systems, and internal forwarding paths.

Test unsubscribe behavior, not just the footer link

For promotional and subscription mail, recipients need a clear way to stop receiving messages. A visible footer unsubscribe link is necessary in many contexts, but mailbox providers also expect header-based unsubscribe support for bulk mail.

The standard one-click pattern uses both headers:

List-Unsubscribe: <https://example.com/unsubscribe/eyJ1c2VyIjoiMTIzIn0>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The HTTPS endpoint must accept the one-click POST request and identify the recipient and list without asking the recipient to log in or complete extra steps. RFC 8058 defines this mechanism to avoid accidental opt-outs from software that merely fetches a URL found in a header. (datatracker.ietf.org)

Yahoo states that a body unsubscribe link alone is not sufficient for its one-click-unsubscribe requirement; it calls for the List-Unsubscribe header, preferably according to RFC 8058. Gmail and Yahoo also connect easy unsubscription with their bulk-sender guidance. (senders.yahooinc.com)

Test it directly:

1. Send the email to a seed mailbox.
2. Inspect the raw headers for both List-Unsubscribe and List-Unsubscribe-Post.
3. Use the provider’s unsubscribe UI if it appears.
4. Confirm the address is suppressed in your sending platform.
5. Send a second test to confirm the address no longer receives that list’s mail.

Keep the footer link as well. Header support varies by mailbox interface, while a visible link remains important for recipients and compliance.

Worked example: diagnose a campaign that lands in Gmail spam

Assume a small SaaS company is sending a product-update newsletter from updates@northstar.example through its email provider. The campaign uses a branded tracking domain and has a working footer unsubscribe link, but a Gmail seed inbox receives it in spam.

Step 1: establish a baseline

Send the unchanged campaign to Mail-Tester and to Gmail, Outlook, and Yahoo seed mailboxes. Record the folder placement and save the raw message source from Gmail.

The Gmail header contains:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=send.northstar-mail.example;
       dkim=pass header.d=provider-mail.example;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=northstar.example

This is not an SPF failure. It is an alignment failure: SPF authenticates a different envelope-sender domain and DKIM signs with the provider’s domain, while the human-visible From address uses northstar.example. DMARC cannot find an aligned passing SPF or DKIM identifier.

Step 2: correct the domain setup in the sending platform

In the provider’s domain-authentication settings, the team adds the exact DNS records supplied for a custom sending domain and enables custom DKIM signing for northstar.example. It does not guess at CNAME names, selectors, or key values; those details differ by provider.

The company also verifies that its root SPF record includes the provider’s authorized mechanism, merged with any existing Google Workspace or support-system entries. It retains one SPF record rather than adding a second one.

Step 3: publish monitoring DMARC

The team publishes:

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

It monitors the reporting address and confirms that marketing and transactional systems appear as expected. The team does not set p=reject until it knows all legitimate senders are covered.

Step 4: retest the exact message

After DNS changes are visible and the provider confirms the domain, send the exact same campaign again. The Gmail test header now shows:

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

The team verifies that the unsubscribe headers are present, checks all links and image loading, and confirms that the message arrives in the expected folder in each seed inbox. That is a successful authentication test—not proof that a cold or disengaged audience will receive every message in the inbox.

Step 5: validate the live result

For the real campaign, send first to the most engaged, recently active subscribers. Watch hard bounces, spam complaints, unsubscribes, delivery errors, and provider dashboards. Gmail Postmaster Tools provides eligible senders with data and diagnostics including spam rate, reputation, authentication, and delivery errors. (support.google.com)

Why a perfect score can still produce poor inbox placement

A tool can report correct authentication and clean HTML while the campaign still underperforms. This is not necessarily a contradiction.

Reputation is earned from sending behavior

Mailbox providers observe patterns over time. Sending a sudden high-volume campaign from a new domain, targeting recipients who did not expect the email, or accumulating complaints can reduce trust even when every DNS record is correct.

Gmail defines a bulk sender, for its personal Gmail requirements, as a sender that sends close to 5,000 or more messages in 24 hours. Yahoo’s sender guidance likewise distinguishes bulk senders and requires SPF, DKIM, DMARC, aligned authentication, and one-click unsubscribe for that category. (support.google.com)

Your seed list does not model your production list

A seed inbox owned by your team may already recognize the sender, have no history of ignoring your mail, and receive only a few messages. Real lists include inactive people, abandoned addresses, prior complainers, forwarded inboxes, corporate gateways, and provider-specific filtering rules.

Use seed inboxes to detect changes, not to claim a universal inbox rate. Compare like with like: the same sender domain, audience type, campaign category, and approximate sending pattern.

Message relevance is a deliverability factor

Changing the subject line, offer, send frequency, or recipient segment can change how recipients react. If people delete without reading, unsubscribe, or report the email as spam, no DNS tweak can sustainably solve the problem.

The operational fix is usually segmentation and expectation-setting: state what someone signed up for, send on a predictable cadence, let them manage preferences, and stop sending to persistently unengaged segments according to your organization’s policy.

Free tools worth using alongside the test

You do not need an expensive platform to build a useful baseline. Combine free tools based on the question each answers.

Yahoo’s Complaint Feedback Loop is domain-based and requires outbound mail to be DKIM signed so Yahoo can determine the sender. That makes it especially useful after custom DKIM is working. (senders.yahooinc.com)

For teams choosing a sending service, compare more than API ergonomics. Look for custom-domain authentication, domain verification, suppression handling, event webhooks, unsubscribe support, and visibility into bounces and complaints. Those capabilities affect whether you can run and act on a deliverability test—not just whether you can send an email. See email API setup guidance when you need to connect a sending application and authenticate its domain.

A repeatable deliverability-testing routine

The best test is one you can repeat whenever something material changes. Use this operating cadence:

1. When configuring a domain: verify SPF, DKIM, and DMARC; send header tests to Gmail, Outlook, and Yahoo.
2. Before a new template or campaign type: run a scoring test, check rendering, links, plain text, footer details, and unsubscribe headers.
3. Before a large send: test the exact campaign and start with an engaged segment when appropriate.
4. After sending: review bounces, complaints, unsubscribes, provider feedback, and placement changes in seed mailboxes.
5. After adding a tool: update SPF if needed, enable that tool’s custom DKIM setup, and retest DMARC alignment.

Document the results in a simple log with date, sender domain, sending platform, template version, recipient segment, seed placement, authentication results, and changes made. When inbox placement drops, this history turns a guessing exercise into a comparison against the last known-good setup.

Common mistakes that make free deliverability tests misleading

Avoid these shortcuts:

• Testing from a personal mailbox but sending production mail through an ESP. The infrastructure is different, so the result is not comparable.
• Using a generic “from” address during testing. Test the real visible From domain and display name.
• Fixing a score by removing legitimate content. A score is a clue; do not strip useful information merely to chase a number.
• Assuming SPF pass means DMARC pass. Alignment still matters.
• Adding a second SPF record. Merge mechanisms into one valid SPF TXT record instead.
• Publishing DMARC enforcement before inventorying all senders. This can disrupt legitimate mail.
• Confusing a newsletter’s footer link with one-click unsubscribe. Test the required message headers and endpoint behavior.
• Buying or scraping a list after authentication is fixed. Permission and recipient response remain central to deliverability.

The conclusion is simple: use a free email deliverability test to verify the controllable basics, then protect inbox placement through disciplined list management and recipient-first sending. Authentication gets you through the front door; relevance and trust determine whether you stay in the inbox.

FAQ

Is there a completely free email deliverability test?

Yes. You can send an email to a free diagnostic address such as Mail-Tester, inspect DNS and message headers, and use personal Gmail, Outlook, and Yahoo seed inboxes. These methods are useful for preflight checks, although they cannot guarantee inbox placement across an entire list. (mail-tester.com)

What is a good score on a deliverability test?

Use the score to find specific problems rather than as a universal pass/fail threshold. A message should have passing SPF, DKIM, and DMARC results, functioning links, and appropriate unsubscribe support; it should also land acceptably in your seed inboxes.

Why does my email pass SPF but go to spam?

SPF validates the envelope-sender authorization, not the whole sender identity or recipient experience. The message may have failed DKIM or DMARC alignment, come from a low-trust sending pattern, or generated poor recipient feedback. Microsoft also notes that SPF alone does not prevent spoofing; DKIM and DMARC are needed as well. (learn.microsoft.com)

How do I test whether DMARC works?

Send an email to a Gmail, Outlook, or Yahoo seed mailbox and inspect Authentication-Results. Look for dmarc=pass and confirm that the header.from domain is your visible From domain. Also publish a DMARC record with an rua reporting address and review aggregate reports before adopting an enforcement policy.

Does an unsubscribe link improve deliverability?

An easy, trustworthy unsubscribe path can reduce the chance that recipients use the spam button instead. For bulk promotional mail, test both the visible footer link and List-Unsubscribe / List-Unsubscribe-Post headers, because major mailbox providers include one-click unsubscribe in their sender requirements or guidance. (senders.yahooinc.com)