SMTP.com SPF and DKIM setup

What you are setting up

SMTP.com is a transactional relay: your app or mail client hands mail to it over SMTP or the API, and SMTP.com delivers it. Out of the box it DKIM-signs everything with one of its own shared domains, which authenticates but does not align to your From domain. You fix that with two DNS records, an SPF include and a DKIM CNAME, so SMTP.com signs as you. Unlike most ESPs, publishing the records is not the last step: SMTP.com support has to switch the signing on.

Publish SPF and DKIM

In the SMTP.com dashboard, open the Account dropdown in the navigation bar and choose Manage Sending Emails and Domains to verify your domain with SPF and DKIM. The records to publish at your DNS host:

Type:  TXT     (SPF)
Host:  @
Value: v=spf1 include:_spf.smtp.com ~all

Type:  CNAME   (DKIM)
Host:  smtpkey._domainkey
Value: smtpcustomer._domainkey.smtpsend.com

If you already have an SPF record, edit it and add include:_spf.smtp.com before the ~all rather than creating a second record; two v=spf1 records make both invalid. The DKIM selector is smtpkey and the CNAME target is the same for every customer, so there is no key to copy. One exception: SMTP.com's docs say GoDaddy users should name the host smtpmail._domainkey instead, with the same target. SMTP.com also offers a TXT option, where support generates a key pair and hands you the selector and public key to paste; the CNAME is simpler and sidesteps the 255-character TXT limit that long keys trip on.

Wait up to an hour for the records to resolve, confirm the selector answers with our DKIM checker, then contact SMTP.com support and tell them which method (TXT or CNAME) and which domain and selector you used. They enable DKIM signing on their side; until they do, your mail keeps going out under the shared signature.

Add DMARC

Standard _dmarc TXT record, nothing SMTP.com-specific. Start in monitor-only mode and ramp up:

Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

SMTP.com's own advice matches ours: get custom DKIM and SPF verified first, sit at p=none while you read reports, then tighten. Build the record with our DMARC builder and progress past p=none once your reports are clean.

The SMTP.com gotcha

The DNS record alone does nothing. With most senders, a green check appears the moment the CNAME resolves. With SMTP.com, signing under your domain only starts after you tell support the record is live and they flip it on. If your reports still show SMTP.com signing with one of its shared domains a day after you published the CNAME, that is the missing step, not a DNS problem. The second thing to know is that SMTP.com's documentation covers SPF for the domain you send from and does not describe a custom bounce or Return-Path domain. Treat the DKIM signature as the record that carries DMARC for this source; if your reports show SMTP.com passing DKIM but SPF not aligned, that is why, and DMARC still passes.

Confirm it worked

• Check the domain in SMTP.com. Under Manage Sending Emails and Domains, your domain should show SPF and DKIM verified, and support should have confirmed signing is enabled.
• Send a test and read the headers. Relay a message through SMTP.com to a Gmail address, open it, and confirm the DKIM signature shows d=yourdomain.com and dmarc=pass. Our header analyzer reads it back plainly.
• Watch the reports. SMTP.com should appear as an aligned, passing source in your DMARC aggregate reports, labeled as a known sender in trustyourinbox.