SPF, DKIM & DMARC for MailerLite.
MailerLite authenticates your domain from Account settings → Domains, and it's a CNAME/DKIM-based setup rather than a paste-in SPF line. The record that does the real work is a single DKIM CNAME — litesrv._domainkey.yourdomain.com pointing at litesrv._domainkey.mlsend.com — which lets MailerLite cryptographically sign mail as your domain, backed by a one-time domain-verification TXT that proves you own the sending address. Because MailerLite sends over its own mlsend.com bounce domain and never lets you change the Return-Path, DKIM alignment (not SPF) is what carries your DMARC pass. MailerLite's Automatic Domain Authentication can even sign in to your DNS host and write the records for you; if it can't (for example when you log into that host with a social login, or you'd simply rather do it by hand), you copy three records from the Domains page and click Check DNS records to verify.
Why authenticate MailerLite?
Authenticating your domain in MailerLite decides whether your campaigns reach the inbox at all. Since February 2024, Gmail and Yahoo have required every bulk sender (roughly 5,000+ messages a day) to pass DKIM and DMARC with alignment, and Microsoft began junking then rejecting non-compliant bulk mail across Outlook/Hotmail in 2025. Until you authenticate, MailerLite signs and bounces your mail on its own mlsend.com infrastructure: Gmail shows a "via mlsend.com" note, your From address isn't cryptographically yours, DMARC can't pass, and your reputation is pooled with every other unauthenticated MailerLite sender on that shared domain. MailerLite also now blocks sending from free-mail From addresses (you@gmail.com, you@yahoo.com) outright under those same rules, so you must send from a domain you own and authenticate. Completing domain authentication makes MailerLite sign as your domain (DKIM aligned), removes the "via" tag, lets DMARC pass, and builds sending reputation under your own name instead of the shared pool.
The SPF reality for MailerLite
MailerLite is a CNAME/DKIM-authentication provider, not a root-SPF-include provider — and there is an important nuance most guides get wrong. MailerLite does hand you an SPF TXT record to publish (v=spf1 include:_spf.mlsend.com ~all, merged into your single root SPF), but that record does NOT create DMARC SPF alignment for your domain. MailerLite does not allow a custom Return-Path: the envelope-from (bounce address) on every message stays on mlsend.com. SPF is always evaluated against that envelope domain, so it authenticates against MailerLite's own mlsend.com SPF record — which passes on MailerLite's side — and never lines up with the yourdomain.com in your visible From address. That means your DMARC pass rides entirely on DKIM alignment from the litesrv._domainkey CNAME, and SPF is effectively along for the ride. So publish MailerLite's SPF value if you want a clean, all-green Domains page (MailerLite does check for it), but treat the DKIM CNAME as the load-bearing record — if DKIM isn't verified, DMARC fails no matter what your SPF says. One more trap: there are two MailerLite platforms. The current "new MailerLite" uses include:_spf.mlsend.com and the litesrv._domainkey selector; the legacy "MailerLite Classic" used include:_spf.mailerlite.com and the mailerlite._domainkey selector. Always copy the exact values from your own account's Domains page rather than a blog, and keep exactly one v=spf1 TXT record on your root.
Two ways to set it up
Automatic Domain Authentication (recommended)
- MailerLite scans your domain, detects your DNS host, and (after you sign in to that host) writes the DKIM CNAME, SPF, and verification records for you
- Fewest typos — no host-field doubling or wrong record-type mistakes
- Usually verifies within minutes to a few hours
- Won't work if you log into your DNS/hosting provider with a social login like Gmail — MailerLite can't sign in on your behalf, so use Manual instead
Manual DNS records
- Copy the three records straight from the Domains page into your registrar or DNS host yourself
- Required when your DNS host uses a social (e.g. Gmail) login, or when MailerLite can't auto-detect your host
- You control exactly where each record lands (root vs sending subdomain)
- On Cloudflare you must set the DKIM CNAME to DNS only (grey cloud) by hand
Step by step
- 1
Open the Domains page
Log in and go to Account settings (bottom-left profile menu) → Domains. Click Add domain — or, if you're setting a sender email, MailerLite prompts you to authenticate the domain of that address.
- 2
Enter your sending address
Type the email address you'll send campaigns from (e.g. news@yourdomain.com). MailerLite derives the domain to authenticate from it and creates the domain entry.
- 3
Choose Automatic or Manual authentication
MailerLite offers Automatic Domain Authentication (it detects your DNS host and, after you sign in to that host, writes the records for you) or Manual. Automatic is easiest; pick Manual if you log into your DNS host with a social login like Gmail (MailerLite can't sign in for you), your host isn't detected, or you prefer to add records yourself.
- 4
Copy the three records
On the Domains page MailerLite shows the DKIM (CNAME), SPF (TXT), and Domain verification (TXT) records with their exact Name and Value fields. These cannot be edited inside MailerLite, so they must be added to DNS as an exact match. Keep this tab open.
- 5
Add the DKIM CNAME
Create a CNAME record: Name litesrv._domainkey, Value litesrv._domainkey.mlsend.com (the same target for every MailerLite account). This is the load-bearing record — it delegates DKIM to MailerLite so it can sign as your domain. Do not add it as a TXT record.
- 6
Merge the SPF TXT record
Add or update the single root SPF TXT so it contains include:_spf.mlsend.com — e.g. v=spf1 include:_spf.mlsend.com ~all. If you already have an SPF record for other senders, merge the include into that one line; never publish a second v=spf1 record.
- 7
Add the domain-verification TXT
Publish the verification TXT record exactly as MailerLite lists it (an account-specific value on your root domain). This proves you own the sending address and unlocks sending from it.
- 8
Add your own DMARC record
MailerLite does not create DMARC for you. Add a TXT record at _dmarc with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com so you can collect reports before enforcing.
- 9
Click Check DNS records
Back in MailerLite's Domains page, click Check DNS records. Propagation is often minutes but can take up to 24–48 hours; when the records resolve, MailerLite marks the domain Authenticated.
- 10
Send a test and confirm DKIM alignment
Send yourself a campaign or test, open it in Gmail, and use Show original: you want DKIM: PASS showing d=yourdomain.com and DMARC: PASS. SPF will show mlsend.com and won't align — that's expected for MailerLite.
Records to add
MailerLite generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.
| Type | Host | Value |
|---|---|---|
| CNAME | litesrv._domainkey | litesrv._domainkey.mlsend.comDKIM — the load-bearing record; lets MailerLite sign d=yourdomain.com so DMARC passes. Same target for every account. Add as CNAME, not TXT. |
| TXT | @ | mailerlite-verification=abc123def456… (account-specific)Domain-ownership verification, published on your root. Illustrative — copy the exact Name and Value from your Domains page. |
| TXT | @ | v=spf1 include:_spf.mlsend.com ~allSPF include MailerLite provides — merge into your one root SPF. Doesn't create DMARC alignment (Return-Path is mlsend.com). Illustrative; new-platform value. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comYour DMARC policy — MailerLite won't add it. One per domain. Illustrative. |
Keep exactly one SPF (v=spf1) TXT record on your root domain — merge every sender into it. Two SPF records is itself an error.
The 10-lookup budget
SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what MailerLite's setup costs against that budget.
MailerLite adds 1 of your 10 lookups; ip4: and ip6: mechanisms are free.
DKIM
DKIM is the record that actually makes MailerLite mail pass DMARC. You publish a single CNAME — Name litesrv._domainkey.yourdomain.com, Value litesrv._domainkey.mlsend.com — which is a delegation, not a key you paste. Because it's a CNAME pointed at MailerLite, MailerLite holds the private key and signs every message with d=yourdomain.com; s=litesrv, and receivers follow your CNAME to fetch the matching public key from mlsend.com. That d= matching your From domain is what gives you DKIM alignment, and since MailerLite's envelope-from stays on mlsend.com (so SPF can't align), this DKIM alignment is the sole basis for your DMARC pass. The target is the same for every MailerLite account (it's the delegation host, not a per-account key), so don't be surprised it isn't unique to you. Add it as a CNAME (never TXT), enter just the litesrv._domainkey label so your registrar doesn't double the domain, and on Cloudflare set it to DNS only (grey cloud) or it won't resolve. If this record is anything but green, DMARC fails regardless of your SPF.
DMARC
DMARC is a separate policy record on your root domain that MailerLite does not create for you — you add it yourself. Publish a TXT record at _dmarc.yourdomain.com starting with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none is monitor-only, so it won't affect delivery while you confirm MailerLite mail is authenticating. There's a MailerLite-specific catch: because SPF can never align for MailerLite (the Return-Path is on mlsend.com), your DMARC pass depends entirely on DKIM. So before you tighten to p=quarantine or p=reject, verify in your aggregate (rua) reports that MailerLite is showing up as a DKIM-aligned, passing source — otherwise enforcement will start quarantining or rejecting your own campaigns. Keep exactly one _dmarc record for the whole domain no matter how many senders you use; don't publish a second one for MailerLite.
Check it actually worked
Don't trust the Domains page's "Authenticated" badge alone — confirm it on a real message. Send yourself a campaign or test, open it in Gmail, and choose ⋮ → Show original. You want DKIM: PASS with the signing domain showing yourdomain.com (via the litesrv selector) and DMARC: PASS. SPF will report mlsend.com and won't align to your domain — that's normal and expected for MailerLite, since DKIM is what carries the DMARC pass. The "via mlsend.com" note should be gone. Prefer a report card? Send a test to check-auth@verifier.port25.com for a full breakdown, or run your domain through Qualisend's domain health check and the SPF/DKIM/DMARC checker to confirm the CNAME resolves and DKIM is aligned. Once DMARC aggregate reports start arriving, drop one into the DMARC report analyzer — MailerLite should appear as a DKIM-aligned, passing source (with SPF unaligned, which is fine).
Common gotchas
- Coverage
Classic vs new MailerLite use different values. If a guide tells you to add mailerlite._domainkey or include:_spf.mailerlite.com, that's the legacy MailerLite Classic platform. New MailerLite uses litesrv._domainkey and include:_spf.mlsend.com. Always copy the exact records from your own account's Domains page.
- DNS setup
SPF can never align for MailerLite. Because there's no custom Return-Path, the envelope-from stays on mlsend.com, so SPF authenticates against MailerLite — not your domain. Don't rely on SPF for DMARC; if the DKIM CNAME isn't verified, DMARC fails no matter what your SPF looks like.
- DNS setup
Cloudflare proxy breaks the DKIM CNAME. Set litesrv._domainkey to DNS only (grey cloud). An orange-cloud proxied CNAME won't resolve to mlsend.com and MailerLite's Check DNS records will keep failing.
- DNS setup
Host-field doubling. Many registrars auto-append your domain, so entering litesrv._domainkey.yourdomain.com produces litesrv._domainkey.yourdomain.com.yourdomain.com. Enter just the litesrv._domainkey label if the panel adds the domain for you.
- DNS setup
Add DKIM as a CNAME, not a TXT. A common failure is pasting the litesrv._domainkey value into a TXT record. It must be a CNAME pointing at litesrv._domainkey.mlsend.com.
- Breaks auth
Keep exactly one SPF record on your root. If you already send through Google, Microsoft 365, or another tool, merge include:_spf.mlsend.com into that single v=spf1 line — two separate SPF TXT records is itself a PermError.
- Coverage
MailerLite won't create DMARC for you. Without a _dmarc record you don't meet the Gmail/Yahoo bulk-sender rules; add it yourself and start at p=none.
- Coverage
Free-mail From addresses are rejected. You can't authenticate you@gmail.com or you@yahoo.com in MailerLite — send from a domain you own and have authenticated.
- Coverage
Automatic authentication can't use a social login to your DNS host. If you sign in to your registrar or DNS provider with Google/Gmail or another social login, MailerLite's automatic flow can't log in on your behalf — switch to Manual and add the records yourself.
Build your SPF record
MailerLite doesn't need an SPF include: on your root domain — use the generator to assemble one clean record for your other senders, and keep it to a single line.
Sending sources
Search for each platform you send email through and tick it.
Search for your email platform above, or .
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listMailerLite SPF — FAQ
Related reading
Once it's published, confirm everything resolves with the domain health check, then read who's sending as you with the DMARC report analyzer. Browse all sending sources in the generator. Authentication is only half of deliverability, though — a listed sending IP or domain still lands you in spam no matter how clean your SPF is, so it's worth watching the blacklists with blacklist monitoring.
Authenticated — now keep the list clean
Passing SPF, DKIM, and DMARC gets you to the inbox; a clean list keeps you there. Verify yours — start free with 100 credits, no card required.