For current ClickFunnels native sending, connect your domain to the workspace, open Workspace Settings → Email Settings → Email Domains, and publish the DNS records generated for that email domain. Preserve existing SPF senders and DMARC policy, verify the records, then create and select a custom sender address. Completion requires a real delivered message with the intended branded DKIM signature passing and aligning, plus a DMARC pass. ClickFunnels email-domain setup.
The current documented native SPF mechanism is include:mailer.myclickfunnels.com, but use the account's current record output rather than replacing an existing policy with a canned string. DKIM is a generated 2048-bit TXT key. Website connection, email authentication and sender selection are separate steps.
Choose the right ClickFunnels sending route
This guide applies to current ClickFunnels, formerly ClickFunnels 2.0, using its built-in email service. It does not cover ClickFunnels Classic. Classic SMTP menus, plans and provider-specific recipes must not be applied to this workflow.
In Email Domains, inspect the SMTP Settings column before diagnosing authentication:
- No external SMTP connection: ClickFunnels' native servers handle the domain's sending.
- External SMTP connected: Marketing messages from that domain are routed through the connected service, such as SendGrid or Mailgun. That provider's authentication and envelope behavior must also be configured and tested.
- System emails: External SMTP is a marketing-only route in the current product. A domain linked to SMTP cannot supply the system-email custom From address in the same way; ClickFunnels documents a default system sender such as a
clickfunnelsmail.comaddress when no eligible custom sender is available.
The specific route restrictions in ClickFunnels' SMTP documentation govern this distinction. Do not treat a successful external-SMTP broadcast as proof that order, course or appointment system emails use the same From, DKIM key or Return-Path.
Prerequisites, root-domain behavior and plan limits
You need an active account, a domain connected and secured to the intended workspace, authoritative DNS access and a role allowed to use Email Settings: Funnel Builder, Marketing or Administrator. Add the Email app for marketing email work. Complete the business mailing address in Email Settings before creating broadcasts or workflow email steps. Email-domain prerequisites, getting started with email.
The website hostname and email domain are not interchangeable. Connecting a site at info.example.com can establish the root email domain example.com, allowing a sender such as contact@example.com. Current developer documentation expressly provisions sending domains at the root, not news.example.com. Confirm the email-domain row's name instead of assuming that a connected website subdomain becomes the domain after @. Sending-domain identity and ownership.
As checked November 12, 2026, ClickFunnels lists monthly email allowances of 50,000 for Launch, 300,000 for Scale, 750,000 for Optimize and 1.2 million for Dominate. Launch includes five custom domains; the other listed tiers show unlimited custom domains. Legacy subscribers retain their existing plan limits. Verify the account's actual allowance, not an old Classic plan comparison. DNS authentication does not remove sending limits. Current pricing and limits.
Shared @clickfunnelsmail.com sender addresses are documented for testing only, with a maximum of 100 emails. They are not a replacement for an authenticated custom domain for marketing. Creating a custom sending address also does not create an inbox: retain separate mailbox hosting for replies. Custom-address requirements and restrictions.
Obtain the native DNS records
Open Workspace Settings → Email Settings → Email Domains, then the gear icon beside the relevant unverified domain. You can use the documented automatic update option or copy the records manually. Before granting an automatic DNS tool access, inspect the proposed changes and their effect on existing records. Manual publication makes it easier to review individual changes in a shared zone. Native verification workflow.
Save every generated type, full owner, value and purpose:
- DKIM TXT: The complete public key at the assigned selector owner. Do not assume another account's selector or key applies.
- SPF TXT: The policy at the generated owner. The vendor's current native example authorizes
mailer.myclickfunnels.com; preserve any existing legitimate policy terms. - DMARC TXT: Review the applicable policy before applying the suggested record. A suggested monitoring value must not overwrite an existing enforcement policy or reporting arrangement.
- Return-Path CNAME: The generated bounce-handling alias. The current developer reference describes this as recommended and tracks its verification independently from native sender readiness.
The developer example uses cf2mail.example.com pointing to mailer.myclickfunnels.com, but the returned account record is what you should publish. Do not infer a universal DKIM selector or copy example keys. Public DNS and the delivered envelope still need separate validation. First-party sending-domain record reference.
Merge SPF correctly instead of replacing other senders
One owner can have multiple unrelated TXT records, but it must not have multiple independent records beginning v=spf1. If an SPF policy already exists at the generated owner, edit that policy rather than adding a second one. Preserve working ip4, ip6, a, mx, authorized includes and other intentional mechanisms; do not convert every domain reference into an include or change the final policy casually. SPF publication rules.
This fictional before-and-after example illustrates retaining an existing mechanism while adding the currently documented native include. The address belongs to a documentation-only range and must not be copied as a real sender:
Before: v=spf1 ip4:192.0.2.10 -all
After: v=spf1 ip4:192.0.2.10 include:mailer.myclickfunnels.com -all
If the account already returns a merged value, compare it with your saved policy to confirm it preserves all legitimate senders and has no unintended duplicates. Policies using redirect, macros or complex ordering need a proper evaluation rather than a text-only merge.
If the existing SPF policy uses redirect=, reconcile its authorizations with the DNS owner before changing it. An all mechanism makes redirect ineffective regardless of their order; do not append all as an automatic merge step. SPF qualifiers express authentication results, not a guaranteed receiver delivery or rejection decision. SPF all and redirect processing.
SPF permits at most ten evaluated DNS-querying terms across the full evaluation path, including nested includes and redirects. It is not simply ten includes written in your root record. ip4, ip6 and all do not consume that term budget. Review the resulting path before adding another dependency; excessive lookups can cause permerror. SPF lookup limits.
SPF evaluates the SMTP envelope domain, normally reflected in Return-Path, not automatically the visible From domain. The root record may be required for ClickFunnels' verification, while the delivered message identifies which domain the receiving server actually evaluated. Record smtp.mailfrom and its DNS path. A branded bounce subdomain can align in relaxed mode but not strict mode when it differs from From; a provider-owned envelope outside your organizational domain does not align just because SPF passes. Do not promise a particular alignment result without examining the message. SPF identity.
Publish DKIM and CNAMEs without breaking the zone
Copy the 2048-bit DKIM TXT key completely. A 255-octet limit applies to an individual DNS character-string, not necessarily the entire TXT resource record. Many providers support a long value as multiple quoted strings in one record. Confirm the DNS host's supported entry method and check that concatenation recreates the exact key. Do not shorten the key, create several independent key records or migrate DNS merely because an editor displays two strings. DKIM TXT key handling.
Calculate owner names against the actual zone. A fictional full owner key1._domainkey.example.com is key1._domainkey in a suffix-appending example.com zone. If _domainkey.example.com is already delegated, its owner there is key1. An editor requiring fully qualified names needs the full owner. The generated root-domain SPF policy belongs at @ only in an editor where @ denotes that actual root zone.
Follow existing delegation. A record hidden beneath a delegated subtree in the parent zone will not replace the authoritative child-zone answer. Do not transfer nameservers, delegate a new subtree or move the website as an incidental authentication fix.
For the issued Return-Path CNAME, and any required alias in a separately authenticated external route, apply the following controls. These do not apply to native ClickFunnels' direct-TXT DKIM key. Where literal CNAME answers are required, the end state is a DNS-only alias returning the exact issued target, without HTTP proxying or flattening hiding it. Turn the relevant per-record Flatten control off when available and ensure applicable zone-wide settings preserve those aliases. On Cloudflare, 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 behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration with the DNS owner and sending service. Do not blindly change the whole zone or remove an existing NS delegation. Cloudflare CNAME verification, flattening controls and limits.
A normal CNAME cannot share an owner with ordinary TXT, MX or address data, nor with SOA/NS at a zone apex. If the generated bounce or selector owner conflicts, stop and resolve the name with ClickFunnels and the existing service owner. Do not remove employee-mail MX, website addresses or another sender's DKIM to force a new record into place. DNS alias rules.
Preserve or carefully introduce DMARC
DMARC compares the visible From domain with authenticated SPF and DKIM domains. Either an aligned SPF pass or an aligned DKIM pass can satisfy DMARC. Relaxed mode uses the applicable organizational-domain relationship; strict mode requires an exact domain match. A native branded setup is complete only when the intended ClickFunnels DKIM signature passes and aligns, as well as DMARC passing. A pass supplied solely by SPF does not prove DKIM is configured correctly. DMARC, RFC 9989.
Inspect the direct From-domain policy and any applicable inherited policy first. Current discovery prefers a valid direct policy, otherwise finding the relevant organizational-domain or public-suffix policy. Retain p, sp, np, alignment modes and approved report destinations. Do not replace them with ClickFunnels' example p=none just to satisfy a screen. If the verifier does not recognize a valid existing arrangement, investigate with support rather than weakening it.
Only if neither a direct nor an inherited policy applies, an owner-approved monitoring starting point is:
Type: TXT
Full owner for From example.com: _dmarc.example.com
Value: v=DMARC1; p=none
In a suffix-appending example.com zone, that owner is _dmarc; an editor requiring full names needs _dmarc.example.com. If separately assessing a child From domain, its direct policy would be _dmarc.CHILD.example.com, entered as _dmarc.CHILD in the parent zone or _dmarc in the delegated child zone. These are DNS naming illustrations, not a claim that native ClickFunnels provisions arbitrary child sending domains. Publish one applicable policy at an owner, not duplicates.
p=none alone does not request reports. Append ; rua=mailto: and the actual approved reporting address to the same record if aggregate reporting is authorized. Compare the Organizational Domain of the report URI's host with the Organizational Domain of the domain where the DMARC policy was found. If they differ, the report-generating receiver must check external-destination DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. Preserve existing destinations and obtain privacy approval for sharing domain-level authentication data; do not copy a sample mailbox. More detailed failure reports need separate review. External destination verification.
Before changing enforcement or alignment, inventory all legitimate senders and relevant forwarding paths. One successful broadcast is insufficient. EmailAuth's strict-versus-relaxed alignment guide explains the domain relationships and delegated authority involved.
Verify DNS, ownership and the selected sender
Run read-only checks using your actual assigned names. Capitalized tokens are placeholders:
dig +short NS YOUR_ZONE
dig @YOUR_AUTHORITATIVE_NS DKIM_OWNER TXT +noall +answer
dig @YOUR_AUTHORITATIVE_NS SPF_OWNER TXT +noall +answer
dig @YOUR_AUTHORITATIVE_NS RETURN_PATH_OWNER CNAME +noall +answer
dig @1.1.1.1 DKIM_OWNER TXT +noall +answer
dig @1.1.1.1 SPF_OWNER TXT +noall +answer
dig @1.1.1.1 RETURN_PATH_OWNER CNAME +noall +answer
dig +short TXT _dmarc.YOUR_FROM_DOMAIN
Compare all expected authoritative answers with at least one public recursive resolver. Confirm full TXT content, a single SPF policy, the exact CNAME destination and DMARC coverage. Follow aliases to their relevant TXT data when needed. Investigate NXDOMAIN, empty responses and SERVFAIL separately; they do not all mean “wait longer.”
Return to ClickFunnels and select Verify. Its UI guide allows up to 72 hours depending on DNS timing. The newer developer reference discusses a roughly ten-minute verification cache and up to 48 hours for propagation; neither is a guarantee that a wrong record will resolve itself. Check the authoritative answer first and use current account feedback. UI verification, verification-state reference.
A verified DNS set is not the only prerequisite. ClickFunnels separates transport verification from workspace domain ownership. For the native DNS route, both are required for ready_for_sending; sender addresses then expose usable_as_sender. The return-path verification flag is separate, so readiness alone does not certify bounce-domain configuration. These documented states help explain why apparently correct email DNS can coexist with an unusable sender. Domain state definitions.
In Email Settings → Email Addresses → Add Email Address, supply the display name, internal nickname, username and verified domain. Then select the appropriate marketing and system addresses in the workspace's general email settings and check the From choice in each broadcast or workflow. Keep the SMTP/system restriction in mind. Reply-To controls responses, not DMARC alignment, and needs an actual receiving mailbox. Creating and assigning addresses.
Test delivered native and system messages separately
Have the authorized owner send representative messages to a controlled external mailbox: a native broadcast, a workflow email and any relevant system-email type. If external SMTP is also used, keep those samples in a separate validation record. A preview from the shared testing domain cannot prove the branded production route.
Use raw message source or a trace from receiving infrastructure you control or trust. An attacker can prepend Authentication-Results with a plausible authserv-id. If the receiver cannot distinguish or remove untrusted fields, obtain evidence from an independent trusted mailbox or trace. Authentication-Results security boundary.
For each route, capture the visible From, smtp.mailfrom, intended DKIM d= and s=, SPF/DKIM/DMARC outcomes and applicable alignment modes. Query the selector actually used as SELECTOR._domainkey.SIGNING_DOMAIN. If more than one signature exists, identify the intended branded signature rather than accepting any provider-only pass.
Accept native custom-domain setup only when the right From is used, the intended branded DKIM signature passes and aligns, DMARC passes, and SPF has no unexplained fault. A passing but unaligned SPF result is distinct from fail, temperror or permerror; diagnose those failures even when DKIM supplies the DMARC pass. Check the bounce-domain configuration separately. Authentication does not guarantee inbox placement or prove all campaigns and system messages share one route.
Troubleshooting and frequently asked questions
My website domain works. Why is email still unverified?
Website integration and email transport use different record sets. Open Email Domains and inspect the missing record, then check that the root sending domain is owned by this workspace. A website success indicator does not certify DKIM, SPF or DMARC.
Why does native sending remain unavailable after DNS passes?
Check domain ownership and the selected address, not just transport verification. The current native route needs both ownership and authentication. Also verify the business mailing address and account limits before investigating DNS again.
Do I need to switch DNS providers for the DKIM key?
Not automatically. First ask whether the current host supports a multi-string TXT resource record and verify the complete published key. Escalate a genuine host limitation with a planned migration only after assessing all shared DNS dependencies.
Why did system-email From change after connecting SMTP?
Current external SMTP handles marketing email only. The domain's system-email custom From eligibility changes when SMTP is associated. Inspect the actual system-message sender and use the documented eligible native custom-domain arrangement rather than assuming a marketing SMTP test covers it.
Should I add SPF again when external SMTP is enabled?
Follow the external provider's current authentication setup and inspect the actual envelope identity. Avoid duplicate policies and unnecessary authorization. The native ClickFunnels record set is not a complete SendGrid, Mailgun or other SMTP-provider configuration.
Is archiving an old address a safe way to stop its scheduled mail?
No. ClickFunnels documents that pending broadcasts and existing workflows can continue using an archived address. Review scheduled messages and workflow sender settings explicitly before retiring its DNS or domain. Address archiving behavior.
What evidence should I send to support?
Provide the workspace and domain involved, whether SMTP is connected, assigned record names, sanitized authoritative/public answers, the exact verification error and a redacted trusted receiver result. Do not share account passwords, SMTP credentials or API keys. State whether the failing sample is a broadcast, workflow or system email.
This guide reflects public documentation and standards, not hands-on customer setup. No account configuration, customer DNS edits, test sends or delivery validation were performed.