SPF, DKIM & DMARC for SMTP.com.
SMTP.com is an SMTP relay and email API — you point your app, CRM, or mail server at it and it delivers on your behalf, so your own domain has to authorize it. Setup is three DNS records plus one account-side switch: a genuine SPF include (include:_spf.smtp.com) you merge into your root SPF, a custom-domain DKIM CNAME on the smtpkey selector that SMTP.com must also enable on your account so mail signs as your domain instead of its shared one, and a DMARC policy record you publish yourself. Get all three lined up and SMTP.com relays fully authenticated as you, with DKIM aligned to your From domain so DMARC passes instead of leaning on SMTP.com's shared signing domain.
Why authenticate SMTP.com?
Authenticating the domain you relay through SMTP.com decides whether your mail reaches the inbox, and for a high-volume relay the stakes are higher than for a mailbox host. Since February 2024, Gmail and Yahoo have required every bulk sender (roughly 5,000+ messages a day) to pass SPF, DKIM, and DMARC with alignment, and Microsoft began enforcing the same on high-volume mail into Outlook.com/Hotmail/Live in 2025 — exactly the volumes people run SMTP.com for. The relay-specific catch: out of the box SMTP.com DKIM-signs your outbound mail with one of its own shared domains (d=smtpsend.com) and hands off bounces on its own return-path, so neither SPF nor DKIM aligns to your From domain. That means an unconfigured SMTP.com domain has no aligned mechanism at all — DMARC can't pass, receivers can show a "via smtpsend.com" note, and the sending reputation you're paying to build pools with every other unauthenticated sender on the shared infrastructure. Enabling the SPF include and, crucially, custom-domain DKIM is what makes the mail cryptographically yours, passes DMARC, and lets reputation accrue under your own domain.
The SPF reality for SMTP.com
SMTP.com is a true "include" provider: you add one shared mechanism, include:_spf.smtp.com, to the single SPF TXT record on your root domain, giving v=spf1 include:_spf.smtp.com ~all. It is a real shared include — every SMTP.com customer uses the same one — and it's lean: the include resolves to a flat record containing only two IPv4 ranges and its own softfail (v=spf1 ip4:192.40.160.0/19 ip4:74.91.80.0/20 ~all), so it costs just ONE of your 10 SPF DNS lookups, not the two or three some cached checkers report. Here's the honest nuance that trips people up, though: adding this include authorizes SMTP.com's sending IPs, but it does not, on its own, make DMARC pass. By default SMTP.com relays with its own envelope sender / return-path domain (it processes your bounces), and SPF is always evaluated against that envelope domain — so the check passes against SMTP.com's infrastructure rather than aligning to your From domain. The include is still the correct, documented, recommended SPF step (it prevents raw SPF failures and is what SMTP.com's setup expects), which is why you should publish it — but the mechanism that actually carries your DMARC pass is the custom-domain DKIM CNAME, which signs as d=yourdomain.com. Treat the include as necessary-but-not-sufficient: publish it, then rely on DKIM for alignment (the only other route to an aligned SPF is arranging a custom return-path/bounce domain on your own domain with SMTP.com, which most accounts skip in favor of DKIM). And keep exactly one SPF record on the domain — if you also send through Google Workspace, Microsoft 365, or another tool, merge include:_spf.smtp.com into that single v=spf1 line rather than publishing a second SPF TXT (two SPF records is a PermError).
Step by step
- 1
Identify the domain you relay as
Log in to the SMTP.com Control Panel and note the From domain your app/API sends as (the domain in your From: header, e.g. yourdomain.com). SMTP.com relays mail for whatever From address you set, so authentication is done on that organizational domain — not on an SMTP.com-owned host. This is also where your Sender/relay credentials and Reputation Defender settings live.
- 2
Add or merge the SPF include
At your DNS host, create ONE TXT record on the root (host @ or blank) with v=spf1 include:_spf.smtp.com ~all. If a v=spf1 record already exists (Google Workspace, Microsoft 365, another relay), don't add a second one — merge include:_spf.smtp.com into that single record alongside the other mechanisms. Keep the ~all softfail SMTP.com uses unless you're certain every sender is listed.
- 3
Turn on custom-domain DKIM signing
By default SMTP.com signs with its shared domain (d=smtpsend.com), which does NOT align. To have mail signed as d=yourdomain.com on the smtpkey selector, custom-domain DKIM signing has to be enabled on your account — this is an account-side switch, so request it via SMTP.com support or your account manager and confirm the exact selector/target they assign you (the widely published pair is below).
- 4
Add the DKIM CNAME
Create a CNAME record: host smtpkey._domainkey (so smtpkey._domainkey.yourdomain.com) pointing to smtpcustomer._domainkey.smtpsend.com. This is a delegation — SMTP.com holds the private key behind that shared target and signs on your behalf. Keep the type as CNAME; don't switch it to TXT or A.
- 5
Publish the DMARC record
SMTP.com doesn't create DMARC for you. Add a TXT record at host _dmarc with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none is monitor-only, so nothing about delivery changes while you confirm SMTP.com's mail is signing and aligning; you'll tighten it later.
- 6
Fix host doubling and the Cloudflare proxy
If your registrar auto-appends the domain, enter just the label (smtpkey._domainkey, and @ for SPF) so you don't end up with smtpkey._domainkey.yourdomain.com.yourdomain.com. On Cloudflare, set the DKIM CNAME to 'DNS only' (grey cloud) — an orange-cloud proxied CNAME won't resolve to smtpsend.com and DKIM validation fails.
- 7
Send a test and read the headers
Once custom DKIM is enabled and the records propagate (usually minutes, up to 24–72 hours), relay a test through SMTP.com to a Gmail address, open it, and choose ⋮ → Show original. You want DKIM: PASS with d=yourdomain.com and selector smtpkey (the tell-tale failure is d=smtpsend.com, meaning custom signing isn't live yet), SPF: PASS, and DMARC: PASS.
- 8
Confirm every record resolves
Run your domain through Qualisend's domain health check to confirm the SPF stays at one record under the 10-lookup limit, the smtpkey._domainkey CNAME resolves to smtpsend.com, and the DMARC record is present. Once aggregate reports start arriving, drop one into the DMARC report analyzer to see SMTP.com show up as an aligned, passing source.
Records to add
SMTP.com generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.
| Type | Host | Value |
|---|---|---|
| TXT | @ | v=spf1 include:_spf.smtp.com ~allRoot SPF — keep exactly ONE SPF record; merge this include if you already have a v=spf1 line. include:_spf.smtp.com resolves flat (two ip4 ranges + ~all) so it costs 1 DNS lookup. Authorizes SMTP.com's IPs but does not align by default. |
| CNAME | smtpkey._domainkey | smtpcustomer._domainkey.smtpsend.comCustom-domain DKIM (the aligned mechanism). Illustrative — this is the widely documented shared target, but confirm the exact selector/target SMTP.com assigns your account. SMTP.com must ALSO enable custom signing account-side, or the CNAME does nothing. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comYou add this yourself — SMTP.com never creates it. One DMARC record per domain; start at p=none, then tighten to quarantine/reject once DKIM aligns cleanly. |
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 SMTP.com's setup costs against that budget.
SMTP.com adds 1 of your 10 lookups; ip4: and ip6: mechanisms are free.
DKIM
DKIM is the part that actually earns your DMARC pass with SMTP.com, and it's the step most people miss because SMTP.com is "already signing" before you do anything — just with the wrong domain. By default the relay DKIM-signs your outbound mail using one of its own shared domains (d=smtpsend.com). That signature is cryptographically valid, but because it isn't your domain it does not align, so it does nothing for DMARC on yourdomain.com. To fix that you enable custom-domain DKIM, which is two coordinated actions: (1) publish a CNAME at smtpkey._domainkey.yourdomain.com pointing to smtpcustomer._domainkey.smtpsend.com, and (2) have SMTP.com switch your account to sign with your domain on the smtpkey selector — this is an account-side toggle that's typically arranged through SMTP.com support or your account manager, so open a ticket and confirm the exact selector/target they issue you (some accounts may be given a different pair). Because the record is a CNAME (not a TXT key you paste), SMTP.com holds the private key behind that shared target and can rotate it without you touching DNS again — the trade-off of the shared-target model is that the key isn't unique to you, but alignment doesn't depend on key uniqueness: what matters is that the signature's d= value is your organizational domain, which it becomes once custom signing is on. The published record on your side is small and static; the heavy lifting (the actual signing) happens on SMTP.com's servers. Until BOTH the CNAME resolves AND custom signing is enabled, Show original will keep reporting d=smtpsend.com and DMARC will have no aligned mechanism.
DMARC
DMARC is a separate policy TXT record on your domain that SMTP.com does not create — you publish it at your DNS host. Add a TXT record at _dmarc.yourdomain.com starting with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none is monitor-only: it changes nothing about delivery but tells receivers to email you aggregate (rua) reports so you can confirm SMTP.com mail is passing DKIM aligned to your domain before you enforce anything. This monitoring step matters more than usual with SMTP.com precisely because its SPF doesn't align by default — the reports are how you verify the custom DKIM CNAME is actually carrying the alignment. Watch them for a week or two, make sure every legitimate source (SMTP.com plus any other senders) is authenticating, then tighten the policy to p=quarantine and eventually p=reject. Do NOT go straight to a strict policy before confirming DKIM signs as d=yourdomain.com — if custom signing isn't enabled yet, a p=reject record will bounce your own relayed mail. Keep exactly one _dmarc record for the whole domain regardless of how many senders you use; never add a second DMARC record specifically for SMTP.com.
Check it actually worked
Don't trust the Control Panel or a propagation timer alone — confirm authentication on a real message. Relay a test through SMTP.com to a Gmail (or Outlook) mailbox, open it, and choose ⋮ → Show original. You want DKIM: PASS with d=yourdomain.com and selector smtpkey — if you see d=smtpsend.com, custom signing isn't live yet, so the CNAME is published but SMTP.com hasn't switched your account. You also want SPF: PASS (it will pass, though remember it's aligned to SMTP.com's envelope, not your domain, unless you've arranged a custom return-path) and DMARC: PASS, which here should be earned by DKIM alignment. Prefer a full report? Send a test to check-auth@verifier.port25.com and it emails back a line-by-line breakdown. Then run the domain through Qualisend's domain health check to confirm your SPF is a single record under the 10-lookup limit, the smtpkey._domainkey CNAME resolves cleanly to smtpsend.com, and DMARC is present — and once aggregate reports arrive, drop one into the DMARC report analyzer to see SMTP.com appear as an aligned, passing source.
Common gotchas
- DNS setup
The SPF include passes but does NOT align by default. By default SMTP.com relays with its own return-path/envelope domain, so include:_spf.smtp.com authorizes the IPs and passes the raw SPF check against SMTP.com — not against your From domain. Adding the include alone will not give you a DMARC pass; the custom DKIM CNAME does.
- Breaks auth
Out of the box, DKIM signs as d=smtpsend.com (SMTP.com's shared domain), which validates but does not align. You must enable custom-domain DKIM so mail signs as d=yourdomain.com on the smtpkey selector — otherwise DMARC has no aligned mechanism at all.
- Breaks auth
Custom DKIM is an account-side switch, not just a DNS record. Publishing the smtpkey._domainkey CNAME does nothing until SMTP.com enables custom signing for your account — open a support ticket / ask your account manager, then confirm the exact selector and target they assign you.
- DNS setup
The DKIM CNAME target is a shared host (smtpcustomer._domainkey.smtpsend.com) and that's by design, not a copy-paste error. SMTP.com holds the private key behind it and rotates it for you; alignment still works because the signature's d= is your domain. Keep it a CNAME — never a TXT.
- DNS setup
Cloudflare proxy breaks the DKIM CNAME. Set smtpkey._domainkey to 'DNS only' (grey cloud) — an orange-cloud proxied CNAME won't resolve to smtpsend.com and DKIM enable fails.
- Breaks auth
Keep exactly ONE SPF TXT record on the root. If you already send via Google Workspace, Microsoft 365, or another relay, merge include:_spf.smtp.com into that single v=spf1 line — two SPF records is itself a PermError.
- DNS setup
Host-field doubling: many registrars auto-append your domain, so entering smtpkey._domainkey.yourdomain.com produces smtpkey._domainkey.yourdomain.com.yourdomain.com. Enter just the label (smtpkey._domainkey, and @ for the SPF record) if the panel adds the domain for you.
- Coverage
Use the ~all that SMTP.com's include ships with unless you've inventoried every sender. A premature -all can hard-fail legitimate mail from a tool you forgot to add to the same SPF line.
Build your SPF record
SMTP.com is pre-selected below. Add any other platforms you send through, then publish the single merged record.
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
- 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 listSMTP.com SPF — FAQ
Related reading
Once it's published, confirm everything resolves with the domain health check, then read who's sending as you with the DMARC report analyzer. Browse all sending sources in the generator. Authentication is only half of deliverability, though — a listed sending IP or domain still lands you in spam no matter how clean your SPF is, so it's worth watching the blacklists with blacklist monitoring.
Authenticated — now keep the list clean
Passing SPF, DKIM, and DMARC gets you to the inbox; a clean list keeps you there. Verify yours — start free with 100 credits, no card required.