Do I need to add include:spf.smtp2go.com to my SPF record?

No — not with the recommended setup. The emXXXXXX return-path CNAME points your envelope Return-Path at return.smtp2go.net via VERP, which makes SPF both pass and align to your domain without touching your root SPF. The shared include:spf.smtp2go.com still resolves, but it's the legacy path: with it the Return-Path stays on SMTP2GO's domain, so SPF authorizes the mail but doesn't align, leaving DMARC to rely on DKIM alone.

What's the difference between a Single Sender and a Sender Domain?

A Single Sender verifies one email address by clicking a confirmation link — quick, but it gives you no SPF or DKIM alignment. A Sender Domain is the CNAME-based flow described here: it authenticates the whole domain, aligns SPF and DKIM, and is what you need for deliverability and to meet the Gmail/Yahoo requirements. Add the Sender Domain.

Do I add these as CNAME or TXT records?

All three of the authentication records — the emXXXXXX return-path, the sXXXXXX._domainkey DKIM record, and the link tracking host — are CNAMEs. The only TXT record is your DMARC policy at _dmarc, and that's separate and added by you.

Why is the record host something like em1234567 or s1234567._domainkey?

Those labels are generated for your SMTP2GO account — the return-path host carries your account's numeric ID, and the DKIM host is the selector SMTP2GO assigns you. Because they're account-specific, you must copy the exact labels shown in your dashboard — don't invent or reuse a label from another guide, or validation will fail.

Is the link / tracking CNAME required?

No, it's optional for authentication — SPF and DKIM pass without it. It only enables open and click tracking over HTTPS on your own subdomain instead of SMTP2GO's shared tracking domain. It's recommended for branded, secure links, but you can skip it and add it later.

Will SMTP2GO's records conflict with Google Workspace, Microsoft 365, or another sender I already use?

No. SMTP2GO uses CNAMEs on its own subdomains (emXXXXXX, sXXXXXX._domainkey, link) and its own DKIM selector, so it won't overwrite your existing DKIM or your root SPF. The only rules: keep a single SPF TXT record on your root and a single _dmarc record — never publish two of either.

My mail still isn't aligning or shows a "via smtp2go" attribution — what's wrong?

Almost always one of three things: you verified a Single Sender instead of a Sender Domain, the return-path (emXXXXXX) CNAME is missing or was deleted, or a Cloudflare orange-cloud proxy is stopping the CNAMEs from resolving. Confirm all three CNAMEs are present, set to DNS only, and showing Verified, then re-test with Show original.

SPF setup guide

SPF, DKIM & DMARC for SMTP2GO.

SMTP2GO authenticates your domain the same way the other modern transactional providers do: through its Verified Senders flow, not by having you paste a shared SPF line. When you add a Sender Domain, SMTP2GO generates a small set of CNAME records — a return-path (VERP) subdomain, a DKIM key, and an optional link-tracking host — that delegate SPF alignment and DKIM signing back to SMTP2GO. Once those CNAMEs verify, SMTP2GO can send as your domain with SPF and DKIM both aligned, no "via smtp2go.com" note, and DMARC passing — and because the keys live on SMTP2GO's side, you never have to re-edit DNS when they rotate.

CNAME domain authentication

Your DNSAdd the CNAME / TXT records

SMTP2GOSigns & sends as your domain

The inboxSPF · DKIM · DMARC pass

Why authenticate SMTP2GO?

Registering a Verified Sender is no longer optional at SMTP2GO — since 2025 it blocks sending until a domain (or at least a single address) is verified, and for deliverability a full Sender Domain is what you want. The reason is the mailbox-provider rules: since February 2024 Gmail and Yahoo require every sender to pass SPF or DKIM, and every bulk sender (roughly 5,000+ messages a day) to also publish a DMARC policy with alignment; Microsoft began enforcing the same baseline for high-volume senders to Outlook and Hotmail in 2025. Until you verify a Sender Domain, SMTP2GO can only fall back to sending that doesn't align to your organizational domain — recipients may see a "via" attribution, DMARC can't pass on SPF, and any reputation you build pools with SMTP2GO's shared space instead of your own domain. Adding the CNAMEs fixes all of it at once: SPF aligns through your own return-path subdomain, DKIM signs with your domain, DMARC passes, and the sending reputation accrues to you.

The SPF reality for SMTP2GO

