To send native Kundo Mail / Inbox replies from your own address, confirm the inbox address, open Settings > Send & receive > Use sender address, and publish the DNS records issued there. The documented example contains an SPF TXT record, a DKIM TXT key and two MX records on a dedicated child domain. After every check turns green, complete Activate or the support-activation step shown in your account. Then verify a newly delivered reply, not just the DNS indicators. Kundo whitelabel procedure.
This guide covers that native whitelabel route. It does not configure external SMTP, the Microsoft Graph inbound upgrade, unrelated forum/chat notifications or Paloma pages hosted on Kundo. Kundo's current website uses Ticketing, while its operational guide retains Mail and Inbox labels. Follow the controls for the actual channel, not a name-based assumption about another product.
No account, DNS, forwarding, activation, support request or email test was performed.
What changes when whitelabel is activated?
Kundo's example starts with inbox jobb@example.com but sends from jobb.example.com@mail.kundo.se before whitelabel. After activation, new outgoing mail uses the inbox address. This is a visible sender change, not merely an invisible DNS improvement. Mail can work without whitelabel, but a passing message from the provider's rewritten address does not prove your own domain is authenticated. Before and after behavior.
The guide says the DNS work is once per domain, so adding another inbox on that domain should not require duplicating the same records. Still verify each intended inbox's address and a new reply. The public instructions do not establish one universal runtime MAIL FROM or DKIM signing domain, nor an exact whitelabel plan tier. Confirm missing controls with the account administrator or Kundo rather than guessing an upgrade.
Confirm the correct inbox before requesting DNS changes
- Open the main menu and choose Settings for the intended channel.
- Open Basic Settings and check the receiving email address. Also check the inbox name and sender name so the test represents the intended identity.
- Save the intended settings. Repeat for each inbox.
- Identify the channel operator, DNS administrator, routing owner and person who will review the received-message evidence.
These are the provider's inbox-address preparation steps. Use authorized channel access; do not grant broader user permissions just to follow the guide.
Capture the current From behavior, all records at the proposed child domain and selector, applicable DMARC policies and existing routes. Agree a recovery plan before activation. A child name can already serve another application even though Kundo uses a subdomain to reduce conflicts.
Copy the complete issued record set
Open Settings > Send & receive > Use sender address for the inbox. Give the authorized DNS administrator the exact full owners, record types, values and MX priorities shown by that account.
Kundo's official screenshot illustrates four checks:
- One SPF TXT policy at a child domain.
- One DKIM TXT public-key record beneath that child domain's
_domainkeynamespace. - Two MX records at the child owner, each with its specified priority and destination.
The illustration uses a child such as mgeu.example.com and Mailgun infrastructure. Those are not universal Kundo records. Copy your current values, not the screenshot's public key, selector, region or MX targets. Do not substitute a Mailgun dashboard workflow or add an apex include merely because Mailgun supplies infrastructure. Issued-table source.
SPF belongs at the issued owner
SPF normally evaluates the SMTP MAIL FROM domain and connecting IP, not the visible From or Reply-To. For a null reverse path, the relevant identity is HELO. A parent SPF record does not automatically authorize a child. Publish the account's SPF requirement at its exact owner, then check the actual envelope on delivered mail. SPF identities.
If the owner already has SPF, reconcile the required authorization into one policy while preserving legitimate senders and its approved qualifier. Do not add another v=spf1 record or replace a shared policy with the tutorial example. Multiple unrelated TXT records are allowed; competing SPF policies are not. EmailAuth's multiple-SPF-record guide explains that distinction.
Check the maximum ten evaluated DNS-dependent terms, including nested processing, not ten visible includes. Any all mechanism makes redirect ignored. If redirect currently authorizes other mail, preserve those legitimate authorizations and terminal semantics in a reviewed design instead of appending all blindly. A qualifier does not guarantee how every receiver will deliver or reject mail. SPF evaluation limit, all and redirect.
Publish the complete public DKIM TXT value
Preserve the complete tagged public value exactly as issued. Long TXT data can be represented by multiple quoted character strings within one logical record; the strings concatenate without added spaces. Do not create separate conflicting key records, expose a private signing key or replace another service's selector. DKIM key publication.
This documented native route uses TXT for DKIM. There is no instruction here to convert it into CNAME or to change proxy/flattening settings intended for aliases. If the proposed TXT owner already contains a CNAME, stop and resolve the collision with the DNS and service owners rather than deleting the existing record.
Approve both MX records as routing, not just verification
Copying an issued MX pair is not authorization to change incoming-mail routing. Obtain the routing owner's approval for the exact full child owner and complete numeric-priority/target MX set before publication or activation. Compare it with current use of that owner. Preserve corporate root MX and any unrelated mailbox or bounce service.
Publish the approved complete set, not only the first row. At verification, compare every priority/target tuple at the authoritative servers and recursive resolvers with the approved plan. Extra, missing or different tuples are stop conditions. A nonempty MX answer or one green row is not acceptance.
Map full DNS owners to the actual authoritative zone
These are naming examples only. Replace SELECTOR and the illustrative child with account-issued values.
- Full SPF/MX owner
mgeu.example.comis relativemgeuin the parentexample.comzone, or@in a separately delegatedmgeu.example.comzone. - Full DKIM owner
SELECTOR._domainkey.mgeu.example.comisSELECTOR._domainkey.mgeuin the parent zone, orSELECTOR._domainkeyin the delegated child zone. - If
_domainkey.mgeu.example.comis itself delegated, publish relativeSELECTORat that delegated authority.
Preserve NS delegations and active selectors. A dormant record below a delegation in the parent zone is not the authoritative answer. Confirm the final full owner after the editor appends its suffix, avoiding a doubled domain name. DNS zone boundaries.
Keep the applicable DMARC policy and reporting
DMARC protects the actual visible From domain. Inspect its direct record and any applicable inherited policy before changing anything. The SPF/DKIM child shown by Kundo does not automatically determine where your From domain's DMARC policy belongs. Preserve enforcement, alignment modes and authorized reporting recipients.
Only when no direct or applicable inherited policy exists, and the domain owner approves an appropriate monitoring plan, consider this first-record example:
Type: TXT
Full owner for From example.com: _dmarc.example.com
Relative host in example.com zone: _dmarc
Illustrative value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Replace the example recipient with an approved operational destination. For From support.example.com, the full local-policy owner is _dmarc.support.example.com: relative _dmarc.support in the parent zone or _dmarc in a separately delegated support.example.com zone. Do not add a child policy to override inherited protection, duplicate an existing record or lower enforcement to make setup easier. DMARC policy discovery.
Compare the report destination URI host's Organizational Domain with the Organizational Domain of the domain where the policy was found. A different Organizational Domain requires the report-generating receiver to check DNS authorization; the same Organizational Domain is excepted. This protocol check does not replace the owner's approval to share report data. Aggregate-report authorization.
Relaxed alignment allows a shared Organizational Domain; strict alignment requires an exact match. A signature for mgeu.example.com would not strictly align with From example.com. Do not infer actual signing or strict alignment solely from the published owner. Test the issued route under existing adkim and aspf, and resolve a mismatch with Kundo rather than weakening policy.
Verify DNS, then complete activation
Use exact issued owners in these read-only command patterns. Replace every uppercase placeholder; no output below is fabricated.
dig @AUTHORITATIVE_NS ISSUED_CHILD_OWNER TXT +noall +answer
dig @AUTHORITATIVE_NS ISSUED_DKIM_OWNER TXT +noall +answer
dig @AUTHORITATIVE_NS ISSUED_CHILD_OWNER MX +noall +answer
dig ISSUED_CHILD_OWNER TXT +noall +answer
dig ISSUED_DKIM_OWNER TXT +noall +answer
dig ISSUED_CHILD_OWNER MX +noall +answer
Compare the full logical TXT values, single selected SPF policy and complete approved MX set at authority and recursive resolvers. Investigate wrong-zone publication, NXDOMAIN, SERVFAIL or an unexpected answer rather than treating every problem as propagation.
Return to Use sender address. Kundo says its checks can take 10 minutes to 24 hours to turn green; existing TTL and negative caching mean this is an estimate, not a deadline. When all checks are green, its prose instructs Activate, which double-checks records and changes new outgoing mail to the inbox sender.
The official green-check screenshot also contains a banner asking the user to contact support for activation. If your account presents that requirement, follow that support path and await confirmation. Do not assume the visible button overrides it or that four green checks alone mean signing and branded sending are active. Confirm the final whitelabel status before a new controlled reply. Activation and screenshots.
Prove the newly delivered native reply
Use a harmless test conversation and controlled valid recipients through the actual native inbox route. Avoid customer tickets, production notifications or sensitive content. Record the inbox/domain, activation time, intended and actual From, SMTP MAIL FROM, sending IP, every DKIM d=/s= pair and the receiver's SPF, DKIM and DMARC outcomes.
Use results produced inside the actual receiving service's known processing boundary, with its documented removal or exclusion of externally supplied Authentication-Results. If headers cannot establish that boundary, use receiver-controlled diagnostics or an administrator-confirmed trace. Matching authserv-id text or header position alone is insufficient; ignore attacker-supplied fields. Receiver trust.
Accept the branded route only when the intended Kundo signature passes, its observed d= and s= reconcile to the issued setup, it aligns with the unchanged intended From under the effective policy, and the trusted receiver reports dmarc=pass. An unrelated signature, rewritten provider From or SPF-only DMARC pass does not complete the DKIM test.
Record SPF separately. An unaligned provider-domain pass differs from a failure. At the actual envelope owner, fail/softfail calls for sender-authorization and route review; temperror indicates transient evaluation/DNS trouble; permerror points to permanent syntax, duplicate-policy or lookup-budget defects. Unexpected none calls for checking the identity and missing policy. Investigate errors even if DKIM makes DMARC pass. SPF result meanings.
Keep inbound forwarding separate
Kundo documents inbound forwarding as a separate final launch step, with Microsoft Graph as a separate upgrade. Outbound whitelabel success does not prove that incoming conversations reach the correct inbox. If launching forwarding, obtain separate approval of the exact destination copied from Basic settings > E-mail address on Kundo, the affected mailbox and any backup-copy handling. Test only that approved route with harmless content. Do not replace root MX or forward customer mail merely to test DKIM. Kundo inbound setup boundary.
Troubleshooting and frequently asked questions
Why does the sender still end in mail.kundo.se?
Check the correct inbox, completed activation and a newly generated reply. DNS checks alone do not change the sender. If support activation is requested, await that completion before declaring the branded route ready.
Can I add only a Mailgun include at my root domain?
No. Follow the complete issued Kundo table at its actual owners, including the public key and separately approved MX set. A root include neither selects the runtime envelope nor activates whitelabel.
Do all inboxes need duplicate DNS records?
Kundo says whitelabel DNS is once per domain. Confirm each inbox's settings and test representative replies; do not duplicate SPF or key records for another inbox on the same domain.
One MX check is green. Can I activate?
Wait for the complete issued set and all checks. Confirm the full MX tuples against the separately approved routing plan, not simply the existence of an MX answer.
What if DNS is correct but DKIM fails?
Compare actual signature domain/selector, issued public value and activation time. Investigate downstream message modification and wrong-route replies before regenerating keys or altering DMARC.
Does successful authentication guarantee delivery?
No. It establishes the observed message's identities, not reputation, content safety, every other inbox or guaranteed inbox placement. Retain the original approved state for recovery and retest after inbox, domain, DNS-host or sending-route changes. Coordinate any key retirement so active or queued mail remains verifiable.