What records does MailerLite need to authenticate my domain?

Three, for the domain of your sender address: a verification TXT, an SPF TXT, and one DKIM CNAME — litesrv._domainkey pointing to litesrv._domainkey.mlsend.com. Authentication is mandatory for sending from a custom domain (only a 14-day trial is exempt). MailerLite's own DMARC article states the design: 'the domain used to create the DKIM signature should match the Header/From domain' — so aligned DKIM is the documented DMARC leg. SPF is required and must match the dashboard value exactly, but MailerLite never documents its envelope/return-path domain, so whether SPF also aligns is an open question its help centre does not answer; a separate optional feature called Domain alignment adds a branded subdomain with its own A, MX and TXT records for header/tracking identity — its FAQ explicitly says that subdomain is not your From domain.

Should I delete my existing SPF record when setting up MailerLite?

No — despite what several MailerLite per-host help articles literally say ('delete your existing SPF record; the record provided by MailerLite will cover all of your services'). That instruction is contradicted inside MailerLite's own help centre by its GoDaddy article, a dedicated SPF-merge article, and an automatic merge feature described in troubleshooting — all of which say MERGE. Deleting your SPF would remove authorisation for your mailbox provider and every other sender, breaking mail far beyond MailerLite (and a second SPF record is equally wrong: it causes a PermError). The safe rule, as everywhere in this series: exactly one SPF record, with MailerLite's include merged into it — here, include:_spf.mlsend.com inside the full record your dashboard shows.

MailerLite · Domain authentication

MailerLite authentication: three records, one dangerous instruction to ignore

First published 20 October 2026 · Records and dashboard behaviour from MailerLite's help centre read across ten per-host articles plus its DMARC and merge guides. Where MailerLite's articles disagree with each other, this guide says so and follows the safe side (§Contradictions).

