Skip to main content

Documentation Index

Fetch the complete documentation index at: https://support.jetemail.com/llms.txt

Use this file to discover all available pages before exploring further.

If you’re a hosting provider, agency, or platform reselling JetEmail to your customers, you probably don’t want spf.jetsmtp.net showing up in their DNS. You can publish your own branded SPF include on a domain you control and have customers use that instead. JetEmail does the rest.

​
How it works

SPF supports nesting. When a receiving server evaluates an SPF record and hits include:, it follows the include and evaluates that record too. Whitelabeling just means putting a thin SPF record on your own domain that includes JetEmail’s, so customers reference your brand and never see ours.

​
Setup

1

Pick a hostname on your own domain

Choose a hostname under a domain you control. Common patterns:
  • spf.yourbrand.com
  • _spf.yourbrand.com
  • mail.yourbrand.com
Anything works. Use whatever fits your branding.
2

Publish a TXT record there

At the hostname you picked, publish a single TXT record containing JetEmail’s include:
v=spf1 include:spf.jetsmtp.net ~all
That’s the whole record. No other includes, no IP mechanisms, no extras needed. JetEmail’s include already covers every IP we send from, including future expansions, so you don’t need to maintain it.
If you also send from other providers under the same brand, you can add their includes here too — but most resellers keep this record JetEmail-only and use a different hostname for other senders.
3

Have customers use your hostname in their SPF

Each customer’s sending domain still needs an SPF record at its own root. Tell them to publish:
v=spf1 include:spf.yourbrand.com ~all
Replace spf.yourbrand.com with whatever hostname you chose in step 1. Receiving servers will follow your include, then follow ours, and authenticate the mail correctly. Your brand is the only thing customers see.
4

Verify it resolves

Confirm the chain resolves before rolling it out:
dig +short TXT spf.yourbrand.com
dig +short TXT spf.jetsmtp.net
The first lookup should return your v=spf1 include:spf.jetsmtp.net ~all record. The second should return JetEmail’s actual SPF mechanisms. If both resolve, customer SPF records using include:spf.yourbrand.com will pass.

​
Things to keep in mind

  • The 10 DNS-lookup limit. SPF has a hard cap of 10 DNS lookups per evaluation. Adding your hostname adds one lookup on top of JetEmail’s includes. If a customer already chains many ESPs, this can push them over the limit. Keep customer SPF records lean.
  • Don’t add ~all or -all mechanisms anywhere except the customer’s root record. The include record itself ends with ~all but the all mechanism is only evaluated on the top-level record, not on includes. (Some DNS UIs warn about this — it’s fine.)
  • Allow any domain still requires SPF on every sender. Whitelabeling doesn’t change the Allow any domain requirement; it just lets customers point at your brand instead of ours.
  • DKIM, DMARC, and return-path CNAMEs are not whitelabeled by this. This page is SPF only. Those records still reference *.jetsmtp.net hostnames if customers add their domains in the dashboard. Most resellers either skip those records (using SMTP allow-any-domain with SPF only) or accept that backend hostnames will mention us.

​
Combining with allow-any-domain

The most common reseller setup is:
  1. One SMTP user with Allow any domain enabled (Pro plan), used by every customer’s site or server.
  2. A whitelabeled SPF include on your brand domain.
  3. Each customer publishes v=spf1 include:spf.yourbrand.com ~all at their root.
That’s the entire authentication setup customers need to see. They never have to log in to JetEmail and they never see our brand in their DNS.