Email Deliverability Check

Email Deliverability Check looks up a domain's MX, SPF and DMARC records at once and rates how likely your mail is to reach the inbox instead of the spam folder. Receiving servers like Gmail and Outlook only trust a domain when these core authentication records are in place.

Enter a domain and the tool shows whether MX (mail servers) exist, your SPF record and its policy (-all, ~all, etc.), and your DMARC policy (none/quarantine/reject), each flagged ok, warning or danger, plus an overall score and grade. DKIM is excluded here because it requires a selector — check it with DKIM Record Lookup. View individual records in detail with SPF Record Lookup and DMARC Record Lookup.

Why MX, SPF and DMARC must work together

To stop email spoofing, the three records act as a set. MX defines the servers that receive mail, SPF declares which IPs may send mail using your domain name, and DMARC tells receiving servers what to do (ignore, quarantine or reject) when SPF/DKIM checks fail. Leave any one out and attackers can impersonate your domain more easily, while legitimate mail is more likely to land in spam.

Reading policy strength

• SPF -all: reject anything not listed (recommended). ~all is a soft fail (accept but mark), while ?all/+all offer little protection.
• DMARC p=reject: reject failing mail (strongest). p=quarantine sends it to spam, and p=none only monitors without blocking.
• If you are just starting, begin with p=none to collect reports, then ramp up to quarantine and finally reject once things look clean.

Score and grade

The tool weights MX presence, SPF presence and policy strength, and DMARC presence and policy strength into a 0–100 score with an A–F grade. A and B are healthy, C and D need work, and F means almost no protection. If your score is low, tighten the policies above and add DKIM as well. Also confirm your SPF stays within the 10-lookup limit using SPF Lookup Counter, and check whether your sending IP is listed with Email Blacklist (DNSBL) Check.

How each record is graded

Here is exactly which values flag ok, warning or danger. The overall score is a weighted sum of all three, and what sets it apart from a plain existence check is that it also reads the policy strength of SPF and DMARC.

A worked example

Suppose example.com returns the following:

• MX: 10 aspmx.l.google.com present → OK
• SPF: v=spf1 include:_spf.google.com ~all → ends in ~all (soft fail), so Warning
• DMARC: v=DMARC1; p=none; rua=mailto:dmarc@example.com → p=none, so Danger

Here MX scores full marks, but the SPF is not -all and DMARC is only monitoring, so points are deducted and the domain lands around a grade C. To improve it, tighten the SPF tail from~all to -all (after listing every sending IP), and move DMARC from p=none— after collecting reports for a week or two — to p=quarantine and finally p=reject to reach grade A. The presence of rua= for aggregate reports is already a good sign.

Common pitfall

• Never publish two or more SPF TXT records on one domain. Per RFC, multiple SPF records cause a permerror and the whole check fails. Merge every sending service into a single record using include:.
• An OK result here does not guarantee DKIM signing or DMARC alignment. Even when SPF passes, DMARC still fails if the authenticated domain is not aligned with the From: header.