Authenticate the domain you own and use in your Stibee sender address with one SPF TXT policy containing include:mail.stibee.com and a DKIM CNAME from stb._domainkey under that domain to dkim.stibee.com. Separately verify the sender email address in the address book, check the DNS status, and validate an actual controlled Stibee message. A saved sender address or a DNS lookup alone does not prove aligned signing.
This guide covers Stibee's documented hosted-email, owned-domain workflow, not an external SMTP service or a custom Return-Path feature.
On this page
- Scope and permissions
- Verify the sender address
- Publish SPF and DKIM safely
- Preserve or establish DMARC
- Check DNS and Stibee status
- Validate the delivered message
- Troubleshooting and recovery
- Frequently asked questions
- Sources and verification limits
Scope and permissions
Use a sender address on a domain your organization owns, with access to its authoritative DNS and permission to manage the relevant Stibee address book. Stibee's SPF/DKIM instructions expressly exclude domains you do not own, including gmail.com, naver.com and kakao.com. These instructions do not establish a universal subscription tier, regional variation or account-role name. Confirm your own permissions rather than assuming every workspace member can make changes.
Record the approved visible From address, sender domain, address book and existing DNS settings before starting. Coordinate with the domain owner and campaign owner. DNS access is not authorization to change campaigns, inbound mail routing or another team's authentication records.
For Gmail and Naver addresses, Stibee documents a separate fallback: it rewrites the sender to an address on send.stibee.com, such as example-gm@send.stibee.com or example-nv@send.stibee.com, without an additional conversion charge. That is not authentication of your own brand domain. Do not treat a passing result for that rewritten identity as completion of this guide.
Verify the sender address
Stibee configures sender addresses per address book. Its sender-address procedure gives these steps:
- Open the name of the intended address book.
- Choose Dashboard → Edit (
대시보드 → 수정하기). - Under Sender email address, choose + Add (
발신자 이메일 주소 → + 추가하기) and enter the approved address. - Complete the verification email sent to that address. It must be a working address whose mailbox you can access; a display name alone is not verified ownership.
- If the campaign owner wants this address used by default for newly created emails, choose Set as default (
기본값으로 지정하기). Otherwise, do not change the default merely to complete authentication. - Choose Save (
저장하기).
The workspace owner's email is initially the default sender, according to the documentation. Check the actual selected From on the intended campaign rather than assuming an address-book default updates every existing message.
Email-address verification and DNS authentication are different checks. The public procedure does not document a separate universal “Enable DKIM” switch. Do not invent one or assume a saved address proves that Stibee is signing with your domain.
Publish SPF and DKIM safely
Make changes at the DNS service authoritative for the sender domain, not automatically the registrar or web host. Export the existing zone records first. The following example uses example.com; replace it with the actual approved sender domain.
Sender domain: example.com
SPF owner: example.com
Type: TXT
New-policy example only: v=spf1 include:mail.stibee.com ~all
DKIM owner: stb._domainkey.example.com
Type: CNAME
Target: dkim.stibee.com
SPF: merge the authorization, not unrelated TXT records
Stibee specifies TXT, an apex host of @ or blank according to the DNS interface, and TTL 3600 or the DNS provider's default. Thus full owner example.com maps to that provider's documented apex input in the example.com zone. For an approved child sender domain news.example.com, its full SPF owner maps to news in the parent zone or the apex input in a separately delegated news.example.com zone.
If an SPF policy already exists at the intended owner, add Stibee's include:mail.stibee.com authorization to that single policy after reviewing the entire record. Preserve other legitimate senders and the owner's intended policy. Do not publish a second v=spf1 record. The vendor's wording about an existing TXT value must not be read as permission to merge SPF into an unrelated site-verification or other TXT record.
SPF evaluates the actual SMTP MAIL FROM domain, or HELO where applicable, not automatically the visible From domain. The vendor's sender-domain setup does not establish a universal custom MAIL FROM or Return-Path. Inspect the delivered message before claiming that this SPF policy was the one evaluated or that it aligns.
Evaluate the RFC7208 limit of 10 DNS-dependent terms, including nested mechanisms and redirects; this is not simply “10 includes.” An all mechanism causes redirect to be ignored. Preserve policy semantics when merging, and do not promise that ~all or -all dictates a receiver's final delivery decision.
DKIM: publish the literal CNAME at the correct owner
Stibee expressly publishes selector stb and target dkim.stibee.com in its current public prose. The CNAME owner is under the actual sender domain, not under Stibee's domain. Do not create a TXT record containing the target hostname or generate and upload a private key.
For example.com, full owner stb._domainkey.example.com is usually entered as stb._domainkey in the example.com zone. For news.example.com, full owner stb._domainkey.news.example.com is stb._domainkey.news in the parent zone, or stb._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com itself is delegated, coordinate with that authoritative namespace's owner; within that zone the relative owner is stb. Preserve existing NS delegations and shared signing dependencies.
Use your DNS provider's documented full-name or relative-name convention so the zone suffix is not added twice. The target must resolve as dkim.stibee.com, not as a hostname accidentally suffixed with your domain. At the CNAME owner, stop if conflicting TXT, A, AAAA, MX or another CNAME exists. Do not delete another service's selector or delegation without understanding its use and obtaining approval.
Use DNS-only behavior, not an HTTP proxy. Where flattening would hide the required CNAME, disable the applicable per-record flattening control when available and ensure applicable zone-wide settings do not suppress the alias. Consider same-zone and apex behavior, but do not globally change unrelated records. Cloudflare's current flattening guidance explains its controls and exceptions. If mandatory behavior cannot preserve the required literal alias, stop and coordinate a supported configuration with the DNS provider and Stibee rather than inventing a switch.
This workflow does not require changing your inbound MX, parent nameservers, DNSSEC, mailbox credentials or mail-forwarding destinations.
Preserve or establish DMARC
First discover the applicable DMARC policy, including inherited policy. Preserve existing protection, alignment settings and approved reporting destinations. Never replace a working policy with p=none simply because a tutorial includes it.
Only when no direct or applicable inherited policy exists, and the domain owner approves a first monitoring policy and monitoring plan, may this minimal example be appropriate:
Type: TXT
Full owner: _dmarc.example.com
Relative owner in example.com zone: _dmarc
Value: v=DMARC1; p=none;
For a child sender domain, full owner _dmarc.news.example.com maps to _dmarc.news in the parent zone or _dmarc in a separately delegated child zone. Do not create duplicate policies or overwrite an existing child policy. The example intentionally supplies no report address: add only a provisioned, monitored destination approved by the owner, with privacy and data-sharing implications reviewed.
Under RFC9990 section 4, compare the report destination's Organizational Domain with the Organizational Domain of the domain where the DMARC policy was discovered. A destination in a different Organizational Domain requires the report-generating receiver to verify DNS authorization; the same-Organizational-Domain exception applies even when hostnames differ. DNS authorization does not replace the owner's approval to share report data.
Stibee recommends allowing time for SPF/DKIM propagation before adding DMARC. Its stated 48-hour window is operational guidance, not a protocol requirement to leave a domain unprotected for 48 hours. Verify the actual configuration before changing policy. Use current RFC9989/9990 behavior rather than copying obsolete pct rollout advice, uppercase V=DMARC1 examples or deterministic inbox claims from older explanatory material. Enforcement should follow authorized inventory and monitoring of all legitimate senders, not one successful Stibee test.
Check DNS and Stibee status
Use read-only checks against the correct authoritative server and an independent recursive resolver. Replace all example domains and ns1.example.net with the actual authoritative DNS server. These are queries, not example results:
dig @ns1.example.net TXT example.com
dig @ns1.example.net CNAME stb._domainkey.example.com
dig @1.1.1.1 CNAME stb._domainkey.example.com
dig @1.1.1.1 TXT dkim.stibee.com
dig @1.1.1.1 TXT _dmarc.example.com
Confirm one valid SPF policy at the intended owner, the exact DKIM CNAME target, and a usable public DKIM key at the end of the alias chain. Follow any further aliases rather than accepting a CNAME's presence as proof of a usable key. For SPF, inspect the actual evaluated MAIL FROM owner from the subsequent message as well.
Stibee documents two status locations: Stibee Lab, or Address book → Dashboard → Sender email address (주소록 → 대시보드 → 발신자 이메일 주소). Check the intended domain. It allows up to 48 hours for status/DNS changes and directs users to support by email or the logged-in help/chat control if records still do not appear. A cached failure is a reason to compare authoritative and recursive answers, not repeatedly replace correct records.
DNS status confirms publication, not the signature on a delivered campaign. No Stibee account or customer-domain lookup was performed in preparing this guide.
Validate the delivered message
With the campaign owner's approval, send non-sensitive test content to controlled, valid recipients through the actual intended Stibee sending path and address book. Check the selected From immediately before the test. Do not use a customer list for diagnostics or assume a different preview path proves production behavior.
Read Authentication-Results generated inside the actual receiving service's known processing boundary, using that service's documented handling of externally supplied Authentication-Results. Familiar authserv-id text or header position alone is not trustworthy. Ignore attacker-supplied or otherwise untrusted result fields.
Accept the branded-DKIM setup only when:
- The intended Stibee DKIM signature passes, with its actual selector and signing domain inspected.
- That signing domain aligns with the approved visible From under the applicable DMARC alignment mode.
- The visible From remains the approved address, not a
send.stibee.comreplacement. - The trusted receiver reports
dmarc=pass.
Relaxed DKIM alignment permits the applicable Organizational Domain relationship; strict alignment requires the signing domain to match the From domain exactly. Do not infer either from the CNAME target. SPF alignment is evaluated separately against the actual MAIL FROM identity and its applicable relaxed or strict rule. A child envelope domain does not automatically meet strict alignment.
A DMARC pass obtained through SPF alone does not demonstrate that DKIM works. Conversely, aligned DKIM can yield a DMARC pass while SPF is failing. Investigate SPF fail, temporary DNS temperror, and policy/syntax/lookup-limit permerror separately rather than hiding them behind DMARC. See raw DKIM results versus aligned DKIM policy results for the distinction.
Troubleshooting and recovery
Sender cannot be selected: complete mailbox verification for the correct address book and save. Changing the display name is not email verification.
CNAME not found: check the full owner, zone suffix, authoritative delegation, conflicts, proxy and flattening behavior. Confirm the selector is stb, not a selector copied from another provider.
DNS looks correct but DKIM fails or is absent: inspect the actual message's signer, selector and path. Compare the selected sender with the authenticated domain. Preserve a redacted message sample and DNS evidence for Stibee; do not invent a separate activation toggle or paste a key from another service.
SPF fails: identify the actual MAIL FROM first. Check the correct owner, one-policy rule, authorized senders, evaluated lookup budget and DNS errors. Do not blindly add more includes to the visible From's apex.
DMARC fails despite DKIM pass: compare the passing signature's domain with the unchanged From and applicable alignment policy. A provider-domain signature or rewritten sender may pass without authenticating your intended identity.
A rollout disrupts sending: obtain the campaign owner's approval to pause affected sends. Compare the saved configuration, and with the appropriate owner's approval restore the previously known-good sender/DNS configuration where safe. Do not weaken DMARC or remove a selector still used by queued campaigns or another service. Retest both the failed path and a previously working path before resuming. A rollback is a coordinated change, not permission to delete shared records.
Sources and verification limits
Provider procedures were read in their current public Korean documentation, with the controls translated here and key original labels retained. The recovered pages did not expose a reliable publication/update date, so the documentary check date above is not presented as a vendor update date.
- Stibee: SPF and DKIM setup.
- Stibee: adding sender addresses.
- Stibee: DMARC setup and status, read alongside current standards where explanatory examples differ.
- Cloudflare: configure CNAME flattening.
- RFC7208: SPF, RFC6376: DKIM, RFC8601: Authentication-Results, RFC9989: DMARC and RFC9990: aggregate reporting.
The sender-add and Lab screenshots were unavailable for visual inspection. The procedure, record values and status paths above come from explicit authoritative prose, not inferred image content. No customer account, DNS change, actual send, rendered CMS page or live deployment was tested. Keep the final operational acceptance checks separate from this documentary guide.