MailerLite SPF, DKIM and DMARC setup, step by step

Authenticate your sending domain in MailerLite using the DKIM CNAME, SPF TXT and verification TXT records generated for your account. If you also configure MailerLite's optional domain-alignment feature, publish its separate A, MX and TXT records at an unused subdomain, verify them, and turn alignment on. Neither a DNS lookup nor an Authenticated badge proves that a particular campaign passes DMARC: check a delivered message too.

On this page

• Choose the right MailerLite workflow
• Publish authentication records
• Configure optional domain alignment
• Preserve or establish DMARC
• Verify DNS and campaign headers
• Troubleshooting
• Frequently asked questions

Choose the right MailerLite workflow

This guide covers the current MailerLite marketing platform, not MailerSend's transactional API or SMTP service. MailerLite directs Legacy (Classic) customers to a separate authenticated help center; do not assume its screenshots, account controls or DNS values are interchangeable. Current documentation requires authentication for custom-domain sending, with an initial 14-day trial exception for new accounts. Treat that exception as onboarding flexibility, not a reason to postpone authentication. MailerLite domain authentication.

Before changing anything, record the account, intended campaign or automation, full From address and DNS administrator. Confirm which nameservers are authoritative. A registrar, website builder and DNS host may be three different companies. Export the current zone or save the affected records and TTLs. Include employee email, customer support and other marketing systems in the sender inventory.

Choose a From address on a domain you control. Verifying access to a mailbox and proving control of DNS are different steps. A personal address at a public mailbox service does not give you permission to publish that service's SPF or DKIM records. Keep the reply mailbox working independently of the bounce and tracking infrastructure.

Plan and account permissions can affect available assistance and controls. Use your account's generated instructions as the source of truth, rather than a screenshot from another subscription. The public documentation reviewed does not establish regional DNS variants or universal availability of every optional feature.

Publish authentication records

In Account settings → Domains, select Add sending domain, enter the sender email address and save. Choose Authenticate manually if you want to review each change. MailerLite presents three record categories:

• DKIM: CNAME. Copy the exact selector hostname and destination.
• SPF: TXT. Review the proposed policy against existing authorizations at that owner.
• Domain verification: TXT. Copy the account-specific verification token without changing other TXT records.

Use the manual wizard's record confirmations, then return to the domain's menu and select Check DNS records. Wait for Authenticated, rather than treating Authentication in process as completion. MailerLite documents propagation of up to 24 hours. Current manual setup.

Enter names without duplicating the domain

If MailerLite displays SELECTOR._domainkey.example.com, a DNS editor that appends example.com may require only SELECTOR._domainkey. An editor expecting a full hostname needs the entire name. SELECTOR is a placeholder, not a recommended selector. Preview the resulting fully qualified name before saving.

For an issued signing domain such as news.example.com, a full owner SELECTOR._domainkey.news.example.com is SELECTOR._domainkey.news relative to the parent example.com zone, or SELECTOR._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com itself is delegated, the relative owner there is SELECTOR. Replace the selector placeholder with the issued value, preserve the account’s exact type and public value, and publish at the actual authority without removing the NS delegation. This example explains name placement, not automatic product eligibility for a new domain. DKIM owner construction, relative DNS names.

Keep the DKIM CNAME DNS-only, unproxied and unflattened so the expected alias remains visible. In Cloudflare, disable flattening for this authentication owner if enabled; do not broadly change unrelated records. Cloudflare CNAME verification guidance.

For authentication records that actually use CNAME, retain a literal CNAME answer to the issued target and use DNS-only rather than HTTP proxying. Turn the relevant per-record Flatten setting off where available, and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are DNS-host behaviors, not assumed controls in the sending application. If mandatory behavior or shared settings cannot preserve the required CNAME answer, stop and coordinate a supported layout without breaking other services or removing shared NS delegations. Do not blindly disable features across the whole zone. Cloudflare verification guidance, flattening controls and limits.

