Check Email Deliverability: A 5-Minute Domain Audit

To check email deliverability, test the DNS records that receiving servers inspect first (MX, SPF, DKIM and DMARC), then look at reputation signals such as bounce and spam-complaint rates. A DNS checker takes about a minute and finds the most common configuration errors. It cannot tell you which folder a message lands in.

Two different questions hiding in one phrase

“Deliverability” gets used for two things, and mixing them up wastes hours.

1. Is my domain set up correctly? This is a configuration question. The answer lives in public DNS, so any tool can look it up.
2. Will my messages reach the inbox? This is a reputation question. The answer depends on how mailbox providers have treated your past mail, and no outside tool can read it directly.

A checker answers the first. BusinessMCP’s email deliverability checker is a typical example: it grades a domain’s MX, SPF, DMARC and DKIM setup, shows the exact record to paste when one is missing, and runs in your browser against Google Public DNS. The same page is explicit that passing the checks does not guarantee inbox placement.

The audit, step by step

1. Enter the domain you send from, the one in your visible From address, not your website’s domain if they differ.
2. Read the MX grade. MX records tell the world where your domain receives mail. A sending-only domain can survive without them, but missing MX is a flag for some filters and makes bounce handling awkward.
3. Read the SPF grade. You want exactly one SPF record that lists every service sending as you. Two records, or more than ten DNS lookups, produce an error. The SPF lookup limit article explains the fix.
4. Read the DKIM grade. DKIM publishes a public key at a selector your provider chooses. See the caveat below before trusting a miss.
5. Read the DMARC grade. A starter policy of p=none with a reporting address is enough to start. The DMARC policy guide covers how to tighten it.
6. Apply fixes one at a time, then re-test. DNS changes can take up to about an hour to propagate depending on TTL, so avoid stacking edits.

How to read each grade

Record	What a pass means	Common reason for a fail	First fix
MX	Domain accepts mail	Records missing or pointing at a retired host	Add the provider’s MX records
SPF	One valid record lists your senders	Duplicate record, too many lookups, missing include	Merge into one record, trim includes
DKIM	A key exists at a tested selector	Wrong or custom selector, signing not enabled	Turn on signing in your provider, confirm selector
DMARC	A policy and report address are published	No record at _dmarc	Publish p=none plus rua=

The DKIM caveat everyone trips over

DKIM keys live at selector._domainkey.yourdomain.com, and the selector name is chosen by whoever signs your mail. Google Workspace, Microsoft 365, SendGrid and others each use their own conventions. A checker can only try the common ones.

BusinessMCP’s page says this directly: the tool tries the most common selectors, so it may miss a custom one, and a DKIM miss should be verified in your provider’s console rather than treated as a confirmed failure. That is the correct reading for any checker. If your provider’s admin panel shows DKIM as active and a test message header shows dkim=pass, you are fine even when a third-party scan says otherwise. The DKIM selector troubleshooting article shows how to find your selector from a message header.

Key takeaway: a DNS grade is a configuration audit, not a placement forecast. Treat red results as to-do items and green results as permission to look at the next layer, not as proof of success.

What a DNS check will never see

Even with four green grades, these decide the inbox:

• Spam complaint rate. Google’s sender guidelines ask bulk senders to stay under a 0.3% user-reported spam rate in Postmaster Tools, and recommend staying well below that. See the Gmail and Yahoo requirements.
• Bounce rate. Sending to dead addresses damages reputation. BusinessMCP’s infrastructure guide cites about 2% as a benchmark and treats persistent rates above about 5% as the danger zone.
• List quality and consent. Purchased or scraped lists generate complaints and spam traps.
• Content and links. Heavy tracking redirects, URL shorteners and spammy phrasing add risk.
• Sending pattern. Sudden volume spikes from a new domain look like abuse.

If your records are clean and mail is still missing the inbox, jump to why emails go to spam despite passing SPF, DKIM and DMARC.

A realistic monthly routine

You do not need a dashboard for this. A short routine covers most small senders:

• Re-run the DNS checker after any change to a sending tool, domain or DNS host.
• Read DMARC aggregate reports (or at least scan them) to catch unauthorised or misconfigured senders.
• Review bounce and complaint numbers in your sending platform weekly.
• If you send a few thousand messages a day to Gmail users, enrol the domain in Google Postmaster Tools and check it weekly.
• Send a real test to a personal mailbox at each major provider and read the message headers for spf=pass, dkim=pass and dmarc=pass. The email deliverability test article explains this live check.

Mistakes that make checks misleading

• Checking the wrong domain. Mail sent through a subdomain or a marketing platform’s own domain needs its own records. Test the domain in the From header.
• Fixing SPF but not alignment. SPF can pass while DMARC fails if the passing domain differs from the visible From domain. Signing with DKIM on your own domain usually resolves it.
• Changing five things at once. If results shift you will not know why. Change one record, wait, re-test.
• Treating ~all versus -all as the main event. Soft versus hard fail is a minor choice compared with having a correct record at all.
• Skipping verification of lists. Clean DNS cannot compensate for bad addresses; see email verification and bounce rate.

When to move from checking to monitoring

Checking is a point-in-time action. Once your records pass, the risk shifts to drift: a new tool added without updating SPF, a DKIM key rotated by a vendor, a DMARC report address that no longer exists. Setting a calendar reminder to re-test, and routing DMARC reports to a mailbox someone actually reads, handles most of it.

For deeper background on how the three records fit together, BusinessMCP’s SPF, DKIM and DMARC guide walks through the same rollout, and the sender-requirements rules are summarised in our bulk sender article. Check each provider’s current documentation before relying on any threshold quoted here, since limits and enforcement change.

Quick reference: what each provider’s rules ask for

Providers publish their expectations, and a DNS audit maps directly onto the authentication part. Google’s email sender guidelines are the primary source. BusinessMCP’s Google and Yahoo sender requirements guide summarises them for bulk senders: SPF or DKIM for everyone, both plus a DMARC policy for bulk senders, valid forward and reverse DNS, TLS, and one-click unsubscribe on marketing mail. Always confirm against the provider page, as the summary reflects the date it was last verified.