Start Smaily authentication by verifying ownership of your sending domain, then publish the SPF authorization and both DKIM CNAMEs. Run the authentication check in the account's Domains tab and verify a real delivered campaign. Ownership verification, DNS authentication and DMARC alignment are separate checks: passing one does not prove the other two. Smaily ownership prerequisites, Smaily SPF and DKIM setup.
Which Smaily sending route are you configuring?
The steps below cover the standard Smaily account's sending-domain workflow for newsletters and marketing automation. They apply to the domain in the sender's email address, not merely the website URL or the account's login subdomain.
Smaily also offers Smaily Transactional, with a different interface and sending IPs from marketing campaigns, and API/SMTP access. Do not assume that authenticating a marketing account proves a transactional integration uses the same signer, envelope identity or activation state. Obtain the transactional account's current domain instructions and validate that route separately. A campaign API call and a dedicated transactional SMTP integration are not interchangeable authentication tests. Smaily Transactional product description.
Record the exact account, From address, sending route and DNS administrator. If several Smaily accounts share a domain, identify their owners before choosing the verification method. That coordination matters because changing ownership verification can affect other accounts.
1. Verify ownership before the first send
Smaily requires sender-domain ownership verification before campaigns, automations and API sending workflows can proceed. In the account menu, open Preferences, then Domains, choose Verify Domain, and add the domain. The documented methods are an email confirmation link or a DNS token. Domain ownership workflow.
DNS token verification
Use the DNS verification option to obtain the exact TXT value generated for this account. It begins with smaily-domain-verification-key; copy the complete value from the modal, not a token from another account or an example guide. Publish it at the domain being verified and return to Verify domain.
For example.com, the intended owner is example.com. The DNS panel may represent that as @ or a blank name. If verifying news.example.com inside the parent zone, the relative owner is news; @ in that parent zone would verify a different name. Match the full owner shown for the domain.
Keep the token after verification. Smaily periodically checks it, and removing it can revoke verification. If multiple Smaily accounts legitimately use the domain, each needs its own unique TXT token. These separate ownership TXT records can coexist with a single SPF policy; they must not be merged into the SPF text. Persistent and per-account token requirements.
Keep the account’s technical-contact email current and monitored: Smaily says ownership-verification problems are sent there. That notification is a prompt to investigate, not permission to remove another account’s token. Ownership monitoring
Coordinate before switching methods: activating DNS ownership verification revokes previous email-link ownership verifications in other Smaily accounts. Arrange the required DNS tokens for those legitimate accounts rather than unexpectedly interrupting their sending.
Email-link verification
The email method requires access to a working inbox on the same domain. Complete the confirmation received there; the documented link validity is seven days. Smaily recommends DNS-based verification as the stronger ownership control. An email-link confirmation establishes the account's permission to use the domain, but it does not publish SPF or enable a passing branded DKIM signature. Verification options and consequences.
2. Publish the two DKIM CNAMEs at the correct owners
For a standard sending domain of example.com, Smaily documents both of these records:
| Relative host in example.com | Full owner | Type | Target |
|---|---|---|---|
blue.smly._domainkey |
blue.smly._domainkey.example.com |
CNAME | blue._dkim.smaily.com |
green.smly._domainkey |
green.smly._domainkey.example.com |
CNAME | green._dkim.smaily.com |
Publish both aliases. These are the shared values in Smaily's public authentication guide, not tenant-generated public keys. If the account or Support supplies a different configuration for your product, resolve that difference before publishing. Official Smaily DKIM values.
The selectors are blue.smly and green.smly. The _domainkey label is the key-lookup namespace, not part of the selector itself. A delivered signature with s=blue.smly and d=example.com leads to blue.smly._domainkey.example.com. Use the s= and d= from the same signature when investigating. DKIM key lookup.
For a sender at news.example.com, the full names belong under that sending domain when it is the domain being configured. For example, blue.smly._domainkey.news.example.com is entered as blue.smly._domainkey.news in the parent example.com zone, or blue.smly._domainkey in a delegated news.example.com zone. Do not inadvertently publish the records one level too high.
If _domainkey.news.example.com itself is delegated, full blue.smly._domainkey.news.example.com uses relative blue.smly in that zone; the green selector uses green.smly. Preserve that NS delegation and use its actual operator rather than creating an inactive parent-zone record. A full-name field takes the complete owner. DNS zone boundaries.
Keep these as CNAMEs. Do not generate a replacement DKIM key pair, copy the provider's current TXT key into your zone, or publish a private key. The supported alias allows Smaily to manage its public-key endpoint.
Where the issued authentication or return-path records require literal CNAME answers, use DNS-only aliases returning the exact targets, without an HTTP proxy or flattening hiding them. Turn the relevant per-record Flatten control off when available and ensure applicable zone settings preserve those aliases. Cloudflare documents that flatten-all cannot be overridden per record, apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are conditional DNS-host behaviors, not assumed controls in every panel. If mandatory apex/same-zone behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration with the DNS owner and sender. Do not blindly change the whole zone or remove an existing delegation. CNAME verification, flattening controls and limits.
3. Add SPF without replacing other senders
Smaily's public guide specifies this authorization mechanism:
include:_spf.smaily.com
Add it once to the existing SPF policy at the domain the standard Smaily setup asks you to authenticate, before the policy's terminal all mechanism. Preserve other approved senders and the existing qualifier. Do not create a second TXT record beginning with v=spf1. Smaily SPF instructions.
If there is no SPF record, inventory the domain's other sending systems before creating one. A domain used only for this approved authorization might use the following illustrative policy, but a shared business domain normally needs additional authorized sources:
v=spf1 include:_spf.smaily.com ~all
The provider's example also contains a and mx. Those mechanisms authorize the addresses of the domain's host and mail exchangers; do not add them unless those systems genuinely need to send with that envelope domain. Do not replace an established -all with ~all merely because an example uses softfail.
If the existing SPF policy uses redirect=, reconcile its authorizations and terminal behavior with the DNS owner before changing it. Any all mechanism makes redirect ignored regardless of their order. Do not append all automatically: preserve the redirected senders and approved policy semantics through a reviewed design. SPF all and redirect processing.
An SPF include does not prove SPF alignment
SPF checks the SMTP MAIL FROM domain. The receiver usually records it as smtp.mailfrom, with the return path visible in the delivered message. A TXT record at your visible From domain cannot control SPF for an unrelated provider-owned envelope domain. Smaily's public authentication page does not establish a universal custom-return-path configuration, so do not invent one or promise that the include makes SPF align. SPF identity rules.
Plan to verify the actual envelope identity after sending. SPF may pass for a provider identity while branded DKIM supplies the aligned authentication needed by DMARC. A nonaligned SPF pass is different from a genuine SPF error, and the two require different responses.
Before saving a policy, evaluate the full recursive SPF chain. There is a limit of ten lookup-causing terms during evaluation, not ten visible includes in the top-level string. Do not paste a snapshot of Smaily’s IP addresses as an unmanaged workaround. SPF evaluation limit.
Protect existing DNS and domain policies
Use the DNS host serving the authoritative nameservers, which may differ from your registrar or web host. Save the original values and TTLs before editing. The following guardrails prevent common breakages:
- Preserve unrelated TXT verification tokens, MX records and DKIM selectors used by other systems.
- Inspect both Smaily selector owners for conflicts. A CNAME must not share its owner with an ordinary TXT, A or MX record.
- Check the DNS panel's automatic domain suffix. Enter either the expected relative name or a full name according to that panel's rules, not a duplicated combination.
- Use plain hostname targets, not a URL or pasted smart quotes. Retain a final dot where the DNS host requires it for an absolute target.
- Disable web proxying on authentication aliases when that option exists. DNS-only publication is not a website redirect. Keep the requested CNAME unflattened. Cloudflare authentication-CNAME guidance.
- Keep the ownership TXT tokens separate from the single SPF record. Several TXT records at the domain are normal; several SPF policies at the same owner are not.
If ownership verification succeeds but DKIM fails, do not delete the ownership token while troubleshooting. If a selector name already belongs to another integration, stop and ask the administrator and Smaily for a supported resolution rather than overwriting it.
4. Check DNS publicly and run Authenticate in Smaily
These are read-only query examples. Replace example.com with the exact domain being authenticated:
dig +short NS example.com
dig +short TXT example.com
dig +short CNAME blue.smly._domainkey.example.com
dig +short CNAME green.smly._domainkey.example.com
dig +short TXT blue.smly._domainkey.example.com
dig +short TXT green.smly._domainkey.example.com
dig +short TXT _dmarc.example.com
At the domain owner, expect the account-specific ownership token and only one v=spf1 policy if SPF is configured there. Unrelated TXT records are not duplicates of SPF. For DKIM, confirm both exact CNAME targets and usable public-key data reached through each alias. A successful CNAME query without a usable downstream key is not enough.
To check what the DNS host is actually serving, replace the nameserver placeholder below with one of the domain's authoritative nameservers:
dig @ns1.dns-host.example example.com TXT +noall +answer
dig @ns1.dns-host.example blue.smly._domainkey.example.com CNAME +noall +answer
dig @ns1.dns-host.example green.smly._domainkey.example.com CNAME +noall +answer
Use the appropriate delegated zone for a subdomain. Compare these answers with a recursive resolver. A wrong authoritative answer needs a correction; an old recursive answer may reflect TTL or negative caching. No fixed waiting period can repair a typo or a record in the wrong zone.
In Smaily's account settings, open Domains and choose Authenticate beside the domain. The provider advises refreshing after 15 to 20 minutes. If it still shows Unauthenticated after roughly half an hour, click that text to see which records are missing. A successful check displays Authenticated with a green checkmark. Smaily authentication status workflow.
Treat ownership status and authentication status as separate fields. Neither is a received-message test, and a valid domain does not by itself resolve unrelated account or campaign restrictions.
5. Preserve DMARC and set up useful reporting
DMARC needs either SPF or DKIM to pass with a domain that aligns with the visible From domain. Relaxed alignment uses the organizational-domain relationship; strict alignment requires identical domains. A DKIM signature for example.com and a From domain of news.example.com may align under relaxed mode but not under adkim=s. Confirm the policy that actually applies, including any inherited parent policy. Current DMARC alignment specification.
Do not replace an existing DMARC record with a new Smaily-specific record. Retain its policy, alignment settings, reporting destinations and intended subdomain treatment. In particular, do not downgrade p=quarantine or p=reject to compensate for an unauthenticated campaign.
Only if no direct or applicable inherited DMARC policy exists, and the domain owner approves this first policy and a monitoring/review plan, a first TXT policy may use the following example. Provision the approved reporting destination before publishing it:
Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Replace the example reporting mailbox with a working destination your organization authorizes. p=none requests monitoring without DMARC-specific enforcement; it is neither a spam bypass nor an inbox promise. Review legitimate Smaily traffic and all other senders before enforcement.
For a first policy at full owner _dmarc.example.com, a relative-name field in zone example.com takes _dmarc. For a deliberately approved child policy at _dmarc.news.example.com, use _dmarc.news in the parent zone or _dmarc in a separately delegated news.example.com zone. A full-name field takes the complete owner. These examples do not authorize overriding an inherited policy.
Compare the Organizational Domain of the aggregate-report URI's host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as the policy domain is excepted; a different hostname alone does not make it external. Obtain the reporting operator's exact authorization instructions when required. This protocol check is separate from the domain owner's approval to share report data; agree access, retention and privacy. RFC 9990 section 4.
Before a separate domain-wide move to p=reject, follow RFC 9989 section 7.4: legitimate outbound mail needs valid DKIM, and indirect-mail interoperability, including forwarding and mailing lists, needs review. Completing this sender alone does not authorize enforcement for every route.
6. Accept the configuration only after a real campaign test
Have an authorized operator send from the configured Smaily account to controlled external mailboxes. Use the real campaign route and exact From domain; a template preview or a message from your normal mailbox is not a substitute. Test an automation separately if it has a different sender or route.
Open the original received message.
Establish which results were generated inside the receiving service's known processing boundary and how it removes, ignores or distinguishes externally supplied Authentication-Results. Use receiver-controlled diagnostics or have the receiving-mail administrator confirm its documented handling. A familiar authserv-id string or header position alone is not proof. Ignore attacker-supplied or otherwise untrusted fields; obtain authenticated receiving-system evidence when provenance is uncertain. Receiver-result trust.
The acceptance record should contain:
| Check | What must be established |
|---|---|
| Sender | The intended From domain survived the sending process |
| Branded DKIM | The intended Smaily customer-domain signature reports dkim=pass and its d= aligns with From under the applicable mode |
| Selector | The relevant s= and d= identify the key actually used, rather than a guessed selector |
| SPF | The actual smtp.mailfrom and SPF result are recorded, with alignment assessed separately |
| DMARC | The trusted receiver reports dmarc=pass for the intended From domain |
| Workflow coverage | Representative campaigns and materially different automation/API paths were checked |
One selector may sign a message while both are published. Do not require both signatures on every email, and do not accept a provider-owned signature as proof of branded DKIM. A DMARC pass through SPF alone still leaves your DKIM work unproven.
If SPF passes for an unrelated envelope domain, document that it is unaligned and verify that branded DKIM supplies the DMARC pass. If SPF returns fail, softfail, none, permerror or temperror, investigate it rather than dismissing it because DKIM passed. Query the actual envelope owner and establish whether your DNS administrator or Smaily controls its policy. Give Support sanitized headers and the send time for provider-controlled failures. Do not add unrelated includes to the visible From domain.
Diagnose SPF at the actual envelope owner independently even when aligned DKIM supplies DMARC. For fail or softfail, compare the observed connecting source and MAIL FROM identity with the approved authorization and sending route. For permerror, check duplicate SPF policies, malformed syntax and the full nested DNS-dependent term budget. For temperror, investigate temporary DNS resolution or availability failures and retest after recovery. A provider-owned SPF pass without alignment is different from these failures; escalate errors for provider-owned identities to that sender rather than editing unrelated apex DNS. SPF result definitions.
Keep the original test evidence, account status and DNS answers together. A future campaign using another From domain must be validated on its own.
Before changes, agree which affected campaigns or automations may be paused and who can restore the approved prior route. Restore only a route whose account ownership and authentication still work; retain all shared account tokens and keys needed by queued mail. Coordinate retirement with dependent senders and retest after DNS, account or product-route changes. Do not assume a campaign configuration can restore the separate Transactional product.
Troubleshooting common Smaily failures
Domain ownership was verified, but Authenticate fails
Ownership tokens establish permission to use a domain. Authentication checks look for the separate SPF and DKIM configuration. Open the missing-record detail, then query those exact public owners. Do not treat the presence of a token as a substitute for either DKIM CNAME.
Another account stopped sending after DNS verification
Check whether that account previously used email-link verification. Smaily documents revocation of those verifications in other accounts when DNS verification is activated. Coordinate a unique DNS token for each authorized account. Do not remove the new token to restore an insecure or undocumented state without the domain owner's review.
Only one Smaily DKIM CNAME is present
Add the missing documented record after checking for owner conflicts. Both are required by the standard setup. A message that currently passes using one selector does not prove the incomplete configuration will remain healthy.
DNS looks right, but there is no branded DKIM signature
Check the actual From address, account and sending route. Confirm the domain is authenticated in that account and ask Support to investigate activation. If the message came from Smaily Transactional, validate its separate setup rather than assuming the campaign configuration covers it. See finding the selector from message evidence.
SPF says permerror after adding Smaily
Look for duplicate v=spf1 records, an include inserted after all, malformed text or an excessive recursive lookup budget. Preserve unrelated TXT tokens and authorized senders while fixing the specific problem. A permanent policy error needs a policy correction; repeatedly clicking Authenticate is not a fix.
DKIM passes, but DMARC still fails
Compare the passing signature's d= with the real From domain, and check strict versus relaxed alignment. DNS publication under example.com does not prove a message sent as news.example.com meets a strict policy. Do not loosen alignment without reviewing the domain's trust requirements.
Verification note
This is a documentary guide, not a report of a configured customer account. No DNS changes, account actions or test sends were performed. Account-generated ownership tokens, current route-specific instructions and delivered-message results must be verified during your implementation.