DMARC, SPF and DKIM for MailerLite

MailerLite is an email marketing platform. It sends newsletters and automations from its own servers, with your address in the From field. For a custom domain, it asks you to authenticate the domain with DNS records. Since the Google and Yahoo sender rules, MailerLite says authentication "is required" if you send from a custom domain. This guide follows MailerLite's help centre. For the background on each standard, see SPF explained, DKIM explained and DMARC explained.

What MailerLite sends from

As of November 2026 you add a sending domain under Account settings, tab Domains, then + Add sending domain, and enter the address you want to send from. The visible From is that address on your own domain, for example [email protected].

As of November 2026 the manual setup shows three records:

• a DKIM CNAME record,
• an SPF TXT record,
• a domain verification TXT record.

MailerLite also offers automatic setup for partner DNS hosts.

The help pages do not name the envelope sender (Return-Path) domain that MailerLite uses by default. They do describe a separate, optional feature called domain alignment. It asks for an A, an MX and a TXT record and a subdomain prefix you choose, such as newsletter. MailerLite says that subdomain "is used for headers and tracked links". It does not say in plain words that it becomes the Return-Path. Check the headers of a test message to see which domain appears there.

The DKIM record is a CNAME under _domainkey.example.com. A signature that verifies through that name carries d=example.com.

If you send from a free address such as Gmail, MailerLite rewrites it, as of November 2026, to an address under send.mailerlite.eu. That case is outside this guide.

SPF

MailerLite asks for one TXT record on the domain itself. At most DNS hosts the host name is @ or empty; for a subdomain, use the subdomain. Copy the value from your Domains page. As of November 2026 the help pages show this MailerLite value in their examples:

example.com TXT "v=spf1 a mx include:_spf.mlsend.com ~all"

The troubleshooting page also shows a variant ending in ?all, which MailerLite's merge page calls "not recommended". Its pages also show -all and call the choice of qualifier "your choice". We recommend ~all. RFC 9989 warns that some receivers check SPF early in the SMTP transaction, so -all can get mail rejected before DMARC runs, even when aligned DKIM would have passed it. That mail never appears in your aggregate reports.

MailerLite is clear that you may only have one SPF record: "Having more than one SPF record will make the authentication impossible." If other services send as your domain, merge them into one record. When you click Check DNS records, MailerLite proposes a merged value for you. With another service (_spf.example.net is a placeholder), it looks like this:

example.com TXT "v=spf1 a mx include:_spf.mlsend.com include:_spf.example.net ~all"

That record uses 4 DNS lookups itself: a, mx and the two includes. The include _spf.mlsend.com then adds the lookups inside its own record. MailerLite does not document a fixed number for it. When we counted it with real DNS on 7 November 2026, _spf.mlsend.com held only IP ranges, so it cost 1 lookup in total. MailerLite can change that record, so check your own tree with the SPF lookup counter. RFC 7208 sets the limit at 10, and MailerLite's troubleshooting page says the same: "You can have up to 10 lookups". Above that, SPF fails with a permanent error (too many SPF lookups). The same page notes that one SPF string is limited to 255 characters.

The a and mx terms authorise your own web and mail servers, and each costs one lookup. Remove them only if Check DNS records still approves the record.

DKIM

MailerLite signs mail and hosts the key. You publish a CNAME that points at it. The steps, as documented in November 2026:

• Go to Account settings, Domains, and add the sending domain.
• Choose Authenticate manually.
• Click Add record under Add DKIM CNAME record, pick your DNS host or Other, and click I'm logged in.
• At your DNS host, create a CNAME with the name litesrv._domainkey and the target litesrv._domainkey.mlsend.com.
• At Cloudflare, set the proxy status to DNS only, as MailerLite's Cloudflare guide says.
• Back in MailerLite, click I added the record, then add the SPF and verification records the same way.
• Use Check DNS records in the menu next to the domain. The status changes to Authenticated when the records match.

litesrv._domainkey.example.com CNAME litesrv._domainkey.mlsend.com.

The selector is litesrv. Most DNS hosts add your domain to the name for you, so enter only litesrv._domainkey. Some hosts also append your domain to the target. Only at those hosts, MailerLite's fix is a trailing dot: litesrv._domainkey.mlsend.com..

As of November 2026 MailerLite says records can take up to 24 hours to propagate, and in some cases up to 72 hours.

DMARC alignment

DMARC passes when SPF or DKIM passes and the authenticated domain aligns with the From domain.