SMTP2GO is a CNAME-based domain-authentication provider, so for the recommended setup there is NO include:spf.smtp2go.com to add to your root SPF. The clever part is how SPF is handled: when you add a Sender Domain, SMTP2GO gives you a return-path CNAME — a host like emXXXXXX.yourdomain.com (the XXXXXX is your account's numeric ID) that points to return.smtp2go.net. That subdomain becomes your envelope sender / Return-Path via SMTP2GO's VERP (Variable Envelope Return Path) technology. When a mailbox provider runs SPF, it checks the SPF record on return.smtp2go.net (which lists SMTP2GO's sending IPs) and passes — and because the envelope domain is a subdomain of your organizational domain, SPF also *aligns* for DMARC under relaxed alignment. That is why you don't touch your root SPF at all: the return-path CNAME does the job, and it adds zero DNS lookups to your public SPF record. A legacy shared include, include:spf.smtp2go.com, does still resolve, but SMTP2GO's documented method is the CNAME/VERP subdomain — and the include path is strictly worse, because with it the Return-Path stays on SMTP2GO's own domain, so SPF authorizes the mail but does NOT align to yours (leaving DMARC to lean entirely on DKIM). Bottom line: use the Sender Domain CNAMEs, leave your root SPF alone, and you get both SPF alignment and a lookup budget you didn't have to spend.

Two ways to set it up

Recommended

Sender Domain — CNAME (recommended)

SMTP2GO manages SPF via the VERP return-path subdomain and signs/rotates DKIM behind the CNAMEs
Adds zero DNS lookups to your root SPF — there's nothing to merge
SPF and DKIM both ALIGN to your domain, so DMARC passes on both
Keys and IP changes are handled on SMTP2GO's side; you never re-edit DNS

Legacy

Legacy — include:spf.smtp2go.com (not recommended)

You add v=spf1 include:spf.smtp2go.com ~all to your root SPF yourself
Costs one of your 10 SPF DNS lookups
Return-Path stays on SMTP2GO's domain, so SPF authorizes but does NOT align — DMARC then relies on DKIM alone
Only a fallback if you genuinely can't publish CNAMEs on a subdomain

Step by step

In SMTP2GO

1
Open Verified Senders
Log in at app.smtp2go.com and go to Sending → Verified Senders in the left-hand menu, then open the Sender Domains tab (not Single Sender Emails).
2
Add your sender domain
Click Add Sender Domain, enter the domain you send from (yourdomain.com — the domain in your From address), and confirm. SMTP2GO immediately generates the CNAME set for that domain.
3
Copy the three CNAME records
SMTP2GO displays three records: a return-path host (emXXXXXX → return.smtp2go.net), a DKIM host (sXXXXXX._domainkey → dkim.smtp2go.net), and a tracking host (link → track.smtp2go.net). The emXXXXXX label carries your account's numeric ID; copy every label exactly as shown. Leave this tab open — you'll come back to Validate.

In your DNS

4
Add the return-path (SPF) CNAME
At your DNS host create a CNAME: Host = emXXXXXX (exactly as shown), Value = return.smtp2go.net. This is the VERP return-path subdomain — it's what makes SPF pass AND align to your domain, so you do not add any include: to your root SPF.
5
Add the DKIM CNAME
Create a second CNAME: Host = sXXXXXX._domainkey (the DKIM selector SMTP2GO shows for your account — copy it exactly), Value = dkim.smtp2go.net. Don't paste this as a TXT record — it's a CNAME that delegates the DKIM key to SMTP2GO.
6
Add the tracking CNAME (recommended)
Create the third CNAME: Host = link, Value = track.smtp2go.net. This lets open/click links be tracked over HTTPS on your own subdomain instead of SMTP2GO's shared http domain. It's technically optional — skip it and SPF/DKIM still pass — but it's recommended for branded, secure link tracking.
7
Turn off the Cloudflare proxy
If your DNS is on Cloudflare, set each of these records to DNS only (grey cloud). An orange-cloud proxied CNAME won't resolve to *.smtp2go.net and validation will fail.
8
Publish a DMARC policy
SMTP2GO doesn't create DMARC for you. Add a separate TXT record at _dmarc.yourdomain.com — v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com — to start monitoring. Keep only one _dmarc record for the whole domain.

Verify

9
Click Validate in SMTP2GO
Back on the Sender Domains page, click Validate next to your domain. Propagation is usually minutes but can take up to 48 hours; the domain flips to Verified (green) once all CNAMEs resolve.
10
Send a real test and check the headers
Send yourself a message from an address on the verified domain, then open it in Gmail → ⋮ → Show original. You want SPF: PASS and DKIM: PASS both mapped to your domain, plus DMARC: PASS — not an smtp2go.com attribution.

Records to add

SMTP2GO generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.

Type	Host	Value
CNAME	em1234567	return.smtp2go.netReturn-path (VERP) subdomain — this is what satisfies and ALIGNS SPF. The em1234567 label carries your account's numeric ID; copy it exactly from your dashboard (the value shown here is illustrative).
CNAME	s1234567._domainkey	dkim.smtp2go.netDKIM — the sXXXXXX._domainkey selector SMTP2GO assigns your account; copy it exactly from the dashboard (label shown is illustrative). SMTP2GO holds and rotates the key behind this CNAME, so there's no TXT to paste.
CNAME	link	track.smtp2go.netOpen/click tracking over HTTPS on your own subdomain. Recommended but technically optional — SPF/DKIM pass without it.
TXT	_dmarc	v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comYour DMARC policy — one per domain, added by you, not by SMTP2GO.

Keep exactly one SPF (v=spf1) TXT record on your root domain — merge every sender into it. Two SPF records is itself an error.

The 10-lookup budget

SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what SMTP2GO's setup costs against that budget.

SPF 10-lookup budget0 used · 10 free

SMTP2GO's recommended setup adds 0 lookups — all 10 stay free for the senders that do need an include.

DKIM

DKIM is handled entirely by the sXXXXXX._domainkey CNAME (e.g. s1234567._domainkey.yourdomain.com) pointing to dkim.smtp2go.net. Because it's a CNAME delegated to SMTP2GO — not a TXT record you paste — SMTP2GO holds the private key and can rotate the published public key behind that selector without you ever touching DNS again. You do not generate a key, and there's nothing to copy into a TXT value; you only add the one CNAME exactly as the dashboard shows it (and set it to DNS only / grey cloud if you're on Cloudflare). Once it resolves, every message SMTP2GO sends from your domain is DKIM-signed and aligned, which on its own satisfies the Gmail/Yahoo "SPF or DKIM" baseline — though you'll want the return-path CNAME in place too so SPF aligns as well.

DMARC

DMARC is a separate policy record on your root domain — SMTP2GO's Verified Senders flow does not create it for you, so add it yourself. Publish a TXT record at _dmarc.yourdomain.com beginning with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none is monitor-only, so it won't affect delivery while you confirm SMTP2GO mail is passing SPF and DKIM aligned to your domain. Watch the aggregate (rua) reports for a week or two, then tighten to p=quarantine and eventually p=reject once you're confident every legitimate source aligns. Keep exactly one _dmarc record for the whole domain no matter how many senders you use — don't add a second one just for SMTP2GO. If you send bulk to Gmail or Yahoo, at least p=none with alignment is now required, not optional.

Check it actually worked

Don't trust the dashboard's green "Verified" badge alone — confirm it on a real message. Send yourself a test from an address on the verified domain, open it in Gmail and choose ⋮ → Show original: you want SPF: PASS and DKIM: PASS both showing your domain (SPF should reference the emXXXXXX return-path aligned to your org domain, DKIM the s-selector), plus DMARC: PASS. Prefer a written report? Send a test to check-auth@verifier.port25.com and it emails back a full breakdown. You can also run your domain through Qualisend's domain health check to confirm all three CNAMEs resolve and the DMARC record is valid, and once aggregate reports start arriving, drop one into the DMARC report analyzer — SMTP2GO should appear as an aligned, passing source.

Domain health check DMARC report analyzer

Common gotchas

DNS setup
Cloudflare proxy breaks it: set every SMTP2GO CNAME to DNS only (grey cloud). An orange-cloud proxied CNAME won't resolve to *.smtp2go.net and validation fails — this is the single most common cause of a domain stuck on "unverified".
DNS setup
Single Sender Emails is not domain authentication: verifying one address via the confirmation link lets you send from it but gives you no SPF/DKIM alignment. You must add a Sender Domain (the CNAME flow) for real authentication and deliverability.
DNS setup
Host-field doubling: many registrars auto-append your domain, so entering em1234567.yourdomain.com produces em1234567.yourdomain.com.yourdomain.com. Enter just the label (em1234567, s1234567._domainkey, link) if the panel adds the domain for you.
DNS setup
Don't add include:spf.smtp2go.com to your root SPF when you used the CNAME setup — it's unnecessary, wastes one of your 10 SPF lookups, and (because the Return-Path stays on SMTP2GO's domain) doesn't even give you SPF alignment. The emXXXXXX return-path CNAME already handles SPF.
DNS setup
Keep the return-path CNAME in place permanently: it is your VERP Return-Path. Deleting it later breaks SPF alignment and bounce handling, and can quietly cause DMARC to start failing on SPF.
Coverage
Copy the account-specific labels exactly: the em and s host labels are generated for your account (e.g. em1234567, s1234567._domainkey). Guessing, reusing another account's labels, or transposing digits will fail validation.
DNS setup
Add these as CNAME, not A or TXT — and don't let a DNS host "flatten" the CNAME. The DKIM record in particular is often mistaken for a TXT; it must stay a CNAME to dkim.smtp2go.net.
Breaks auth
Keep exactly one SPF TXT and one _dmarc TXT on the domain. If you also send through Google, Microsoft 365, Mailchimp, etc., merge their mechanisms into a single v=spf1 line rather than publishing a second SPF record — two SPF records is itself a PermError.

Build your SPF record

SMTP2GO doesn't need an SPF include: on your root domain — use the generator to assemble one clean record for your other senders, and keep it to a single line.

Sending sources

Search for each platform you send email through and tick it.

Search for your email platform above, or .

This domain's own servers

Authorize the domain itself, if it sends mail directly (not through a platform above).

a — the domain's own A recordmx — the domain's MX hosts

Other senders & IPs

Anything not in the list — another provider's SPF host, or specific IP addresses.

Additional includes

We add the include: prefix — enter the hostname your provider documents.

IPv4 addresses

IPv6 addresses

Policy for everyone else

What receivers should do with mail from any server not listed above (the all mechanism).

-all (fail)Strict — receivers should reject mail from any server not listed.~all (softfail)Recommended default — unlisted senders are accepted but marked suspicious.?all (neutral)No opinion — provides almost no protection; use only while testing.

Your SPF record0/10 DNS lookups

v=spf1 ~all

No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.

Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.

Authentication published? The next step is sending to a clean, verified list.

Verify a list