Laposta SPF, DKIM and DMARC setup, step by step

To authenticate a custom sender domain in Laposta, first confirm the sender email address, then open Instellingen → Authenticatie → Toon instructies. Publish the two CNAME records Laposta supplies for Bounces and DKIM at your authoritative DNS host. Review any requested DMARC TXT record against your existing policy, then return to Laposta and click Activeren. For standard sending, Laposta says you do not need to configure a separate SPF record for its mail servers.

The final check is a controlled message sent through the native campaign route with your intended From address. DNS records and an authenticated status alone do not prove that the delivered message carries an aligned, passing Laposta DKIM signature.

1. Confirm the sending route and who can change it

This guide covers newsletters sent natively by Laposta from a custom domain you control. It does not configure another SMTP service, move your domain, or change the hostname used for links and images. Laposta distinguishes the sender email address, domain authentication, and account hostname as separate settings in its current domain-authentication instructions.

Prepare these items before editing:

• The exact intended From address and a working reply mailbox.
• An authorized account operator who can access Instellingen and the relevant sender/domain settings.
• The actual authoritative DNS host and an authorized DNS operator. Your registrar and DNS host may be different organizations.
• The domain owner's approval for the specific authentication records and any report-data sharing.
• A saved copy of existing records, active selectors, delegations and applicable DMARC policy, plus a change owner and recovery plan.

The reviewed authentication documentation does not establish a named role or plan matrix. If the controls are unavailable, establish access and product applicability with your account administrator or Laposta before changing DNS. Do not purchase an upgrade or change security settings merely to make the screen match a tutorial.

A personal webmail address that Laposta rewrites during sending is not the same as authenticating your own brand. Use an approved custom-domain address for this task, and reject an unexpected provider-domain From rewrite during acceptance.

2. Add and confirm the sender address

Domain authentication and mailbox confirmation solve different problems. An address can be present in the account without being available as a campaign sender.

Follow Laposta's sender-address procedure:

1. Open Instellingen → Afzendadressen.
2. Select Nieuw afzendadres.
3. Enter the intended address in E-mailadres.
4. Choose its permitted use. Geen beperkingen is the default and permits both sender and reply-address use. Alleen als verzendadres permits only sender use; Alleen als antwoordadres permits only reply-address use.
5. Click Voeg het e-mailadres toe.
6. Open the confirmation message in the matching authorized mailbox and follow its confirmation link.

Do not confirm an address on someone else's behalf without authorization. If the address already exists but is unconfirmed, use Details → Verstuur bevestigingsmail opnieuw rather than repeatedly adding it.

The Extra info column distinguishes an unconfirmed address, missing domain authentication, restricted address use and a planned address rewrite. Read that explanation rather than treating a green availability mark as proof that SPF, DKIM and DMARC have passed on a delivered campaign.

3. Obtain the domain's current authentication records

Open Instellingen → Authenticatie. Laposta lists domains used by your sender addresses with their statuses. Select Toon instructies for the exact domain you intend to authenticate.

The current setup page requires two CNAMEs and, when indicated for that domain, a DMARC TXT record:

Copy each Naam and Doel or value with the adjacent copy control. Alternatively, use Kopiëren naar klembord to copy the combined instruction block for your DNS operator.

Laposta illustrates eprov pointing to mail.eprov.eu and eprov-k1._domainkey pointing to dkim.eprov.eu. These are useful for recognizing the two jobs, but the same page explicitly says to use your own account's domain and values. Do not substitute a remembered selector, an old screenshot or another customer's instructions for the current packet.

The DKIM entry is a CNAME, not a request for you to generate or paste a private key. Do not convert it to a TXT record or put an SPF policy at its owner. If the current packet differs materially from the documented route, stop and resolve the difference with Laposta before publication.

4. Publish the records at the actual DNS authority

Locate the zone that is authoritative for each requested owner. If your organization delegates a child domain or its _domainkey namespace separately, its DNS operator may differ from the parent-domain operator.

Laposta's DNS-provider instructions say to retain other records and preserve an existing DMARC record pending discussion with the domain administrator. Use the default TTL, or 3600 seconds if the DNS editor requires an explicit value. Save the records using that DNS host's normal save/apply action.

Translate full owners into the correct editor input

The table below uses fictional placeholders, not values to publish. SELECTOR and BOUNCE mean the exact labels supplied in your account; example.com is an example domain. Keep each issued target unchanged while adapting the owner to the zone editor.

If your DNS editor expects a fully qualified owner, enter the complete owner instead. Check the final saved name so the zone is not appended twice. The bounce record still belongs in its own authoritative zone, not in a delegated _domainkey zone.

