--- title: Free Email Health description: Check a domain's SPF and DMARC records in one run, with a letter grade. DKIM needs a selector, so it shows as not checked here; use the DKIM Checker for the key. canonical: https://watchfor.io/email-policy-checker --- [Back to all free tools](/free-tools) # Email Health Check a domain's SPF and DMARC records in one run, with a letter grade. DKIM needs a selector, so it shows as not checked here; use the DKIM Checker for the key. [How to use this tool](/blog/how-to-check-email-authentication) Result No result yet Fill in the form above and run it — the result appears here. Monitor this 24/7 — get alerted when a failure is confirmed. [Start free](/auth/sign-up) Only run these tools against systems you own or are authorized to test. Using them to scan or probe systems without permission violates our [Terms](/legal/terms). ## The Email Health grade scale Every domain gets one of these grades for its SPF and DMARC records, with the reasons and the exact DNS change behind it. DKIM counts only when a selector is checked — not checking it never lowers the grade. A+ Excellent One valid SPF record that ends in -all or ~all, and DMARC at p=reject for all mail with aggregate reports turned on. Spoofed mail is rejected and you can see who sends as you. A Good Protected, one step short of A+: usually DMARC at p=quarantine, pct below 100, a weaker subdomain policy, no aggregate reports, or a 1024-bit DKIM key. B Needs attention DMARC is published but only monitors (p=none). Receivers report spoofed mail and deliver it anyway. C Weak SPF or DMARC is missing or broken: no record, two SPF records, more than 10 DNS lookups, a neutral ?all, an invalid DMARC record — or a DKIM key too short to count. F Failing SPF ends in +all: the domain authorises every server on the internet to send as it. ## Every rule, in full The grade starts at A+ and each problem can only lower the ceiling, so the grade is always explained by the worst finding in the report. Rules version email-health-2026.10 . Grade at most When F SPF ends in +all (or a bare all) — every server is allowed to send as the domain C No SPF record C More than one SPF record — receivers must treat SPF as a permanent error C The SPF record itself has more than 10 DNS-lookup terms (include, a, mx, ptr, exists, redirect) — a permanent error C SPF ends in ?all, or has no all and no redirect — neutral, it protects nothing C No DMARC record at _dmarc. C DMARC record invalid: more than one record, or no p= policy C The DKIM key at a checked selector is RSA below 1024 bits — receivers ignore it B DMARC p=none — monitoring only, spoofed mail is delivered A DMARC p=quarantine — spoofed mail goes to spam, not rejected A DMARC pct below 100 — the policy covers only part of the mail A DMARC sp=none while p enforces — subdomains can still be spoofed A No rua= aggregate reports — you cannot see who sends as you A The DKIM key at a checked selector is RSA 1024–2047 bits (2048 recommended) — SPF ~all (softfail): reported, not graded — DMARC decides with an enforcing policy — SPF with 8–10 lookup terms: reported — includes are counted, not followed, so the real total may be higher — SPF redirect=: reported — the redirected record is not followed — DKIM not checked (no selector), no key at the selector, or a revoked key: reported, never graded No grade at all when: the check did not complete, or the domain does not resolve; a DNS lookup failed at our side (timeout, SERVFAIL) while SPF or DMARC reads as missing. A failure on our side is never your F. [How WatchFor grades everything the same way](/grades#email-health) ## What is Email Health ? Email health is the combined assessment of the three records every modern mail provider uses to decide whether your mail is legitimate: SPF (which servers are allowed to send for your domain), DKIM (cryptographic signature on outgoing mail), and DMARC (what receivers should do when SPF/DKIM fail). All three working = good deliverability. One missing = you'll see soft fails. All three missing = your mail lands in spam at most large providers. This tool reads the SPF and DMARC records of any domain in one run, shows each record with its policy, counts the SPF record's top-level DNS lookups, and gives the domain an Email Health grade from A+ to F — with every reason listed worst first and the exact DNS record that fixes it. DKIM needs a selector, and this page has no selector field, so DKIM shows as not checked; not checking it never lowers the grade. Check the key with the DKIM Checker and your selector. It turns "why does my mail end up in spam" into a short list of records to fix. ## How it works All three records are TXT lookups in DNS, just at different names: - 1 SPF: query TXT at the apex — Look up TXT example.com and find the record starting with v=spf1 . Read its all qualifier ( ~all , -all …) and count the terms that cost a DNS lookup ( include: , a , mx , ptr , exists: , redirect= ). Includes are counted, not followed, so lookups inside them aren't in the number. - 2 DKIM: query TXT at the selector — The key lives at TXT ._domainkey.example.com , and the selector is announced by the sender in each message ( DKIM-Signature: ... s= ). DNS can't list selectors, so this page doesn't guess: DKIM shows as not checked. The DKIM Checker takes your selector and checks the key; the Smart Website Checker tries a few common ones. - 3 DMARC: query TXT at _dmarc — Look up TXT _dmarc.example.com . Find the record starting with v=DMARC1 . Parse tags: p= (policy: none/quarantine/reject), rua= (aggregate report URI), ruf= (forensic report URI), sp= (subdomain policy), pct= (percentage of mail to apply policy to). - 4 Grade it: start at A+, every problem caps — The domain starts at A+ and each finding can only lower the ceiling — the worst one wins, nothing adds points back. +all caps at F; a missing or broken SPF or DMARC record (two SPF records, more than 10 lookups, ?all , no p= ) caps at C; DMARC p=none caps at B; p=quarantine , pct below 100, sp=none or no rua= reports cap at A. ~all is reported but doesn't cap — with an enforcing DMARC policy receivers act on DMARC. The full rule table (rules version email-health-2026.10 ) is under the tool. If a DNS lookup failed on our side and a record reads as missing, there is no grade rather than a wrong one. ## When you'd use it ### Pre-launch deliverability check Before sending marketing or transactional email at scale from a new domain, run a full email-health check. Anything missing = fix before sending. Skipping this is the most common cause of "first campaign went straight to spam." ### Onboarding a new ESP Adding Mailchimp/SendGrid/Resend/Postmark — they all give you SPF includes and DKIM selectors to add. Run this tool to confirm both records are correct and that DMARC will still pass after the change. ### Investigating a deliverability drop Open rates fell off a cliff. Run an email-health check on your sending domain. Common discoveries: a second SPF record added by someone onboarding a new tool, SPF close to 10 DNS lookups (count the nested ones too — see pitfalls), DMARC moved from p=none to p=quarantine without warning. Then check the DKIM selector with the DKIM Checker. ### Defending against email spoofing Phishing campaign impersonating your domain. Check DMARC — if p=none , receivers aren't blocking spoofed mail. Move to p=quarantine then p=reject after analysing aggregate reports for legitimate-but-misaligned senders. ### Subdomain policy verification DMARC sp= tag controls subdomain policy. If unset, subdomain policy inherits from parent. Verify that mail-sending subdomains (e.g. marketing.example.com ) have explicit DMARC policies appropriate for their use. ## Reading the result ### SPF — Sender Policy Framework Lists the authorised senders. v=spf1 ip4:1.2.3.4 include:_spf.google.com ~all means: IP 1.2.3.4 is allowed, anything Google's SPF allows is allowed, everything else is softfail ( ~all ) — would-be senders not in the list trigger a soft fail at the receiver. -all is the strict version (hard fail). +all is a misconfiguration that authorises everyone. ### DKIM — DomainKeys Identified Mail Cryptographic signature added to outgoing mail by the sending server. The public key is published in DNS at ._domainkey. . Receiver fetches the public key, validates the signature, confirms the mail wasn't tampered with in transit AND was sent by someone who controls the private key. Strong signal of authenticity. ### DMARC — Domain-based Message Authentication, Reporting, and Conformance Tells receivers what to do when SPF or DKIM fail and how to send you aggregate reports about it. p=none = monitor only, don't reject anything (audit mode). p=quarantine = send failing mail to spam. p=reject = bounce failing mail entirely. rua=mailto:dmarc@example.com = receivers send daily aggregate XML reports here. ### Why all three together is strong SPF alone passes for forwarded mail (which legitimately changes the sender IP). DKIM alone survives forwarding but fails if the mail is modified. DMARC requires either SPF or DKIM to pass AND to align with the From: header — that combination is what makes spoofing hard. ## Common pitfalls ### SPF record exceeds 10 DNS lookups RFC 7208 allows at most 10 DNS lookups while evaluating SPF, and the lookups inside each include: count too. Exceed it and receivers return a permanent error — your SPF fails. This tool's number counts only the top-level terms, so a record at 8 can really be at 10 or more: check what each include costs with dig TXT before adding one. Fix: drop unused includes, or replace an include with the provider's literal IP ranges. ### Multiple SPF records on the same domain Only one TXT starting with v=spf1 is allowed. If you have two (common when adding a new ESP without removing the old one), receivers MUST treat it as a permanent error. Consolidate into one record. ### DKIM selector returns no record Either: (1) the selector you're querying isn't the one the sender is using — check the actual DKIM-Signature header in a received message to confirm; (2) the ESP rotated selectors and the old one was removed from DNS; (3) the selector was never added (deployment mistake when onboarding the ESP). ### DMARC at p=none indefinitely p=none is the audit mode — receivers report what would happen but don't act on it. Many teams set p=none and never move past it. That means receivers can still accept spoofed mail. Use the aggregate reports to identify legitimate senders, fix their SPF/DKIM, then move to p=quarantine and eventually p=reject . ## Run Email Health on every change, not just once. Get alerted when an outage is confirmed — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 15 monitors. No card. [Start free](/auth/sign-up) ## Frequently asked questions Which of SPF, DKIM, DMARC matters most? All three, together. DMARC is the policy layer; without it, SPF/DKIM signals don't have enforcement. SPF alone fails for forwarded mail. DKIM alone doesn't protect against header spoofing. Modern best practice: all three, with DMARC at p=reject . Will configuring DMARC p=reject break legitimate mail? It might, if any legitimate sender isn't in SPF or doesn't DKIM-sign and aligns. Always start at p=none , analyse aggregate reports for 2-4 weeks, identify any legitimate-but-failing senders, fix them (add to SPF or get them DKIM-signing), then move to p=quarantine , then p=reject after another period of clean reports. What does the Email Health grade mean? How well your SPF and DMARC records stop other people sending mail as your domain. A+ = one valid SPF record ending in -all or ~all , and DMARC at p=reject for all mail with aggregate reports on. A = protected, one step short (usually p=quarantine ). B = DMARC only monitors ( p=none ), so spoofed mail is still delivered. C = SPF or DMARC is missing or broken. F = SPF ends in +all and authorises every server on the internet. How is the grade calculated? It starts at A+ and every finding can only cap it, so the grade is always explained by the worst reason shown under it — each with what it means and the DNS record that fixes it. The rules are versioned ( email-health-2026.10 ) and published in full on this page; the same capped approach is used by every WatchFor grade (see /grades). Does a missing DKIM check lower my grade? No. DKIM keys sit under a selector only the sender knows ( google , selector1 , s1 …), and this page has no selector field, so DKIM shows as not checked and is left out of the grade. Run the DKIM Checker with your selector — find it in the s= tag of a received message's DKIM-Signature header. When a selector is checked, a key shorter than 1024 bits caps the grade at C and a 1024-bit key at A. Why does ~all still get A+ here? Because with an enforcing DMARC policy ( p=quarantine or p=reject ) receivers act on DMARC, not on the SPF qualifier. Without enforcing DMARC, the DMARC finding already caps the grade at B or C. -all is still the stricter choice once every sender is listed. Why do I get no grade at all? When a DNS lookup timed out or failed on our side and SPF or DMARC therefore reads as missing, we don't know whether the record exists — so we show no grade instead of blaming your domain. Run the check again in a minute. A lookup that answers "no such record" is a real missing record and is graded. What does ~all vs -all actually mean? ~all = soft fail. Mail from unauthorised senders is suspicious but not rejected outright. -all = hard fail. Receivers should reject mail from unauthorised senders. With DMARC p=reject in place, the two are nearly equivalent — DMARC enforces regardless. Without DMARC, -all is stricter. What's a DKIM selector and why does each ESP use a different one? A selector is a label that lets one domain have multiple DKIM key pairs for different senders. ESPs use selectors so you can rotate keys, run multiple ESPs in parallel, or distinguish marketing vs transactional. The selector is announced in the DKIM-Signature header of each outgoing message. How long does it take for SPF/DKIM/DMARC changes to take effect? DNS TTL bound — if your records have a 5-minute TTL, the change is visible to most receivers within 5 minutes. With a 24h TTL, up to a day. Setting low TTLs before making changes is the standard pattern. Should I have SPF or DMARC at the subdomain level? SPF: usually yes if the subdomain sends mail. DMARC: optional — if unset, DMARC at the parent applies via sp= tag (or inheritance default). For domains that send no mail from any subdomain, an explicit DMARC sp=reject is a defense against spoofed subdomain mail. Where do I receive DMARC aggregate reports? Wherever you set the rua=mailto: tag. Receivers will send daily XML reports there. Parse them with a tool like Postmark's DMARC service, dmarcian, or self-hosted ( opendmarc includes a parser). Raw XML is dense; tooling makes it tractable. ## Related email tools - [SPF CheckerRead a domain's SPF record — its all policy, includes, a second-record check and a count of the DNS lookups the record itself makes (includes are counted, not followed).](/spf-record-checker) - [DKIM CheckerCheck the DKIM key published for a selector — the record, key type and key size, and whether the key is live or revoked.](/dkim-record-checker) - [DMARC CheckerRead a domain's DMARC record — policy, subdomain policy, pct, alignment modes and whether aggregate and failure reports are requested.](/dmarc-record-checker) - [SMTP Server TestConnect to any mail server on port 25, 465 or 587 from a real probe location and see what a sending server sees — the banner, whether STARTTLS is offered, whether reverse DNS matches, and whether it relays for strangers. Verify a new mail host before you route production mail through it.](/smtp-test) --- Canonical page: https://watchfor.io/email-policy-checker · Site guide: https://watchfor.io/llms.txt