MailerLite emails going to spam? The two-SPF mistake that breaks everything

If your MailerLite campaigns are going to spam, the first thing to rule out is also the most destructive: two SPF records on your domain. It's the signature MailerLite setup mistake, because MailerLite (unlike most modern ESPs) asks you to add an SPF include, and pasting it as a new TXT record instead of merging it into your existing one leaves your domain with two records starting v=spf1. The SPF standard treats that as a permanent error. From that moment SPF fails for everything you send, from every tool, including your ordinary business email. Check your domain now; the checker flags a double SPF instantly.

The wretched part is that mail mostly keeps flowing afterwards, just with worse and worse placement, so the mistake gets found weeks later, if at all. Let me walk through the setup the way I wish every tutorial did.

MailerLite's two records, and where each one goes

MailerLite authentication is genuinely simple:

• a DKIM CNAME at ml._domainkey.yourdomain.com, pointing into MailerLite's mlsend.com infrastructure (older accounts used mailerlite._domainkey)
• an SPF include, mlsend.com, which belongs inside your existing SPF record

The DKIM record is a new record; adding it is safe and boring. The SPF include is not a new record, and this is the fork in the road.

Say your domain already has:

v=spf1 include:_spf.google.com ~all

Correct after adding MailerLite:

v=spf1 include:_spf.google.com include:mlsend.com ~all

One record, one more include inside it. What the disaster case looks like in your DNS panel is two separate TXT entries, each beginning v=spf1. If you ever see that on any domain you run, fix it today regardless of MailerLite: merge the includes into a single record and delete the extra one. Receivers don't pick one of the two; they fail you.

Why "just add this record" advice keeps causing this

Nobody writes "carelessly create a second SPF record" in their docs. The instruction is always "add this to your SPF record", and the ambiguity does the damage: in a DNS dashboard, "add" naturally reads as "create new entry". Providers' interfaces make the wrong move the easy move.

This is also why I'm wary of setup instructions that end at "click verify". Verification often checks that the include is visible somewhere, not that your SPF record as a whole still parses to one valid entry. You can pass a tool's verification and fail the internet's.

The rest of the checklist

With the SPF question settled, MailerLite problems follow the familiar shape:

1. DKIM answering at the right name. ml._domainkey must resolve from the outside world. The usual saboteur is a DNS dashboard appending your domain to the name, creating ml._domainkey.yourdomain.com.yourdomain.com. If your provider auto-appends, enter only ml._domainkey.
2. DMARC published. MailerLite pushes every account toward domain authentication because Gmail and Yahoo's bulk-sender rules demand it, but the DMARC record itself is always yours to create: TXT at _dmarc.yourdomain.com, starting value v=DMARC1; p=none; rua=mailto:you@yourdomain.com. Start at p=none; tighten once reports show your mail aligning, not before.
3. The foundation: MX records answering, domain clean on blocklists. A perfect MailerLite setup on a listed domain still folders.

The free checker runs all of it in one pass: both DKIM name generations, the include's presence inside a single valid SPF record, DMARC, MX and 24-plus blocklists, with a plain verdict per item.

After it passes

Give DNS changes up to a couple of hours to propagate before re-verifying in MailerLite. Then, honestly, put a calendar reminder on the whole topic or delegate it, because the two-SPF story has a sequel that plays out in slow motion: a year from now someone adds another tool, pastes another "just add this" record, and the domain quietly breaks again. What we see from monitoring sending domains is that authentication doesn't fail at setup; it fails at the fourth tool, the agency handover, the DNS spring-clean.

That's the standing problem Inbox Decay solves: it re-checks your records on a schedule and emails you the moment one breaks, with the exact fix attached. Watching is free. The alternative monitoring system, the one most businesses run by default, is noticing your open rate three weeks too late.