Some DNS hosts require a trailing dot on a fully qualified CNAME target; others add or normalize it. Follow that editor's documented convention and verify that the saved target is the exact intended hostname, not a target accidentally extended with your own domain. Leave existing NS delegations in place.

Keep the required CNAME answers visible

At either issued CNAME owner, do not add a conflicting TXT, A, AAAA, MX or second CNAME. An occupied name is a dependency to investigate, not permission to delete existing records. Ask the responsible operators to agree a supported resolution.

For DNS hosts with an HTTP proxy, the authentication aliases must remain DNS records, not proxied web hosts. In Cloudflare, use DNS only, as described in its proxy-status documentation.

Also ensure that flattening does not hide the required aliases. Where available, turn the relevant per-record Flatten control off, and ensure applicable whole-zone settings do not suppress these CNAME answers. Coordinate shared-setting changes rather than disabling unrelated records globally. Cloudflare documents apex and same-zone behavior that can apply even when an ordinary per-record setting seems correct. If mandatory behavior cannot preserve the required answer, stop and arrange a supported configuration; do not invent a switch or remove a delegation. See Cloudflare's actual CNAME-flattening setup guide.

A DNS-host limitation is not a reason to move the domain silently

Laposta's current Jimdo guidance identifies a specific problem: the required Bounces CNAME cannot be entered there, even though the DKIM-specific control may accept the other record. It recommends raising the limitation with Jimdo and describes alternative DNS hosting or another domain as possible projects.

Do not change nameservers, transfer the domain, alter MX, or register a replacement domain as an incidental authentication step. Any migration requires its own owner-approved routing and dependency plan. If your host cannot publish both required aliases, hold activation until there is a supported, approved arrangement.

5. Leave standard Laposta SPF management with Laposta

Laposta's current glossary, SPF section says there is nothing to configure for standard use of SPF by its mail servers. Complete its domain-authentication workflow instead of inventing an apex include or copying an unrelated IP range.

That does not mean SPF is irrelevant, nor does it authorize removing the SPF policy used by your other services. SPF evaluates the actual SMTP MAIL FROM identity, or HELO in the relevant cases, not automatically the address visible in From. After activation, record the envelope identity on an actual native campaign and inspect its result.

If a separate, approved mail service needs changes to a policy you control:

• Keep one v=spf1 TXT policy at the evaluated owner.
• Preserve existing legitimate authorizations and qualifiers. Do not blindly replace the policy or append a second one.
• Check the limit of ten evaluated DNS-dependent terms, including nested mechanisms. It is not merely a count of top-level include strings.
• Remember that redirect is ignored when an all mechanism is present.

These rules come from RFC 7208, not a Laposta-specific editing requirement. An SPF pass does not by itself establish alignment with the visible From or guarantee delivery.

6. Preserve DMARC before adding a policy

Laposta may display a DMARC proposal alongside the two CNAMEs. First check the intended From domain's direct policy and any applicable inherited policy. Do not add a child-domain p=none record that overrides inherited protection, replace quarantine or reject with a tutorial example, or create duplicate DMARC records.

If there is no applicable direct or inherited policy, the domain owner approves first-time monitoring, and there is an appropriate monitoring plan, the minimal first-policy TXT value can be:

v=DMARC1; p=none

This is conditional monitoring, not enforcement. It does not enable Laposta DKIM and does not produce aggregate reports without an authorized report destination. Apply it only to the agreed owner:

Use the full owner if that is what your editor accepts. A separately delegated _domainkey zone does not host DMARC simply because it hosts the DKIM selector.

Do not copy the report recipient shown in Laposta's sample. Add an actual rua=mailto: destination only after the owner approves the receiving organization and report-data sharing. When that destination is in a different Organizational Domain from the domain where the applicable DMARC policy was discovered, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain is excepted; a different hostname alone does not make it external. This is the rule in RFC 9990, section 4. DNS authorization does not replace the owner's privacy decision.

If Laposta's proposed value conflicts with an existing approved policy, preserve the policy and resolve the discrepancy with the responsible administrator and Laposta. Do not weaken protection just to clear a status indicator. Current DMARC evaluation follows RFC 9989; old percentage-rollout examples are not a reason to add obsolete pct guidance.

7. Activate in Laposta, then verify an actual campaign

After the authoritative DNS records are saved:

1. Return to Instellingen → Authenticatie.
2. Open Toon instructies for the intended domain again.
3. Click Activeren below the records.
4. Check the confirmation that campaigns can use the sender address for the authenticated domain.