A CNAME destination is a hostname, not a URL. Do not add https://, a path or a copied display label. Do not publish a TXT key at the same owner as a DKIM CNAME. If another service already occupies the exact owner, stop and investigate the collision rather than deleting it. Multiple providers can coexist using different selectors.

Merge SPF deliberately

MailerLite's merge guidance shows how to combine authorizations, and its troubleshooting guidance describes automatically proposing a merged value during a DNS recheck. Compare that proposal with the current authoritative answer before publication, especially if another administrator has changed the zone since setup began. SPF merging and authentication troubleshooting.

There must be only one v=spf1 policy at a given DNS owner, not one per service. Preserve necessary mechanisms and the intended terminal policy; do not paste one whole SPF record after another. Count DNS-querying terms, including nested includes, against SPF's limit of ten during evaluation. Other TXT records can remain alongside SPF. SPF specification.

If an existing SPF policy uses redirect=, preserve its intended authorizations and final semantics through a reviewed merge. Any all mechanism causes redirect to be ignored, so appending a canned policy or an all without reviewing that dependency can change which senders are authorized. SPF redirect semantics.

MailerLite’s documented SPF mechanism is include:_spf.mlsend.com; confirm it against your account’s current proposal. Avoid treating a universal copied MailerLite value as your complete policy. The account's proposed policy must be reconciled with your real sender inventory. An SPF pass authenticates the envelope MAIL FROM domain, not automatically the From address displayed to the reader. Adding a root-domain include cannot change which envelope identity a campaign uses.

Configure optional domain alignment

After authentication, open the sending domain, find Domain alignment, and select Add records. Choose an unused subdomain prefix without underscores. The manual route supplies an A record, MX record and TXT record. Publish their exact owners and values, including the supplied MX preference; MailerLite recommends priority 10. Check DNS, then switch alignment ON. Publication alone is not activation. MailerLite alignment instructions.

Before publishing or enabling this optional feature, compare its exact full owners, complete A-address set and complete MX-priority/target set with the mail-routing and web-routing owners’ separately approved plan. Account-issued values alone do not authorize new destinations. Query each exact owner at both authoritative and recursive resolvers and match the complete approved A and MX sets, plus the issued TXT. Extra, missing or changed records must be resolved before acceptance; a nonempty answer is not enough. Preserve root mailbox routing and other web services. Optional alignment record set.

Do not use the alignment subdomain as the From sender domain. MailerLite requires the sender address to remain on the authenticated main domain; the alignment hostname serves headers and tracked links. Alignment FAQ.

Reserve this hostname for MailerLite. Do not repurpose a website address or an existing mailbox domain. Its MX belongs at the assigned alignment hostname, not automatically at the organizational root. Replacing the root MX could divert employee mail. An A record should expose the supplied address rather than an unrelated web proxy's address.

MailerLite's feature also covers branded links and image URLs. That is broader than DMARC identifier alignment: DMARC compares authenticated email identities, not the domains of every hyperlink. Do not call a campaign DMARC-compliant merely because its links look branded.

Keep a record of which campaigns used the alignment hostname. Before removing or repointing it later, assess previously delivered links and images as well as new sends. Readers can open old newsletters long after a campaign ends. A narrow, documented rollback is safer than deleting an entire subdomain because one check failed.

Preserve or establish DMARC

Check the policy for the visible From domain and any inherited parent policy before creating a record. For news.example.com, inspect _dmarc.news.example.com and the relevant parent-policy discovery path. An absent local record does not establish that the subdomain has no protection. Retain existing p, sp, alignment modes and report destinations unless the domain owner approves a separate change.

For a domain with no existing or inherited policy, a monitored initial setup can be:

• DNS type: TXT.
• Owner: _dmarc.example.com, or _dmarc within the example.com zone.
• Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com.
• TTL: your DNS host's normal default.

Replace example.com and the report address with your actual domain and a working, authorized reporting destination. For a From domain of news.example.com, the local owner is _dmarc.news.example.com, often _dmarc.news in the parent zone. Do not create a second DMARC policy at an occupied owner or weaken inherited enforcement to make setup pass. External report destinations may require reporting authorization.

