Lightspeed SPF, DKIM and DMARC setup, step by step

For Lightspeed eCom C-Series, verify your store's Generic and Service email addresses in Settings > General Settings > Company, then select Open detailed guide to obtain the store's DNS authentication records. The official C-Series guide shows three CNAME records: one mail-domain alias and two DKIM aliases. Publish the complete values issued for your account, preserve existing SPF and DMARC policies, and test both manual and automated store email for aligned DKIM and DMARC success.

Do not copy the shortened record values in the public screenshot. Do not use the separate X-Series/E-Series setup as a substitute. The official C-Series instructions govern this guide.

On this page

• Confirm the product and prerequisites
• Verify the Generic and Service addresses
• Retrieve the account's three CNAME records
• Publish the records in authoritative DNS
• What to do with SPF
• Preserve or establish DMARC
• Finish authentication without assuming an activation button
• Test both sending paths
• Troubleshooting
• Acceptance and rollback
• Frequently asked questions

Confirm the product and prerequisites

This procedure is for the eCom C-Series Back Office and its native store messages:

• Generic address: manual communication, such as messages concerning an order.
• Service address: automated communication, such as order confirmations.

It is not a procedure for Retail X-Series, eCom E-Series, Restaurant, Golf or a third-party marketing application. Lightspeed's X-Series article for E-Series notifications uses a different menu, record-generation flow and eligibility statement. Its authentication timing and completion-email promise must not be transferred to C-Series.

Use working mailboxes at a domain your organization controls, with access to their verification emails. A public mailbox domain such as gmail.com is not yours to authenticate. Hosting the website on Lightspeed does not itself establish control of an unrelated email domain.

You also need an account user authorized to edit Company email settings and a DNS administrator for the actual authoritative zone. The C-Series source does not specify a universal named-role, subscription-tier or regional entitlement. If the described controls are absent, have the store administrator confirm the product and available access rather than upgrading or switching products based on an assumption.

Record the current sender addresses, SPF, DKIM, DMARC, DNS delegations and inbound-mail routing before changes. Keep mailbox hosting and sender authentication separate: this procedure does not require replacing MX, parent nameservers, DNSSEC, credentials or forwarding recipients. If new mailbox hosting is needed, complete its approved setup separately.

Verify the Generic and Service addresses

1. Open the Lightspeed eCom C-Series Back Office.
2. Go to Settings, then Company under General Settings.
3. In the email-address section, enter the intended Generic and Service addresses. If the correct addresses are already present, use Verify ownership.
4. Select Save or Save and Verify, according to the current ownership-verification state.
5. Open the confirmation messages delivered to the addresses and follow their verification links.

Confirm every address involved, even if one was verified earlier. Do not assume verification of a Generic address covers a different Service address. Lightspeed documents this sequence in Adding your store's brand to your emails.

Mailbox verification is only the first gate. The official screenshot can show an address as verified while still asking you to finish authentication with DNS. A verified mailbox proves access to that mailbox; it is not evidence that Lightspeed is signing mail for your domain.

Retrieve the account's three CNAME records

Return to Settings > General Settings > Company. In Email Addresses, select Open detailed guide. Retain the complete DNS packet for the currently configured addresses and domains.

The current official screenshot labels three rows:

• mail_cname, type CNAME, for the mail-domain portion of the setup.
• dkim1, type CNAME, for one DKIM selector.
• dkim2, type CNAME, for the other DKIM selector.

These are descriptive row labels, not universal DNS owner names. Copy each actual Host/Name and full Value/Target from your account. The public screenshot truncates the example owners and targets, so it cannot supply a runnable record set. Do not reconstruct the missing suffixes from another store, another provider or a familiar mail backend. The screenshot is part of the C-Series source.

If the two addresses use different domains, inspect the current guide's coverage for both. Do not assume one domain's record set authorizes another domain, or invent a total record count across multiple domains. Resolve missing or conflicting issuance with Lightspeed before publication.

The DKIM targets ultimately lead to public-key records maintained by the sending service. You publish the issued aliases, not a generated private key or an extra TXT record alongside each CNAME. No real cryptographic keys need to be generated for this account-driven workflow.

Publish the records in authoritative DNS

Use the DNS host that serves the domain's authoritative zone, not automatically the company where the domain was purchased. At a delegated child domain or _domainkey namespace, make the change in the responsible child zone. Preserve existing delegations and unrelated sender records.

For every issued row:

1. Choose CNAME as its type.
2. Enter the issued owner in the form your DNS editor expects.
3. Enter the complete issued target hostname without shortening it or appending the local zone accidentally.
4. Save with the organization's normal suitable TTL and confirm the resulting full owner and target.

