Email Deliverability Check
Before reputation, before content, receivers ask one question: can this domain prove the mail is really theirs? This check reads the proof — MX records, the SPF sender list (expanded and counted the way a receiver counts it), the DMARC policy at _dmarc, and DKIM keys under the common selectors — and returns findings in plain language, ordered the way an operator would fix them.
Want this watched continuously? Monitor this free with myeventwatch — expiry and downtime alerts, no card required.
What the check measures
Spam filtering starts with identity because identity is checkable in milliseconds. When mail arrives claiming to be from a domain, the receiving server looks up that domain's published rules. SPF names the servers allowed to send. DKIM offers a signature to verify against a published key. DMARC demands that the visible From domain align with one of those two proofs and states the penalty — none, quarantine, reject — for mail that has neither. The page calls GET /api/check/email-auth on sysosx's server, which reads the same records through the DNS parsers the health check uses, and translates them into findings: each protocol, each problem, one severity, in the order worth fixing.
Two of the findings deserve a word about honesty, because both are places where checkers commonly fake precision. The SPF lookup count is real: the checker expands include and redirect chains term by term under the same rules a receiver applies, so the number it reports is the number a strict receiver would compute — including when the record has quietly drifted over the ten-lookup limit as vendors changed their own records. And the DKIM result is a probe, not a census: keys are published under selector names the owner chooses, the check tries the common ones, and finding none of them does not prove DKIM is absent — a key under any other selector is invisible from outside, and the result states that plainly rather than declaring a domain unsigned. The only complete DKIM test remains a real message and its Authentication-Results header.
Reading a result
Start with the failures; they are the spam folder's favourite causes. No MX means the domain cannot receive mail at all. No SPF, or an SPF record ending in +all, means anyone can claim to be you — the second is worse, because the claim is officially permitted. Multiple SPF records quietly void SPF evaluation entirely. A missing DMARC record means failing mail has no stated penalty and, just as costly, nobody is collecting the aggregate reports that show who is sending as your domain — those reports are how spoofing campaigns are usually discovered. Warnings are the middle state: p=none is a fine place to start DMARC and a poor place to stop; ~all is testing mode, not a destination. Then take the second half of the picture: authentication proves identity, while the DNS blacklist checker measures reputation — run both, because a perfectly authenticated domain on a listed IP still lands in spam, and a clean IP with broken SPF does too. The guide that ties it together is why your email lands in spam.
Frequently asked questions
What are SPF, DKIM and DMARC, and how do they fit together?
They are three DNS-published answers to the question "is this mail really from the domain it claims?" SPF lists the servers allowed to send for a domain. DKIM lets a domain cryptographically sign messages, so a receiver can verify the signature against a key published in DNS. DMARC ties them together: it requires that the sending domain in the visible From header aligns with the SPF or DKIM result, and it tells receivers what to do — monitor, quarantine, or reject — when neither aligns. SPF without DMARC is an unsigned suggestion; DMARC is what turns the other two into a policy.
My mail still goes to spam even though all three pass. Why?
Because authentication is the entry ticket, not the seating plan. Passing SPF, DKIM and DMARC means receivers believe the mail is genuinely yours — after that, placement depends on reputation and content: blacklist listings (check those with the blacklist checker on this site), recipient engagement, complaint rates, sending-volume patterns and the message itself. Authentication failures are the most common fixable cause of spam placement, which is why this check comes first, but a clean result here plus persistent spam placement means the problem lives in reputation or content, not identity.
The check says no DKIM key was found. Does that mean my domain does not sign?
No — and the result says so in as many words. DKIM keys live under selector names the domain owner chooses, and there is no way to enumerate a domain's selectors from outside. This check probes the common selectors used by major providers (default, google, selector1, selector2, mail, dkim, s1, s2, k1, mandrill and a few more). A key under any other name is invisible to the probe. The definitive test is a real message: send mail to a mailbox you control and inspect the Authentication-Results header, which reports the selector used and whether the signature verified.
Why does the check count SPF lookups, and why is 10 the limit?
Evaluating an SPF record can require further DNS lookups — every include, a, mx, ptr, exists and redirect term costs one. RFC 7208 caps the total at 10; beyond it, receivers return a permanent error and the SPF result is void, which can be worse than a modest record that evaluates cleanly. Records grow lookups quietly as providers are added (each include brings its own terms), so a record that was legal at setup can drift over the limit as vendors change their records. This check expands the record the way a receiver would and reports the real count, so drift is visible before it voids your authentication.
What should I fix first if several findings are failures?
In order: multiple SPF records (merge to one — everything downstream is unreliable until that is fixed), a missing or +all SPF record (publish the real sender list, ended by -all), a missing DMARC record (start at p=none with a reporting address, so you can see who sends as you before enforcing), then raising DMARC from p=none toward p=reject as the reports come in clean. Blacklist listings, if any, are parallel work — fix their cause and request delisting while the records are being repaired. Our guide walks the order with the reasoning: why your email lands in spam.