← Blog

Sending email from your customers' domains

August 14, 2026 by Mailer To Go
Building a helpdesk, CRM, or platform that sends on behalf of your customers' domains? How to choose between sending from your own domain and provisioning DKIM for theirs, and how to avoid the 550 sender is unacceptable rejection.

If you’re building a multi-tenant app (a helpdesk, CRM, or any platform that sends email on behalf of your customers), you eventually hit one question: should mail go out from your domain or theirs? Get it wrong and messages bounce with 550 sender is unacceptable. Here is the model that works on MailerToGo.

The two approaches

Send from your own domain (for example support@yourapp.com) and put the customer’s address in Reply-To. It works immediately, needs no customer DNS setup, and keeps deliverability fully under your control. This is what Zendesk, Intercom, and most SaaS helpdesks do by default.

2. Customer domain (better brand and deliverability)

Provision a DKIM key for the customer’s domain so mail is signed as theirs. This requires the customer to add DNS records, but it gives brand consistency and, once DKIM and DMARC align on their own domain, better deliverability.

Most platforms offer both: start every tenant on the platform sender, and let customers upgrade to their own domain when they are ready.

What happens if you skip DKIM provisioning

This is the trap. If your app sends from a customer domain that has no DKIM key provisioned on MailerToGo, one of two things happens: the message is rejected (550 sender is unacceptable), or the envelope sender is rewritten to your default domain as a fallback.

Neither is something to build on. A rejection means dropped customer mail. A silent envelope rewrite means your DMARC alignment quietly breaks. We have seen this exact failure in the wild: an app sending as info@customerdomain.com with no DKIM provisioned, and every message bouncing 550 sender is unacceptable.

Don’t rely on the fallback. Decide the sender in your own code.

Track, per customer, whether their sending domain is verified on MTG. Pick the MAIL FROM accordingly, and fall back to your platform domain when it is not:

# Ruby
PLATFORM_DOMAIN = "yourapp.com"

def sender_for(customer)
  if customer.sending_domain_verified?
    { from: "support@#{customer.domain}" }                 # signed as theirs
  else
    { from: "support@#{PLATFORM_DOMAIN}",                  # your domain
      reply_to: customer.support_address }                 # replies still reach them
  end
end

// Node
const PLATFORM_DOMAIN = "yourapp.com";

function senderFor(customer) {
  return customer.sendingDomainVerified
    ? { from: `support@${customer.domain}` }
    : { from: `support@${PLATFORM_DOMAIN}`, replyTo: customer.supportAddress };
}

A few things to get right:

Provisioning a customer’s domain

When a customer wants mail sent as their own domain:

  1. Add a sending subdomain on MailerToGo. Use a dedicated subdomain like mtg.customerdomain.com rather than the root domain. It isolates sending reputation and is the pattern MTG is built around. See Why MailerToGo sends from mtg.yourdomain.com.
  2. Have the customer publish the DNS records. The simplest path is a single delegated NS record: MailerToGo then manages SPF, DKIM, and DMARC for that subdomain for them. The manual path, publishing the SPF, DKIM, and DMARC TXT records yourself, is also supported if the customer prefers to own the records. See Use a subdomain for sending email.
  3. Verify, then flip the flag. Once MTG reports the domain verified, set sending_domain_verified = true for that customer and start sending as their domain.

Until step 3 completes, keep the customer on your platform sender. New tenants can send from day one, and upgrade to their own domain with zero downtime.

TL;DR