iContact SMTP Settings and Configuration (2026)

If you came here for a host and port to paste into WordPress or a monitoring agent, iContact offers none and no setting will make one appear. The useful answer splits three ways: authenticate your sending domain so campaigns pass SPF, DKIM and DMARC; drive iContact from your own code through its REST API; and put a real relay behind anything transactional. If you are still choosing a platform, the closest list-and-campaign peers are Constant Contact, AWeber, GetResponse and Mailchimp-and of those only Mailchimp offers a relay, as a paid add-on.

Quick reference

Why iContact has no SMTP relay

iContact is a marketing-first ESP and its whole documented surface is list-and-campaign shaped: contacts, lists, subscriptions, segments, messages, campaigns and sends. Every send is addressed to an audience, not to an individual recipient handed over at connection time. An SMTP relay is the opposite shape, a stateless pipe that takes one envelope at a time and asks nothing about consent. Bolting that on means a second reputation model, a second suppression system and a second billing model, which is why most ESPs in this bracket skip it.

The absence is structural, not an oversight. iContact’s published article index contains no relay hostname, no port table and no transactional-send topic, and the three official PHP libraries on github.com/icontact contain HTTP calls only. Read this as a high-confidence assessment of the published surface rather than a quotation: iContact has never published a page saying “we do not offer SMTP”, it simply has no SMTP pages.

What you actually need instead

Sending transactional email

Receipts, password resets and order confirmations should not run through a marketing ESP even when one offers a relay. Put that traffic on a dedicated relay, on its own subdomain, isolated from your newsletter’s reputation. Postmark suits modest volume where receipt deliverability outweighs price; Amazon SES wins on unit cost at scale; SMTP2GO and MailerSend sit in between; Resend suits teams templating in code. Each gets its own DKIM key and SPF include.

Connecting a CMS or an application

If the goal is pushing contacts from your site into iContact or triggering a campaign from your app, the REST API is the supported path. Every call is scoped as /icp/a/{accountId}/c/{clientFolderId}/{resource}: GET /a/ for the account ID, GET /a/{accountId}/c/ for the client folder ID, then contacts, subscriptions, messages and sends underneath. Authentication is three custom headers-Api-AppId, Api-Username, Api-Password-plus Api-Version: 2.2. Call the API directly rather than importing the official PHP wrapper: its last commit was January 2, 2018, no Python, Node, Ruby, Java or Go client exists, and the PHP code disables TLS peer verification.

For WordPress, note the split: the official iContact Lead Forms plugin embeds subscribe forms and pushes signups into your lists, but does not make WordPress send its own mail through iContact. Password resets, WooCommerce order emails and form notifications still leave through PHP mail() unless an SMTP plugin points them at a relay. No-code teams can cover most contact-sync work with the official Zapier app, with 8 triggers and 8 actions including Send HTML Message.

Routing system and server notifications

Cron output, backup reports, uptime alerts and CI failures need a plain SMTP endpoint, and this is the request iContact cannot satisfy. Point them at a relay that publishes standard ports and accepts arbitrary recipients: Amazon SES, SMTP2GO, Brevo or Elastic Email, most free at notification volumes. Keep them on an operational subdomain such as alerts.example.com: machine mail is high-volume, low-engagement and often addressed to dead mailboxes.

Sending domain authentication

This is the part that actually matters for iContact, and the work most people are really after when they search for SMTP settings. Since the Gmail, Yahoo and Microsoft bulk-sender rules took effect, a sender without aligned authentication is not at a disadvantage, it is rejected or filed as spam.

SPF and DKIM setup

iContact generates your DKIM records per account, and the setup uses both CNAME and TXT record types, so a checker looking for only one gives a false negative. Take the literal names and values from the iContact interface, never from a blog or the Campaigner relay pages below; selectors are account-specific and a wrong one fails silently.

; iContact Custom DKIM, record TYPES are documented; the literal names
; and values are per-account. Copy them from the iContact UI.

