EmailLabs SPF, DKIM and DMARC setup, step by step

For the current EmailLabs SMTP/API workflow, authorize your From domain, publish the CNAMEs generated by the panel, and complete verification. EmailLabs manages SPF for its default Return-Path domain. If you choose a custom Return-Path, its generated CNAME delegates SPF management for that subdomain. The dedicated SMTP SPF documentation says this route needs no manual SPF TXT change at your main domain. EmailLabs SMTP SPF configuration.

DKIM, sending permission and DMARC alignment still need separate checks. A valid SPF record does not by itself authorize the domain in your account, select the correct SMTP account, or prove that a delivered message aligns with its visible From address.

This guide covers EmailLabs, including its current sender-authorization panel. Do not reuse DNS values from other products in the same corporate group. Some detailed current documentation is in Polish; the labels below retain those names with English explanations rather than assume your account has identical translated labels.

On this page: Prerequisites · SPF options · Domain setup · Safe DNS · DMARC · Validation · Troubleshooting · FAQs

Before you change DNS

Prepare:

• An activated EmailLabs account and access to sender authorization.
• The exact From domain or subdomain your application will use.
• The SMTP account or accounts that will send from it.
• Access to the domain's authoritative DNS, including any separately delegated sending subdomain.
• An inventory of existing SPF, DKIM, DMARC, tracking and bounce records.
• A receiving mailbox you control for later authorized testing.

Account onboarding is a prerequisite, not a DNS task. EmailLabs describes a sandbox domain that becomes available after the required company details, sending-activity survey and Support verification. Authorizing your own domain is still required for the intended branded configuration. Do not treat a sandbox test as proof that your production domain is configured. EmailLabs first-step sender authorization.

Select a sending subdomain deliberately. It can separate authentication owners from your main mail service, but it is not automatically isolated from inherited DMARC policy. Keep your corporate MX records, other services' selectors, and existing SPF authorization unless a coordinated migration requires otherwise. If employee mail uses Google, its separate configuration is covered in the Google Workspace authentication guide.

Choose the correct SPF and Return-Path route

The Return-Path represents the SMTP envelope sender used for bounce handling. For ordinary mail, its domain is the SPF lookup identity. The visible From is a different identity, and Reply-To controls replies rather than SPF. SPF identity rules, RFC 7208.

The first two rows are the route covered here. There is no separate SPF-only wizard in the detailed current SMTP instructions. Configure the envelope option through sender authorization, then inspect the resulting DNS and a delivered message.

Why do some EmailLabs instructions show an SPF include?

A live introductory page still tells users to add include:_spf.emaillabs.net.pl to an existing SPF policy. That advice differs from the dedicated SMTP page's default/custom Return-Path architecture. It is a documentation discrepancy, not evidence that every current account needs both configurations. EmailLabs introductory SPF instructions.

Use the current account-generated Return-Path workflow when it matches your account. If your account or integration instead explicitly requires the include, confirm the owner and sending route with EmailLabs before changing DNS. Do not call the live introductory page retired, automatically add the include at the root, or remove an existing include without checking whether other active mail depends on it.

SPF is evaluated per hostname. Adding an include to example.com does not change the policy for mailing.example.com, and it cannot make a provider-owned Return-Path align with From: news@example.com. Where an SPF TXT edit is actually required, merge into the single existing SPF record and stay within RFC 7208's limit of ten DNS-lookup-causing terms, including nested evaluations. Do not stack multiple SPF records or flatten provider IPs into an unmaintained list.

Authorize the domain and enable DKIM

1. Add the intended From domain

In the new panel, open E-mail, then Bezpieczeństwo nadawcy (Sender Security) and Autoryzacja nadawców (Sender Authorization). In the domain-authorization area, choose Dodaj domenę (Add domain). Enter the full domain or subdomain in Domena From, not a complete email address. EmailLabs domain selection.

For example, if the application will send as receipts@news.example.com, the domain to authorize is news.example.com. Confirm what the application actually submits; authorizing the parent is not a reason to assume every subdomain or account is covered.

2. Review advanced options before generating DNS

The documented advanced settings let you choose a dedicated Return-Path, a branded tracking subdomain, a custom DKIM selector, and DMARC options. The sample prefixes mailing and click are choices, not universal required records. The optional custom selector is documented as 3–7 characters. EmailLabs advanced settings.

Choose unused labels. A bounce CNAME must not overwrite a web hostname, an existing mail-routing record or another sender's bounce service. A DKIM selector must not replace another service's key. A tracking CNAME is not proof that either SPF or DKIM aligns.

Treat the DMARC option as shared-domain policy management. Review the safeguards below before delegating _dmarc or changing its values. Do not accept a weaker policy simply because the panel suggests one.

3. Generate the account's records

Choose Dalej (Next). The current documented flow generates four CNAME entries, each with a host, type and value. Use the complete set actually shown for the account and selected options. Do not reconstruct targets from a screenshot, copy another customer's selector, or assume each row's purpose from its position. EmailLabs DNS generation instructions.

4. Publish, verify and check SMTP permissions

After safely publishing the records, allow DNS propagation. EmailLabs gives a 15-minute to 24-hour window. Return to the panel and choose Weryfikuj (Verify). Successful authorization enables sending addresses in the authorized From domain, subject to the account's sending controls. EmailLabs verification step.

Then open the authorized domain and expand Status. Check which SMTP accounts are allowed to use it. EmailLabs supports restricting a domain to selected SMTP accounts. A verified domain can therefore coexist with an application using an unauthorized SMTP account. Correct the intended assignment rather than broadening access to every account as a troubleshooting shortcut. EmailLabs SMTP authorization restrictions.

