Free Email Deliverability Test

Testing email deliverability starts with your DNS records

When emails land in spam, the first suspects are four DNS records. MX proves your domain can receive replies. SPF lists the servers allowed to send as your domain. DKIM adds a cryptographic signature that receivers verify. DMARC tells Gmail, Yahoo and Outlook what to do when SPF or DKIM fails, and whether to trust your mail at all.

Testing email deliverability therefore starts here: mailbox providers evaluate these records on every single message you send. This free test queries DNS live from your browser and grades each record OK, WARNING, MISSING or ERROR, with the exact issue spelled out in plain English.

One SPF, DKIM & DMARC check, not three separate tools

Most record checkers make you test SPF, DKIM and DMARC in three different tools and stitch the answers together yourself. This test runs all of them (plus MX) in one pass and applies the validation rules that cause real-world failures: multiple SPF records are a permanent error under RFC 7208, +all authorizes anyone to send as you, more than 10 DNS lookups breaks SPF entirely, and a DMARC policy of p=none is monitoring only.

DKIM is the record most tools skip, because it lives under a selector you have to know in advance. We solve that by reading your MX records first: if your mail runs on Google Workspace we probe the google selector, if it runs on Microsoft 365 we probe selector1 and selector2, and otherwise we try the most common generic selectors like default, k1 and mail.

How authentication builds email domain reputation

Gmail and Yahoo score the reputation of your sending domain, and authentication is how that history gets attributed to you. Every message that passes SPF and DKIM with an aligned From domain adds to your domain's track record; unauthenticated mail either builds no reputation or, increasingly, gets rejected before it can.

DMARC is what makes that reputation yours alone: with an enforcing policy, spammers can no longer send as your domain and burn your reputation for you. That is why a complete record set matters even for small senders: it protects the asset every future campaign depends on.

Records are the entry ticket, not the whole game. Once they pass, email domain reputation is earned through engagement: real replies, low bounce rates, and complaint rates kept under 0.3%.

Run this email deliverability check before every campaign

DNS records drift. A new marketing tool adds a second SPF record and silently breaks the first. An IT migration drops your DKIM key. A registrar change wipes the _dmarc entry. A ten-second email deliverability check before each campaign catches these regressions before they cost you a week of inbox placement.

Be equally clear about what a record check cannot see: your actual inbox-versus-spam placement, your live reputation score, or how providers judge your content. Those depend on how you send, which is exactly the part Emailchaser automates, pacing your outreach and personalizing every message so healthy records turn into replies.

Why emails land in spam: authentication, content, reputation and volume

Emails get filtered to spam for four largely independent reasons, and it helps to diagnose them in that order. Authentication comes first because it is binary and fixable in minutes: if SPF, DKIM or DMARC is missing or broken, Gmail and Yahoo cannot attribute the mail to you, and that is exactly what this test measures. Content is second: spam-trigger phrasing, a bare link-heavy body, misleading subject lines and image-only messages all raise the score against you. Reputation is third: mailbox providers keep a running history for your sending domain and IP, and a domain with no track record starts from neutral, not trusted. Volume and behaviour are fourth: sending faster than a warmed domain should, mailing stale lists that bounce, or provoking complaints will sink even perfectly authenticated mail.

The practical implication is that fixing your records is necessary but rarely sufficient. A brand-new domain with flawless SPF, DKIM and DMARC will still see poor placement if it sends five hundred cold emails on day one, because it has no reputation and the volume looks automated. Pass the authentication checks here first (they are the cheapest wins), then protect the other three by warming the domain gradually, keeping bounce rates low, and pacing sends so they resemble a person rather than a blast.

The 2024 Google and Yahoo sender requirements, in practice

In February 2024, Gmail and Yahoo turned long-standing best practice into hard requirements. Every sender, at any volume, now has to authenticate with at least SPF or DKIM, publish valid reverse DNS (PTR) for the sending IP, and stop forging a Gmail From address. Cross roughly 5,000 messages a day to Gmail addresses and you are classed as a bulk sender, at which point the bar rises sharply. The count is per day from your domain, so a single large campaign can tip you over it.

Bulk senders must authenticate with both SPF and DKIM, publish a DMARC record (p=none meets the minimum), and add one-click unsubscribe: a List-Unsubscribe header plus the List-Unsubscribe-Post value defined in RFC 8058, with the request honoured within two days. The hardest bar to hold is the spam rate: Google asks you to stay under 0.3% complaints in Postmaster Tools and warns that even brushing 0.1% causes problems. Because 0.3% is only three complaints per thousand delivered, list quality and relevance matter more than any single record.

The requirement people most often miss is DMARC alignment. It is not enough for SPF or DKIM to pass in isolation: the domain each one authenticates has to match the domain in your visible From address (relaxed alignment accepts the same organizational domain). A classic failure is sending through a platform that signs with its own domain and sets its own Return-Path: SPF and DKIM both pass, yet DMARC fails because nothing aligns to your From domain. If you send from a subdomain, publish records there and make sure your DMARC sp= policy covers it.

How to read each record's result and fix the common failures

Each record is graded OK, WARNING, MISSING or ERROR. MISSING means the record does not exist; ERROR means it exists but is invalid, or the lookup itself failed; WARNING means it works but is weaker than it should be. MX rarely warns: it is either present, so your domain can receive replies, or MISSING, which for a sending domain means bounced replies and a weaker trust signal. SPF has three classic failures: two or more v=spf1 records on the domain (a permanent PermError under RFC 7208, so merge them into one), a record ending in +all or with no -all or ~all at all (which authorizes the whole internet to send as you), and more than ten DNS lookups from chained include: statements (also a PermError). The free SPF record generator rebuilds a single clean record if yours has drifted into any of these.

DKIM is the record most likely to look broken when it is actually fine. Because the key lives at selector._domainkey.yourdomain.com, the test has to infer the selector from your provider: google for Workspace, selector1 and selector2 for Microsoft 365, then generic names like default, k1 and mail. A MISSING DKIM result therefore means not found under the common selectors, not definitely absent: if you sign with a custom selector, confirm the exact record your platform issued. A genuine problem shows up as a WARNING when the key exists but its p= value is empty, which means the key was revoked and needs republishing.

DMARC warnings are usually about strength, not absence. p=none is the most common: it is valid and satisfies the Google and Yahoo minimum, but it only monitors. It tells receivers to do nothing when mail fails, so it protects your domain from no one. Moving to p=quarantine and then p=reject is what actually stops spoofing, and the DMARC record generator walks through that ramp. Watch too for pct= below 100 (the policy applies to only a fraction of mail), a missing rua= tag (you receive no aggregate reports to learn from), and two DMARC records at once, which receivers treat as if none exists.