LianaMailer SPF, DKIM and DMARC setup, step by step

Configure LianaMailer through Settings → Domain Settings, copy the proposed DNS records for the actual sending domain, publish them with your DNS administrator, and use Verify again. Also check the subscription site and its Envelope sender setting. Liana's support team supplies any required SPF authorization and completes site-related configuration when needed. A verified domain alone is not proof that the newsletter uses aligned SPF or DKIM. Domain Settings, LianaMailer IT instructions, Sending and site checks.

Start with the correct Liana product and sending identity

This guide covers LianaMailer newsletter sending and its related subscription/unsubscription-site configuration. It is not a DNS recipe for LianaPress, LianaCMS, LianaCommerce or every application in Liana's product family. An integration or automation that ultimately sends through LianaMailer should be validated through that actual route, not assumed to inherit the result of an unrelated preview.

You need access to the relevant LianaMailer account, sufficient rights to view its domain settings, and an administrator who can publish DNS for the sending domain. Availability of domain settings depends on user rights. LianaMailer settings and permissions.

Assign a campaign owner, DNS administrator and mail-security reviewer. Retain the account settings, affected DNS and a baseline original message where available; identify scheduled templates before the change. Before changing anything, write down:

• The precise From address the newsletter will use.
• The LianaMailer account and selected subscription/unsubscription site.
• The site's main domain and any alternative addresses.
• The current envelope/bounce domain, if you have a recent delivered message.
• The DNS administrator and the support case for this setup.
• Other services that send using the same From domain.

LianaMailer permits multiple subscription sites, for example for different languages, and documents a customer domain as the main address with a provider address as an alias. Check the site actually selected for the campaign, not merely the first site in the account. Subscription sites.

Why subscription-site configuration affects LianaMailer authentication

LianaMailer's IT instructions connect the subscription-site address with the envelope-sender identity. Their example contrasts a provider-hosted site and envelope with a branded site such as newsletter.example.com. That branded envelope can share the organizational domain of a From address such as news@example.com. LianaMailer envelope and site relationship.

This creates two different questions:

1. Is LianaMailer's domain/site setup correct? The application may require the sending address and selected site to use corresponding domains.
2. Does the delivered message pass DMARC? The receiver checks the actual SPF and DKIM identities against the visible From domain.

A link or subscription page using the brand's domain is not itself a DMARC authentication result. DMARC does not compare every URL in the message. The site configuration matters here because of LianaMailer's documented sending workflow; the message's envelope and signature still need inspection.

1. Obtain the domain's proposed DNS records

In Settings → Domain Settings, inspect the domain used for sending. Open any unconfirmed or red entry and copy its missing or proposed records. Liana's IT instructions call the action Copy Proposed DNS Values; the current Domain Settings guide also describes copying the displayed missing DNS settings and checking them again after publication. IT setup sequence, Current domain-check interface.

Give the administrator complete record rows, not only their values:

These are not universal copy-and-paste DNS values. The official IT guide explicitly says Liana Support checks whether SPF is needed and supplies the correct authorization. A domain appearing in an online SPF database is not sufficient evidence that your account must add it at the root.

If the intended From domain is missing, ask the account administrator or Liana Support to confirm how it should be provisioned. Do not publish a key from a different domain merely to make a warning disappear.

2. Publish DKIM and any required SPF safely

First export or record existing DNS, including SPF, DMARC, MX and current DKIM selectors. Confirm which nameservers are authoritative. Editing a registrar's inactive DNS zone will not change what mail receivers see.

For DKIM, keep the supplied record type and exact selector owner. If the proposed row is a CNAME, publish its hostname target, not a TXT key or an https:// URL. If the row is a TXT public key, preserve the complete value rather than converting it to an alias. The public key belongs in DNS; the private signing key must not be published. DKIM receivers locate the key using the signature's selector and signing domain. DKIM specification.

Check whether your DNS editor expects a relative name or a full name. For an illustrative owner SELECTOR._domainkey.example.com, a relative field may need only SELECTOR._domainkey. Neither that placeholder nor a guessed liana selector is a deployable record. Verify the final name to catch automatic suffix duplication. For SELECTOR._domainkey.news.example.com, use SELECTOR._domainkey.news in the example.com parent zone, SELECTOR._domainkey in an authoritative delegated news.example.com zone, or SELECTOR in a delegated _domainkey.news.example.com namespace. Preserve NS delegations and publish at the actual authority rather than deleting them.

For a long TXT key, keep all component strings in one logical TXT record. DKIM concatenates them without inserted spaces; preserve the entire tagged value, and do not turn components into separate competing key records. DKIM TXT processing

For an issued authentication CNAME, keep the public alias visible. On Cloudflare, use DNS only, not the HTTP proxy, and set an applicable per-record Flatten control off. Ensure applicable whole-zone flatten-all does not suppress the issued literal alias; coordinate any shared-setting change with its owner and assess unrelated dependencies first. If mandatory apex or same-zone behavior still conceals the required CNAME, stop and agree a supported configuration with the DNS host and Liana. Do not invent an override or disable global behavior indiscriminately. Apply the same alias-preservation checks to any issued site CNAME that requires a literal answer. Cloudflare proxy behavior, Exact CNAME flattening controls.

