S
SCRAWL

Email Deliverability Checker — Free SPF, DKIM & DMARC Test

Check SPF, DKIM, DMARC, MX, and BIMI records for any domain in one pass. See if you meet Google and Yahoo's bulk sender requirements, with copy-paste DNS record fixes. Free, no signup.

What is an Email Deliverability Checker?

An Email Deliverability Checker tests the DNS records that mailbox providers use to decide whether your email lands in the inbox or the spam folder. Enter a domain and the tool runs every check — MX, SPF, DKIM, DMARC, and BIMI — in a single pass, then grades the domain against the bulk sender requirements Google and Yahoo enforced starting February 2024 and Microsoft began enforcing in May 2025. Each protocol gets a pass, warning, or fail verdict with a plain-English explanation, and every failure comes with the exact DNS record to add — record type, host, and value — ready to copy into your DNS provider.

When Should You Use Email Deliverability Checker?

Run this check before launching a new domain for cold outreach or transactional email, after migrating to a new email provider, or any time a campaign's open rates drop and you suspect deliverability rather than content is the problem. It's also useful as a recurring audit: SPF records silently break when a team adds a new sending tool (a CRM, a marketing platform, a transactional email API) without updating the include chain, and DMARC reports often go unread until a domain gets blocklisted for spoofed mail nobody noticed.

How to Read Email Deliverability Checker Results

MX records confirm the domain can receive mail and identify which provider hosts it. SPF lists which servers are authorized to send mail as your domain — the checker resolves the full include chain recursively, counts it against the RFC 7208 limit of 10 DNS lookups (exceeding it causes a permanent SPF failure), and checks whether the record ends in a hard fail (-all), soft fail (~all), or an overly permissive qualifier. DKIM adds a cryptographic signature to outgoing mail; since the signing selector isn't published anywhere, the checker probes common selectors used by major providers and reports the key type and approximate strength of any it finds. DMARC tells receiving servers what to do with mail that fails SPF or DKIM, and whether to send you reports — a domain with no DMARC record, or one with p=none and no reporting address, has no protection against spoofing and limited visibility into who is sending mail on its behalf. BIMI is informational only and never affects the grade — it only displays your logo in supporting inboxes once DMARC is enforced.

What Should You Know Before Using Email Deliverability Checker?

This is a DNS-only check. It cannot see whether your sending IPs have correct reverse DNS, whether your delivery path uses TLS, or whether mail you actually send aligns with these records — those require sending a real message and inspecting headers. The tool lists what it does not check alongside the results so the coverage isn't overstated. For most domains, getting SPF, DKIM, and DMARC all passing with a DMARC policy of at least p=none is enough to clear the Google and Yahoo bulk sender bar; reaching p=reject is the recommended end state but requires monitoring DMARC reports first to confirm no legitimate mail gets blocked.

Frequently Asked Questions

What are the Google and Yahoo bulk sender requirements?

Starting February 2024, Google and Yahoo require anyone sending more than roughly 5,000 messages a day to a Gmail or Yahoo address to: have valid SPF and DKIM records, publish a DMARC record at p=none or stronger, ensure the From domain is aligned with the SPF or DKIM domain, keep spam complaint rates below 0.3%, and provide a one-click unsubscribe for marketing mail. Microsoft introduced similar SPF/DKIM/DMARC requirements for high-volume senders in May 2025. This checker verifies the DNS-side requirements — SPF, DKIM, DMARC, and MX — in one pass and flags exactly which ones are missing.

What is a DMARC record and why do I need one?

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS TXT record published at _dmarc.yourdomain.com that tells receiving mail servers what to do with messages claiming to be from your domain that fail SPF or DKIM checks — and aligns those checks with the visible From address. Without a DMARC record, anyone can spoof your domain in the From field and there's no policy telling Gmail or Outlook to reject it. A minimal record looks like v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com — the rua tag is what gets you aggregate reports showing who is sending mail as your domain, including legitimate services you may have forgotten about.

How do I find my DKIM selector?

The DKIM selector isn't published in a discoverable location, so this checker probes common selectors (google, default, k1, selector1, mail, and others used by major email providers). To find your actual selector: send a test email to an address you control, open it in Gmail, click the three-dot menu and choose 'Show original', then look for the DKIM-Signature header. The s= value is your selector and the d= value is the signing domain. Re-run this checker with that selector entered in the optional field to get a full DKIM report.

Why are my emails going to spam?

The most common DNS-level causes are: no SPF record or an SPF record that doesn't list the server actually sending your mail, no DKIM signature or a broken one, no DMARC record (which signals to receivers that the domain has no authentication policy at all), or an SPF record that exceeds the 10 DNS lookup limit and fails outright. Beyond DNS, spam placement is also affected by sender reputation, complaint rates, content, and whether recipients have engaged with previous mail — none of which a DNS checker can see. Fix the DNS issues this tool flags first, since a domain failing SPF, DKIM, or DMARC will be filtered regardless of how good the email content is.

Do I need a DMARC policy of p=reject?

Not immediately, and jumping straight to p=reject is risky if you haven't verified every legitimate sending source first — it will silently drop mail from any service not properly aligned with SPF or DKIM. The recommended path is to start at p=none with a rua reporting address, monitor the aggregate reports for a few weeks to identify every system sending mail as your domain, fix alignment issues for each one, then move to p=quarantine and finally p=reject. p=none already satisfies the minimum Google and Yahoo bulk sender requirement — p=reject is the long-term goal for full anti-spoofing protection, not a day-one requirement.