Compare the Organizational Domain of the aggregate-report URI host with the Organizational Domain of the domain where the DMARC policy was found, not automatically the visible From domain. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted, even when its hostname differs. This protocol check does not replace the domain owner’s separate approval to share report data with that recipient. RFC 9990 section 4.

For _dmarc.news.example.com in a separately delegated news.example.com zone, use relative _dmarc; preserve existing authority and inherited protection.

DMARC passes when at least one passing SPF or DKIM identity aligns with the visible From. Relaxed alignment permits an organizational-domain match; strict alignment requires an exact match. p=none requests no DMARC-based enforcement and is not a blocking policy. Review legitimate senders before enforcement. Current RFC 9989 replaces RFC 7489 and removes pct; do not build a new rollout around that obsolete percentage tag.

Verify DNS and campaign headers

These commands are read-only examples. Replace every placeholder with the actual account-issued name:

dig +short NS example.com
dig +short TXT example.com
dig +short CNAME SELECTOR._domainkey.example.com
dig +short TXT DKIM-TARGET-FROM-ACCOUNT
dig +short A ALIGNMENT-HOST.example.com
dig +short MX ALIGNMENT-HOST.example.com
dig +short TXT ALIGNMENT-HOST.example.com
dig +short TXT _dmarc.example.com

The CNAME should match MailerLite's destination; its final TXT answer should contain a public DKIM key. Check each alignment record against the account, not against another customer's sample. Query the authoritative server with dig @AUTHORITATIVE-NS NAME TYPE if recursive results disagree. An empty answer can mean the wrong name or type; SERVFAIL is not proof that the record is missing.

After account verification and any alignment activation, send an authorized campaign or automation sample to a mailbox you control. Use the actual production path, not a different preview sender. In raw headers, inspect the receiving system's trusted Authentication-Results:

Use receiver-controlled diagnostic output, or have the receiving administrator establish which fields were generated inside its known processing boundary and document how externally supplied Authentication-Results are removed or distinguished. A familiar authserv-id string or header position alone does not establish provenance. Ignore attacker-inserted or otherwise untrusted results, including a forged field naming the expected receiver. Operational receiving-boundary requirements.

• spf=pass, noting the evaluated smtp.mailfrom domain.
• dkim=pass, noting header.d and the signature's s= selector.
• dmarc=pass for the intended header.from domain.

Compare identities under the published alignment modes. A provider-owned SPF pass can coexist with an aligned DKIM pass and successful DMARC. Conversely, two authentication passes for unrelated domains can still fail DMARC. A DNS key lookup cannot verify a signature's validity on a message. DKIM specification.

Record the sample's date, sending workflow and redacted authentication evidence. Passing authentication does not guarantee inbox placement, consent, good content or sender reputation.

For setup acceptance, require a passing DKIM signature for the expected branded domain that aligns with From, plus DMARC pass. Independently investigate actual SPF fail, permerror or temperror results even when DKIM carries DMARC; an unaligned SPF pass is a different diagnosis.

Diagnose SPF at the actual smtp.mailfrom independently, even when aligned DKIM supplies DMARC pass. fail or softfail calls for checking whether the connecting sender is authorized for that envelope route; temperror indicates transient evaluation trouble such as a DNS timeout; permerror calls for checking malformed syntax, duplicate policies and the evaluated DNS-term budget. A passing but unaligned SPF identity is a separate condition. SPF result meanings.

Troubleshooting

DKIM never approves: compare the exact owner, CNAME type and destination; look for an auto-appended domain suffix or conflicting record. Do not regenerate keys repeatedly while caches still contain earlier values.

SPF keeps failing verification: inspect the live record, not only the editor. Remove duplicate SPF policies through an approved merge and preserve the other legitimate senders. Recheck MailerLite's refreshed proposed value.

Alignment records resolve but mail still uses the old identity: confirm the feature is ON, then obtain a fresh sample from the correct campaign. Old headers do not change when DNS changes.

Mail passes but old newsletter links break: investigate the alignment hostname's web records separately. Do not alter DMARC to fix a link-routing problem.