Begin with the Smaily product and account
Smaily authentication requires a decision about both the sending domain and the account entitled to use it. Start by listing campaigns, automations and API-triggered marketing messages that use the domain. Record their business owner and the DNS administrator. A domain used by several brands or agencies needs a shared change plan before ownership verification changes.
Smaily also offers a separate transactional platform with a different interface and sending IPs, including SMTP and API options. Do not assume that a marketing-account check authenticates transactional invoices or application alerts. The reviewed product page establishes that separation, but not an account-specific transactional DNS recipe. Keep that route open for its own setup instructions and received-message evidence. Smaily transactional product description, Why use transactional emails and For developers.
This guide develops the documented account-domain workflow while preserving that boundary. It does not claim that any tenant, domain or message has already passed. If the original requirement includes the transactional service, the implementation cannot be accepted until that service is tested too.
Review the ownership change before authentication
The ownership guide places domain verification in Preferences > Domains. It supports email-link and DNS-token verification. Email verification links last seven days. DNS verification is preferred, and its token must remain published because Smaily rechecks it. Moving to DNS verification revokes earlier email-link ownership approvals in other accounts; each authorized account needs its own token. Smaily domain ownership guide, DNS verification.
Before approving that change, identify every account that legitimately uses the domain, including an agency account that might otherwise be easy to miss. Obtain the current token from the intended account. Record only the information necessary for the implementation ticket, with access restricted appropriately. Do not copy another account's ownership token or remove an unfamiliar one simply because it seems redundant.
Keep an owner for technical notifications and a backup contact. A mailbox used during initial setup can become unattended after a staff change. Review who can request a new sender identity as well as who can publish DNS. Ownership approval and message authentication are separate evidence rows: passing one should never silently close the other.
Publish the documented authentication records carefully
Smaily's authentication guide specifies include:_spf.smaily.com and two CNAMEs: blue.smly._domainkey to blue._dkim.smaily.com, and green.smly._domainkey to green._dkim.smaily.com. These are documented public records, not observations of this account’s DNS. Both DKIM entries are required. It then directs the administrator to the Domains tab and Authenticate; unresolved status can expose which records are missing. Obtain the current values from that official guide and account before changing DNS. Smaily authentication guide, SPF, DKIM and record checks.
Save the existing zone and prepare a record-by-record difference. Confirm whether the DNS editor expects a relative owner or a fully qualified name. After saving, inspect the resulting full owner name so an automatically appended domain does not create a duplicate suffix. A record visible in a management screen is insufficient if that screen is not serving the authoritative zone.
For SPF, preserve the other authorized senders in the one policy at the relevant owner. Do not paste a new complete policy over an existing corporate-mail policy. The evaluation limit includes nested DNS-querying terms, so count the complete dependency chain rather than counting only the visible includes. RFC 7208, sections 4.5 and 4.6.4.
Do not copy optional mechanisms from an example unless the domain owner actually intends to authorize the hosts they identify. Review the precise SPF owner against the envelope domain seen later in a real message. A provider's requested configuration check and the receiver's SPF identity answer different operational questions.
Confirm both DKIM records without guessing rotation
Resolve both issued DKIM owners and follow their CNAMEs to the public-key answers. Save the answers and the observation time. If one fails, investigate that record rather than assuming the other makes the configuration complete. Preserve existing selectors used by unrelated systems.
The public guide does not establish which selector a particular message will use or a promised key-rotation schedule. Test the signature actually present. A DKIM signature identifies its signing domain through d and selector through s; together they locate the key. RFC 6376, sections 3.5 and 6.1.
If the account check remains unsuccessful, compare the intended DNS values with authoritative answers before editing again. Record the provider's current status and any missing-record explanation. Avoid repeated changes while caches still hold the preceding version. Escalate a reproducible discrepancy with the record owners and timed observations, without sending account credentials.
Test the workflow that will send production mail
Use a harmless campaign and a representative automation to controlled external mailboxes. If API-triggered messages use another sender configuration, test that configuration separately. Give each test an identifiable subject and retain its Message-ID and UTC time. A preview or a direct message from a staff mailbox is not a substitute for the production sending route.
Preserve original headers from the receiving mailbox. Record the displayed From domain, Return-Path, SPF-authenticated domain, all DKIM d and s values, and trusted receiver results. Determine which passing identity aligns with the visible From under the domain's policy. DMARC needs a passing aligned SPF or DKIM path; an unrelated provider signature does not establish that result. RFC 9989, Identifier Alignment Explained and DMARC Evaluation.
Custom envelope-domain support remains unconfirmed by the reviewed Smaily setup pages. Do not invent a bounce CNAME or promise aligned SPF. If aligned DKIM supplies the pass, identify it explicitly. If the organization separately requires a particular envelope domain, obtain a supported Smaily configuration and test it before closing that requirement.
Diagnose ownership and delivery separately
An ownership failure points first to the approved account, verification method and retained token. A DNS-authentication failure calls for a comparison of the issued records with public answers. A received message with the wrong From identity calls for a workflow configuration review. These are different problems and should not all be treated by adding another SPF include.
If DKIM passes but mail lands in spam, examine reputation, recipient expectations and content separately. Authentication does not guarantee inbox placement. If DMARC fails, compare the actual domains and alignment modes before considering a policy change. Weakening the organization's existing policy to make one test deliver is not a completed implementation.
Record the handover and recovery plan
Use the Smaily ownership and route worksheet (create a separate review record with the fields described here). Maintain distinct rows for account ownership, the two DKIM records, the SPF policy, campaign evidence, automation evidence and any transactional route. Name the person who will approve each unresolved requirement.
If a test fails, pause the affected workflow using an approved operational plan. Restore a previously tested sender configuration only after checking that its ownership and records still work. Do not remove ownership tokens or authentication records while other authorized accounts or queued messages depend on them. Retest after a DNS migration, account transfer or change to the sending product.
Fictional diagnostic case involving an agency account
Fictional written case only: SM-02 assumes a brand account switches books.example from email-link to DNS ownership, while an authorized agency still needs to send offers@books.example. The agency’s own DNS token is not yet published; its message authentication results are unknown. The brand owner must confirm continued agency authorization, obtain that account’s separate token and verify ownership before a controlled campaign test. A passing brand-account test, if later obtained, would not establish the agency’s permission. No token, account, DNS or campaign was accessed.
Acceptance remains pending
Accept the documented route only after ownership, authentication checks and receiver evidence agree. Original-scope acceptance remains pending for any unverified transactional or custom-envelope requirement. Live tenant access, DNS and message tests, independent technical review, visual review and human SME approval remain pending for this unpublished draft.
Separate a passing message from enforcement readiness
RFC 9989 Section 7.4 requires valid DKIM for a domain publishing p=reject and cautions about indirect-mail interoperability. A single aligned SPF result does not by itself justify a reject-policy rollout. Review all legitimate routes and policy ownership separately from this provider setup.