For example, an issued DKIM owner shaped like SELECTOR._domainkey.example.com normally uses SELECTOR._domainkey as the relative name in the example.com zone. For SELECTOR._domainkey.mail.example.com, use SELECTOR._domainkey.mail in the parent zone or SELECTOR._domainkey in a separately delegated mail.example.com zone. In a delegated _domainkey.mail.example.com zone, the relative name is SELECTOR. These are mapping examples only: replace the placeholder with the exact issued selector, and use the full name if your editor expects one.

At a CNAME owner, do not add a TXT, A, AAAA, MX or another CNAME alongside it. Investigate existing uses and obtain a supported alternate packet if necessary; do not delete another sender's selector just to make room. RFC 1034 establishes the CNAME constraint.

Keep the issued aliases visible

Set these authentication aliases to DNS-only, not an HTTP proxy. Cloudflare's proxy documentation distinguishes DNS records needed for non-web services from proxied web traffic.

The required result is a publicly visible CNAME answer at each issued owner. Turn per-record Flatten OFF where available, and ensure applicable whole-zone “flatten all CNAMEs” settings do not flatten the issued aliases. Coordinate shared-setting changes with the DNS owner rather than globally disabling a feature without checking other dependencies. Preserve existing delegations.

Apex CNAMEs may be flattened automatically, and Cloudflare documents same-zone targets being flattened regardless of the ordinary setting. DNS-only therefore does not always guarantee alias visibility. Do not move the records to the apex or fabricate substitute targets. If mandatory flattening prevents the issued alias from being returned, resolve a supported configuration with the DNS administrator and Lightspeed before proceeding. See Cloudflare's flattening rules.

Compare authoritative answers and publicly cached answers with the exact packet. Allow for TTLs and cached negative responses before treating a stale result as a new configuration error.

What to do with SPF

The C-Series native DNS packet uses the mail alias plus DKIM aliases. The public instructions do not supply a universal SPF include to append to every customer's apex. Publish the complete account-issued packet instead of borrowing an include from a different Lightspeed series or inferred backend.

Preserve the existing SPF policy for your mailbox service and other legitimate senders. Do not add a second v=spf1 TXT record, and do not put an SPF TXT beside the issued mail CNAME. If your current account's instructions differ materially from the documented CNAME route, obtain clarification rather than merging incompatible record types at one owner.

SPF checks the actual SMTP MAIL FROM, usually reflected in Return-Path, or HELO in relevant cases. It does not automatically check the visible From address. A mail-domain alias is not, by itself, proof of the actual envelope domain or strict SPF alignment on a particular message.

If a separate approved change to an existing SPF policy is needed, preserve legitimate authorizations and the intended qualifier. Evaluate the complete policy and its ten DNS-dependent-term budget, including nested lookups, not just the visible number of includes. Adding all can disable a redirect= path. No qualifier guarantees delivery or universal rejection. RFC 7208 governs these rules.

Preserve or establish DMARC

Check for a direct DMARC policy at the intended visible From domain and an applicable inherited policy before publishing anything. Keep existing protection and authorized report destinations intact. The C-Series page's monitoring example is not a reason to downgrade a working policy, add another DMARC record or copy its sample reporting address. Do not introduce its legacy pct example into a new configuration; use the current policy model in RFC 9989.

Only when no direct or applicable inherited policy exists, the domain owner approves it, and an authentication-monitoring plan is in place should you introduce this first-policy baseline:

v=DMARC1; p=none

Use one TXT record at _dmarc.FROM-DOMAIN, replacing the placeholder with the actual visible From domain. For example.com, the full owner is _dmarc.example.com, normally _dmarc in that zone. For store.example.com, use full owner _dmarc.store.example.com: relative input _dmarc.store in the parent zone, or _dmarc in the separately delegated child zone. Verify the resulting full name. This is a monitoring policy, not a guarantee of inbox delivery.

If aggregate reports are wanted, add only an actual owner-approved rua destination. A reporting destination in a different Organizational Domain requires the report-generating receiver to check DNS authorization; a destination in the same Organizational Domain is excepted. Different hostnames alone do not make a destination external. RFC 9990, section 4 defines the rule. DNS authorization does not replace the organization's data-sharing and privacy approval for those reports.

Finish authentication without assuming an activation button