SELECTOR._domainkey.example.com.   IN   CNAME   VALUE-SHOWN-IN-ICONTACT
SELECTOR._domainkey.example.com.   IN   TXT     "v=DKIM1; k=rsa; p=KEY-SHOWN-IN-ICONTACT"

; SPF, ONE TXT record per domain. Merge iContact's include into the
; existing record. Never publish a second v=spf1 line.
example.com.                       IN   TXT     "v=spf1 include:INCLUDE-HOST-SHOWN-IN-ICONTACT ~all"

; Verify after propagation
dig +short CNAME SELECTOR._domainkey.example.com
dig +short TXT   example.com

Two rules govern the SPF line regardless of provider. A domain may publish exactly one v=spf1 TXT record, two is a permanent error, so if Google Workspace or Microsoft 365 is already there, merge iContact’s include into the existing string. And SPF permits at most 10 DNS lookups, each include: costing one; a domain carrying a mail host, a CRM, a help desk, iContact and a relay can breach that ceiling and start failing with no visible change. iContact publishes a GoDaddy and Cloudflare guide; on Cloudflare, leave DKIM CNAMEs DNS-only rather than proxied.

DMARC alignment

DMARC passes only when an authenticated identity aligns with the visible From domain. With Custom DKIM in place your signing domain matches your own and DKIM alignment holds, the entire point of the custom setup. SPF behaves differently: the envelope return-path belongs to the provider’s bounce domain, so SPF may authenticate while failing alignment. That is normal, because DMARC needs only one aligned mechanism, but it means DKIM does the real work, and a broken DKIM record takes DMARC with it.

; Start in monitor mode and read the reports before tightening
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100"

; After 2-4 weeks of clean aggregate reports, ramp gradually
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com"

Publish p=none first, collect aggregate reports for at least two weeks, and confirm iContact sends appear as DKIM-aligned passes before moving to quarantine. iContact keeps a warning article, DMARC Reject Policy and Email Deliverability, because a premature p=reject destroys campaign delivery instantly and looks like a deliverability problem rather than a DNS one.

Sending limits

iContact publishes no numeric throughput figures, and this page will not invent them. The documented constraint is commercial rather than technical: your ceiling is a contact or subscriber count set by your plan tier, and crossing it changes your invoice rather than stopping your send.

An approval-gated Pay Per Send mode also exists, which matters if your volume is spiky rather than steady. Audit contact statuses before any bulk import: under a contact-based plan, records you assumed were inert still count toward the ceiling.

Common mistakes

Pairing iContact with an SMTP provider

The recommended setup

Run two senders, cleanly separated by subdomain. Keep marketing on the domain you already send campaigns from, say news.example.com-authenticated with iContact’s Custom DKIM records. Put transactional traffic on a second subdomain such as mail.example.com, authenticated by the relay’s own DKIM key. Each builds its own reputation, so a bad campaign week cannot drag password resets into spam, and both inherit your DMARC policy at _dmarc.example.com.

Keep the systems of record separate too. iContact owns consent, list membership and unsubscribes; the relay owns nothing but delivery. Do not route marketing through the relay to save money, and do not push transactional recipients into an iContact list: buying a product is not opting into a newsletter.

Keeping the two systems from colliding

Three collisions are worth designing against. The first is DMARC: two senders on one domain means two DKIM keys and two SPF includes, and adding the relay’s include to your root record can push past the 10-lookup limit and break iContact’s authentication. Separate subdomains avoid it, because each carries its own SPF record and lookup budget.

The second is double-sending. If a signup triggers both an iContact welcome automation and a transactional welcome from your app, the customer gets two emails seconds apart. Decide once who owns each lifecycle message: purchase and account events belong to the relay, time and segment triggers to iContact.

The third is suppression. An unsubscribe in iContact does not exist in your relay, and a hard bounce in your relay does not exist in iContact. Neither tells the other. Use iContact’s Web Hooks resource plus its bounce and unsubscribe endpoints to mirror suppression into your own database, and treat that database as the authority both systems read before a send. Otherwise you keep mailing addresses half your stack knows are dead.

Frequently asked questions