Can I copy the screenshot SPF and DKIM values?

No. Obtain the current account packet. Its tenant names, address data, record types and targets are authoritative for that setup; a generic TXT recipe is not interchangeable with issued DKIM CNAMEs.

Why is an active domain not available as a sender?

It also needs an activated email forwarding address. Then select that address on the intended list. Check the list Return-Path separately.

Do I need ADSP for modern DMARC?

No. ADSP is Historic. Clarify any legacy rows in the current packet with kajomi; do not turn an old screenshot into a new authentication requirement.

kajomi MAIL SPF, DKIM & DMARC Setup: Step-by-Step Guide

For hosted kajomi MAIL, add your domain under System → Allgemein (General) → Domains, publish the DNS instructions generated for either Domain Delegation or Keine Delegation, then wait for the domain to become active. Next, select the intended list Return-Path, create and activate an E-Mail-Weiterleitung for the sender, and select that address on the list. DNS registration alone does not complete sender setup.

Use the current account's full record packet. The documentation's sample nameservers, IP address, SPF value and CNAME targets belong to an example tenant, not every kajomi customer. This guide covers the hosted native list-sending route, not an arbitrary external SMTP service.

The operational help pages do not supply reliable article-specific update dates. This is a documentary guide; no delegation, account change, forwarding rule, DNS edit or email test was performed.

Choose the domain and DNS responsibility

Use a dedicated, unused company-controlled child domain, such as news.example.com, for this full domain and mail-routing setup. Before proceeding, identify the DNS administrator and agree on the visible From, return-path domain, list URL and destination for replies.

Kajomi offers two paths in its domain-addition procedure:

Domain Delegation: delegate authority for the chosen child DNS zone to the account-issued kajomi nameservers. Kajomi manages the domain's records after delegation.
Keine Delegation, meaning no delegation: retain DNS control and publish the current account-issued records yourself.

Delegation is a transfer of DNS authority for that child, not just a verification token. Manual mode can still change web, mail-routing and policy behavior. Neither path is a reason to replace your company's root nameservers or an occupied corporate mail domain.

Have access to the System domain settings, list configuration and authorized DNS administration. The retrieved help does not establish a universal named role or price tier. Confirm the required permissions in your account rather than assuming every list user can make these changes.

Save the existing zone records, delegations, SPF and effective DMARC policy, plus current list defaults, overrides and forwarding settings. If a selected child already hosts something, choose a different unused child or create an explicit migration plan before continuing.

Obtain the current domain packet

Open System → Allgemein → Domains. The English help text also labels this System → General → Domains.
Select Hinzufügen (Add) and enter the intended domain or subdomain.
Choose Domain Delegation or Keine Delegation in the type dropdown.
Copy the complete DNS instructions displayed for that account and domain. Review every type, full owner, value, target, priority and any TTL information with the DNS administrator.
Publish the approved records and wait until kajomi can validate them. The provider says the domain cannot be successfully added before the required DNS is in place.
Complete Hinzufügen. A successful addition first shows pending_add, then normally becomes active after about 20 minutes.

The current screenshot of manual mode shows more than SPF and one DKIM record: ownership TXT, address data, SPF, DKIM-related CNAMEs, a DMARC CNAME, legacy ADSP/report rows and MX. Do not reduce that into a guessed two-record recipe. Equally, do not reconstruct the packet from the screenshot; obtain the current account instructions and clarify legacy or conflicting rows.

Publish delegated or manual DNS safely

Domain Delegation: authorize only the intended child

The documented delegation screen issues two NS records for the selected domain. Use the account's exact two nameservers, not the example tenant's names. For a new news.example.com child, the delegation belongs at news.example.com in the parent authoritative zone, often entered as relative name news.

Confirm that the parent now delegates that child to the approved servers and that those servers answer authoritatively for it. Do not merely replace the registrar's nameservers for example.com, and do not leave an accidental mixture of old and new authority.

Existing records inside a delegated child must be accounted for at the new authority before a migration. If DNSSEC or a child DS record is involved, have the administrator coordinate the chain correctly; do not disable parent DNSSEC or delete security records blindly. Kajomi's SPF/DKIM troubleshooting page says delegated-domain configuration is handled automatically by its system. Confirm the resulting policy rather than assuming automatic means identical to the old one.

