For normal SMTP2GO sending, verify a sender domain and publish the three CNAME records issued by your account. SMTP2GO then manages SPF through its return-path subdomain and DKIM through the signing record. You do not normally add an SMTP2GO include to your root SPF record. Single-email verification is different: it permits sending but does not supply the same customer-domain alignment. SMTP2GO authentication overview
This guide covers mail submitted to SMTP2GO over SMTP or its email API, including applications, websites and devices. It retains the domain-verification, application-route and DMARC scope of this implementation guide. It does not configure your incoming mailbox service or certify an integration simply because its SMTP settings mention SMTP2GO. If employee mail uses Google rather than this relay, validate that separate route with the Google Workspace authentication guide.
Before you start
Arrange access to the relevant SMTP2GO account and the authoritative DNS zone. Identify the visible From domain, application owner, submission method and any subaccount. Export the existing DNS records and record the current DMARC policy before making changes.
Keep a small worksheet containing each account-issued record's purpose, complete owner name, target, TTL and previous value. Record which application uses which account, without putting SMTP passwords or API keys in the worksheet. If several suppliers send for your domain, list them before touching SPF.
The documented sender-domain workflow is the scope here. Check your current plan before depending on optional diagnostics; do not assume an advanced testing tool is included. Regional endpoints or reseller arrangements do not justify inventing alternative DNS targets: use the records displayed in the account that actually sends.
Choose domain verification, not just an email confirmation
Open Sending → Verified Senders → Sender domains, add the domain used in your From address, and obtain its DNS records. A verified parent domain can cover subdomain sending, but those subdomains must exist in DNS. Check the resulting signing identity rather than assuming every subdomain is an exact-match signer. Verified Senders
After entering the domain, the documented Continue with this domain flow offers automatic DNS setup through Entri or manual publication. Review and separately approve the requested DNS access and exact changes before automatic setup; use the manual route if that access or change scope is not approved. Do not treat automatic setup as permission to alter unrelated records. Current setup choices
Single sender email verification uses a confirmation email instead of domain DNS access. SMTP2GO warns that this route does not align SPF and DKIM with the sender's domain. It is not an equivalent shortcut for a business-domain authentication project. Domain verification also permits valid addresses at that domain, rather than requiring one confirmation per address. Comparison of verification methods
For a master/subaccount arrangement, confirm that the master has granted the sending subaccount access to the verified domain. Otherwise, a correct record in the master account can coexist with an application using the wrong account. Check the domain's Subaccount access tab and the subaccount's displayed domain assignment before recreating records.
A domain assigned by the master appears in the subaccount with a Master tag and cannot be edited there. Grant only the owner-approved subaccounts access; do not enable access for all or future subaccounts merely for convenience. Test the application with the intended assignment. Subaccount controls
Publish the three account-issued CNAMEs
Treat these as a mapping checklist, not deployable record values:
- Return-path CNAME: the issued owner and target for the envelope sender used by SMTP2GO. This is the SPF-related record.
- DKIM CNAME: the issued selector owner under
_domainkeyand its exact target. This supports the domain signature. - Tracking CNAME: the issued tracking owner and target. This concerns branded links and tracking, not a third authentication protocol.
The provider's overview identifies the first record as return-path/SPF and the second as DKIM. The third serves tracking. A tracking failure and a DKIM failure therefore need different investigations. Record roles
Copy every owner and target from your own account. A host that automatically appends your zone name may require a relative owner; another may accept a complete name. Inspect the resulting full hostname so that your domain is not accidentally appended twice. Preserve underscores in the DKIM owner.
For an illustrative issued owner SELECTOR._domainkey.news.example.com, a suffix-appending editor for example.com uses SELECTOR._domainkey.news; one for a separately delegated news.example.com zone uses SELECTOR._domainkey. If _domainkey.news.example.com itself is delegated, use relative SELECTOR in that zone. A full-name field takes the complete issued owner. Replace the placeholder with the actual account selector, preserve existing NS delegations and active selectors, and publish with the actual authority rather than adding an inactive parent-zone copy. DNS zone boundaries.
Do not place a CNAME on an owner already used by another service or alongside conflicting TXT, A or MX data. Resolve the ownership conflict first, using a supported alternate name where offered. Keep authentication records visible as DNS records rather than routing them through an HTTP proxy. Do not delete unrelated DKIM selectors.
Where the issued authentication or return-path records require literal CNAME answers, use DNS-only aliases returning the exact targets, without an HTTP proxy or flattening hiding them. Turn the relevant per-record Flatten control off when available and ensure applicable zone settings preserve those aliases. Cloudflare documents that flatten-all cannot be overridden per record, apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are conditional DNS-host behaviors, not assumed controls in every panel. If mandatory apex/same-zone behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration with the DNS owner and sender. Do not blindly change the whole zone or remove an existing delegation. CNAME verification, flattening controls and limits.
After publication, select Verify and check the sender domain’s Verified status. SMTP2GO says Verify also requests a certificate for the tracking domain; assess the separate tracking/certificate state rather than confusing it with DKIM. Obtain separate approval for tracking and its privacy implications. SMTP2GO documents a TXT/MX alternative by Support request for organizations that cannot use CNAMEs; do not manufacture that packet yourself. DNS setup and exceptions
Before publishing a Support-issued MX alternative, obtain the DNS/routing owner’s approval for the exact full owner and complete numeric-priority/target set and bounce-routing consequences. Check every approved entry at authoritative and recursive DNS, stopping on missing, extra or unapproved destinations. The issued packet alone does not authorize routing changes. Do not replace the root mailbox MX.
Understand the SPF exception before editing your root record
Ordinary SMTP2GO delivery uses its managed envelope sender. SPF checks that MAIL FROM identity, which is commonly reflected in the delivered Return-Path, rather than simply checking the address a person sees in From. Adding an include at an unrelated hostname does not change that identity. SPF identity rules
There is a documented exception: Maintain Return-Path, intended for approved recipient domains with legacy systems unable to process VERP addresses. With that feature, SMTP2GO preserves the original sender address and requires include:spf.smtp2go.com in that sender domain's SPF policy. Late bounces may no longer appear in SMTP2GO's application. Confirm this exception is actually enabled before applying its instructions. Maintain Return-Path
If the exception applies, merge the required mechanism into the existing single v=spf1 policy at the relevant owner. Preserve other legitimate senders and the existing terminal policy. Do not publish a second SPF record or add the include after an all mechanism. Evaluate the complete SPF policy, including nested includes, against the ten DNS-lookup-causing-term limit. A normal-domain setup does not require this extra edit. SPF record and lookup rules
If the existing SPF policy uses redirect=, reconcile its authorizations and terminal behavior with the DNS owner before changing it. Any all mechanism makes redirect ignored regardless of their order. Do not append all automatically: preserve the redirected senders and approved policy semantics through a reviewed design. SPF all and redirect processing.
Check public DNS before sending a test
Replace the uppercase placeholders below with complete names copied from your worksheet. These are read-only lookup patterns, not literal SMTP2GO values:
dig +short CNAME RETURN_PATH_OWNERdig +short TXT RETURN_PATH_OWNERdig +short CNAME DKIM_OWNERdig +short TXT DKIM_OWNERdig +short CNAME TRACKING_OWNERdig +short TXT _dmarc.FROM_DOMAIN
The CNAME answers should match the issued targets. The TXT queries should allow you to follow the alias chain to the managed SPF policy or DKIM public key. A CNAME alone proves delegation, not that a particular message was correctly signed.
If answers differ between resolvers, inspect the authoritative servers individually and compare TTLs. Correct the zone actually delegated for the domain, not an inactive zone at the registrar. A persistent SERVFAIL requires DNS investigation; repeatedly clicking Verify cannot repair it. Keep evidence of the time and answers so support can distinguish stale caches from inconsistent authoritative data.
Verify the application route with delivered headers
Send a controlled message from the actual production-style workflow to an inbox you can inspect. Test SMTP and API paths separately if both are used. A dashboard test does not establish that an invoice application, web form or scanner uses the same credentials and From domain. SMTP2GO's API requires both valid API authentication and a verified sender; one does not replace the other. API prerequisites
In the receiver's trusted Authentication-Results, examine:
spf=passandsmtp.mailfrom: record the envelope domain that passed.dkim=passandheader.d: record the signing domain; uses=in the signature to identify its DNS selector.dmarc=passandheader.from: confirm the evaluated visible From domain.
Compare these identities rather than counting green checkmarks. A provider-domain SPF pass can be genuine while unaligned with From.
Establish which results were generated inside the receiving service's known processing boundary and how it removes, ignores or distinguishes externally supplied Authentication-Results. Use receiver-controlled diagnostics or have the receiving-mail administrator confirm its documented handling. A familiar authserv-id string or header position alone is not proof. Ignore attacker-supplied or otherwise untrusted fields; obtain authenticated receiving-system evidence when provenance is uncertain. Receiver-result trust.
For this branded DKIM setup, require the intended SMTP2GO signature to report dkim=pass and align with the unchanged approved branded From under the effective adkim policy, together with trusted receiver dmarc=pass for that From. Record the expected and observed d= and s=. A rewritten provider From, unrelated passing signature or SPF-only DMARC pass does not complete the intended DKIM deployment. DMARC itself permits either aligned passing method; this is the commissioned signer’s acceptance gate.
Diagnose SPF at the actual envelope owner independently even when aligned DKIM supplies DMARC. For fail or softfail, compare the observed connecting source and MAIL FROM identity with the approved authorization and sending route. For permerror, check duplicate SPF policies, malformed syntax and the full nested DNS-dependent term budget. For temperror, investigate temporary DNS resolution or availability failures and retest after recovery. A provider-owned SPF pass without alignment is different from these failures; escalate errors for provider-owned identities to that sender rather than editing unrelated apex DNS. SPF result definitions.
For an illustrative incident, suppose the domain is verified in the master account, but a web form still uses another account with only single-email verification. Public DNS may look perfect while the delivered signer remains provider-owned. Trace the account and submission route before replacing a valid DNS record. This is a diagnostic example, not an observed test result.
Preserve DMARC and assess alignment correctly
DMARC passes when at least one passing mechanism, SPF or DKIM, aligns with the visible From domain. Relaxed alignment permits the same organizational domain; strict alignment requires an exact domain match. A return-path subdomain can therefore support relaxed SPF alignment without satisfying aspf=s. Verify DKIM independently if strict alignment is required. Current DMARC standard
Keep an established DMARC record and its reporting destinations. Do not overwrite enforcement with p=none or create a weaker child policy to make setup appear successful. Check the direct From-domain policy and any applicable inherited policy. RFC 9989 replaces RFC 7489 and removes pct; do not design a new rollout around percentage sampling.
Only if no direct or applicable inherited DMARC policy exists, and the domain owner approves this first policy and a monitoring/review plan after reviewing legitimate senders, a first TXT policy for fictional From domain example.com may be v=DMARC1; p=none at full owner _dmarc.example.com. The minimal value requests no reports; provision an approved reporting destination and review process before adding rua. Preserve established enforcement and authorized reports.
For a first policy at full owner _dmarc.example.com, a relative-name field in zone example.com takes _dmarc. For a deliberately approved child policy at _dmarc.news.example.com, use _dmarc.news in the parent zone or _dmarc in a separately delegated news.example.com zone. A full-name field takes the complete owner. These examples do not authorize overriding an inherited policy.
Compare the Organizational Domain of the aggregate-report URI's host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as the policy domain is excepted; a different hostname alone does not make it external. Obtain the reporting operator's exact authorization instructions when required. This protocol check is separate from the domain owner's approval to share report data; agree access, retention and privacy. RFC 9990 section 4.
Before a separate domain-wide move to p=reject, follow RFC 9989 section 7.4: legitimate outbound mail needs valid DKIM, and indirect-mail interoperability, including forwarding and mailing lists, needs review. Completing this sender alone does not authorize enforcement for every route.
Troubleshoot by the failing layer
Domain remains unverified: compare exact owner names and targets, check for a doubled domain suffix, inspect all authoritative servers, and confirm the correct account or subaccount has access. Escalate with redacted DNS evidence rather than secrets.
Sending is rejected: check sender restrictions and domain verification, then submission authentication. SMTP2GO's Reports → Activity → Timeline distinguishes processing, delivery and bounce events. An API authentication error or SMTP login problem is not repaired by a new DKIM selector. Delivery troubleshooting
SPF passes but DMARC fails: compare the actual MAIL FROM with From, then inspect DKIM. Check for single-email verification, an unexpected account or strict alignment before modifying SPF.
DKIM passes but mail lands in spam: authentication is not an inbox-placement guarantee. Review the recipient's response, content, complaint history and sending practices. Preserve the passing configuration while investigating the separate delivery issue.
Completion checklist and review limits
Record the verified domain, account/subaccount, DNS answers, application route, receiver results and current DMARC policy. Keep a rollback copy of previous records; remove superseded records only after confirming no active sender still needs them. Continue reviewing aggregate reports for missed workflows.
Agree a recovery plan with the application and DNS owners before rollout: pause affected sends or reroute them only to an approved, tested configuration. Preserve queued-message keys, subaccount dependencies and previously sent tracking links until retirement is safe. Retest after DNS, From-domain or subaccount changes; a saved DNS copy does not by itself restore account assignments or application credentials.
No customer account, public customer DNS, application submission or delivered message was tested for this guide. Implementation, deployed-page behavior, indexing and inbox placement remain unverified.