Revisit Company > Email Addresses after publishing the exact packet and review the account's current guidance. The public C-Series article establishes the DNS step after mailbox verification but does not name a separate final activation switch, a definitive completion-status label or a fixed verification SLA. Do not invent a Verify Records button or import the E-Series completion-email and 48-hour workflow.

Lightspeed documents a provider-owned fallback address until custom-domain authentication is complete. Its body describes a shop-name address at ecom.lightspeedhq.com, while older-looking illustrations show another provider-owned sender. Neither is successful authentication of your brand. Check the actual visible From on delivered messages rather than accepting a familiar sender name or hard-coding one fallback format. See the C-Series guidance.

If DNS matches but the account still warns or rewrites the sender, provide Lightspeed Support with the affected address, exact DNS packet and relevant sanitized evidence. Do not repeatedly recreate good records or switch products to force a different setup screen.

Test both sending paths

Once implementation and testing are authorized, use controlled valid recipients and the actual intended C-Series paths. Verify a manual message using the Generic address and an automated message using the Service address. Use the store's approved test process for any order-related trigger; do not create a real customer order, charge or unnecessary customer message just to obtain an email.

For each delivered message, use raw headers and Authentication-Results produced inside the receiving service's known processing boundary, with its documented handling or removal of externally supplied result fields. A familiar authserv-id or apparent header position does not prove trust. Ignore attacker-supplied or otherwise untrusted Authentication-Results. RFC 8601, section 7.1 explains this boundary.

Check all of these, separately for both paths:

• Visible From: the intended branded Generic or Service address, not a provider-owned fallback with the same display name.
• Intended DKIM signature: dkim=pass for the relevant Lightspeed signature, with its d= aligned to the actual visible From under the policy's adkim mode.
• Selector: its s= resolves through the appropriate issued CNAME to the intended public key. Multiple published selectors do not mean every message must carry two signatures. EmailAuth's DKIM selector guide explains how to locate this field; RFC 6376 defines the lookup.
• DMARC: the trusted receiver reports dmarc=pass. A pass via SPF alone does not prove the newly configured branded DKIM route works.
• SPF: record the actual MAIL FROM, result and alignment independently. Investigate fail, temperror or permerror even when aligned DKIM makes DMARC pass.
• Replies: replies reach the intended existing mailbox; no unapproved inbound route or forwarding has been introduced.

Relaxed alignment allows the same Organizational Domain; strict alignment requires exact domain equality. A branded child envelope domain can satisfy relaxed SPF alignment while failing strict alignment. The public setup page does not establish a universal Return-Path or d= for every account, so inspect real identities rather than promising them. RFC 9989 provides the alignment rules.

Troubleshooting

The address is verified but still sends as Lightspeed

Mailbox ownership and DNS authentication are separate. Reopen the detailed guide, confirm the complete three-row packet for the relevant domain, and check actual DNS answers. Do not treat a provider-owned From that passes DMARC as success for your custom domain.

One alias is missing or returns only an IP address

Check the full owner, target, zone authority, duplicate-zone suffix, conflicts, proxy status and applicable flattening. A flattened A/AAAA response is not the requested visible CNAME answer. Correct only the affected supported configuration, then account for caches.

Generic email works but Service email does not

Check the two addresses' ownership verification and domain coverage independently. Test the actual automated route. A manual message is not evidence that all store notifications use the same authenticated sender.

DKIM passes but DMARC fails

Compare the passing d= with the visible From and the alignment mode. A valid signature for an unrelated provider domain is insufficient. Confirm the intended Lightspeed signature passes rather than relying on another intermediary's signature.

SPF has an error but DMARC passes

Aligned DKIM can independently satisfy DMARC. Still identify the actual evaluated SPF owner. fail concerns authorization under that policy; permerror can indicate duplicate SPF policies, syntax or excessive DNS-dependent evaluation; temperror concerns a temporary evaluation failure. Avoid editing the apex repeatedly when the actual MAIL FROM uses a different domain.

Acceptance and rollback

Accept the branded rollout only when both intended addresses are verified, the exact issued aliases are publicly visible, the account no longer leaves authentication unresolved, and real Generic and Service messages meet the aligned-DKIM and trusted-DMARC criteria. Keep dated DNS and message evidence. Authentication improves identity assurance, but neither DNS nor DMARC guarantees inbox placement.

If a path fails, pause the affected rollout and preserve an approved working notification route. Restore only the sender settings and DNS changes made for this rollout after checking dependencies. Do not delete a shared selector, mail alias, delegation or existing DMARC policy. Premature key removal can prevent verification of in-flight mail. A provider fallback may preserve some communication, but it is a separate continuity decision, not proof that branded authentication succeeded.