Keine Delegation: preserve each issued record type

In manual mode, publish the current packet in the authoritative zone you control:

Ownership TXT and address records: use the exact tenant token and full issued owner. Compare the complete issued A address set with the destination IPs the organization has separately approved for this sending hostname. Resolve any discrepancy with kajomi and the DNS owner before publishing or activating. Do not overwrite a working website owner with a sample or unapproved IP.
SPF TXT: reconcile at its specified owner, as explained below. The screenshot's SPF example is not a universal policy for every account.
DKIM CNAMEs: preserve their exact owner and target. General help describes TXT records, but the issued-record screenshot uses CNAMEs pointing to provider-managed DKIM data. Do not convert them into a generic public-key TXT record.
DMARC CNAME, if issued: inspect its resolved policy and agree on who will maintain it. It cannot coexist with an existing DMARC TXT at the same owner, and must not silently weaken an inherited policy or introduce unapproved report recipients.
MX: compare the complete issued numeric-priority/target set at the exact sending-domain owner with the organization's approved inbound routing plan before publishing or activating. Resolve any difference first. MX changes route incoming mail; adding one matching record while leaving unrelated old MX targets is not a verified migration.

The screenshot contains _adsp and _report aliases. ADSP is Historic, not a modern DKIM or DMARC prerequisite, as the RFC Editor's RFC 5617 status shows. Ask kajomi what any such rows in your current packet are for. Do not copy obsolete policy rows merely because an old screenshot includes them, or silently invent an alternative packet that kajomi has not approved.

Map full owners correctly

These examples explain name fields, not tenant-specific records to publish:

Full owner: SELECTOR._domainkey.news.example.com
Parent zone example.com: SELECTOR._domainkey.news
Delegated child zone news.example.com: SELECTOR._domainkey
Full DMARC owner: _dmarc.news.example.com
Parent zone example.com: _dmarc.news
Delegated child zone news.example.com: _dmarc

Use the actual issued selector. Some panels append the zone automatically; others expect a full hostname. Avoid duplicated suffixes. If _domainkey.news.example.com is separately delegated, publish through its actual authority rather than adding a shadow record in the parent. Preserve selectors used by other senders and any existing NS delegation.

At a CNAME owner, do not add TXT, A, AAAA, MX or a second different CNAME. A CNAME target is a hostname, not an HTTPS URL. If an issued owner conflicts with existing data, resolve it with the DNS owner and kajomi first. RFC 1034 section 3.6.2 defines the alias restriction.

For Cloudflare CNAMEs, use DNS only and turn Flatten off for each issued alias where that per-record control is available. Check whole-zone flattening, apex handling and same-zone-target behavior too: none of the applicable settings should conceal the required CNAME answer. DNS only alone does not guarantee this. Coordinate any shared-setting change with the DNS administrator and kajomi, preserving delegated namespaces and unrelated records. Do not disable unrelated global features to fix one alias. See proxy status and flattening behavior.

Protect SPF and DMARC policy

Keep SPF at the domain actually evaluated

SPF evaluates SMTP MAIL FROM, normally reflected in the received Return-Path, not automatically the visible From. Kajomi's SPF and DKIM explanation distinguishes that envelope identity. Selecting the list Return-Path is therefore separate from publishing a record and selecting the From address.

For manual DNS, keep one v=spf1 TXT policy per evaluated owner. Retain legitimate existing senders and reconcile the current account instructions into that policy instead of adding a second SPF record. If the issued policy contains a or mx, confirm that authorizing those addresses is intended. Do not copy the screenshot's qualifier or change an existing qualifier casually; SPF fail and softfail are not guaranteed rejection or delivery decisions.

Check the 10 evaluated DNS-dependent term limit, including nested terms reached through include or redirect, not just ten visible includes. Adding any all mechanism disables an existing redirect= policy, so preserve the redirected authorizations through an administrator-reviewed design rather than appending a new ending. RFC 7208 defines these rules.

Preserve the effective DMARC policy before delegation or aliasing

