Check your email setup with free tools, and read the results

The short version

• Use a record checker: our email deliverability checker, Google’s Check MX, or a lookup site such as MXToolbox.
• MX should lead to the service you actually use for email, directly or through a filtering service.
• SPF should be one record, listing every service that sends as you.
• DKIM needs your provider’s selector name to be found; “not found” can be a false alarm.
• DMARC should exist. Then send a real message to Gmail and read the headers.

Which free tools check email records?

The record checkers can’t change anything. They read public DNS records, so they’re safe to run on any domain. A header analyzer is different: pasted headers can show names, email addresses, internal server names and message IDs. Only paste headers from messages you’re allowed to share, and remove personal details first. If you need the background on what the three records are, read what SPF, DKIM and DMARC do first.

How do I run the check and read the results?

1. Look up your domain

Enter the part after the @ in your email address, such as example.com, not a full email address or a web address.

2. Read the MX result

MX records say which servers receive your mail. Usually the names match the provider you pay for email. Microsoft 365 hostnames usually end in mail.protection.outlook.com, and Google Workspace ones in google.com. Some businesses route mail through a spam-filtering or security service first, so the MX names that service instead, and that’s correct. If they point to an old host or a provider you’ve left, incoming mail may be going there. Don’t change MX just because the name doesn’t match a brand; check with whoever manages your email first.

3. Read the SPF result

• “No SPF record”: receivers can’t tell who may send for you. This needs fixing.
• “Multiple SPF records”: there should be exactly one record that starts v=spf1. Two records break SPF entirely, per the SPF standard, RFC 7208.
• “Too many DNS lookups”: RFC 7208 allows at most ten DNS lookups. Our guide to the SPF lookup limit explains how to fix it.
• Ends in ~all or -all: both are normal. ?all or +all means the record doesn’t protect anything.

4. Read the DKIM result

DKIM records live under a “selector” name that your provider chooses. A checker that guesses common selectors may say “not found” even when DKIM works. Look up the selector in your provider’s admin settings, or in the DKIM-Signature line of a message’s headers (it follows s=), and check again with it.

5. Read the DMARC result

You want a record at _dmarc.yourdomain. p=none means monitoring only. p=quarantine asks receivers to treat failures as suspicious, usually by sending them to junk, and p=reject asks them to refuse failures. These are requests: the current DMARC standard, RFC 9989, says each receiver applies its own local policy and isn’t required to follow them. The rua= address is where reports go; make sure someone reads them. See how to read DMARC reports.

6. Check for blocklists

Lookup sites can test your mail server’s address against public blocklists. On shared email hosting, a listing is usually the provider’s to fix, not yours. See checking blocklists and your sending reputation.

7. Test real mail

Records can look right while mail still fails. Send a message from your business address to a Gmail account. In Gmail on a computer, open it, select More next to Reply, then Show original, as Gmail’s header guide describes. Look for the Authentication-Results line, a standard header described in RFC 8601. You want spf=pass, dkim=pass and dmarc=pass.

Do the same for your website’s form emails and any newsletter tool. They often send through a different service than your inbox.

Why does checking matter?

Inbox providers read these records to decide whether your mail is genuine. A missing or broken record means quotes, invoices and form notifications can land in junk without anyone knowing. A two-minute check tells you whether the records exist before you spend time on anything else. Our answer on why business emails go to spam covers the other causes.

What are the common mistakes?

• Adding a second SPF record for a new service instead of merging it into the first.
• Trusting a DKIM “not found” without checking the right selector.
• Testing only your inbox, not the website form and the newsletter tool.
• Copying a DMARC record with p=reject before every sender passes. Start with p=none.
• Changing DNS without a copy of the old records. Save them first, so you can put them back.

What if this didn’t work?

• The records look right but mail still lands in junk: read the full headers with Messageheader, after removing personal details. One sender may be failing, or the content may look like bulk mail.
• You can’t find where DNS is managed: see who owns your domain and who to call.
• A checker and your provider disagree: DNS changes can take time to appear everywhere. Wait, then check again before changing more.
• You’re not sure what’s safe to change: stop. A wrong MX or SPF edit can stop mail. Ask whoever manages your email.

How much does it cost, and how long does it take?

The lookups are free and take a minute each. Fixing records takes longer, depending on how many services send as you and who controls your DNS.

How does E-3 handle this?

DNS and email are one of the most common things clients ask us about: about 139 requests in our records from January to October 2026, many tied to email moves. E-3 saves the existing DNS records before changing them, so they can be put back. It’s part of our business email work and website care.

Related questions

• Back to the free website tools guide
• How do I read an SSL Labs report?
• Which free tool should I use when something looks wrong?
• How do I set up a free uptime monitor?
• Why are my form emails going to spam or missing?
• Why are good emails landing in my junk folder?
• Business email that lands: the complete guide

Sources

1. Google Admin Toolbox (Google)
2. Check MX (Google Admin Toolbox)
3. SuperTool (MxToolbox)
4. Trace an email with its full headers (Gmail Help)
5. RFC 7208: Sender Policy Framework (SPF) (IETF)
6. RFC 8601: Message Header Field for Indicating Message Authentication Status (IETF)
7. RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC) (IETF)