What does the Email Deliverability Checker do?
The Email Deliverability Checker looks up the four DNS records that decide whether Gmail and Yahoo trust mail from your domain: MX, SPF, DKIM and DMARC. It grades each one against the sender rules those inboxes have enforced since February 2024. Then it tells you, in one sentence, whether your mail is likely landing in spam. Every failed check comes with the record to paste.
Here's a real run. Someone on Microsoft 365 types [email protected]. The checker keeps only the part after the @ and checks acme.com. The domain has an MX record pointing at acme-com.mail.protection.outlook.com, and its only TXT record is a Microsoft verification string. The verdict comes back: "Your email is likely landing in spam. Here's the fix."
- MX: Pass. Mail goes to Microsoft 365.
- SPF: Fix. No record. Add
v=spf1 include:spf.protection.outlook.com ~allas a TXT record atacme.com. - DKIM: Tighten. No key under the usual names. That doesn't prove it's off.
- DMARC: Fix. No record. Add
v=DMARC1; p=none; rua=mailto:[email protected]at_dmarc.acme.com.
Two records and about ten minutes at your DNS provider fix both failures. There's no sign-up, no email address to hand over, and no daily cap.
When you'll use an email deliverability checker
Nobody checks their DMARC record for fun. You land here because something went wrong, usually one of these.
- A customer found your invoice in spam. This is the classic one. A freelancer or small shop moves to their own domain, sets up mail, and never touches DNS again. Mail works fine to friends. Then a client on Gmail never sees the invoice. Nine times out of ten, SPF or DMARC is missing.
- Your newsletter service says the domain isn't authenticated. Every email platform now asks you to prove you own the sending domain. The checker shows which of the four records is the problem before you start editing DNS blind.
- You just changed email providers. Moving from one host to another leaves old records behind. The most common leftover is a second SPF record, which breaks both of them. A two-second check after the switch catches it.
- You're the person someone asked for help. A friend's small business, a client's site, a nonprofit you volunteer for. DNS is public, so you can check any domain without logins. Copy the fix list and send it to whoever holds the DNS keys.
- You're about to send a big batch. A product launch, a fundraising appeal, a class reunion. Check first. A bad SPF record on day one costs you the whole send.
It works the same for a solo founder on Google Workspace, a student running a club's mailing list, or an IT person at a large company looking at a side domain. The records don't care how big you are.
How the Email Deliverability Checker grades your domain
Type a domain and press Enter. Your browser sends about 20 DNS lookups to Cloudflare's public DNS service, falling back to Google's if Cloudflare doesn't answer. It fetches the MX record, the domain's TXT records (where SPF lives), the TXT record at _dmarc. plus your domain, and DKIM keys under 16 common selector names. It also follows every include: inside your SPF record, up to 10 levels deep, so it can count lookups the way a receiving server does.
Each check gets one of four grades: Pass, Tighten, Fix or Couldn't check. The overall verdict is a Fix if anything fails, a Tighten if anything is loose, and a Pass only when all four pass.
| Check | Pass | Tighten | Fix |
|---|---|---|---|
| MX | At least one mail server listed | — | No MX record, or only the "0 ." record that says the domain takes no mail |
| SPF | One record ending in ~all or -all, 10 lookups or fewer | Ends in ?all or has no all; or an included record couldn't be read | Missing; two or more records; +all; more than 10 lookups |
| DKIM | A selector with a real public key | No key under the 16 names we try | Every key found is empty (DKIM was switched off) |
| DMARC | p=quarantine or p=reject | p=none | Missing; two or more records; no valid p= |
When your MX points at Google Workspace, Microsoft 365 or Zoho Mail, a missing SPF record comes with that provider's exact include. For any other host, the checker tells you to ask your provider for their include, because guessing would hand you a record that doesn't work.
Why "Couldn't check" exists. If a DNS lookup times out, the checker says so and grades nothing. It never reports a record as missing just because the network was slow. Telling you to add a record you already have is the worst wrong answer here: you'd add a second SPF record, and two SPF records fail every check.
Examples: what real records grade as
Most deliverability problems come down to a handful of patterns. We ran each of these through the checker on a domain that uses Google Workspace, with the DKIM and other checks passing, so only the record in the first column changes the grade.
| Record | Grade | Why |
|---|---|---|
v=spf1 include:_spf.google.com ~all | Pass | Uses 4 of the 10 lookups: the include plus the three records inside it |
v=spf1 include:_spf.google.com -all | Pass | Same count, stricter ending |
v=spf1 include:_spf.google.com ?all | Tighten | Tells inboxes nothing about servers it doesn't list |
v=spf1 include:_spf.google.com | Tighten | No all at the end, same problem |
v=spf1 include:_spf.google.com all | Fix | A bare all means +all: every server on the internet may send as you |
| Google's include plus 6 single-record includes | Pass | Exactly 10 lookups, right at the limit |
| Google's include plus 7 single-record includes | Fix | 11 lookups. Receivers stop reading and treat SPF as broken |
Two separate v=spf1 records | Fix | Inboxes ignore both |
v=DMARC1; p=none; rua=mailto:[email protected] | Tighten | Meets the Gmail and Yahoo rule, but blocks nothing |
v=DMARC1; p=quarantine | Pass | Failing mail goes to spam |
v=DMARC1; rua=mailto:[email protected] | Fix | No p= policy at all |
DKIM record ending in p= with nothing after it | Fix | An empty key means DKIM was revoked |
The checker also reads records the way DNS actually stores them. Long TXT records arrive split into chunks, so a record stored as "v=spf1 ip4:203.0.113.0/24 " "-all" is joined to v=spf1 ip4:203.0.113.0/24 -all and passes. A 2048-bit DKIM key is too long for one chunk, so it always arrives split like this.
Input is forgiving too. [email protected], https://www.acme.com/contact and ACME.COM. all check acme.com. An international domain like café.fr is checked as xn--caf-dma.fr, the form DNS uses. Typing localhost or hello gets you "That doesn't look like a domain. Try the part after the @ in your email address."
Common mistakes that send mail to spam
Adding a second SPF record instead of editing the first
You sign up for a new email platform. Its setup page says "add this SPF record." You add it. Now you have two, and SPF fails for every message, including the ones that worked yesterday. The fix is one record with every include in it: v=spf1 include:_spf.google.com include:yourplatform.example ~all.
Collecting includes until you pass 10 lookups
Every tool you ever tried for newsletters, invoices or help desks wanted an include. Nobody removes them when they cancel. Google Workspace alone costs 4 lookups, so six more single-record services puts you exactly at the limit, and a seventh breaks it. The checker counts recursively and shows the total, so you know how much room you have. Delete the includes for anything you no longer send from.
Leaving DMARC at p=none forever
p=none is the right place to start. It's also the right place to leave after a few weeks. Read the reports that arrive at the rua= address. When everything legitimate passes, move to p=quarantine. Change that address to an inbox you actually read, too. A report nobody opens is a smoke detector with no battery.
Assuming DKIM is broken because it wasn't found
DKIM keys sit at a name you can't guess from outside. The checker tries the 16 names most providers use. If yours picked something else, you'll see Tighten, not Fix. Open any email you sent, find the DKIM-Signature header, and look for s=. That's your selector. Type it into the box that appears and check again.
Checking a subdomain? The checker grades exactly the name you type. news.acme.com gets its own lookups, including _dmarc.news.acme.com. Real inboxes fall back to the parent domain's DMARC policy when a subdomain has none, but this check doesn't. If a subdomain shows DMARC missing, check acme.com as well before you add anything.
If the checker says your mail will get through but you're still in spam, the records aren't the problem. Look at what you're sending. Gmail also expects bulk senders to keep spam complaints under 0.3% and offer one-click unsubscribe, which no DNS check can see.
Why a domain check shouldn't cost you an email address
A lot of free domain scans are the top of a sales funnel. You type your domain, and the report arrives by email after you hand over an address. The free tests are capped per day. The real product is a monitoring subscription. That's the Free Trial Industrial Complex doing what it does: turn a ten-minute DNS question into a recurring invoice.
DNS records are public. Anyone can look them up. Grading them is a few hundred lines of rules from published standards. The Email Deliverability Checker does the whole job on the page: the lookups go from your browser straight to a public DNS service, the grading runs in your browser, and we never see the domain you typed. You get the answer and the fix, and you leave.
What it deliberately doesn't do: blocklist lookups (the big blocklists refuse queries from public DNS services, so a browser check would report "not listed" even when you are), inbox-placement tests, or ongoing monitoring. Each of those needs a server or an account. We'd rather do four checks completely than ten checks badly.
Related tools
Once the Email Deliverability Checker shows four passes, the next question is whether people open what you send. Paste your email into the Email Subject Line Tester and it writes five subject lines with different hooks, ranked. If you're writing outreach from a fresh domain, the Cold Email Generator drafts a direct three-sentence first message. Tag the links inside with the UTM Parameter Generator so you can tell which email brought someone in.
If your SPF record lists raw IP ranges like ip4:203.0.113.0/24, the CIDR Calculator shows exactly which addresses that range covers, so you can confirm your own mail server is inside it.
Frequently asked questions
How long until a DNS change shows up in the check?
Usually minutes, sometimes a few hours. Public DNS services cache each answer for as long as the record's TTL says, often an hour. If you just added a record and the checker still says it's missing, wait for the TTL to run out and check again. Changing the record twice while you wait only makes it slower to settle.
Do I need any of this if I send from a Gmail or Outlook address?
No. If your address ends in @gmail.com or @outlook.com, those companies own the domain and handle SPF, DKIM and DMARC for you. This check is for people sending from their own domain, like [email protected].
Does a Pass mean my email will land in the inbox?
It means inboxes can confirm the mail really comes from you, which is the entry ticket. It doesn't cover what's inside. A domain with perfect records can still go to spam if recipients keep reporting it, or if a brand-new domain suddenly sends thousands of messages. Records first, then reputation.
My email platform says DKIM isn't set up, but the checker passes. Who's right?
Possibly both. The checker passes DKIM as soon as it finds one working key, usually your main email provider's. Your newsletter platform signs with its own key, under its own selector, often published as a CNAME it asks you to add. So a Pass here says your everyday mail is signed. It doesn't say the platform's key is in place. Its own domain settings page is the place to confirm that one.
Can I check a domain I don't own?
Yes. MX, SPF, DKIM and DMARC records are public, so you can check a client's domain, your employer's, or a vendor's before you trust their invoices. You'll need whoever controls that domain's DNS to apply any fix.
What does a "0 ." MX record mean?
It's called a null MX. It announces that the domain never sends or receives email. Inboxes refuse mail from it, so the checker marks it Fix. If you put it there on purpose for a parked domain, ignore the warning. If you actually send from that domain, replace it with your provider's MX records.
Why does it suggest ~all instead of -all?
Both pass. ~all is the forgiving choice: if you forget to list a service, its mail gets marked suspicious instead of bounced. With DMARC in place, inboxes act on the DMARC policy anyway. Once you're sure every sender is listed, switching to -all is fine.