A CNAME cannot share an owner with ordinary other records. If Liana's proposed name conflicts with an existing record, resolve the collision with the administrator and Support instead of deleting a working service. Preserve unrelated DKIM selectors and inbound MX records. DNS alias rules.

For SPF, obtain the required owner and value from Support. SPF normally evaluates the SMTP envelope sender, not the visible From address. Updating the From domain's SPF does not fix an unrelated envelope identity. At a given owner, maintain one SPF policy and preserve all still-authorized senders. Review all evaluated DNS-dependent mechanisms and modifiers, including nested includes and redirects, against the ten-term processing limit, not a count of ten visible includes; do not append a second v=spf1 record. Relevant HELO checks, including a null reverse-path message, use their applicable identity rather than assuming the visible From is the SPF owner. SPF identities and DNS rules.

Preserve every legitimate sender and the existing qualifier. An all mechanism makes redirect ignored regardless of the qualifier, so do not casually append all to a redirect-based policy. Qualifiers describe SPF results, not a guaranteed receiver disposition. SPF all/redirect rule

Keep a record of what changed and why. If the setup requires a CNAME at an envelope-related owner, do not add a separate TXT record at that same name to satisfy a generic checklist.

3. Complete the subscription-site and provider-side steps

Open Settings → Sites and inspect the subscription site used for the newsletter. Liana's troubleshooting instructions specifically require checking that Envelope sender is enabled in that site's settings. Then inspect the newsletter's sending-step settings and confirm that the chosen From domain corresponds to the site domain. LianaMailer sending diagnostics.

If the site still uses a default provider address such as a mailpv.net or mail-eur.net address, Liana directs customers to Support for the appropriate record. Once the administrator publishes the required records, inform Support so it can finish configuration. Branded landing-page redirects likewise require provider-side final adjustments. IT support workflow, Domain and redirect completion.

A requested site A record or redirect has routing consequences beyond copying a packet. Compare its exact destination IP, hostname or forwarding URL with the approved site plan and existing dependencies before publication or activation. Do not accept an unapproved destination from a screenshot, change inbound MX, or move parent nameservers merely to satisfy a tutorial.

Return to Domain Settings and use Verify again. Record the result and whether Support has confirmed completion. Also open the intended subscription page in a browser to confirm it resolves to the correct site. That browser check validates the web destination, not SPF, DKIM or DMARC.

Do not switch off automatic bounce handling as a workaround for an authentication error. Liana recommends system-managed bounce handling and warns that disabling it removes bounce data from reports. Review changes to bounce behavior with Support instead. Delivery settings.

4. Keep DMARC policy and alignment separate

DMARC requires a passing aligned SPF result or a passing aligned DKIM signature. For SPF, compare the authenticated envelope domain with the From domain. For DKIM, compare the passing signature's d= domain with the From domain. Relaxed alignment allows a shared organizational domain; strict alignment requires an exact match. Current DMARC standard.

For a fictional newsletter from news@example.com:

• A passing envelope identity at newsletter.example.com can align under relaxed SPF alignment.
• That envelope does not align when the policy requires aspf=s, because it is not exactly example.com.
• A passing intended LianaMailer DKIM signature with d=news.example.com aligns with this From in relaxed mode, but cannot align under adkim=s.
• A passing intended signature with d=example.com matches exactly and can supply alignment in both modes, including adkim=s.
• A passing signature or envelope belonging only to an unrelated provider domain does not authenticate example.com for DMARC.

Before adding DMARC, check the record applicable to the actual From domain and any inherited parent policy. Preserve existing enforcement and approved reporting addresses. Do not create a second DMARC record at the same owner or downgrade a working policy to get through setup.

Only if neither a direct nor an applicable inherited policy exists, and the domain owner approves an appropriate monitoring plan, a first policy can use this example:

Type: TXT
Full owner: _dmarc.example.com
Value: v=DMARC1; p=none

In the example.com zone its relative owner is _dmarc. For _dmarc.news.example.com, use _dmarc.news in the parent zone or _dmarc in an authoritative delegated news.example.com zone. These examples do not authorize overriding existing protection. p=none alone does not request reports; add rua only for an approved destination and monitoring process.

When the report destination is in a different Organizational Domain from the policy domain, the report-generating receiver must check the destination operator's DNS authorization. A destination within the same Organizational Domain is excepted; a different hostname is not automatically external. Aggregate-report authorization DNS authorization does not replace the owner's privacy, retention and access approval for sharing report metadata. Do not copy a vendor's report mailbox. Establish all legitimate senders' alignment before enforcement; do not build a new percentage rollout around removed pct.

5. Validate DNS and the actual newsletter separately

Check public DNS