• DKIM alignment compares the d= domain with the From domain. With the litesrv CNAME documented as of November 2026 in place, the key sits under example.com. A valid signature through it carries d=example.com and aligns.
• SPF alignment compares the RFC5321.MailFrom (Return-Path) domain with the From domain. MailerLite does not document which domain it uses there. If the Return-Path is a MailerLite domain, SPF can pass for that domain, but it does not align with example.com. SPF is evaluated at the exact MailFrom domain, so your SPF record at example.com only counts if the envelope sender is exactly example.com.

MailerLite describes the two modes in its DMARC article. Strict means "the domains must be an exact match". Relaxed means the domains can be "different subdomains of the same root domain", the organisational domain. Relaxed is the default for both adkim and aspf.

MailerLite does not document this. If you turn on domain alignment and a test message shows newsletter.example.com in the Return-Path with SPF passing for it, SPF also aligns in relaxed mode (not strict).

Step by step to p=reject

1. Add the domain and publish SPF. In MailerLite, add the sending domain under Account settings, Domains, and publish the verification TXT record from that page. Then add the SPF TXT record on example.com, merged into one record with every other service that sends as your domain, and keep it at 10 DNS lookups or fewer.
2. Publish the DKIM CNAME. As of November 2026, create litesrv._domainkey.example.com as a CNAME to litesrv._domainkey.mlsend.com, and wait until MailerLite shows the domain as Authenticated.
3. Start DMARC at p=none with reports. Publish a TXT record at _dmarc.example.com with v=DMARC1; p=none; rua=mailto:[email protected]. This policy does not protect the domain yet; it turns on aggregate reports.
4. Read the reports and fix other senders. For two to four weeks, check which servers send as your domain and whether MailerLite mail passes DKIM with d=example.com. Give every other legitimate service SPF and DKIM for your domain.
5. Move to quarantine. Change the policy to p=quarantine once the reports show only aligned mail from your own services. Failing mail then usually goes to spam, so a sender you missed is still recoverable.
6. Reject. Change the policy to p=reject when the reports stay clean. Receivers then refuse mail that fails DMARC.

The record for step 3:

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

The final record:

_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

MailerLite's own example uses p=none with a rua address and advises caution with quarantine and reject on existing domains.

Common mistakes

• Two SPF records. MailerLite's Cloudflare guide says there should be only one SPF record, and to delete any other record that starts with v=spf1. Merge instead, because deleting it without merging breaks SPF for your other services (multiple SPF records).
• Expecting SPF alone to pass DMARC. MailerLite does not document a Return-Path on your domain by default. Without the DKIM CNAME, MailerLite mail may have no aligned result at all (DKIM not found).
• The domain typed twice. Many DNS hosts append the domain to the name. Entering litesrv._domainkey.example.com (the name as of November 2026) there creates a name that ends in example.com.example.com. MailerLite's troubleshooting page warns about the same issue for the target.
• Proxied CNAME at Cloudflare. MailerLite's Cloudflare guide asks for DNS only, not proxied.
• Reusing the alignment subdomain. As of November 2026 MailerLite says the alignment subdomain must be used for that purpose only, not for a landing page, and not as the From address. Underscores in it are not supported. If you turn alignment off later, links in campaigns already sent stop working.
• Staying at p=none. A p=none policy only reports. It does not stop spoofing (DMARC policy none).
• Relying on a test flag. Some receivers support t=y (RFC 9989, DMARCbis) or pct (RFC 7489). Neither is a safety net. RFC 7489 says unknown tags must be ignored, so a receiver that implements only RFC 7489 can treat p=reject; t=y as a full reject. Move through the policies in order and let the reports decide each step.

How to check it

Run the email security check on your domain. It reads SPF, DKIM and DMARC in one pass. Use the SPF lookup counter to count every lookup behind include:_spf.mlsend.com and your other includes. In the DKIM selector finder, look for the selector documented as of November 2026, litesrv; it should resolve through the CNAME to a key. Build or check your policy with the DMARC record generator.

Sources

• Domain authentication, MailerLite documentation, fetched 2026-11-06.
• Cloudflare step-by-step domain authentication, MailerLite documentation, fetched 2026-11-06.
• Amazon Route 53 step-by-step domain authentication, MailerLite documentation, fetched 2026-11-06.
• Troubleshooting domain authentication errors, MailerLite documentation, fetched 2026-11-06.
• How to merge SPF records, MailerLite documentation, fetched 2026-11-06.
• Domain alignment, MailerLite documentation, fetched 2026-11-06.
• The basics of DMARC, MailerLite documentation, fetched 2026-11-06.
• MailerLite subdomains: What you need to know, MailerLite documentation, fetched 2026-11-06.
• RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1, RFC Editor, fetched 2026-11-06.
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), RFC Editor, fetched 2026-11-06.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC), RFC Editor, fetched 2026-11-06.