Email Deliverability Test: DNS Checks vs Real Inbox Tests

An email deliverability test is either a DNS audit of your SPF, DKIM, DMARC and MX records or a live send to test inboxes to see where the message lands. The DNS audit finds configuration errors in seconds. The live send shows what a real mailbox did with one message. You usually want both.

The two kinds of test

Search results for this phrase mix two quite different products, so it helps to separate them.

Test type	What you do	What it shows	What it misses
DNS audit	Enter a domain	Whether authentication records exist and are valid	Reputation, folder placement
Header check	Send to yourself, read headers	Whether this message passed SPF, DKIM, DMARC	Behaviour at other providers
Seed-inbox test	Send to several test mailboxes	Inbox vs spam vs promotions at those providers, at that moment	Your real audience, future sends
Postmaster data	Read provider dashboards	Domain reputation and spam rate trends at that provider	Anything below the provider’s volume thresholds

Start with the cheapest and work down. There is no point studying folder placement while your SPF record is throwing a permanent error.

Step 1: run a DNS test

A DNS-based tool such as BusinessMCP’s free deliverability checker grades the four records and prints the record to paste when one is missing. It queries Google Public DNS from your browser and needs no signup. Fix anything red, wait for the TTL, and re-run. If a DKIM line is red but your provider says signing is on, jump to step 2 before changing anything, because the checker only tries common selectors.

Step 2: read the headers of a real message

This is the most underused test, because it checks the exact message path you use, including your actual sending service.

1. Send a message from your normal tool to a personal Gmail address.
2. Open it, choose the three-dot menu and select “Show original”. Gmail displays SPF, DKIM and DMARC results at the top.
3. In other clients, find the raw source and search for Authentication-Results.
4. Read the three verdicts. You want spf=pass, dkim=pass and dmarc=pass.

The line follows the format defined in RFC 8601, so it looks similar across providers. Pay attention to the domain beside each result, not just the word “pass”.

Key takeaway: DMARC passes only when SPF or DKIM passes and the passing domain aligns with the visible From domain. A pass on a vendor’s domain can still end in dmarc=fail.

That alignment point causes many confusing results. If SPF shows pass for your email vendor’s bounce domain but DMARC fails, enable custom-domain DKIM signing in the vendor so the signature uses your own domain. The setup walkthrough covers the steps.

Step 3: a small seed test for placement

A seed test sends one message to a few mailboxes you control and observes where each lands.

• Create or use one mailbox each at Gmail, Outlook and Yahoo.
• Send the same message you would send to customers, including links and unsubscribe header if it is a marketing message.
• Note inbox, spam or promotions tab at each provider.
• Repeat over several days with slightly different content to see patterns.

Be modest about conclusions. Provider filters personalise: the same message can land differently for different recipients, because engagement history with your domain matters. A seed mailbox that has never interacted with you is a cold recipient, which may look worse or better than your engaged audience. Commercial seed-list services exist; we cannot vouch for their accuracy, so check any vendor’s methodology and run your own comparison before paying.

Step 4: add reputation data when volume justifies it

Google Postmaster Tools reports domain reputation and spam rate for mail sent to Gmail users, but it only shows data once enough volume reaches Gmail. Google’s own bulk-sender guidance asks senders to keep user-reported spam rate under 0.3% and aims lower; see the Gmail and Yahoo requirements for what those numbers mean in practice. Small senders may see an empty dashboard, which is normal, not a failure.

A sensible test order

1. DNS audit. Fix errors.
2. Header check on a real message. Fix alignment problems.
3. Small seed test for placement.
4. Live monitoring of bounces and complaints inside your sending platform.
5. Postmaster data if volume allows.

Reading mixed results

• DNS green, headers show dkim=none: the provider is not actually signing. Turn on DKIM in its admin console.
• Headers all pass, message in spam: this is a reputation or content issue. Read why mail goes to spam despite passing authentication.
• Passes at Gmail, fails at Outlook: providers weigh signals differently. Check bounce text from Outlook for the specific rejection reason, since it often names a policy.
• Headers show softfail on SPF: your record ends in ~all and the sending server is not listed. Add the sender or stop using it.

Pitfalls

• Testing from a different tool than production. If marketing mail goes through one service and receipts through another, test both.
• Trusting a single send. One message is an anecdote. Run several.
• Ignoring the bounce text. Rejections often say exactly what policy you tripped.
• Using a list full of old addresses for the test. Verify first; the verification article explains why.

For the broader picture, our guide to how to check email deliverability gives a monthly routine you can reuse. Always confirm provider thresholds on their official pages, since they update over time.

A worked example: reading one Authentication-Results line

Suppose you send a test through your email marketing platform and the headers contain something like this (values are illustrative):

Authentication-Results: mx.google.com;
  dkim=pass header.d=mailer-vendor.example;
  spf=pass smtp.mailfrom=bounce.mailer-vendor.example;
  dmarc=fail header.from=yourcompany.example

Every protocol says pass or fail for a domain, and that domain is the clue. Here DKIM passed, but it was signed by the vendor’s domain. SPF passed, but for the vendor’s bounce domain. Neither matches yourcompany.example, the visible From domain, so DMARC fails alignment. The fix is not in your SPF record at all. You need to add the vendor’s DKIM records (usually CNAMEs) to your own DNS so the signature carries your domain. After that the same test should show dkim=pass header.d=yourcompany.example and dmarc=pass.

This is the kind of problem a pure DNS audit cannot reveal, because your own DNS may look fine. Combining the audit with a header read exposes it. BusinessMCP’s guide to SPF, DKIM and DMARC lists “SPF passes but DMARC fails” as a common failure with the same explanation: the domain SPF checked does not match the visible From domain.

Checklist before you trust any result

• The test used the same sending service and From address as real mail.
• You read the domain next to each pass, not just the word.
• DNS changes had time to propagate, which can take up to about an hour depending on TTL.
• You repeated the placement test on more than one day.
• You kept a note of what you changed between tests, so cause and effect stay clear.

If you only have time for one thing, run the free BusinessMCP checker first and a header read second. For providers with strict bulk rules, compare your results with the official Google sender guidelines, which list the authentication, spam-rate and unsubscribe requirements in one place. BusinessMCP also publishes a plain-English summary of the same rules at its Google and Yahoo sender requirements guide, including the date it last verified them.