Identify the current platform and sending account
The current first-party help center states that Manago AI is the new name for SALESmanago. This article retains the catalogue name so existing teams can find it, while using the current help pages alongside the provider's authentication PDF. A change of brand name is not permission to change working DNS targets. Confirm the account's current instructions before replacing any legacy-named record. Manago AI DKIM guidance
Start by identifying the sender account actually selected by the message. The platform distinguishes an Email Marketing account using its own sending infrastructure from an External SMTP account using infrastructure selected by the customer. The relevant settings are documented under Channels > Email Marketing > Settings. Manago AI sender accounts
This distinction changes who is responsible for the final signature and envelope identity. Platform-authentication records should not be assumed to repair a message handed to a separate SMTP service. Inventory campaigns, automations, API-triggered messages, and subscription confirmations that use each account. Include dormant but scheduled workflows so a passing one-off test does not leave an old sender active in the next automation run.
Build a domain and ownership inventory
List every visible From domain and subdomain, the responsible team, and the account that selects it. Do not reduce distinct domains to the main website's name. If a personalized sender field can produce several domains, each domain belongs in the review. Record the fallback sender used when personalization data is missing, because that is another identity a real recipient may see.
The provider documents optional substitution of sender details from a contact's standard fields. Its sender-account instructions also distinguish the visible sender from the reply address. Test the combinations actually enabled, without assuming that a working reply mailbox authenticates the visible From address. Manago AI sender accounts
Use harmless test contacts with explicit permission to receive the checks. Do not change an entire customer segment's sender details for diagnosis. Preserve the existing account selection and template configuration so an administrator can restore them if a test exposes a mismatch. Keep SMTP passwords, API secrets, and private keys out of the worksheet and any support screenshots.
Prepare the supported platform records
The provider's authentication PDF documents the SPF mechanism include:_spf.jupiter.salesmanago.pl and two DKIM CNAME selectors, salesmanago and salesmanago2. Their documented destinations are the corresponding selector names under _domainkey.smgrid.com. Apply them only after confirming that the current account uses this supported platform route. The current DKIM help page also directs administrators to coordinate domain preparation with the provider. SALESmanago authentication PDF Manago AI DKIM guidance
For each selector, obtain the complete owner and target in the provider's instructions. Translate them carefully into the DNS console's naming format. A console that appends the zone name can create a duplicated suffix if a fully qualified owner is pasted into a relative-name field. Inspect the public result rather than relying on how the text looks in the editor. Existing data at a proposed CNAME owner needs review before replacement.
Maintain one applicable SPF policy at the relevant owner. Merge only the needed authorization into the existing inventory, preserving other approved senders and the intended terminal mechanism. Evaluate the DNS-lookup budget with nested includes and other lookup-causing terms. SPF syntax and authorization are separate from DMARC alignment; a record at the visible From domain does not change the envelope domain selected by the sending service. SPF RFC 7208
Do not copy a sample entire policy into a production zone. The organization may use staff mail, an order system, and other platforms from that domain. An authentication guide for one provider cannot determine which of those systems should remain authorized. Likewise, an observed IP address is not a stable replacement for a provider's maintained authorization mechanism.
Complete domain ownership verification
The PDF separates DKIM DNS publication from ownership verification. It documents an optional TXT record containing smv= followed by the account's Client ID, with that ID available in Integration Center > API > API v2. It also provides support-assisted verification when the optional record is not used. Confirm the current account procedure and obtain its completion evidence. SALESmanago authentication PDF
The Client ID used for this documented public verification record is not a request to publish an API secret. Copy only the field required by the provider. If the interface exposes adjacent credentials, redact them from screenshots and handoffs. Do not create new API access merely to find a verification identifier already associated with the account.
The current sender-account guide separately requires Support verification for each new sender account intended for more than 1,000 contacts. Treat that account review as a launch prerequisite in addition to domain ownership verification; publishing the optional smv record does not substitute for it. Confirm completion with the account owner before scheduling that audience. Manago AI sender accounts
Treat verification as an account-control step. A DNS lookup showing both CNAMEs cannot by itself prove that the correct customer account is permitted to use the domain. Retain the account reference, confirmation time, and reviewer. If verification remains incomplete, resolve that issue with the provider rather than cycling between arbitrary selectors or changing DMARC policy to hide the failure.
Verify platform and external SMTP messages separately
Send a controlled message through each in-scope route and capture its original headers at a trusted receiver. Record the selected account, visible From, envelope identity, each DKIM signing domain and selector, and receiver authentication results. Compare the signing domain with the authorized domain inventory. DKIM's d= and s= values identify the signing domain and selector used for the lookup. DKIM RFC 6376
For an External SMTP account, first identify the actual mail provider and its documented signing procedure. Do not assume the SALESmanago selectors apply to it. A successful connection or an accepted SMTP submission proves neither a passing signature nor an aligned envelope. Hold route-specific implementation until that service's administrator supplies supported settings and a received-message result.
For a platform account with personalization, test an ordinary populated contact and a contact that invokes the fallback. Repeat any distinct sender domain rather than sampling only display names. If one version fails, compare the emitted From address with the domain configured for signing. The relevant question is which identity left the system, not which identity the template editor seemed to display.
DMARC passes when at least one successful authentication path aligns with the visible From domain under the effective policy. A provider-domain pass that does not align is insufficient. Apply the current specification to the observed identities and preserve the result beside the raw evidence. DMARC RFC 9989
Review DMARC without adopting a sample policy
The provider PDF includes an enforcement-oriented DMARC example and reporting addresses to replace. Those are examples, not a decision for the whole organization. Review existing policy and every legitimate sender before changing enforcement. Do not downgrade an established policy just to accommodate an unverified marketing account, and do not upgrade an unreviewed domain solely because one sample campaign passes.
Select reporting destinations deliberately. Aggregate reports can reveal sending infrastructure and traffic patterns; more detailed reports can have additional privacy implications. Use only approved recipients and keep the reporting configuration separate from the provider's account-verification TXT record. A report destination is not a DKIM key, and an ownership token is not a DMARC policy.
Fictional example involving a fallback sender
Fictional written case only: SM-01 stipulates populated contacts produce offers@shop.example with passing d=shop.example, while missing personalization fields fall back to offers@brand.example. Ownership verification for brand.example is incomplete and its SPF/DKIM results are unknown. The marketing owner must approve and verify that fallback domain before releasing those contacts. A separate External SMTP account remains outside the platform result. No contact, account or message was accessed; these identities are teaching assumptions.
Implementation worksheet and release limits
- Account scope: current platform name, account identifier, selected sender-account type, and workflow owner.
- Identity inventory: default From, personalized domains, fallback values, and monitored reply destinations.
- DNS evidence: issued public records, existing SPF policy, CNAME owner expansion, TTLs, and authoritative lookup times.
- Ownership: chosen verification method, approved public identifier if used, provider confirmation, and completion time.
- Route tests: platform or external SMTP, workflow reference, From, envelope domain, all DKIM d=/s= pairs, and trusted results.
- Recovery: prior supported sender, affected automations, pause authority, and retest criteria.
Current tenant records, ownership status, external SMTP settings, live DNS, and received messages have not been inspected. Visual review, human SME approval, and publication remain pending. The guide remains unpublished; external-service setup and any account-specific departure from the public instructions are explicit scope holds.
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.