Determine the policy that applies to the intended From, including relevant ancestor policy. Record enforcement, alignment modes and authorized reporting destinations before changing DNS. If kajomi manages policy through a CNAME or delegated zone, compare the resolved result with the approved policy and settle any discrepancy before switching traffic. Do not add a competing TXT at a CNAME owner or downgrade enforcement to clear a warning.

Only where no direct or inherited DMARC policy applies, and the owner approves a first monitoring policy with a review plan, may this minimal example be used in an administrator-managed TXT configuration:

Type: TXT
Full owner: _dmarc.news.example.com
Relative name in parent example.com: _dmarc.news
Relative name in delegated news.example.com: _dmarc
Value: v=DMARC1; p=none

This is not an additional record to place beside an issued DMARC CNAME. If kajomi manages that owner, arrange the approved policy through that management path. A missing child record alone does not exclude inheritance; resolver failures do not establish absence. See RFC 9989.

The minimal record requests no reports. Before adding rua, approve the recipient, access and retention arrangements, including any destination introduced by a provider-managed policy. Aggregate reports can reveal infrastructure and traffic patterns.

Under RFC 9990 section 4, compare the Organizational Domain where the policy was found with the Organizational Domain of the report URI's host. Different Organizational Domains require the report-generating receiver to check DNS authorization; the same Organizational Domain is excepted even when hostnames differ. An external recipient normally provides v=DMARC1 authorization at POLICY-DOMAIN._report._dmarc.REPORT-DESTINATION-HOST. Obtain its exact instructions. This protocol check is separate from your organization's data-sharing decision.

Complete domain activation

Check the approved DNS against both authoritative servers and a public resolver. Replace uppercase placeholders in these read-only templates:

dig @PARENT_AUTHORITATIVE_SERVER CHILD_DOMAIN NS +noall +answer
dig @CHILD_AUTHORITATIVE_SERVER CHILD_DOMAIN SOA +noall +answer
dig @AUTHORITATIVE_SERVER FULL_ISSUED_OWNER ISSUED_TYPE +noall +answer
dig @PUBLIC_RESOLVER FULL_ISSUED_OWNER ISSUED_TYPE +noall +answer
dig @AUTHORITATIVE_SERVER FULL_ISSUED_ADDRESS_OWNER A +noall +answer
dig @PUBLIC_RESOLVER FULL_ISSUED_ADDRESS_OWNER A +noall +answer
dig @AUTHORITATIVE_SERVER FULL_ISSUED_MX_OWNER MX +noall +answer
dig @PUBLIC_RESOLVER FULL_ISSUED_MX_OWNER MX +noall +answer

The first two checks apply to delegation; use the issued types for manual records. Before activation, compare answers from both authoritative DNS and the recursive resolver at each exact full owner with the current account packet and the separately approved routing plan. The A answers must match the complete approved address set; the MX answers must match the complete approved numeric-priority/target set, with no unexpected destination, missing record or leftover route. A nonempty answer or one matching target is insufficient. Also check the ownership token, SPF and complete CNAME chains, including the resolved DMARC policy. For empty answers, inspect the full response without +noall +answer to distinguish negative answers, delegation faults and resolver failures.

After DNS validates and Hinzufügen succeeds, wait for pending_add to become active. The approximate 20-minute interval is not a guarantee. Confirm the domain's DKIM, SPF and MX indicators as well as its activation state; the documented domain list can show an active domain with failing checks. A green indicator remains account-side evidence, not proof of a specific delivered signature.

Select the list Return-Path and sender

Apply the active domain to the intended list

The Return-Path instructions call the page System → Domain-Konfiguration. The current supplied screenshots label it System → Allgemein, with the Allgemein tab. Look for the table containing List-URL, Return-Path, Mailserver, DKIM and SPF.

Choose the correct row. The first Default row affects every list without an individual override; editing it is a wider change than editing one list.
Open the row and select the intended active List-URL and Return-Path from their controls.
Select Speichern (Save). Kajomi documents a short test, usually 5–10 seconds.
Check individual list overrides. Grey rows inherit the default; Default wiederherstellen restores inheritance only when that is the intended outcome.

