MailerLite Domain Authentication: Set Up DKIM, SPF and DMARC
Authenticate a MailerLite sending domain without breaking other email services. Copy the exact DKIM, SPF and ownership records, merge SPF where needed, and verify delivery with a controlled test.
Start with a sending-domain inventory, not a DNS change
Before signing into your DNS provider, list all services that currently send mail for your domain: MailerLite, Google Workspace or Microsoft 365, ecommerce notifications and CRM messages. The domain registrar, website host and authoritative DNS host may be three different companies. Only the authoritative DNS zone controls the records that matter here.
Save your current TXT, CNAME and MX records before making a change. Record the email address you plan to use in the From field, the DNS host's existing SPF policy and whether your provider automatically appends the domain name to a Host field. This makes a safe rollback possible if another sender stops passing authentication.
Find the records inside MailerLite before entering a single value
Go to MailerLite account settings, open Domains and then Sending domains, and add the business email address associated with the domain. MailerLite offers automatic DNS setup for some providers; manual authentication remains available when your host is unsupported or you need to review each change yourself. Legacy or Classic accounts can use a different interface.
For manual setup, copy the Name and Value shown for the specific sending domain. The normal set consists of a DKIM CNAME, an SPF TXT and a domain-verification TXT. Treat examples in help articles as illustrations, not as replacement values for your account. MailerLite checks these records after they are published in your own DNS host.
Cloudflare setup: DNS-only DKIM and a carefully checked root TXT
In Cloudflare, open the correct zone and choose DNS, then Records. When adding MailerLite's DKIM CNAME, compare the Name and Target directly with MailerLite's screen and keep Cloudflare's Proxy status set to DNS only, not Proxied. MailerLite specifically instructs Cloudflare users to switch that CNAME proxy off. A proxied verification hostname may not resolve to the value expected by the email platform.
For SPF and domain verification, create TXT records using the host expected by your zone, often @ for the root domain. Don't copy a second, full domain suffix into an interface that already appends it. Review the complete target and existing records in Cloudflare before saving. Official provider-specific instructions: https://www.mailerlite.com/help/how-to-authenticate-a-domain-with-cloudflare.
Google Workspace or Microsoft 365: merge SPF, never stack policies
Suppose the company already uses Microsoft 365 for employee email but is adding MailerLite newsletters. Your root domain might already publish an SPF TXT entry starting with v=spf1. A second SPF policy at the same name is not a harmless addition: multiple SPF records can fail evaluation and damage existing mail authentication. The same principle applies to Google Workspace and other senders.
Return to MailerLite's Check DNS records screen, which may propose a merged value. Review the resulting mechanisms against the current approved sender list, then publish a single complete SPF policy for that same DNS name. Preserve legitimate include entries and review the terminating all mechanism; don't publish an illustrative SPF example verbatim. Also check the DNS lookup limit and long TXT-string handling before rollout. Source: https://www.mailerlite.com/help/how-to-merge-spf-records.
Distinguish DKIM signatures, SPF authorisation and domain verification
DKIM lets receivers check a cryptographic signature attached to outgoing mail. MailerLite's manual workflow provides a CNAME to expose the signing key location. SPF identifies services authorised to use an envelope sender domain. The separate verification TXT helps prove that you control the sending domain. Passing one of these checks does not prove the other two are configured correctly.
For an initial check, compare record types as carefully as record values: CNAME for DKIM; TXT for SPF; TXT for MailerLite's ownership verification. If a receiving mailbox exposes full message headers, inspect the actual DKIM and SPF result after a small controlled test. MailerLite's Authenticated badge is useful, but it is not a promise that every message will land in the inbox.
Troubleshoot pending verification and a rejected DKIM record
If DKIM remains unapproved, verify the CNAME Host is correct. MailerLite notes that some DNS providers append the domain automatically to Name or Value fields; their troubleshooting guide explains how a trailing period on a fully qualified CNAME target can prevent an unintended suffix. On Cloudflare, also check that the record remains DNS only. Compare exactly what the MailerLite account requests rather than assuming a generic screenshot is current.
If SPF fails, check for a second v=spf1 record, a host set at the wrong zone level, a malformed include or too many DNS lookups. If verification TXT fails, confirm that the complete value was published. DNS propagation frequently finishes earlier, but MailerLite says updates can take 24 hours and sometimes as long as 72 hours; recheck the public records before repeatedly editing correct data. Source: https://www.mailerlite.com/help/troubleshooting-domain-authentication.
DMARC is a separate alignment decision, not a magic spam-folder fix
DMARC evaluates whether a message claiming to be From your visible domain has aligned SPF or DKIM authentication, and defines how receivers should handle failures. It is generally published as a TXT record under _dmarc for the domain. A monitoring policy such as p=none is not equivalent to a strict rejection policy; choose a policy after understanding all services that legitimately send as your organisation.
Moving straight to quarantine or reject without checking third-party platforms can cause valid emails to fail, especially when you operate multiple systems. Review aggregate reports and sender alignment before tightening enforcement. Even a properly authenticated domain still needs permission-based lists, functional unsubscribes and sensible sending practices. Official MailerLite documentation: https://www.mailerlite.com/help/the-basics-of-dmarc.
Treat MailerLite's optional domain alignment as its own DNS project
MailerLite's optional domain-alignment feature is separate from the initial CNAME and TXT authentication. It uses a dedicated subdomain for message headers and tracked links, and the manual workflow can request A, MX and TXT records. Pick a unique prefix that is not currently used by your website, landing page or any other application. Do not redirect or repurpose an active production hostname merely to follow a tutorial.
MailerLite recommends domain alignment but does not require it for basic sender authentication. Disabling alignment after sending campaigns may break previously delivered tracking links, so check historical messages before turning the feature off or changing its subdomain. Official guide: https://www.mailerlite.com/help/how-to-align-a-domain.
Run a two-provider regression test before you scale a campaign
After MailerLite reports Authenticated, send a small test message to at least two mailbox providers. Verify the displayed From address, reply-to handling, unsubscribe link, tracked links and mail-header authentication. Then send a routine test from your existing Google Workspace or Microsoft 365 mailbox to confirm the SPF update did not damage ordinary business email.
Write down the DNS record names and values changed, the services that still need to send and the time each test was completed. Avoid interpreting one successful message as evidence that high-volume inbox placement is guaranteed. This checklist is a reproducible procedure for readers, not a claim that Claim26 performed real campaigns for MailerLite accounts.
Use this short decision tree when a check still fails
DKIM CNAME missing: examine the Host, suffix handling and Cloudflare proxy setting. SPF failing: find duplicate records and verify the combined sender policy and DNS-lookup count. Ownership TXT missing: compare the Name and complete verification Value. Everything looks correct but MailerLite still says Pending: allow propagation, check public DNS responses and review the official troubleshooting instructions again.
Messages pass the DNS tests but reach spam: investigate list quality, reputation, consent, complaint rates, content and DMARC alignment instead of adding random DNS records. Distinguish an authentication failure from delivery or engagement problems; the remedy is different. For the broader decision of whether MailerLite suits your business, use the linked Claim26 review rather than confusing this setup guide with a product endorsement.
Check these four signals.
✓Identify the authoritative DNS provider before edits
✓Check Cloudflare DKIM CNAME is DNS only
✓Keep a single combined root-domain SPF policy
✓Verify the domain status within MailerLite
✓Test MailerLite and the existing mail service after changes
Need the bigger picture before choosing a plan?
Open the current offer and check MailerLite pricing, limits and features before deciding on a subscription.
Official sources for this guide
Software pricing and features can change. Review the official documentation below before choosing a product or plan.
