Start with the envelope sender as well as the visible From address. The turboSMTP reference places its SPF authorization on the envelope-address domain. A successful SMTP login proves permission to submit mail to the relay; it does not prove that the recipient will authenticate your chosen From domain.
Publish the applicable relay authentication records
The official example authorizes include:spf.turbo-smtp.com. Merge that mechanism into the single existing SPF policy where applicable, before its terminal all mechanism. Do not copy the example's a, mx or ?all into an established policy without deciding whether those authorizations and failure semantics are intended.
The reference provides a TXT public key for turbo-smtp._domainkey. Copy the current complete key from the official reference or your provider-confirmed configuration, not a key invented from the selector name. Confirm the actual outgoing signature uses that selector and your expected signing domain. The page contains an inconsistent sentence in its DMARC section: DMARC belongs at _dmarc.<domain>, as its own table shows, not at the DKIM selector. Follow the DMARC standard for that owner name. turboSMTP configuration reference
Do not replace an existing enforcement policy with the page's p=none example merely to complete setup. A vendor's deliverability language is not an inbox guarantee. If your account exposes different authentication values, resolve the difference with support and retain the account-specific instructions before changing DNS.
Verify DNS and a real receiving result
Before changing SMTP relay sender configuration, export the existing DNS values, record the approved diff and name the rollback owner. Confirm whether the DNS editor expects a relative label or a fully qualified name; doubling the domain suffix creates a record that no intended verifier will find. Query the actual owner name after saving, including any CNAME target, rather than relying on the editor's success banner.
SPF must remain one policy at the relevant domain and stay within the DNS-querying-term limits in RFC 7208. Adding an include does not itself establish alignment. Under RFC 9989, DMARC passes when at least one successful SPF or DKIM result aligns with the visible From domain under the applicable mode. Do not require both mechanisms to align as a condition imposed by the standard, and do not mistake a provider-domain pass for an aligned customer-domain pass.
Send a message submitted through the same SMTP credentials and application used in production to a mailbox you control. Save the receiving system's trusted authentication results, visible From, envelope identity, DKIM d= and s= values, timestamp and provider status. A DNS lookup only shows the available key; RFC 6376 verification also evaluates the signature over the received message. Use non-sensitive content and avoid exposing full customer messages to public checkers.
Use a bounded acceptance and rollback decision
An illustrative acceptance case is a message from alerts@example.com with a valid signature using d=example.com. That exact domain match supports DKIM alignment in either mode. A valid signature using only d=vendor.example.net does not align with example.com; without aligned SPF, that sample fails the DMARC acceptance test. These are reasoning examples, not observed TurboSMTP results.
If the test fails, separate missing DNS, wrong selector, inactive provider configuration, unexpected routing and message modification before making another change. Retest the same workflow after each approved correction. Do not weaken the whole domain's DMARC policy to hide a single sender problem. Where rollback is needed, restore the approved prior routing or sender configuration and retain key records while queued signed messages still need them. Keep the test evidence and unresolved exceptions with the domain inventory. No tenant access, DNS change or real sending was performed in preparing this guide.
Separate a misplaced policy from a working signature
Written case TS-01 assumes a message received before the erroneous DNS edit had From alerts@example.org and a trusted DKIM pass with d=example.org, s=turbo-smtp. This supplies exact DKIM alignment. Separately, an administrator mistakenly placed a DMARC TXT value at turbo-smtp._domainkey.example.org; the actual policy at _dmarc.example.org is unknown. That misplaced value is not a usable DMARC policy at the required discovery owner, and mixing it with key data warrants investigation. The DNS owner should preserve the correct public key and reconcile the intended policy at _dmarc.example.org without replacing existing enforcement. The hypothetical signature result does not validate the mistaken DNS change. No message, key or zone was inspected or changed.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.