Choose the sender verification model deliberately
For an organization's own domain, SMTP2GO sender-domain verification is the documented route to customer-domain authentication. Single-email verification is a different option and does not provide the same SPF and DKIM alignment. Begin with the domains and addresses applications will use rather than selecting the quickest verification screen. SMTP2GO verification options, Sender Domain and Single Sender Email.
List the actual sources: application API calls, SMTP relay clients, devices and integrations. Record each account or sub-account, intended From domain and operational owner. A shared domain does not mean every route uses the same credentials or configuration. Include fallback routes explicitly and do not treat their successful delivery as a test of the primary route.
SMTP2GO documents verified senders as required and records attempts from unverified senders as rejected. Its rollout announcement also explains its return-path subdomain model and why existing root SPF records need not be expanded. SMTP2GO verified-sender announcement.
Capture the three records issued to the account
In Sending > Verified Senders > Sender domains, add the intended domain and capture the three CNAME records. The documented set covers the return-path/SPF function, DKIM and tracking. Publish the current issued values rather than generic examples. The guide offers manual DNS changes or an automated DNS flow. SMTP2GO Verified Senders, Steps One and Two.
The sender-domain guide allows existing DNS subdomains to send under a verified top-level domain. That is sending permission, not proof of strict alignment for every subdomain. If policy forbids CNAMEs, the guide offers TXT/MX configuration on request; obtain that supported alternative rather than translating records yourself.
Select the method through the organization’s change process. An automated flow may request access to DNS, so review exactly what access and changes it proposes before granting it. Manual publication should still use the same reviewed record set. Do not grant broader access merely to avoid understanding a naming conflict.
For every record, save the full owner, target and TTL. Check existing use of the proposed names, including other CNAMEs, certificates, tracking services and mail processing. Ask the account administrator for a supported alternate hostname when there is a collision; do not invent a new target or overwrite the existing service.
Keep SPF and tracking distinct
SMTP2GO's customer-domain return path is the relevant SPF identity. Adding an include to the corporate root policy does not substitute for the issued return-path CNAME. This distinction is especially useful where the root policy already authorizes several unrelated services. Keep those existing permissions unchanged unless a separately reviewed change requires it.
SPF checks the SMTP identity used in the transaction. Its evaluation rules do not automatically transfer a policy from the visible From domain to a different envelope domain. RFC 7208, sections 2.4 and 4.
The tracking CNAME serves a separate purpose. SMTP2GO documents HTTPS certificate provisioning for that tracking name after verification. A tracking problem should be investigated on its own terms, not interpreted as proof that the DKIM key is missing. SMTP2GO Verified Senders, Tracking domain.
Record tracking verification and certificate status separately in the worksheet. If privacy or communications policy restricts tracking, have the appropriate owner review those application settings. Authentication work should not silently activate an unrelated analytics feature.
Verify public DNS and account access
Inspect the public CNAME answers from the authoritative DNS service and compare them with the issued records. Confirm that the DNS editor has not appended the domain twice or changed the target. When results differ across authoritative servers, resolve that inconsistency instead of repeatedly recreating the domain in SMTP2GO.
The provider guide supports granting selected sub-accounts access to a domain verified in the master account. Confirm that the actual sending sub-account has that access. Do not assume a domain appearing in the master account is automatically usable everywhere. The guide identifies allocated domains in the sub-account with an uneditable Master tag; record that evidence for the actual sending account. SMTP2GO Verified Senders, Subaccount access.
Record which account owns the domain, which sub-accounts are authorized and who can alter those permissions. For client or multi-brand use, retain authorization for the specific domain and sender purpose. DNS control does not settle whether a particular application should be allowed to send as that brand.
Test SMTP and API paths separately where used
The API documentation treats API-key authentication and sender verification as separate requirements. A valid key alone does not authorize an unverified From identity. SMTP2GO API guide, Authentication and Sender Verification.
Use harmless content to controlled external mailboxes and send through each material route. Keep application identifiers, UTC times, Message-IDs and corresponding provider activity records. For a device or integration, test from that device or integration rather than only from a developer's separate test script. Preserve the observed From even if the application was expected to use something else.
At the receiver, record Return-Path, trusted SPF identity and result, every DKIM d and s value, and the DMARC result. Inspect the public key for the selector actually used; a verified but unused selector does not prove the message was signed with it. RFC 6376, sections 3.5 and 6.1.
Determine which authenticated domain aligns with the visible From. A subdomain return path may satisfy relaxed SPF alignment without satisfying strict exact-domain alignment. One passing aligned mechanism is sufficient for DMARC, although separate provider or organizational requirements may ask for both mechanisms. RFC 9989, Identifier Alignment Explained and DMARC Evaluation.
Keep DMARC policy under domain ownership
SMTP2GO's DMARC setup page places policy publication in the domain's DNS rather than the sending platform. Treat this as a separate domain-level change that affects other senders too. SMTP2GO DMARC guide, How to set up DMARC.
Use the current protocol definition for the pass decision. Some provider explanatory wording compresses authentication and delivery into a simpler story; it should not override the distinction between alignment, policy and a receiver's independent filtering. Do not lower an existing enforcement policy simply to make an unverified single-email route usable.
If mail is rejected before submission completes, check sender verification, account scope and the actual From address. If the message is delivered with unexpected identity, inspect the integration's overrides and account selection. If authentication passes but spam placement remains poor, investigate reputation, recipient expectations and content separately. Repeatedly altering CNAMEs is not a general deliverability remedy.
Document the rollout and recovery route
Use the SMTP2GO domain and application worksheet (create a separate review record with the fields described here). It separates the three DNS functions, sub-account permission and route-specific receiver evidence. Record the precise reason for any failed acceptance check rather than only a red or green status.
Pause or reroute affected application traffic through an approved, previously tested path if a rollout fails. Retain records needed by queued mail and working integrations. Before retiring a domain, verify that no device, client account or fallback route still depends on it. Retest after changing the DNS host, application From identity or sub-account access.
Fictional diagnostic case involving the wrong account
Fictional written case only: S2G-01 assumes the master account has verified service.example, but an application sending alerts@service.example uses a sub-account without the required domain allocation and receives a submission rejection. No recipient SPF, DKIM or DMARC result exists for that rejected attempt. The application owner must verify account selection and obtain approval for narrowly scoped domain allocation, then test the same route. A master-account sample does not close the sub-account issue. No API key, tenant permission or message was used.
Acceptance remains pending
Accept only when the actual routes use the approved domain, issued DNS records resolve, the relevant account scope verifies and trusted receiver results establish the required alignment. Live tenant, DNS and message checks, original-scope acceptance, 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.