Is your domain's email authentication set up correctly?
Checks your MX, SPF, DKIM, and DMARC records for any email provider — Klaviyo, GoHighLevel, Microsoft 365, Google Workspace, Zoho, and more. Free, instant, no email needed.
Checks your MX, SPF, DKIM, and DMARC records for any email provider — Klaviyo, GoHighLevel, Microsoft 365, Google Workspace, Zoho, and more. Free, instant, no email needed.
I run into the same four broken records over and over when I diagnose why a domain is landing in spam, regardless of what it's sending through. Here is what each one actually does, so the results above mean something instead of just being pass or fail.
Your MX records tell the rest of the internet which servers handle incoming mail for your domain. They need to point at whatever your actual provider is, whether that's Google Workspace, Microsoft 365, or a dedicated mail server. This checker confirms MX records exist, not that they're correct for your specific provider, since the right values differ from provider to provider. Compare what shows up here against your provider's own documentation before assuming anything is wrong. If MX is missing entirely and this domain is supposed to receive mail, that's the problem — but a send-only domain can have no MX at all and that's fine.
SPF is a DNS record that lists which mail servers are authorized to send email using your domain. When your provider sends on your behalf, whether that's Klaviyo, GoHighLevel, or your own SMTP server, your SPF record needs to include that provider's sending infrastructure, or receiving mail servers have no way to confirm it was allowed to do that. Two mistakes show up constantly here. The first is no SPF record at all. The second is having two of them, which is actually worse, because a domain can only have one SPF record and receivers ignore both when they find a second. I see this happen when a team adds a new record without checking whether one already exists.
DKIM attaches a cryptographic signature to outgoing mail, verified against a public key published in your DNS at a specific selector, a short label like google._domainkey or kl._domainkey that comes before your domain name. Every provider names its selector differently. Because there's no single selector to ask for on a domain of unknown origin, this checker tries a list of known and common selector guesses instead. For GoHighLevel, MailerLite, and Zoho specifically, the selector is assigned per account rather than fixed, so a "not found" result for those providers isn't proof DKIM is broken — check the provider's dashboard directly before concluding it's missing.
DMARC tells receiving servers what to do when a message claims to be from your domain but fails SPF or DKIM. It has three settings. p=none only monitors and reports, it doesn't stop anything. p=quarantine sends failing mail to spam. p=reject blocks it outright. Google and Yahoo's 2024 bulk sender rules require a published DMARC record for anyone sending more than 5,000 messages a day, and I'd recommend one regardless of volume, since without it there's no real policy in place at all, just a suggestion.
Every major mailbox provider, Gmail, Outlook, Yahoo, uses these same four signals to decide whether your mail belongs in the inbox, whether you're sending through Klaviyo, GoHighLevel, Microsoft 365, Zoho, or a self-hosted server. Passing all four doesn't guarantee placement on its own, sender reputation, content, and list quality still matter, but failing any of them is one of the fastest ways into spam regardless of how good everything else is. This checker runs MX, SPF, DKIM, and DMARC in that exact order, the same order I rule out causes in a real diagnostic, because each one narrows down where the actual problem lives before moving to the next.