Authorized-domain mail is DKIM signed according to EmailLabs' sender-authorization documentation. Verify the actual branded signing domain and selector in the receiving mailbox; the generated-record screen is not proof of a particular message's signature. EmailLabs sender authorization overview.

Publish the generated records safely

Copy each host and target together. DNS editors differ on whether they append the zone automatically. The following examples show owner-name arithmetic only; none is an EmailLabs-generated record:

Use the actual selector and labels from the panel. Verify the saved owner to avoid a doubled suffix. Keep authentication CNAMEs DNS-only where a proxy exists. Inspect zone-wide flattening too; a visible CNAME in the editor may not produce a CNAME response to a verifier.

A CNAME cannot coexist with ordinary TXT, MX or competing records at the same owner. In particular, do not add a hand-written SPF TXT beside a custom Return-Path CNAME. Its delegated destination supplies the provider-managed data. If an existing owner is occupied, stop and coordinate a new label or supported migration. DNS CNAME constraints, RFC 2181.

Keep DKIM public-key resolution distinct from private-key storage. Publish only the generated DNS material. You do not need to place SMTP passwords, API credentials or DKIM private keys in DNS.

Preserve DMARC and check alignment

Start from the effective policy for the actual From domain, not from an empty form in a new service. Inspect _dmarc locally and any applicable parent policy. If the generated set includes DMARC delegation and the owner already has a TXT policy or another CNAME, do not install both or delete the existing entry. Resolve which service will manage that shared policy and preserve enforcement, alignment settings and reporting destinations.

DMARC needs a successful aligned SPF or DKIM result. Relaxed alignment compares organizational domains; strict alignment requires exact domain equality. Consider this illustrative arrangement:

Here, an SPF pass for mailing.example.com can align in relaxed mode but not with strict aspf=s. A valid DKIM signature using d=example.com can align exactly. With the default provider-owned envelope, do not expect an SPF pass alone to align with your brand. Use the delivered values and effective policy, not the label “custom,” to decide. Current DMARC alignment rules, RFC 9989.

EmailLabs' advanced-settings documentation also describes a PCT control. The current DMARC standard, RFC 9989, makes pct historic. Do not rely on that field as a predictable enforcement rollout mechanism across receivers. Preserve an existing approved policy and plan changes using observed traffic and current receiver behavior rather than copy legacy percentage examples. RFC 9989, removal of the pct tag.

For reporting, preserve approved rua destinations. If reports go to a different organizational domain, the reporting service must supply the required external-destination authorization in its DNS. A report mailbox must also exist and accept the reports. RFC 9990 external reporting authorization.

Review all legitimate senders before tightening enforcement. Do not weaken an inherited reject or quarantine policy to make one new sender work. No DMARC policy guarantees inbox placement.

Validate the live route

DNS acceptance

Use read-only lookups against the actual generated owners. These sample names must be replaced:

dig +short NS example.com
dig +short CNAME mailing.news.example.com
dig +short TXT mailing.news.example.com
dig +short CNAME abc._domainkey.news.example.com
dig +short TXT abc._domainkey.news.example.com
dig +short CNAME _dmarc.news.example.com
dig +short TXT _dmarc.news.example.com
dig +short TXT _dmarc.example.com

Each expected CNAME must lead to the supplied target and usable final records. For a custom envelope, confirm the resulting SPF policy authorizes the outbound route. For DKIM, follow the selector's alias to the public key. For DMARC, inspect the effective policy, not just the existence of an alias. Compare authoritative and recursive answers before attributing a discrepancy to propagation.

Account acceptance

Record the verified domain, selected advanced options and allowed SMTP accounts. Match those settings to the SMTP/API route used by the application. A different application's successful test does not cover this integration.

Delivered-message acceptance

When authorized to test, submit a new message through the intended application and EmailLabs account to a mailbox you control. Inspect its original headers. Trust the receiving service's own authentication results, not an arbitrary Authentication-Results field supplied earlier in transit. RFC 8601 security considerations.

Check all of the following:

1. The visible From is the authorized branded domain.
2. spf=pass references the expected smtp.mailfrom; a custom envelope is actually being used if you configured one.
3. dkim=pass includes the intended aligned header.d/d= and the expected s= selector. An unrelated infrastructure signature is not a substitute.
4. dmarc=pass applies to the intended header.from. Identify whether SPF, DKIM or both supplied alignment.
5. Replies and bounce handling still follow the intended separate routes.

Keep a dated acceptance record for each domain/account combination. Later aggregate reports help confirm that production traffic, not only a single test, continues to authenticate. A dashboard's verified label cannot establish those receiver outcomes.

Troubleshooting

Distinguish a non-aligned SPF pass from an error. fail or softfail means the evaluated policy did not authorize the observed sending IP; none means no usable SPF policy; permerror points to conditions such as invalid syntax, multiple SPF records or an exceeded lookup limit; temperror points to a transient lookup failure. Investigate the actual envelope owner. For an EmailLabs-owned domain or delegated target, escalate the evidence to EmailLabs instead of editing the root-domain SPF. SPF evaluation and limits.

If escalation is needed, provide the domain, SMTP account identifier, generated record names, DNS answers, timestamp and sanitized receiver results. Do not disclose SMTP passwords or API secrets in a support message.

Documentation review and testing boundary

This is documentary verification, not a tested customer installation. No EmailLabs account settings, DNS records or messages were changed or sent. The implementer must use the account's generated values and complete the DNS, permission and delivered-message checks.