MailerLite emails going to spam? Check your domain in 60 seconds.
We verify MailerLite's DKIM record (ml._domainkey), your SPF include, DMARC, MX and 24+ blocklists — and catch the classic two-SPF-records mistake that silently kills authentication.
Free · no signup · unlimited checks · reads public DNS only
MailerLite authentication is two records: a DKIM CNAME at ml._domainkey pointing into mlsend.com infrastructure, and an SPF include added to your domain's existing SPF record. Simple — except that second step is where setups die: SPF only works as ONE record, and pasting MailerLite's value as a new TXT record next to your existing SPF gives you two, which the standard treats as a permanent error. Everything you send, from every tool, fails SPF from that moment.
Type your domain and we'll check the DKIM record answers at the right name, the SPF include is present in a single valid record, DMARC exists, and your domain is clean on 24+ blocklists.
How MailerLite setups actually fail
Two SPF records
The most damaging MailerLite mistake, because it breaks more than MailerLite: the include belongs INSIDE your existing v=spf1 record, not beside it. If our SPF check fails with multiple records detected, merge them into one line and authentication comes back everywhere.
The DKIM CNAME at the wrong name
MailerLite's record belongs at ml._domainkey.yourdomain.com (older accounts: mailerlite._domainkey). DNS dashboards that auto-append your domain produce ml._domainkey.yourdomain.com.yourdomain.com — present, but invisible to receivers. We probe the exact names.
Authenticated domain, missing DMARC
MailerLite requires domain authentication since the 2024 Gmail/Yahoo rules, but DMARC is still yours to publish. p=none at _dmarc.yourdomain.com satisfies the requirement today and gives you reporting.
Fix anything above in your MailerLite dashboard following the official MailerLite setup guide, then re-run the check — DNS changes usually show within minutes.
Record names and provider behavior on this page were last verified against MailerLite's official documentation on 12 July 2026.
Questions, answered plainly
Why are my MailerLite emails going to spam?
Check three things in order: that your domain is actually authenticated in MailerLite (the ml._domainkey DKIM record answers in DNS), that your SPF record is a single valid record containing MailerLite's include, and that a DMARC record exists. A blocklisted domain or broken MX comes next — this checker covers all of it in one pass.
What DNS records does MailerLite need?
Three: a DKIM CNAME at ml._domainkey pointing at MailerLite's key host, MailerLite's include merged into your existing SPF TXT record, and a domain-verification TXT. You'll find the exact values in MailerLite under Account settings → Domains — copy them exactly.
Can I have two SPF records?
No — the SPF standard requires exactly one record starting v=spf1 per domain, and receivers treat two as a permanent failure. Merge all your includes (Google Workspace, MailerLite, anything else) into a single record.
Is domain authentication required by MailerLite?
Effectively yes: since the February 2024 Gmail and Yahoo sender requirements, MailerLite pushes every account to authenticate its own domain, and unauthenticated senders see notably worse inbox placement. It takes about ten minutes.
The full guide
MailerLite emails going to spam? The two-SPF mistake that breaks everything
MailerLite setup is two records, and one wrong move while adding them silently breaks email authentication for every tool you send with. How to check, and the merge that fixes it.
Read the guide →More free checkers
A passing check is a snapshot: records that are right today drift, expire and get overwritten, and nobody gets notified. That slow rot is what we call deliverability decay, and it has its own curriculum in Decay University.