For an existing authorized Teenvio marketing sender, open Remitentes → Configurar, use the SPF and DKIM instructions issued for that sender, publish the approved DNS changes, and return to the DKIM tab to select Activar firma DKIM. A matching DNS record is not the final activation step. Confirm the intended Teenvio signature and DMARC result on a newly delivered, authorized campaign message before declaring the route verified.
This guide covers native Teenvio marketing campaigns using an already approved sender. It does not establish new-sender onboarding, transactional email, dedicated hosting, white-label migrations or paid configuration services. You need authorized Teenvio access and permission from the domain owner to change the relevant DNS records and activate signing. If your current account lacks the documented controls, ask Teenvio to confirm applicability rather than borrowing settings from another product.
No customer account, DNS change or delivered-message test was performed for this article. Teenvio’s official walkthrough supplies the native procedure and screenshots described below.
Before changing anything
Record the exact approved visible From address, existing sender row and domain. Export the affected DNS records and identify the people responsible for the domain and other legitimate senders. Check which DNS service is actually authoritative; it is not necessarily the registrar or web host. Confirm any delegated child zone or _domainkey namespace before deciding where to publish.
Preserve working staff-mail, billing and other marketing authorizations. Do not change MX records, parent nameservers, DNSSEC, credentials or mail routing to follow this guide. Do not replace a working selector or remove a delegation without the responsible owners’ agreement. This is an authentication change for one existing route, not permission to migrate other mail services.
There are conflicting examples in Teenvio’s published material. They matter:
- The main walkthrough’s SPF prose spells one include host
sfp.teenvio.net, while its actual illustrated dialog displaysspf.teenvio.net. Elsewhere it mentions an olderteenvio.cominclude. - The main DKIM illustration displays a CNAME targeting
dkim1.teenvio.net; the older DKIM guide describes a different target. - The screenshots’ sender domains and existing SPF authorizations belong to examples, not your domain.
Use the complete record instructions currently issued for your exact sender. Do not combine all published alternatives, copy the typo, or migrate an existing working record simply because another tutorial uses a different value. If the current account instructions conflict with DNS, an existing configuration or the intended route, stop and have Teenvio confirm the exact owner, type, value and activation requirements. The older DKIM guide and older SPF guide are useful context, not universal replacement records.
Step 1: Open the correct sender’s configuration
In Teenvio’s upper-right menu, select Remitentes (senders). Locate the already authorized sender you intend to use for native marketing campaigns. Select Configurar on that row, beside the status indicators.
The popup contains separate SPF and DKIM tabs. Check the domain shown in the dialog before copying anything. Record the current instructions from both tabs, including the complete owner name, record type and required value. A green field showing a proposed value is not proof that you have published it or enabled signing.
If a sender or domain is missing, do not create a substitute as part of this procedure. First resolve the correct existing sender and its authorization with the account owner and Teenvio.
Step 2: Configure Teenvio SPF without breaking other senders
The SPF tab shows the current finding and the proposed TXT policy for the sender domain. Have the DNS administrator compare that proposal against the actual existing policy and the approved sender inventory. The illustrated example retains another mail provider’s authorization while adding Teenvio; it is not an instruction to add that unrelated provider to your DNS.
SPF permits only one v=spf1 TXT policy at a given evaluated owner. If one already exists, incorporate only the confirmed Teenvio authorization into that policy, preserving legitimate mechanisms and the owner-approved qualifier. Do not add a second SPF policy or overwrite the first with a tutorial example. Other unrelated TXT records can remain.
If no SPF policy exists at the required owner, obtain the domain owner’s approval for the complete initial policy after inventorying all services that send with that envelope identity. Use the current account-issued instructions as the Teenvio input, not as proof that no other sender needs authorization. Stop for administrator review if the resulting policy cannot safely cover the existing route.
Check the evaluated DNS-dependent SPF terms, including nested mechanisms, against the limit of ten. This is not simply a count of visible include statements. Preserve intended ordering and behavior: a redirect modifier is ignored when an all mechanism is present. Do not change -all to ~all or ?all to make a warning disappear. These qualifiers express evaluation outcomes, not guaranteed delivery or rejection decisions. RFC 7208 defines these rules.
Publish at the precise owner required by the approved configuration. For a zone-root owner, the DNS host may use @; for a child name it may expect only the relative part. Inspect the resulting fully qualified owner so the zone name is not appended twice. Allow caches to expire according to the actual TTL, then reopen the SPF tab and inspect the updated result.
Important: Teenvio’s sender-domain SPF indicator does not prove that a particular campaign used that domain for SPF. Receivers evaluate the SMTP MAIL FROM identity, or HELO in relevant cases, not automatically the visible From address. Check the real message later. This guide makes no universal promise about Teenvio’s Return-Path or custom envelope-domain behavior.
Step 3: Publish the issued Teenvio DKIM CNAME
In the same sender dialog, select DKIM. The documented self-service route supplies a CNAME owner and destination. Copy the actual account-issued pair, not a screenshot domain, remembered selector or another tenant’s record. Do not turn a CNAME instruction into a TXT record or generate a private key for this workflow.
Map the full owner to the authoritative zone. For illustration only, an issued owner SELECTOR._domainkey.example.com would normally be entered as SELECTOR._domainkey inside the example.com zone when the host appends the zone automatically. Inside a separately delegated _domainkey.example.com zone it would instead be relative to that zone. SELECTOR and example.com here are placeholders, not Teenvio-issued settings.
Before saving, inspect the exact owner for existing CNAME, TXT, A, AAAA, MX or NS records and shared dependencies. A CNAME cannot coexist with conflicting ordinary data at the same name. Do not delete an existing selector or delegation to force the new record through. Escalate a collision to the DNS owner and Teenvio for a supported plan. RFC 1034 describes CNAME behavior.
Publish the alias as DNS-only, not as an HTTP-proxied website record. Where a DNS provider offers CNAME flattening, preserve the literal CNAME answer required by this Teenvio check. With Cloudflare, turn off the relevant per-record Flatten control where available and ensure applicable whole-zone settings do not suppress this alias. Also consider mandatory apex and same-zone behavior. If those behaviors cannot preserve the issued CNAME response, stop and agree a supported configuration; do not make blanket global changes or invent a switch. See Cloudflare’s actual flattening setup instructions.
Use read-only lookups to check publication. Replace every uppercase placeholder before running these examples:
dig @AUTHORITATIVE_NAMESERVER EXACT_SPF_OWNER TXT
dig @AUTHORITATIVE_NAMESERVER EXACT_DKIM_OWNER CNAME
dig @PUBLIC_RESOLVER EXACT_DKIM_OWNER CNAME
The DKIM answer should preserve the exact issued alias destination, not merely resolve to an address. An empty response, unexpected owner, conflicting record or DNS error needs investigation, not activation. Compare authoritative answers with a recursive resolver after the TTL has elapsed. Do not disable DNSSEC to bypass a validation failure. These commands are diagnostic examples, not test results from this project.
Step 4: Return to Teenvio and activate DKIM signing
After DNS is visible, return to Remitentes → Configurar → DKIM for the same sender. The official illustration shows a successful matching DNS result followed by the separate button Activar firma DKIM (activate DKIM signing). It explicitly states that the configuration is correct and signing can now be activated.
That sequence is the key checkpoint: DNS match first; signing activation second. Once the account/domain owner has approved enabling this signer, use that button. Reopen the sender configuration and confirm Teenvio reports the intended DKIM configuration as active and correctly signing. If the control is missing, the status is inconsistent or the record still mismatches, stop and contact Teenvio. Do not repeatedly replace DNS records to make the button appear.
The provider describes orange as missing configuration and red as an incorrect or mismatched configuration in these sections. Diagnose the actual tab and record details, not color alone. Even a green status is provider-side evidence, not a delivered-message acceptance test. The official native walkthrough documents the return-and-activate step separately from DNS publication.
Step 5: Verify a real native campaign and preserve DMARC
With explicit permission for the content and recipient, send a harmless controlled message through the actual native marketing campaign route and approved From identity. Use an isolated valid test recipient, not a production audience, imported customer list or resubscribed suppressed contact. Do not assume an editor preview exercises the same final signing route. A third-party testing mailbox also receives message data; obtain the appropriate data-sharing approval before using one.
Inspect the delivered message through the receiving service’s original-message view. Use Authentication-Results produced inside that service’s known processing boundary, following its documented handling of externally supplied result headers. Header position or a familiar authserv-id string alone does not establish trust; ignore attacker-inserted or otherwise untrusted results. See RFC 8601.
Require all of the following for this new branded DKIM configuration:
- The visible From remains the intended approved brand identity, not a substituted provider address.
- The intended Teenvio signature is present and the trusted receiver reports
dkim=pass; inspect its signing domain and selector, especially when multiple signatures exist. - That passing DKIM domain aligns with the visible From under the applicable
adkimpolicy. Relaxed alignment compares Organizational Domains; strict alignment requires an exact domain match. - The trusted receiver reports
dmarc=passfor the intended From. A DMARC pass supplied only by SPF is not proof that this DKIM configuration works.
Record the actual smtp.mailfrom identity and SPF result separately. Investigate SPF fail, temporary DNS errors (temperror) and permanent policy errors (permerror) even when aligned DKIM supplies DMARC pass. SPF alignment likewise depends on the applicable aspf mode; a child envelope domain does not promise strict alignment. See raw DKIM results versus aligned DKIM policy results for that distinction, and RFC 9989 for current DMARC rules.
Preserve existing direct and applicable inherited DMARC policies and approved report destinations. Do not downgrade protection, add duplicate policies or copy report recipients to troubleshoot this route. If there is no applicable policy, have the domain owner plan a separate first-policy deployment after reviewing all legitimate senders; this procedure does not silently install a monitoring policy.
For aggregate reporting to a destination in a different Organizational Domain from the domain where the DMARC policy was found, report-generating receivers must check DNS authorization. Destinations within that same Organizational Domain are excepted. This comparison uses the policy domain, including when policy is inherited, not automatically the visible From domain. DNS authorization does not replace the owner’s privacy and data-sharing approval. RFC 9990 section 4 defines the rule.
Troubleshooting and frequently asked questions
Which Teenvio SPF include should I copy?
Use the current approved sender dialog, not the main article’s transposed sfp spelling or a legacy example. If the dialog and your established route disagree, ask Teenvio to resolve the discrepancy before changing the single existing SPF policy. Never add all alternatives speculatively.
Why is DKIM DNS green but mail is not signed correctly?
The documented workflow still requires Activar firma DKIM after the DNS match. Confirm the correct sender was activated, then inspect a fresh native campaign. An old message, a different sender or an unrelated passing signature cannot validate this change.
Should I replace an older Teenvio DKIM target?
Not solely because this guide describes a newer illustration. Have Teenvio confirm the current instructions for your existing sender and agree any migration with the DNS owner. Preserve a working configuration until its replacement and dependencies are understood.
Can green SPF or DKIM status guarantee inbox placement?
No. Status checks do not reproduce every receiver’s authentication or filtering decisions. Even a passing aligned message does not establish every other sender is correct, or guarantee delivery, ranking or inbox placement.
What should I retain for an escalation?
Keep the approved sender/domain, the current dialog’s public record instructions, authoritative and recursive lookup results, activation status and a safely redacted failing message from the same route. Exclude credentials, private keys and unrelated recipient data. Record whether the failure is publication, activation, authentication or alignment so the next change addresses the actual problem.