Custom Domain Email: In Development

Right now, when your church sends an email campaign through Ekkli, it goes out from Ekkli's own shared sending infrastructure — not from an address at your-church.org. Letting a church send campaign email through its own domain, so it arrives looking like it came directly from your-church.org rather than a shared Ekkli address, is not built. This page exists to be straightforward about that gap, not to sell you on it.

What's real today, and what this page is actually about

It's worth separating two different things that both involve the phrase "custom domain," because they're easy to mix up and only one of them exists:

• Custom domain for your church website — real, built, available today on paid plans. If your church is on a paid plan, your public Ekkli website can run on your own domain (your-church.org) instead of an Ekkli subdomain, and the "Powered by Ekkli" footer comes off. This is live functionality, not a roadmap item.
• Custom domain for sending campaign email — not built, the subject of this page. Even on a paid plan today, when your church sends a newsletter or announcement through Ekkli's email campaigns, the message is sent from Ekkli's own shared sending domain, not from an address at your-church.org. That's the gap.

If you only remember one thing from this page, remember that distinction. Your website's address bar and your outgoing campaign email's "from" domain are two separate systems in Ekkli, and only the first one is customizable today.

What would change if this were built

The practical difference a custom sending domain would make: your church's newsletters and announcements would arrive with a from-address at your own domain instead of a shared one, which can help with recipient trust and, for churches that care about it closely, with inbox deliverability signals that depend on sender domain reputation. That's the shape of the idea. We haven't built the verification flow, the DNS setup a church admin would need to walk through, or the sending infrastructure changes underneath it — so we can't describe those specifics honestly, and we won't pretend to.

Why custom-domain sending matters, in general (not an Ekkli claim)

The two paragraphs below are general, well-established email-industry background — how this problem is understood across email platforms generally, not a description of anything Ekkli has built or decided how to build. We're including it because it explains why the gap above is worth caring about, not because we're announcing a design.

Across the email industry, sending from an organization's own domain instead of a shared platform domain is understood to improve recipient trust, because the "from" address matches the sender a recipient actually recognizes — This email address is being protected from spambots. You need JavaScript enabled to view it. reads as more legitimate than a generic shared address ever will. It also lets an organization build and maintain its own sender reputation, rather than sharing reputation with every other organization on the same shared domain. The standard technical mechanism, industry-wide, is a set of DNS records — SPF, DKIM, and DMARC — that mail providers check to confirm a message was actually authorized to be sent from the domain it claims. SPF lists which servers may send for a domain, DKIM attaches a cryptographic signature proving the message wasn't altered in transit, and DMARC tells receiving servers what to do if those checks fail and gives the domain owner visibility into who's sending mail as them. Together, these three records are the mechanism nearly every legitimate sending-domain setup relies on.

This matters more for churches and nonprofits than for some other senders, specifically because they're frequent targets of spoofing and phishing — scammers impersonating a pastor or church office to ask a member for gift cards or an urgent wire transfer is a well-documented pattern, and it has made many congregants understandably more cautious of email claiming to be from their church. A recognizable, authenticated own-domain sender address is one of the few signals an ordinary recipient can see and trust at a glance, and industry data on email generally shows authenticated, own-domain sending tends to correlate with better open rates than mail from an unfamiliar shared address. None of this describes how Ekkli's eventual implementation would work, what a church admin would need to configure, or when it would ship — those decisions haven't been made. It's here so that if you're wondering why a custom sending domain is worth having at all, you have an honest, general answer instead of a marketing one.

What you can do today instead

Everything else in Ekkli — the parts that are actually built — works the same whether or not this ever ships. That includes consent-aware email campaigns sent from Ekkli's shared domain, your church's website on your own custom domain if you're on a paid plan, worship display, member database, rota, and event registration, all on the six-month free trial for churches up to 50 people.

Tell us if this matters to your church

We don't have a dedicated signup list for this specific feature, and we're not going to invent one just to make this page feel more active than the underlying plan is. What we do have is a real way to hear from you: if a custom sending domain for email would change whether Ekkli works for your church, let us know through our contact form. Genuine interest from real churches is one of the things that turns an idea on a list into an actual build — it isn't a promise of when, but it does get read and factored in.

This page describes a gap honestly rather than a feature that exists. If you're evaluating Ekkli against another platform's custom-domain email capability, plan your decision around what's built today — see email campaigns for what Ekkli's email sending actually does right now, and pricing for what's included at each plan.