Email Deliverability Checker — SPF, DKIM, DMARC and MX
Find out why your email lands in spam. This checks your MX records, SPF policy, DKIM signatures and DMARC alignment in one pass, and tells you exactly which record to fix.
The four records that decide whether your email arrives
Email that lands in spam almost never has anything to do with the message. It has to do with four DNS records that tell receiving servers whether you are allowed to send mail as your domain. Get them right and delivery improves immediately; get one wrong and even a plain text message from a real customer conversation can be filtered.
- MX — where inbound mail is delivered. Without it, nobody can email you at all.
- SPF — a public list of the servers permitted to send mail as your domain. Receiving servers check the sending IP against it.
- DKIM — a cryptographic signature added to each message, proving it was not altered and really came from you.
- DMARC — the policy that ties the other two together and tells receivers what to do when a message fails: nothing, quarantine, or reject.
The SPF ten-lookup limit
SPF records may trigger at most ten DNS lookups while being evaluated. Every include, a, mx, ptr and exists mechanism counts. Sites that add a record for their host, their newsletter tool, their CRM and their invoicing platform routinely cross the limit, at which point the whole SPF record is treated as permanently failed — not partially, entirely. This tool counts your lookups and tells you how close you are.
Why a soft SPF fail is worse than none
An SPF record ending in ~all asks receivers to accept but flag unauthorised mail. Ending in -all asks them to reject it outright. Starting with ~all while you confirm every legitimate sender is sensible; leaving it there for years means anyone can spoof your domain and expect their mail to be delivered. Once your senders are verified, tighten it.
Starting DMARC safely
Publish p=none with a reporting address first. That changes nothing about delivery but starts sending you daily reports on who is sending mail as your domain. After a few weeks the picture is clear enough to move to quarantine, and later to reject. Skipping straight to reject is the most common way to accidentally block your own invoices.
Frequently asked questions
Why do my emails go to spam?
In most cases because the receiving server cannot verify you are allowed to send as your domain. Missing or broken SPF, DKIM and DMARC records are the leading cause, followed by a blacklisted sending IP and poor sending reputation. Run the check above — it tells you which of the four records is missing or misconfigured.
What is an SPF record?
SPF is a TXT record listing the servers allowed to send email using your domain name. When a message arrives, the receiving server compares the sending IP against that list. If the IP is not authorised, the message is flagged or rejected depending on your policy.
Can I have two SPF records?
No. A domain must publish exactly one SPF record. Two or more is a permanent error and receiving servers will treat the whole check as failed, which is worse than having no SPF record at all. Merge every sender into a single record using multiple include mechanisms.
What is DKIM and do I need it?
DKIM adds a cryptographic signature to each outgoing message using a private key, which receivers verify against a public key published in your DNS. It proves the message was not altered in transit and genuinely originated from your domain. You need it: DMARC cannot pass on SPF alone once a message is forwarded.
What should my DMARC policy be?
Start with p=none and a reporting address so you can see who sends mail as your domain without affecting delivery. Once you have confirmed every legitimate sender passes SPF or DKIM, move to p=quarantine, then p=reject. Rushing to reject before that is how businesses block their own invoices and newsletters.
How long do email DNS changes take to work?
SPF, DKIM and DMARC are TXT records, so they follow normal DNS timing — usually live within five minutes to an hour depending on the TTL. MX changes are the same. Reputation recovery after fixing a problem takes longer, typically a few days of consistent sending.