The screenshot's Mailserver field does not establish an external-SMTP setup procedure. Do not populate it with an unrelated server as a workaround. Record the selected Return-Path for comparison with the actual message later.

Activate forwarding before selecting a new From

Kajomi's sender requirements require both an active domain and an email forwarding address. Follow its forwarding procedure:

Open E-Mail Weiterleitungen in the same System area. The screenshots show System → Allgemein → E-Mail Weiterleitungen; the prose uses Domain-Konfiguration.
Select Hinzufügen. Enter the sender's local part, select its active domain, and enter the mailbox that should receive forwarded replies.
Use an existing, monitored destination approved to receive those messages. This creates a mail-forwarding relationship, not merely a display label.
Wait for activation, normally around 20 minutes. The new sender cannot be assigned until successfully activated.
Open Verwaltung → Verteiler, select the intended list, and choose the activated address in Absender-Adresse, following the list sender procedure.

Do not assume domain activation changed existing lists' From or Return-Path. Verify both settings, and test reply handling separately with approved recipients.

Verify a native list message

Send a new message through the actual kajomi list configuration to controlled recipients. Do not use a forwarded old sample or mail sent by a different application. Collect:

The actual visible From domain and the list configuration used.
The receiver's actual smtp.mailfrom identity and SPF result, compared with the selected Return-Path.
The intended kajomi signature's d= signing domain and s= selector from the same DKIM-Signature field.
A trusted receiver's dkim=pass for that intended signature, aligned to the intended branded From.
A trusted dmarc=pass for that From domain.

Use EmailAuth's selector guide to query SELECTOR._domainkey.SIGNING-DOMAIN. Interpret each signature individually. A CNAME ultimately supplies public DKIM data; its existence does not prove the signing key was used on this message.

Relaxed alignment compares Organizational Domains; strict aspf=s or adkim=s requires exact equality for that mechanism. For example, a child Return-Path domain can relaxed-align to a parent From without strictly matching it. Do not infer alignment merely because the list table shows SPF Pass or DKIM Ja.

A DMARC pass supplied by SPF alone does not validate the intended branded DKIM setup. A rewritten provider-owned From is not success for your requested company identity.

Use receiver-controlled authentication diagnostics, or have the receiving mail administrator establish which Authentication-Results fields were produced inside that service's known processing boundary. Confirm its documented handling strips or reliably distinguishes externally supplied result fields, and ignore untrusted or attacker-supplied fields. Neither a familiar authserv-id string nor header position establishes provenance. If the boundary cannot be established, repeat the controlled test at a receiver with trustworthy diagnostics rather than accepting those headers as proof. See RFC 8601 section 7.1.

Troubleshooting and safe rollback

Hinzufügen will not complete: compare the current issued packet with authoritative DNS. Check owner spelling, record types, delegation, MX, collisions and cached answers; do not paste the documentation tenant's values.
Domain stays pending: verify DNS and the account's activation status, then ask kajomi to investigate if the documented interval passes without progress. Do not repeatedly delete and recreate it.
From address is missing: confirm both the domain and its forwarding address are active, then check the correct list's sender dropdown.
The wrong Return-Path remains: inspect the list override versus the Default row. DNS activation does not replace list-specific settings.
DKIM is absent, fails or is unaligned: check the native route, selected From, observed selector and signing domain. Compare resolved key data, then investigate signing configuration or message modification if DNS is correct.
SPF fails while DMARC passes: investigate separately. fail or softfail concerns authorization; temperror means transient evaluation trouble; permerror can involve syntax, duplicate policies or lookup-budget faults. A passing but unaligned SPF identity is different from SPF failure.
Mail authenticates but lands in spam: review reputation, consent, content and recipient filtering. Older marketing claims about automatic configuration are not an inbox guarantee.

For rollback, pause affected list sends and preserve current evidence. Restore a previously approved list-specific sender or Return-Path only if it remains active and validated. Reversing DNS authority or MX needs an explicit plan that preserves records, reply routing and security dependencies at the restored authority. Do not delete a delegated domain, forwarding address or selector while queued mail or other lists still depend on it. Retest after cache expiry and after any restored account configuration becomes active.

kajomi MAIL SPF, DKIM and DMARC setup, step by step

On this page