How to Send HubSpot Transactional Emails From Your Own Domain (And Why It Matters)

Why Your Transactional Emails Might Be Failing Without You Knowing

You spend hours perfecting your HubSpot workflows. Welcome sequences that drip over weeks. Abandoned cart reminders. Password reset emails that actually get opened.

But here's the uncomfortable truth: when your customer gets that password reset email, their email client might be showing a warning that says " Gmail couldn't verify that yahoo.com actually sent this message."

That's not a good look for your brand.

HubSpot's transactional email system is solid — until you look at the authentication headers. By default, HubSpot signs these emails with their own DKIM keys, not yours. And when Google's authentication checks run, they see a mismatch: the From address says you@yourcompany.com, but the DKIM signature says header.d=hubspot.com.

This is a DMARC alignment failure. And for transactional emails — the ones that matter most because users actually act on them — this is a problem.

The Difference Between Marketing and Transactional Email

Before we fix anything, let's clarify what we're dealing with.

HubSpot's marketing emails go through their dedicated sending infrastructure. They have a whole deliverability team managing IP reputation, warming, and sender scores. For bulk campaigns, this is fine.

Transactional emails are different. These are one-to-one communications triggered by user actions: password resets, order confirmations, form submissions, invoice receipts. Users expect these to come directly from your company. And email clients treat them differently — they run stricter authentication because transactional emails are high-value targets for phishing.

When HubSpot sends these through their infrastructure with their signature, you're borrowing their reputation instead of building your own.

Introducing MailKite: Your Domain's Email Identity

MailKite is an SMTP relay service that sits between your application and the recipient's mail servers. The key feature: it signs every outgoing email with your DKIM key, not theirs.

This means:

• DMARC alignment passes. Your From domain matches your DKIM signature.
• Your domain reputation builds. Each email sent through your domain contributes to your sending history.
• Full logging and analytics. See exactly what emails went where, with delivery status.
• Retries and failovers. If a recipient's server is temporarily unavailable, MailKite handles the retry logic.

The setup is refreshingly straightforward.

Step-by-Step: Routing HubSpot Through Your Domain

Step 1: Claim Your Domain in MailKite

Sign up for MailKite and add your sending domain. You'll need access to your DNS settings (if you're managing DNS elsewhere, this takes 5 minutes; if you're using NameOcean's DNS management, it's even faster through our dashboard).

MailKite will give you three DNS records to publish:

• An MX record for inbound email routing
• A TXT record for SPF
• A DKIM record for email signing

Once these propagate (usually 5-30 minutes), your domain is verified.

Step 2: Get Your SMTP Credentials

In the MailKite dashboard, create an SMTP user. Copy the server address, port, and API key. You'll need these for HubSpot.

Here's what you're looking at:

Server: smtp.mailkite.dev
Port: 587
Username: Your MailKite username
Password: Your API key (starts with mk_live_)
Security: STARTTLS required

Step 3: Configure HubSpot's SMTP Relay

In HubSpot, navigate to Settings → Transactional Email. You'll find the SMTP configuration under your sending domain settings.

Paste in your MailKite credentials. HubSpot will send a test email — verify you receive it.

Step 4: Test Your Authentication Headers

Don't skip this step. Send a test transactional email through your HubSpot workflow. Then open it in Gmail and check the headers.

Look for this:

Authentication-Results: mx.google.com;
    dkim=pass header.d=yourcompany.com;
    spf=pass;
    dmarc=pass

All three should show pass. If dkim shows header.d=hubspot.com, something in your configuration needs adjustment. Check that your sending domain in HubSpot matches your MailKite-verified domain exactly.

SMTP vs. API: Which Should You Use?

HubSpot offers two ways to send transactional email. Here's the practical breakdown:

Use SMTP when:

• You want a simple configuration that works for all HubSpot emails automatically
• You're sending from external systems (a Laravel app, WordPress plugin, or custom CRM)
• You want MailKite's logging and retry logic for every email
• You're not relying on HubSpot's open/click tracking for transactional messages

Use the API when:

• You need HubSpot's native open/click analytics for transactional emails
• You want each email to appear in HubSpot's timeline automatically
• You're building a custom integration where email events trigger other workflows

The honest answer? SMTP is easier to maintain. Once configured, every transactional email from HubSpot routes through MailKite without additional code. The API requires you to update every send call.

Bonus: Capturing Replies and Routing Them to HubSpot

Here's where it gets powerful. When customers reply to your transactional emails, those replies need to go somewhere. With MailKite's inbound routing, you can POST incoming replies to a webhook.

Want those replies attached to the correct contact in HubSpot? Here's a Cloudflare Worker that handles this:

export default {
  async fetch(request, env) {
    if (request.method !== "POST") return new Response("OK");
    
    const { from, subject, text } = await request.json();
    
    // Find the matching contact in HubSpot
    const searchRes = await fetch(
      "https://api.hubapi.com/crm/v3/objects/contacts/search",
      {
        method: "POST",
        headers: {
          Authorization: "Bearer " + env.HUBSPOT_API_KEY,
          "Content-Type": "application/json",
        },
        body: JSON.stringify({
          filterGroups: [{
            filters: [{
              propertyName: "email",
              operator: "EQ",
              value: from,
            }]
          }],
          properties: ["email", "firstname", "lastname"],
        }),
      }
    );
    
    const { results } = await searchRes.json();
    if (!results.length) return new Response('{"ok":true}', { status: 200 });
    
    const contactId = results[0].id;
    
    // Attach the reply as a note
    await fetch(
      "https://api.hubapi.com/crm/v3/objects/notes",
      {
        method: "POST",
        headers: {
          Authorization: "Bearer " + env.HUBSPOT_API_KEY,
          "Content-Type": "application/json",
        },
        body: JSON.stringify({
          properties: {
            hs_note_body: `Reply to: ${subject}\n\n${text}`,
            hs_timestamp: Date.now(),
          },
          associations: [{
            to: { id: contactId },
            types: [{
              associationCategory: "HUBSPOT_DEFINED",
              associationTypeId: 202,
            }],
          }],
        }),
      }
    );
    
    return new Response('{"ok":true}', { status: 200 });
  },
};

Now every customer reply becomes a note on their contact record in HubSpot — complete with the original subject line.

The Bigger Picture: Email Is Part of Your Domain Strategy

This isn't just about email deliverability. Your domain is your digital identity. Every email, every DNS lookup, every authentication check either builds or erodes trust in that identity.

When you route transactional email through your own DKIM-signed domain:

• Gmail and Outlook trust your emails more
• Your sender reputation grows independently of any platform
• Customers see your brand, not a vendor's
• Your domain becomes more valuable as an asset

At NameOcean, we see customers who treat domains as throwaway purchases vs. those who understand them as infrastructure. Email authentication — DMARC, DKIM, SPF — is as fundamental as your website's uptime.

Your transactional emails are often the most important communications you send. They deserve the same brand care as your landing pages and your product itself.