Do not fix the wrong thing first — and do not delete your SPF. Several MailerLite help articles instruct: delete your existing SPF record; MailerLite's will cover all your services. It won't — it authorises MailerLite. Your Workspace/M365 mail, your invoicing tool, your helpdesk all live in the record you'd be deleting. MailerLite's own merge article and troubleshooting contradict those pages. Merge, always (the universal rule, Article #18): one SPF record containing everyone's includes.

The architecture (as MailerLite documents it)

Leg	Documented status
DKIM — the DMARC leg	One CNAME delegates signing to MailerLite; its DMARC article states the design in its own words: “the domain used to create the DKIM signature should match the Header/From domain.” Aligned DKIM carries your DMARC — the Brevo/HubSpot pattern (Articles #34/#35), done with a single selector
SPF — required, alignment undocumented	The KB mandates the record and an exact dashboard match, but never states the envelope/Return-Path domain or claims SPF alignment. Third-party critiques assert a MailerLite-controlled return path (which would make SPF alignment fail); MailerLite neither confirms nor denies in its docs. This guide prints the gap as a gap: authenticate SPF because it's required, rely on DKIM for DMARC, and let your aggregate reports (Article #36) show you the truth on your own domain
DMARC — not MailerLite's flow	Owner-published at `_dmarc` (KB example: `v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com`). MailerLite recommends DMARC once you send ~5,000+ — and, remarkably, recommends hiring a DMARC consultant for it. This site is the cheaper consultant: Article #4 + #36

The record set

Record	Name	Value
TXT (verify)	`@`	Dashboard-issued token
TXT (SPF)	`@`	The dashboard's record merged into yours — merge-article form: `v=spf1 a mx include:_spf.mlsend.com ~all` (the `a`/`mx` terms only if they describe YOUR setup; the include is the essential term)
CNAME (DKIM)	`litesrv._domainkey`	`litesrv._domainkey.mlsend.com` — identical across all ten per-host articles we read. Registrar rejects the trailing dot? Remove it (KB). At Cloudflare: DNS only (KB)

The ladder

MailerLite → Domains → add/verify your sender domain (the root domain of the address you'll send FROM — authenticating a different domain than your From is Trap #1 below). Authentication is mandatory for custom-domain sending; only the 14-day trial sends exempt.
Publish the verification TXT; verify.
SPF: merge include:_spf.mlsend.com into your existing single record so the result matches the dashboard's expected value. (MailerLite's troubleshooting even describes an automatic merge assist — use it, then read the result back yourself.)
DKIM: publish the CNAME.
Check status in the dashboard until all three show authenticated. Propagation bounds in MailerLite's articles wander (24/48/72 hours across pages) — judge by public readback + dashboard state, not by any article's clock.
DMARC: publish yours at _dmarc (KB example above) and climb per Article #4.

Optional extras, correctly labelled

Domain alignment (a separate feature, post-authentication): pick a prefix (e.g. newsletter) and MailerLite adds A + MX + TXT records giving that subdomain the header/tracking/image-link identity. Its own FAQ is explicit: the aligned subdomain is not your From domain — don't try to send “from” it.
Dedicated IP: officially documented gates — at least one authenticated domain + ≥50,000 emails/week, arranged via a Customer Success Manager, team-warmed. (The $50/month figure circulating on blogs is third-party only; MailerLite's KB states no price.)
Free-domain senders get From rewritten to @send.mailerlite.eu — irrelevant once you authenticate, and unavailable above 50k subscribers anyway.

Contradictions inside MailerLite's own help (why this guide exists)

Clash	Resolution used here
Delete vs merge SPF (several host articles vs GoDaddy article + merge article + auto-merge)	MERGE — the only survivable reading (§banner)
SPF ending: `~all` (merge article) vs `?all` (troubleshooting)	Your dashboard's expected value governs; the article-level variants are why step 3 says “match the dashboard”
Propagation: 24 h vs 48 h vs 72 h across articles	No clock printed as fact; readback decides
Old platform (Classic) vs new platform docs	The public KB documents the new platform only; Classic users are routed to a login-gated legacy help centre whose records we could not verify — third-party Classic guides quote the same `litesrv` records (consistent, not proof). Classic users: trust your in-product dashboard above any article, including this one

Verify

Dashboard: all three records “authenticated.”
Headers: a campaign shows dkim=pass with d= your domain and dmarc=pass. Check the SPF line too — your own domain's answer to the §Architecture open question lives there (the envelope domain in Return-Path).
Reports: MailerLite appears in your DMARC aggregates as an aligned DKIM source (Article #36).

Traps

Trap	Reality
Authenticating domain A, sending from domain B	Authentication follows the sender address's domain you registered. A second brand/domain needs its own authentication pass
Adding MailerLite's SPF as a SECOND record “to be safe”	Two SPF records = PermError for everything (Article #18). Merge or don't touch
Treating the aligned subdomain as a sending identity	It's branding for links/tracking (KB FAQ). From stays the authenticated root
Skipping DMARC because “MailerLite handles deliverability”	MailerLite handles its records; your root policy (Article #40's inheritance covers MailerLite's mail too) is yours

FAQ

We're on MailerLite Classic. Do these records apply?

Probably — third-party Classic-era guidance quotes the same litesrv CNAME — but “probably” is the honest word: MailerLite gates the Classic documentation behind login. Your Classic dashboard's shown values are the authority; if they match this guide's, proceed.

Does MailerLite require account approval before sending?

We found no KB article establishing an approval gate for authenticated sending — only the trial rule (14 days exempt from the authentication mandate). Claims beyond that are community lore, labelled as such if you meet them.

Sources

MailerLite Help Centre — domain authentication guides (ten per-host variants) · SPF merge article · troubleshooting (auto-merge; ?all variant) · DMARC article (DKIM-alignment sentence; example record; consultant recommendation) · subdomains/domain-alignment articles · dedicated-IP documentation. Third-party return-path critiques were read and deliberately NOT adopted (quarantined in research).

Verification note: records and flows were confirmed from MailerLite's help centre on 20 October 2026; live-DNS observation of its SPF chain was not possible from the research sandbox and no claim rests on it. The return-path question is printed as open because MailerLite leaves it open.

Did this guide work for you?

Your reaction tells us whether this guide solved the problem it promised to solve.