Laposta says DNS changes may need time and recommends waiting a few hours before retrying if activation does not yet succeed. That is not a guaranteed deadline. Check the actual records before repeatedly clicking the button.

For a read-only DNS check, replace every uppercase placeholder below with the full owner from your packet or approved policy. These commands do not publish records and do not contain fabricated results:

dig CNAME BOUNCE_FULL_OWNER
dig CNAME DKIM_FULL_OWNER
dig TXT DKIM_FULL_OWNER
dig TXT POLICY_FULL_OWNER

The CNAME answers should show the intended aliases and targets. The DKIM TXT query can help follow the public-key resolution chain. A correct answer proves publication, not that Laposta has signed a message or that the signature aligns.

Keep content previews separate from release evidence

Laposta's Testmail instructions describe Testmail in campaign step 4, with up to five addresses per test. Designated test addresses from the campaign's lists can show relationship-specific personalization; manually entered addresses do not have that list data. Use only approved recipients and harmless content.

A preview in the browser is not an email authentication test. A Testmail can provide useful mailbox evidence, but the documentation does not establish that it proves every final campaign path. Before release, arrange a separately approved native campaign restricted to a tiny controlled test audience. Check recipient selection and count before sending; do not send to a real customer list or trigger unrelated automations, purchases or other business actions for testing.

Verify the selected From in step 1, Basisgegevens, and again in step 5, Laatste controle. Laposta's sender-warning explanation notes that domain settings can change between campaign creation and sending.

Required message acceptance

Use the receiving service's message details or original message and establish which authentication results were produced inside that service's known processing boundary. Check its documented handling of externally supplied Authentication-Results, such as stripping or marking those fields untrusted on entry. A familiar authserv-id string or header position alone is not proof. Ignore attacker-supplied results; if that boundary cannot be established, obtain the receiver administrator's analysis before accepting the result. See RFC 8601.

For each intended native route, record:

• The unchanged, intended visible From domain.
• The actual MAIL FROM/Return-Path identity and SPF result.
• The intended Laposta DKIM signature's d= domain, s= selector and passing result.
• DKIM alignment with the visible From under the applicable policy.
• Trusted receiver dmarc=pass.

Under relaxed alignment, qualifying domains share the same Organizational Domain. Under strict alignment, the relevant domains must be identical. A child-domain envelope identity can satisfy relaxed alignment without satisfying strict alignment. The presence of the Bounces CNAME alone does not promise either result.

Require the intended Laposta signature to pass and align, even if DMARC already passes through SPF. A passing unrelated signature or a rewritten provider From is not successful brand authentication. EmailAuth's raw DKIM results versus aligned DKIM policy results explains that distinction. DKIM verification itself is defined by RFC 6376.

Diagnose SPF fail, temporary DNS errors (temperror) and invalid-policy/lookup-limit errors (permerror) separately. Aligned DKIM can permit DMARC to pass while an SPF problem still deserves investigation. Neither authentication nor a successful test guarantees inbox placement.

8. Troubleshoot without weakening the working configuration

Laposta checks authentication daily and warns by email if it becomes inactive. Treat that alert as a reason to inspect dependencies, not as proof that every intervening message was authenticated. Keep the responsible mailbox monitored.

9. Recovery and ongoing ownership

If a change causes trouble, pause affected planned sends while the account and DNS owners inspect it. Keep unrelated senders, existing DKIM selectors, NS delegations and DMARC protection intact. Restore a prior record only after confirming its exact saved value and shared dependencies; a wholesale zone rollback can undo other legitimate changes.

Do not delete a confirmed sender, switch to an unapproved domain, or disable protection as a troubleshooting shortcut. For a DNS migration, include both Laposta aliases in the approved zone plan, verify them at the new authority, reactivate if required, and repeat the controlled native-message check. Reassess each actually used From domain and route rather than extrapolating one success to the whole account.

Keep a small operational record: approved From/domain, issued packet, authority and owner mapping, publication time, activation confirmation, actual message identities/results, and unresolved limitations. Store public DNS data and necessary evidence, not mailbox credentials or private keys.

Sources and verification boundary

Those current pages did not expose an absolute publication or update date in the inspected bodies; the check date is not their publication date. Older dated pages and screenshots were corroborating evidence, not current account-issued DNS data.

This guide describes an implementation and acceptance procedure. No customer account was accessed, DNS changed, confirmation email requested or campaign sent for it. Authentication status, actual message results and the owner's release decision remain implementation checks.