Email Deliverability Checker

An email deliverability checker gives you a single view of the DNS records that decide whether your messages are trusted by Gmail, Outlook and other mailbox providers. Our tool checks your MX records, SPF, DKIM on common selectors, your DMARC policy, MTA-STS, TLS reporting and BIMI in one run. Each record gets a clear status, the domain gets a score, and anything missing or weak comes with a record you can copy straight into your DNS panel.

How to use the Email checker

1. 1 Enter your sending domainType the domain in your From address, such as example.co.uk. You can paste an email address or website URL and we will extract the domain.
2. 2 Run the full email checkSign in with your free account and run the check. We read the domain's live public DNS; nothing is sent and nothing is changed.
3. 3 Work through the results in orderStart with any fails, then warnings. Each line shows what we found and, where relevant, a copy-paste record to publish.
4. 4 Publish fixes and re-runAdd the records at your DNS host, allow time for propagation and for our ten-minute cache to clear, then run the check again to confirm your score has improved.

What an email deliverability test covers

Deliverability is whether your email reaches the inbox rather than the spam folder or nowhere at all. It depends on three things: authentication, reputation and content. Reputation and content take time to change, but authentication is set entirely by records in your DNS, and it is the first thing a receiving server checks. Missing or broken records are one of the most common reasons legitimate mail from small businesses is filtered.

Our email deliverability checker focuses on that authentication and transport layer. It does not send a test message, read your mailbox or check blocklists. It reads the same public records every receiving server reads, so it gives an honest picture of how your domain looks from the outside.

Each record our email checker tests

The checks run in a fixed order and each covers a different part of the mail journey.

• MX records: the servers that receive mail for your domain, listed with their priorities. Without them, the domain cannot receive replies or bounces.
• SPF: the TXT record starting v=spf1 that lists which servers may send for you, graded on whether it ends with -all.
• DKIM: we look for a public key on common selectors such as default, google, selector1, selector2, k1, s1, s2, dkim and mail.
• DMARC: the policy at _dmarc on your domain, graded on whether it is monitor-only or enforced.
• MTA-STS: the TXT record at _mta-sts that announces a policy requiring encrypted TLS connections for mail sent to you.
• TLS-RPT: the record at _smtp._tls that asks other servers to report TLS delivery problems to you. Shown for information only.
• BIMI: the record at default._bimi that lets supporting inboxes show your logo. Optional, and shown for information only.

How to read your deliverability score

Every scored check is marked pass, warning or fail. A pass counts fully, a warning counts half and a fail counts nothing. MX, SPF and DMARC carry the most weight, DKIM a little less and MTA-STS the least. TLS-RPT and BIMI are informational and never affect the score.

A fail on MX means no mail servers are published. A fail on SPF or DMARC means the record is missing entirely, and we give you a starter record. A warning on SPF means the record does not use -all, and we show your own record with the qualifier changed. A warning on DMARC means the policy is p=none, and we show your record moved to p=quarantine. A warning on DKIM means no key was found on the common selectors; your provider may use a custom one, which you can confirm with our dedicated DKIM checker. A warning on MTA-STS means the TXT record is missing, and we provide the record along with a reminder that you also need to host the policy file.

Fixing email deliverability problems step by step

Work in this order, because each step depends on the one before it.

• Confirm MX records point at your real mailbox provider. Google Workspace uses smtp.google.com on new setups, and Microsoft 365 uses a host ending in mail.protection.outlook.com.
• Build one SPF record that includes every service that sends as you, such as include:_spf.google.com or include:spf.protection.outlook.com, ending in ~all while you test.
• Turn on DKIM in each platform: Gmail authentication in the Google Admin console, DKIM in the Microsoft Defender portal, Email Deliverability in cPanel, and domain authentication in your newsletter tool.
• Publish DMARC at p=none with an rua address, read the reports for a few weeks, then move to p=quarantine and p=reject.
• Tighten SPF to -all once DMARC reports show every legitimate source passing.
• Add MTA-STS and TLS-RPT if you want to enforce encrypted inbound delivery, and consider BIMI once DMARC is enforced.

MTA-STS, TLS-RPT and BIMI explained

MTA-STS (RFC 8461) lets you tell other mail servers that they must use a valid, encrypted TLS connection when delivering to you, which protects against downgrade and interception attacks. It has two parts: a TXT record at _mta-sts with a version and an id, and a policy file served over HTTPS at mta-sts.yourdomain/.well-known/mta-sts.txt listing your MX hosts and the mode, which can be testing or enforce. Our checker confirms the TXT record; you also need to host the file, and change the id whenever the policy changes so senders fetch the new version.

TLS-RPT (RFC 8460) asks sending servers to email you daily reports when they have trouble delivering over TLS, which is especially useful while MTA-STS is in testing mode. BIMI lets supporting mailbox providers show your brand logo next to your messages. It requires an enforced DMARC policy, and Gmail also requires a verified mark certificate, so treat it as a final polish rather than a priority.

When to run an email deliverability check

DNS records are easy to break without noticing, because nothing visibly stops working until messages start landing in junk. A quick email deliverability check at the right moments catches most problems early.

• After moving to a new email provider or web host, as DNS zones are often recreated and records get lost.
• After moving DNS to Cloudflare or another provider, to confirm every TXT and MX record came across.
• When you start using a new newsletter, CRM, helpdesk or invoicing tool that sends email as your domain.
• Before a large campaign or seasonal promotion, when volume and scrutiny both rise.
• When customers say your emails are missing or in spam, as a first check before looking at content or lists.
• When taking on a new client domain as an agency, to set a baseline before you change anything.

Bulk sender rules and UK email deliverability

Since February 2024, Gmail and Yahoo have required all senders to use SPF or DKIM, send over TLS and have valid forward and reverse DNS on sending servers. Senders of around 5,000 or more messages a day to their users must also have SPF, DKIM and DMARC, align the From domain with SPF or DKIM, offer one-click unsubscribe on marketing mail and keep reported spam rates below 0.3 per cent. Microsoft applied similar authentication requirements to high-volume senders to Outlook.com and Hotmail in 2025.

For UK businesses, these rules sit alongside PECR and UK GDPR, which govern consent for marketing email. Authentication does not replace consent, but without it even mail people have asked for can be filtered. Running an email deliverability check before a big campaign, after changing provider or when adding a new sending tool catches most problems before customers notice.

Examples you can copy

v=spf1 include:spf.protection.outlook.com include:amazonses.com -all

v=DMARC1; p=none; rua=mailto:dmarc@example.co.uk

v=STSv1; id=20261016090000

version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
max_age: 604800

Common mistakes to avoid

Frequently asked questions