Email deliverability teams
Check SPF, DKIM, DMARC and sending-IP reverse DNS before mail lands in spam
AdminKit's free SPF, DKIM, DMARC, MX and reverse DNS tools let email deliverability teams check every sending domain and IP's authentication and PTR setup today, since a missed DKIM selector rotation, an SPF record over the 10-lookup limit, or a sending IP with no PTR record can quietly suppress inbox placement with no error message pointing at the cause.
Updated
At a glance
The problem
Running an email sending program, whether transactional, marketing, or both, means every sending domain and subdomain needs correct SPF, DKIM and DMARC records, not just a single office domain. SPF records grow brittle as more email service providers get added as include: entries, since RFC 7208 caps the total number of DNS lookups a resolver may perform while evaluating one record at 10; add one more vendor past that limit and a record that validated for years can turn into a PermError with nothing on the sending side pointing at the cause.
DKIM adds its own failure mode: a selector rotated for key hygiene without overlap, cutting the old selector before the new one is confirmed live and propagated, breaks signing for every message sent in that gap. The result looks the same whether the root cause is SPF’s lookup limit or a DKIM rotation done out of order: mail quietly filtered to spam or rejected outright at a growing number of receivers, with no bounce message naming the real reason.
A sending IP with no reverse DNS (PTR) record is a separate, basic signal many receiving mail servers check before they even evaluate SPF or DKIM, and DMARC’s own aggregate (rua) reports are the only reliable way to see, per sending source, whether moving a policy toward enforcement would block legitimate mail or only mail sent in your name by someone else. None of this needs a paid platform to check — it needs the right things checked on a recurring basis as a sending program changes, not once when a domain is first set up.
Talk to an expert
Huy Nguyen (David), Founder & CEO, Netbase JSC
Ask how AdminKit fits email deliverability teams — setup, timeline, or pricing.
What you can do for free today
These tools check public DNS records for any sending domain or IP; none of them need access to your mail provider’s dashboard or an account to run.
- Check your SPF record’s DNS lookup count — follows every
include,a,mx,ptr,existsandredirectmechanism, including nested includes, and counts the total against RFC 7208’s 10-lookup limit. - Check a DKIM selector’s record and key syntax — enter the domain and selector your sending platform uses to confirm the key is published and syntactically valid.
- Check your DMARC policy, alignment and reporting tags — parses
p,sp,pct,rua,ruf,adkimandaspfto show whether you’re enforced, monitoring only, or exposed. - Look up a domain’s mail servers and confirm they resolve — shows MX priority order and makes a second round of A/AAAA lookups so a listed-but-dead host doesn’t look fine just because it’s in the record.
- Check a sending IP’s reverse DNS (PTR) record — many receivers check this before they even get to SPF or DKIM.
For how the three authentication records fit together, see SPF, DKIM and DMARC explained, and for reading a DMARC check’s tags one by one, how to read a DMARC check result. DMARC alignment: relaxed vs. strict covers the adkim/aspf distinction in more depth, and reading DMARC aggregate reports and rolling out to reject walks through the staged move from p=none toward enforcement using real rua report data. If you’re switching providers, migrating email providers without breaking SPF, DKIM or DMARC covers the sequencing that keeps a cutover reversible. See also how AdminKit’s checks compare to other free tools: best free SPF/DMARC checkers and best free MX record lookup tools.
What AdminKit will add
AdminKit’s blacklist (DNSBL) check is coming soon, to check a sending IP or domain against public blocklists in one pass instead of querying each DNSBL manually. Today, a DNSBL lookup is still just a DNS query you can run yourself, which the why is my IP blacklisted guide covers.
AdminKit’s Check API is in early access and development, documented to expose the same DNS, mail, TLS, port, MQTT and Modbus checks as structured, scriptable results — useful for a deliverability team that wants to check many sending domains or IPs on a schedule instead of running each tool by hand through the website. It isn’t live yet, so the tools above are, honestly, free, point-in-time checks you run yourself today, one domain or IP at a time.
This page is general guidance, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.
Frequently asked questions
How many SPF DNS lookups can we use before mail starts failing silently?
10, total, no matter how many email service providers (ESPs) you add. RFC 7208 requires implementations to "limit the total number of those terms to 10 during SPF evaluation" (RFC 7208 §4.6.4) — a void (PermError) record is the result once you exceed it, and some receivers then treat the record as if it failed. AdminKit's SPF check counts every DNS lookup, including nested includes, so you can see the current count before adding another vendor pushes it over.
What should we check before and after rotating a DKIM selector?
Publish the new selector's key in DNS and confirm it with AdminKit's DKIM check before any mail signs with it, then keep the old selector's record live until you're certain nothing is still signing with the old key — the same overlap logic used when migrating to a new provider's DKIM key, just for a planned rotation instead of a provider switch. Cutting the old selector before the new one has propagated and been confirmed is what turns a routine rotation into a signing outage.
A sending IP has no PTR (reverse DNS) record — does that mean it's blacklisted?
No, they're separate signals. A PTR record is a basic anti-spam check many receiving mail servers do before they even evaluate SPF or DKIM; a missing or non-matching one is a red flag on its own, independent of whether the IP is also listed on a DNSBL. AdminKit's reverse DNS tool checks the PTR record specifically; the blacklist check (coming soon) is for DNSBL listings.
Our DMARC aggregate reports show a sending source we don't recognize — what next?
Identify it first, using the report's source_ip and header_from fields against your own list of approved senders, before assuming it's an attacker spoofing your domain — it's often a forgotten legitimate sender (a billing tool, a marketing platform) instead. The dmarc-aggregate-reports-rollout guide walks through reading a rua report and the staged rollout from p=none toward enforcement that this kind of surprise is exactly meant to surface safely.
Can AdminKit check DNSBL/blacklist status for our sending IPs today?
Not yet. AdminKit's blacklist check is coming soon; today, a DNSBL lookup is just a DNS query you can run manually by reversing the sending IP's octets and querying the blocklist zone directly, which the why-is-my-ip-blacklisted guide covers. SPF, DKIM, DMARC, MX and reverse DNS are live checks today; DNSBL status is the one piece of this page's checklist that isn't yet.
Related
- SPF check
- DKIM check
- DMARC check
- MX lookup
- Reverse DNS (PTR)
- Blacklist (DNSBL) check
- /guides/spf-dkim-dmarc-explained/
- /guides/how-to-read-a-dmarc-check-result/
- /guides/dmarc-alignment-relaxed-vs-strict-explained/
- /guides/dmarc-aggregate-reports-rollout/
- /guides/migrating-email-providers-without-breaking-spf-dkim-dmarc/
- /compare/best-free-spf-dmarc-checkers/
- /compare/best-free-mx-record-lookup-tools/
Want AdminKit set up for you?
Tell us about your setup — we will follow up about early access and, if you need it, expert help.
How AdminKit works with you
- Delivered remotely — Netbase JSC, the company behind AdminKit, has worked with clients in 80 countries.
- Contracts and invoices are issued by Netbase JSC; payment goes to the company by bank transfer to Netbase JSC's company account or PayPal Business.
- Talk to the CEO, Huy Nguyen (David), directly on WhatsApp or by email at [email protected].