Substitute your real domain, selector, envelope owner and authoritative nameserver. These read-only examples are diagnostic commands, not Liana-issued DNS values:

dig +short NS example.com
dig +short CNAME SELECTOR._domainkey.example.com
dig +short TXT SELECTOR._domainkey.example.com
dig +short TXT ENVELOPE-DOMAIN.example.com
dig +short TXT _dmarc.example.com

Query the type Liana supplied. A CNAME answer should match the intended target, and a following TXT lookup should resolve to the relevant public key where that is the documented delegation. A TXT key should match the supplied public value. Do not conclude DKIM is missing from a root-domain-only lookup: the selector name is essential.

When the application and public lookup disagree, compare authoritative data with a recursive resolver:

dig @ns1.dns-host.example TXT SELECTOR._domainkey.example.com +noall +answer
dig @1.1.1.1 TXT SELECTOR._domainkey.example.com +noall +answer

Use CNAME instead of TXT when checking an alias itself. Check delegated subdomain nameservers where applicable. If the authoritative record is wrong, fix it rather than waiting for propagation. If authoritative data is correct but cached results are old, allow the previous TTL and negative-cache lifetime to expire before escalating.

Inspect a delivered newsletter

Once Support and the account checks are complete, have an authorized owner send a representative newsletter to a controlled mailbox. Use its raw original message and results generated inside the receiving service's known processing boundary. Establish from that service's documentation or administrator how externally supplied Authentication-Results are removed or distinguished. Neither header position nor a matching authserv-id is proof. Ignore untrusted fields; if the boundary cannot be established, use a controlled receiving system with a documented boundary or its trusted trace. Authentication-Results trust boundary.

Confirm all of the following:

1. From: the delivered message uses the intended domain, not a different template default or rewritten provider-owned fallback. A fallback From is not successful brand authentication.
2. Envelope: smtp.mailfrom and the Return-Path reflect the expected configuration, including the branded site relationship where configured.
3. SPF: the receiver evaluates the actual envelope owner and reports the expected result.
4. DKIM: the signature's d= and s= are the expected identity and selector, and that branded signature passes and aligns with the visible From domain under the applicable adkim setting. Require this even when SPF independently supplies DMARC pass.
5. DMARC: the receiver reports dmarc=pass for the intended header.from, with at least one identifiable aligned passing mechanism.
6. Site: the intended subscription/unsubscription links work; this is a separate functional check.

Save account/template identifiers, timestamp, expected and observed identities, each signature result and the restricted original-message location in one acceptance row per route. Mark untested fields pending, and test replies where relevant. Save the date and route with the result. Validate additional From domains, sites or materially different automated routes individually. Do not claim the account is fully authenticated merely because one preview reaches an inbox.

Troubleshooting LianaMailer-specific failures

“DKIM issue: sender domain differs from the subscription site domain”

This is a LianaMailer configuration warning that can block sending. Compare the selected site's domain and the campaign From address first. Liana's example uses newsletter@company.com with newsletter.company.com, so its correspondence requirement should not be misread as strict DMARC equality. If those settings are appropriate, inspect Domain Settings for missing records and ask Support to verify and finalize the setup. Official domain-mismatch troubleshooting.

Domain Settings is green, but the envelope is still provider-owned

Check the specific subscription site selected for that newsletter and its Envelope sender option. Confirm Support finished the branded-site setup. Recheck a fresh message, because old messages retain the old envelope identity. Do not add speculative root SPF includes to compensate.

DNS looks correct, but DKIM fails

Query the exact selector derived from the message's s= and d= tags. Compare the account-issued record with the public answer and ask Support whether the account is using the intended signing configuration. If direct delivery works but a forwarded copy fails, investigate changes made by the intermediary before replacing the key.

SPF fails even though DKIM makes DMARC pass

Investigate the actual envelope domain rather than ignoring the failed mechanism. For fail or softfail, compare the sending IP and required authorization with Support. For permerror, inspect duplicate SPF policies, syntax and DNS-querying term limits. For temperror, check DNS availability and retry after the transient error clears. Do not broaden the root policy if it was not the SPF owner the receiver evaluated.

SPF passes, but DMARC fails

Look for an unaligned envelope domain or strict SPF alignment. Then inspect DKIM: a provider signature may pass without aligning, or the customer signature may be absent or invalid. A pass for either mechanism is useful to DMARC only when its domain aligns.

Authentication passes, but the newsletter is still filtered

Authentication does not guarantee inbox placement. Inspect recipient errors, complaints, subscriber consent, list quality and content. Avoid weakening DMARC or broadening SPF simply because one message went to spam.

For the difference between a valid signature and one that satisfies brand policy, see EmailAuth's raw DKIM versus aligned DKIM guide.

If the new configuration fails, pause affected campaigns and work with Support and the DNS owner to restore only the approved changes. Preserve other senders, selectors, site dependencies and existing DMARC protection. Keep test originals restricted and redact unnecessary personal data before sharing diagnostics.