Free email tool
Email deliverability test
Domain and received-header checks
Inspect real public DNS settings and read reported authentication results from received-message headers. Use the findings to investigate email setup issues.
Controlled inbox placement test
Send a marked sample from your own email app to approved receiving accounts. When connected, AskQuokka reads the matching copy’s folder in Gmail, Outlook or Yahoo. It sends no email for you.
Loading receiving-account availability…
1. Check the domain
Look up MX, SPF and DMARC records. Add a DKIM selector to inspect that key too. The public domain and selector are sent to AskQuokka for DNS lookups.
2. Read received-message headers
Paste the original headers from a received message. The analyser reads reported authentication results and routing clues locally. Header text stays in this browser tab and is never sent with the domain check.
How to use these checks
1. Inspect your domain
Enter the domain you want to review. To inspect DKIM, use the selector and signing domain from your provider or a sent message’s DKIM-Signature header.
2. Read a received message
Open the original headers in the receiving email app and paste them into the local analyser. Review every reported server and any conflicting results.
3. Share useful evidence
Copy the domain or header report for your administrator. Use the live test above when controlled receiving inboxes are available.
Questions
What does this deliverability test check?
The domain check reads public MX, SPF and DMARC DNS records. DKIM is checked only when you provide a selector. The separate local analyser reads reported SPF, DKIM and DMARC outcomes from pasted received-message headers. Each check has its own findings, rather than a combined delivery score.
Does it tell me whether a message reached Gmail or Outlook's inbox?
The live test checks the folders in controlled receiving accounts when they are configured. You create a test and send its unique message from your own email app, then check the observed results. Providers without a connected test inbox are labelled unavailable. A test covers only those receiving accounts and that message; it does not predict every recipient’s inbox.
Can I trust pass results in pasted headers?
Treat them as reported, unverified evidence. Authentication-Results names the server claiming the result, but pasted headers and server names can be forged. Different results may also describe different hops or identities. This tool does not verify a message's signature or the source of a header.
What happens to headers I paste?
They remain in this browser tab and are analysed locally. They are not sent to the domain-checking API, saved by this tool or included in analytics. Leaving or refreshing clears them. Only your public domain and optional DKIM selector are sent for DNS lookups.
Why can a check be unavailable or not checked?
DNS errors and request limits can prevent a lookup. Those checks are labelled unavailable, separately from missing records. DKIM is not checked when no selector is supplied. This tool does not guess a selector or count an unfinished check as a pass.
Does an MX record prove a mailbox exists?
No. MX identifies published incoming-mail destinations. This tool does not connect to them or probe mailboxes. A missing MX also needs context because SMTP may fall back to A or AAAA addresses, which this check does not evaluate.
References: Authentication-Results trust boundaries, MX and null MX.