How to migrate Multiple Domains from SendGrid to AhaSend

If you're a hosting company, SaaS platform, or managed email provider running transactional email on behalf of dozens or hundreds of customer domains, migrating from SendGrid to AhaSend requires a bit more planning than a single-domain switch. The good news: with the right DNS architecture in place, you can migrate each customer domain with a 30-minute maintenance window and zero permanent DNS changes on the customer's side after the initial setup.

This guide walks through the full process, from preparation to live cutover.

The architecture: why a DNS relay layer matters

When you manage email for many customers, the biggest migration risk is DNS coordination. Asking every customer to update their DNS records twice - once to set up AhaSend, and potentially again in the future if you change providers or infrastructure - creates operational noise and support overhead.

The approach described here solves that by introducing a DNS relay layer at your platform domain. Your customers point their DNS records once to your platform domain (for example customer.com → dkim1.customer.com.yourplatformdomain.com). From that point on, your platform domain controls where those records resolve. You can cut over from SendGrid to AhaSend by updating your own DNS records, with no further action required from your customers.

This is a one-time setup cost that permanently eliminates customer DNS coordination for all future migrations or infrastructure changes.

What to gather before you start

Before touching any DNS or AhaSend configuration, collect the following for each customer domain from your SendGrid dashboard:

DKIM configuration: For each domain, note the DKIM selector(s) in use and the full DKIM subdomain. SendGrid typically uses s1/s2 or os1/os2 as selectors, with corresponding subdomains like s1._domainkey or os1._domainkey. These vary per customer - check each domain individually in the SendGrid dashboard.

Return-Path subdomain: Note the Return-Path subdomain currently in use. This often looks like em3560.customer.com. AhaSend now supports configuring a custom Return-Path subdomain, which means you can reuse the customer's existing record rather than creating a new one. This avoids dangling DNS records and keeps the customer's DNS clean.

Tracking domain: Note any custom tracking domain in use, for example url7936.customer.com. If a customer doesn't have a custom tracking domain configured in SendGrid, you can use AhaSend's default tracking setup.

Step 1: Set up the DNS relay layer at your platform domain

For each customer domain, create CNAME records at your platform domain (yourplatformdomain.com) that initially point to the current SendGrid destinations. These are the intermediate records your customers will point to - and later, you'll update them to point to AhaSend.

Using customer.com as an example customer domain:

Step 2: Ask each customer to update their DNS records (once, ever)

Each customer needs to add or update their DNS records to point at your platform domain instead of directly at SendGrid. This is the only DNS change customers will ever need to make.

Using customer.com as the example:

Note: If no tracking record exist, and if tracking is required: Stick to Ahasend's default: t.domain points to track.customer.com.yourplatformdomain.com which points to track.ahasend.com.

Step 3: Configure AhaSend to match the customer's existing SendGrid settings

This is where AhaSend's support for custom subdomains makes the migration smooth. Rather than assigning new default subdomains that would create new DNS records, you configure AhaSend to match exactly what's already in place at SendGrid.

For each customer domain in the AhaSend dashboard, under Domain Settings or via the Management API:

DKIM: Set the DKIM selector and subdomain to match the values from SendGrid. For example, if SendGrid uses s1._domainkey and s2._domainkey, configure the same values in AhaSend. This ensures the relay records your customers already pointed at your platform domain will work correctly after cutover.

Return-Path: Set the Return-Path subdomain to match the customer's existing record (for example em1234). AhaSend now supports this configuration directly, meaning no new DNS record needs to be created. The existing record the customer already has in place continues to work - it just resolves through your platform relay to AhaSend after the cutover.

Tracking: Set the tracking subdomain to match the customer's existing SendGrid tracking domain. For customers without a custom tracking domain at SendGrid, use AhaSend's default.

The key principle here: because AhaSend supports full customisation of subdomains, you can mirror the existing SendGrid configuration exactly. No new records, no customer communication required, no dangling DNS entries.

Step 4: Lower your platform domain TTL

Before cutting over any customer, lower the TTL on your platform domain (yourplatformdomain.com) DNS records to 300 seconds. This ensures that when you update the relay records to point at AhaSend, the change propagates quickly.

Do this well in advance - at least a few hours before the planned maintenance window, to allow existing cached records to expire.

Do not proceed to step 5 before DNS changes from Step 3 are in place and propagated.

Step 5: Cut over each customer domain

When a customer is ready to migrate (or when you're ready to migrate them):

1. Confirm the platform domain TTL is at 300 seconds.
2. Schedule a 30-minute maintenance window. During this window:
3. Update the relay records at your platform domain to point to AhaSend instead of SendGrid. For customer.com, this means updating:
   dkim1.customer.com.yourplatformdomain.com → uniqueidentifier.setup.ahasend.com
dkim2.customer.com.yourplatformdomain.com → uniqueidentifier.setup.ahasend.com
track.customer.com.yourplatformdomain.com → track.ahasend.com
prsp.customer.com.yourplatformdomain.com → rp.ahasend.com
4. Trigger domain verification in AhaSend and wait for confirmation.
5. Send a test email and verify delivery.
6. End the maintenance window.

The customer's DNS records have not changed. Only your platform domain relay records changed, which is entirely within your control.

Why this approach works at scale

For a hosting company or SaaS platform managing dozens or hundreds of customer domains, this architecture has several practical advantages.

Customer coordination is a one-time cost. After the initial DNS update, future migrations - whether to a different AhaSend configuration, or to a different provider entirely - require no customer involvement.

Reusing existing DNS records avoids the noise of dangling or orphaned records in customer DNS zones. When you reuse the Return-Path subdomain and DKIM subdomains rather than creating new ones, the customer's DNS zone stays clean and easy to audit.

Maintenance windows are short and predictable. Because all the infrastructure work happens in advance, the actual cutover is a DNS update and a verification check.

The Management API means you can script the AhaSend configuration step, making it practical to prepare dozens of domains in parallel before any maintenance windows begin.

Start for free on AhaSend

AhaSend is a European transactional email service built for platform partners and developers. Full Management API, GDPR-compliant infrastructure, and the subdomain customisation capabilities described in this guide are available on all paid plans.

Start for free on AhaSend →