Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Identify the MailerLite account and sender domain
This guide covers the current MailerLite product. Its documentation directs Legacy (Classic) users to their account's separate help center, so confirm the product before following screen names or publishing records. Record the sending account, intended From address, campaign or automation, existing DNS owner and any active alignment subdomain. MailerLite domain authentication.
Distinguish three decisions: permission to use a sending address, DNS authentication for its domain, and MailerLite's optional domain-alignment configuration. These decisions can affect different DNS names and different parts of a message. List the campaigns and automation emails covered by the change. Agree who can pause them and preserve the current account settings and DNS answers in a change record.
Choose a controlled test audience rather than using a scheduled customer campaign as the first verification attempt. If the domain already has DMARC, record its policy and alignment modes before proposing any changes. The service setup should not silently overwrite an established policy that also protects employee mail and other providers.
Complete domain authentication
Go to Account settings > Domains and add the sending domain using the email address intended for mail. For manual authentication, MailerLite supplies a DKIM CNAME, SPF TXT record and verification TXT record. Use the exact account-issued owner names and values. After publication, use Check DNS records and confirm the domain reaches Authenticated status. MailerLite authentication workflow.
For each record, document its full DNS name, type, target or value, previous answer and publisher. Confirm that the editor belongs to the authoritative DNS service rather than merely the website host. Check how its Name field handles the domain suffix. A valid-looking CNAME under a doubled domain name will not answer the selector lookup receivers need.
MailerLite's troubleshooting guide covers mismatched DKIM targets, duplicate SPF records and incomplete verification tokens. It also describes a merged SPF value available during checking. Review any proposed merged value against all legitimate senders before replacing the current policy. A single TXT record may contain multiple character strings; that is different from publishing multiple independent SPF policies at the same name. Count evaluated DNS-causing SPF terms, including nested evaluations, against the ten-term limit in RFC 7208 §4.6.4; this is not simply ten DNS packets or ten visible include entries. MailerLite authentication troubleshooting and SPF specification.
Automatic setup is an alternative when the DNS provider is supported, but it grants another service permission to make changes. Review the records and scope of that authorization first. Whether the setup is automatic or manual, the same DNS and received-message acceptance requirements apply.
Configure the separate alignment subdomain
MailerLite exposes domain alignment only after authentication. Open the authenticated sending domain, choose Add records on the Domain alignment card and select an unused subdomain prefix. The current manual flow supplies A, MX and TXT records. Publish the issued set, check DNS and then turn alignment on. Do not reuse a subdomain already serving a landing page or website. MailerLite domain alignment.
Keep the From address on the intended sending domain. The vendor says the alignment subdomain should not itself be used as the sender address and that enabling alignment does not change where replies go. Treat the new MX record as part of this dedicated subdomain setup, not a request to replace the organization's root-domain mail routing.
MailerLite's product term includes branding for headers and tracked content. DMARC's protocol test is narrower: it compares the visible From domain with a successfully authenticated SPF or DKIM domain. Tracking links and image URLs are not DMARC identifiers. A passing customer-domain DKIM signature may already satisfy DMARC without the optional alignment feature. Conversely, an enabled feature switch alone is not evidence that strict alignment is satisfied. DKIM and DMARC.
Test the message and protect historical links
Original acceptance worksheet, not an executed test: send through each changed campaign or automation route to controlled external recipients. Save the original source and record the account, workflow, timestamp and message identifier. Build a received-message identity table with the visible From domain, actual Return-Path, SPF identity and result, every DKIM d= and s= pair, and the trusted receiver's DMARC result. State which passing path aligns under the domain's relaxed or strict settings.
Separately test a harmless tracked link and a reply. Those checks answer whether branding and reply handling work, not whether DMARC passes. Keep the observations separate so a link success cannot conceal an authentication failure. Compare the real sender address with the one approved in the change record.
Recovery requires care: MailerLite warns that turning alignment off after sending campaigns can break links in those earlier messages. Do not delete the subdomain records or toggle the feature off as an automatic rollback step. Pause new sends if needed, identify the actual failure and plan recovery with the account owner while protecting existing links. A subdomain change requires a deliberate migration rather than casual DNS cleanup.
No MailerLite tenant, authoritative DNS answer or received message was tested here. Current-product confirmation, account-issued records, exact campaign and automation route evidence, historical-link checks and a received-message identity table remain required. Independent technical review and human SME approval are pending before publication or production acceptance.