All checks via Cloudflare DoH (Google DoH fallback). Common DKIM selectors: default, google, mail, k1 (Klaviyo), s1, s2 (SendGrid), mandrill, amazonses.
What this tool does
Free inbox placement test -- check email deliverability with live SPF, DMARC, and DKIM analysis
This free inbox placement test evaluates the technical authentication configuration of any sending domain to predict whether email will land in the inbox or spam folder. Enter a domain name and an optional DKIM selector, then click Run. The tool performs five live DNS checks in parallel: MX record presence, SPF policy enforcement level, DMARC policy strength, DKIM public key existence, and whether the domain is a known disposable email provider. Each check is scored individually and the scores are totalled into an overall placement prediction displayed as a percentage with a clear Likely Inbox, Probably Inbox, At Risk, or Likely Spam verdict.
All DNS lookups run in real time via Cloudflare's DNS over HTTPS (DoH) API with Google's DoH as automatic fallback if Cloudflare is unavailable. This means you always get fresh, live results rather than cached data. MX records are looked up at the domain root. SPF is looked up as a TXT record at the domain root and parsed for the enforcement mechanism. DMARC is looked up at the standardised _dmarc.domain.com hostname. DKIM is looked up at selector._domainkey.domain.com using whichever selector you provide. The disposable domain check uses the Kickbox open API to flag domains associated with throwaway email services.
Inbox placement testing is a critical step in email deliverability troubleshooting. When open rates drop suddenly, when cold email campaigns get no replies, or when transactional emails stop arriving, the first step is always to check the DNS authentication configuration. Missing DMARC, a misconfigured SPF record, or an expired DKIM key are the most common causes of deliverability problems and are completely invisible to email senders until they check. This tool surfaces those issues instantly, before you send a single email, along with enough detail to understand what needs to be fixed and why it matters.
Signals checked
MX Records
Verifies that the domain has at least one mail server configured and can receive email -- a prerequisite for any credible sending domain.
SPF (-all)
Hard-fail SPF scores maximum points -- it tells receivers to reject any sender not listed in the SPF record, the strictest enforcement level.
SPF (~all)
Soft-fail SPF scores near-maximum -- it marks unlisted senders as suspicious but still delivers, the recommended setting for most senders.
DMARC p=reject
Maximum DMARC enforcement. Instructs receivers to reject messages that fail both SPF and DKIM alignment, signalling full sender control.
DMARC p=quarantine
Good DMARC enforcement. Failed messages go to spam rather than being rejected, providing strong protection with less risk of false positives.
DMARC p=none
Monitoring-only DMARC. Provides reporting data but no enforcement -- failed messages are delivered normally. Not a protective configuration.
DKIM key
Checks for the DKIM public key DNS record at selector._domainkey.domain. A missing key means messages are not cryptographically signed.
Disposable domain
Flags domains registered as throwaway email providers -- these are heavily penalised by spam filters and major inbox providers.
Scored prediction
All signals are weighted and combined into a 0-100% score with a four-tier inbox placement prediction verdict.
Actionable detail
Every signal shows not just pass/fail but the exact record found or missing, with enough context to fix the issue without additional research.
Examples
Inbox placement examples -- what good and bad authentication configurations look like
These examples show the DNS records and placement scores for different authentication configurations, from fully production-ready to critically misconfigured.
PassFull enforcement -- production-ready sender, 97% score
MX: 10 mail.example.com [pass, 20/20]
SPF: v=spf1 include:sendgrid.net -all [pass, 20/20]
DMARC: v=DMARC1; p=reject; rua=mailto:dmarc@example.com [pass, 25/25]
DKIM: v=DKIM1; k=rsa; p=MIGfMA0G... [pass, 20/20]
DISP: Not a disposable domain [pass, 10/10]
Score: 95/95 = 100% -> Likely Inbox
This is the gold standard configuration. SPF with -all, DMARC with p=reject, a valid DKIM key, and rua= aggregate reporting all present. Email from this domain will pass authentication at every major inbox provider and will never be flagged on technical grounds. The rua= tag also provides ongoing monitoring so any authentication failures are reported immediately.
GoodQuarantine policy -- good enforcement, minor improvement possible
MX: 10 aspmx.l.google.com [pass, 20/20]
SPF: v=spf1 include:_spf.google.com ~all [pass, 18/20]
DMARC: v=DMARC1; p=quarantine; rua=mailto:rua@example.com [pass, 22/25]
DKIM: v=DKIM1; k=rsa; p=MIGfMA0G... [pass, 20/20]
DISP: Not a disposable domain [pass, 10/10]
Score: 90/95 = 95% -> Likely Inbox
A well-configured domain using Google Workspace for sending with ~all SPF and p=quarantine DMARC. Minor improvement available by upgrading SPF to -all and DMARC to p=reject, but this configuration already achieves excellent inbox placement at all major providers. The ~all vs -all difference matters more for domains with complex forwarding setups where hard fails could block legitimate mail.
WarningNo DMARC -- SPF and DKIM present but no policy enforcement
MX: 10 mail.example.com [pass, 20/20]
SPF: v=spf1 include:sendgrid.net ~all [pass, 18/20]
DMARC: No DMARC record found at _dmarc.example.com [fail, 0/25]
DKIM: v=DKIM1; k=rsa; p=MIGfMA0G... [pass, 20/20]
DISP: Not a disposable domain [pass, 10/10]
Score: 68/95 = 72% -> Probably Inbox
SPF and DKIM are correctly configured but the absence of a DMARC record costs 25 points. Without DMARC, there is no policy for what to do when authentication fails -- receivers make their own decision. Critically, without DMARC you also have no visibility into authentication failures or spoofing attempts. Adding even a p=none DMARC record immediately boosts the score and provides reporting data to monitor before moving to enforcement.
FailMissing SPF and DMARC -- high spam placement risk
MX: 10 mail.example.com [pass, 20/20]
SPF: No SPF record found [fail, 0/20]
DMARC: No DMARC record found [fail, 0/25]
DKIM: No DKIM record at default._domainkey.example.com [fail, 0/20]
DISP: Not a disposable domain [pass, 10/10]
Score: 30/95 = 32% -> Likely Spam
A domain with only MX records and no authentication. This configuration is extremely common for domains that send email through a third-party ESP without completing the DNS setup. Gmail, Outlook, and Yahoo will route these messages directly to spam or reject them entirely under their bulk sender policies. All three records -- SPF, DMARC, and DKIM -- need to be added via the ESP's DNS configuration instructions.
WarningDMARC p=none -- monitoring only, no protection
MX: 10 mail.example.com [pass, 20/20]
SPF: v=spf1 include:mailchimp.com ~all [pass, 18/20]
DMARC: v=DMARC1; p=none; rua=mailto:rua@example.com [warn, 10/25]
DKIM: v=DKIM1; k=rsa; p=MIGfMA0G... [pass, 20/20]
DISP: Not a disposable domain [pass, 10/10]
Score: 78/95 = 82% -> Likely Inbox
DMARC with p=none is the recommended starting point when first deploying DMARC -- it enables reporting without affecting delivery. After reviewing the rua= aggregate reports for 2-4 weeks to confirm all legitimate mail is passing, upgrade to p=quarantine and then p=reject. Staying on p=none permanently means authentication failures are never enforced, allowing spoofed email to be delivered on behalf of your domain.
FAQ
Frequently asked questions about inbox placement testing and email deliverability
What is an inbox placement test and how does it work?
An inbox placement test evaluates the DNS authentication signals associated with a sending domain -- MX records, SPF, DMARC, and DKIM -- to predict whether email sent from that domain is likely to land in the inbox or the spam folder. This tool performs live DNS lookups via Cloudflare DoH and Google DoH, scores each signal based on its configuration quality, and produces an overall placement prediction. A score above 80% indicates well-configured authentication that is unlikely to trigger spam filters on technical grounds.
What signals have the biggest impact on email inbox placement?
The three authentication records -- SPF, DKIM, and DMARC -- have the largest technical impact on inbox placement. SPF specifies which mail servers are authorised to send on behalf of your domain. DKIM adds a cryptographic signature to every outgoing message that receiving servers can verify. DMARC ties them together with a policy that instructs receivers what to do when messages fail authentication. Missing any of these signals, or having them misconfigured, is the leading cause of legitimate email being routed to spam folders by Gmail, Outlook, and Yahoo.
What DKIM selector should I enter for my domain?
The DKIM selector is a short identifier that is part of the DKIM DNS record hostname: selector._domainkey.yourdomain.com. Common selectors include 'default', 'google' (Google Workspace), 'mail', 'k1' (Klaviyo), 's1' and 's2' (SendGrid), 'mandrill' (Mailchimp/Mandrill), and 'amazonses' (Amazon SES). Check your email service provider's documentation for the correct selector. If you have access to your email headers, look for the DKIM-Signature header and find the s= tag -- that value is your selector.
What is the difference between SPF ~all and -all?
SPF records end with an 'all' mechanism that defines what to do with email from senders not listed in the SPF record. '-all' means hard fail -- reject all unauthorised senders. '~all' means soft fail -- mark unauthorised senders as suspicious but still deliver. '-all' is stricter and signals stronger enforcement to receiving servers. '~all' is recommended for most senders as it avoids accidentally blocking legitimate email from forwarded messages. '+all' and '?all' are very permissive and provide essentially no protection and should be avoided.
What does DMARC p=none vs p=quarantine vs p=reject mean?
DMARC's p= tag defines the policy applied to messages that fail both SPF and DKIM alignment. p=none means monitor only -- failed messages are delivered normally and you receive reports about failures. This is used when first deploying DMARC. p=quarantine means failed messages should be sent to the spam/junk folder. p=reject means failed messages should be rejected entirely and never delivered. For maximum inbox placement credibility, p=reject signals to receiving mail servers that you have full control over your domain's sending infrastructure.
Why does my email still go to spam even when I pass all authentication checks?
Authentication is necessary but not sufficient for inbox placement. Even with perfect SPF, DKIM, and DMARC configuration, email can still land in spam due to sending IP reputation (new IP addresses or IPs with complaint history), domain reputation (new domains need a warm-up period of gradually increasing volume), content signals (spam trigger words, all-caps subject lines, excessive punctuation, image-heavy with minimal text), engagement history (low open rates signal to Gmail and others that recipients don't want your mail), and recipient-specific filters (individual users blocking your domain).
How do I fix a failing SPF record to improve inbox placement?
An SPF record is a TXT DNS record at your domain root. A basic SPF record looks like: v=spf1 include:_spf.google.com ~all. Replace the include: value with the SPF include provided by your email service (SendGrid, Mailchimp, etc.). If you send from multiple providers, chain them: v=spf1 include:sendgrid.net include:_spf.google.com ~all. Keep the total number of DNS lookups (include:, a:, mx:) below 10 -- exceeding this limit causes SPF to permerror which is treated as a failure. End with ~all or -all, never +all.
Can this tool test actual email delivery to Gmail or Outlook?
No -- this tool tests DNS-level signals only, which is how most inbox placement tools at the DNS layer work. Actual inbox delivery testing requires sending a real email from your infrastructure to a seed email address at Gmail, Outlook, Yahoo, etc., and then checking which folder it landed in. Tools like Mail-Tester, GlockApps, and Litmus Spam Testing provide this seed-list based approach. This tool is complementary -- it checks all the technical authentication configuration that accounts for the majority of placement decisions, and is faster and requires no email sending.
What is email warm-up and why does it affect inbox placement?
Email warm-up is the practice of gradually increasing sending volume from a new domain or IP address over several weeks. Mail providers like Gmail track sending patterns and treat sudden high-volume sending from a new sender as suspicious -- a common pattern for spammers. Starting with small volumes (50-100 emails/day), consistently sending to engaged recipients who open and click, and slowly increasing volume over 4-8 weeks builds a positive reputation history with mail providers. Using a new domain for cold email outreach without warming it up is one of the most common causes of immediate spam placement.
How often should I run an inbox placement test for my domain?
Run an inbox placement test whenever you set up a new sending domain, add a new email service provider (which requires new SPF includes and DKIM keys), notice a sudden drop in open rates (which can indicate spam placement), change your DNS configuration, or after any domain migration. For active email senders, running a monthly check is a good practice to catch DNS configuration drift -- SPF records sometimes lose includes when DNS is updated, and DKIM keys can expire or be deleted. DMARC aggregate reports (rua=) provide ongoing monitoring between manual checks.
Related Email Deliverability Tools
Need a disposable email address?Generate a free, instant throwaway -- zero signup, zero trace.
Get Free Temp Mail ->