Email Deliverability by Platform: Setup Guides for Every Major ESP

You just signed up for a new email platform, connected your domain, and started sending. A week later, your emails are landing in spam. The platform's setup wizard said everything was "verified," but you are now learning that "verified" and "properly authenticated" are two very different things.

Every email service provider (ESP) handles authentication differently. Each one has its own process for Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) configuration, its own DNS record format, its own quirks, and its own common failure modes. Getting the platform-specific details right is the difference between emails that pass authentication cleanly and emails that fail silently.

This guide covers the real setup details for major email platforms, including actual DNS record examples, common mistakes, and how to manage authentication when you are using multiple services simultaneously. For the fundamentals of email authentication protocols, see our email authentication guide. For the broader deliverability picture, see our complete email deliverability guide.

---

How SPF Includes Work Across Multiple Platforms

Before diving into individual platforms, you need to understand how SPF records work when you have multiple sending services, because almost every organization does.

SPF works by publishing a DNS TXT record that lists all the servers authorized to send email on behalf of your domain. When a receiving server gets a message from your domain, it checks the sending IP against your SPF record. If the IP is not listed, SPF fails.

The problem is that each platform you add requires its own include: mechanism in your SPF record. Each include: triggers a DNS lookup, and SPF has a hard limit of 10 DNS lookups total. This is defined in RFC 7208 [1], and receiving servers enforce it strictly. If your record exceeds 10 lookups, SPF fails for every message, regardless of whether the sending IP is actually authorized.

A Real-World Example: Google Workspace + SendGrid + HubSpot

Let us walk through what happens when an organization uses Google Workspace for business email, SendGrid for transactional email, and HubSpot for marketing email. Here is what the SPF record looks like:

v=spf1 include:_spf.google.com include:sendgrid.net include:mail.hubspot.net ~all

That looks simple. Three includes. But each include: can trigger additional nested lookups. Here is the actual lookup count:

• include:_spf.google.com resolves to additional includes for _netblocks.google.com, _netblocks2.google.com, and _netblocks3.google.com. That is 4 lookups (1 for the initial include + 3 nested).
• include:sendgrid.net resolves to a single record. That is 1 lookup.
• include:mail.hubspot.net resolves to additional includes. That is typically 2 lookups.

Total: 7 lookups out of your 10-lookup limit. You have 3 remaining. Add Mailchimp, Salesforce, or Zendesk and you are at or over the limit.

You can verify your lookup count using SPF Record Check, which shows you the full resolution tree and counts every lookup.

What Happens When You Hit the Limit

When your SPF record exceeds 10 lookups, receiving servers return a permerror result. This is treated as an SPF failure. If your DMARC policy is p=reject or p=quarantine and DKIM also fails (or does not align), your email will be rejected or sent to spam.

Solutions include SPF flattening (replacing include: mechanisms with the actual IP addresses they resolve to), using subdomains for different sending services, or consolidating sending platforms. See SPF too many lookups for detailed solutions and SPF record too long for the related DNS character limit issue.

---

Productivity and Workspace Platforms

These are your organization's core email infrastructure. Getting authentication right here affects every email your company sends, from one-on-one messages to company-wide announcements.

Google Workspace

Google Workspace is the most common business email platform, and it is also the one where DKIM most often goes unconfigured. Google does not enable DKIM signing by default. You must manually generate a DKIM key in the Google Admin console and publish it in DNS. Many organizations run for years without DKIM because everything "seems to work fine," until a DMARC policy change or a receiving provider's enforcement update causes failures.

SPF Record:

v=spf1 include:_spf.google.com ~all

DKIM Setup: In the Google Admin console, go to Apps, then Google Workspace, then Gmail, then Authenticate Email. Select your domain and click "Generate new record." Google will give you a TXT record to publish at a selector like google._domainkey.yourdomain.com:

google._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

The default selector is google, but you can choose a custom prefix. After publishing the record, return to the Admin console and click "Start authentication." It can take up to 48 hours for DNS propagation, though most providers update within an hour.

Common mistake: Generating the DKIM key but forgetting to click "Start authentication" in the Admin console. The DNS record exists, but Google is not actually signing outbound messages with it. You can verify at DKIM Test.

Google Workspace Email Deliverability Guide

Zoho Mail

Zoho provides its own authentication setup through the admin panel. SPF and DKIM records must be added to DNS manually. Zoho's SPF include is include:zoho.com (or include:zoho.eu for EU data center customers).

SPF Record:

v=spf1 include:zoho.com ~all

DKIM: Zoho generates a DKIM key pair in the admin console under Email Authentication. You publish the public key as a TXT record at the selector Zoho specifies.

Zoho Mail Deliverability Guide

---

Email Marketing Platforms

Marketing platforms send bulk email on your behalf. Their authentication setup determines whether those emails pass SPF and DKIM checks against your domain. Getting this wrong does not just affect marketing emails. It can damage your overall domain reputation, which affects all email from your domain.

HubSpot

HubSpot's email authentication has evolved significantly. For DKIM, HubSpot asks you to create two CNAME records that point to HubSpot's DKIM key infrastructure:

hs1._domainkey.yourdomain.com  CNAME  yourdomain-com.hs01a.dkim.hubspot.net
hs2._domainkey.yourdomain.com  CNAME  yourdomain-com.hs01b.dkim.hubspot.net

For SPF, HubSpot uses shared sending IPs by default. On shared IPs, HubSpot handles SPF alignment through their own envelope sender domain. On dedicated IPs (available on Marketing Hub Enterprise), you add HubSpot's include to your SPF record.

Common mistake: HubSpot has a "domain verification" step that is separate from DKIM authentication. Many users complete verification (which just proves domain ownership) and assume authentication is done. Verification and authentication are not the same thing. You must complete both.

HubSpot Email Deliverability

Mailchimp

Mailchimp moved to a CNAME-based authentication system. You create two CNAME records for DKIM:

k1._domainkey.yourdomain.com  CNAME  dkim.mcsv.net
k2._domainkey.yourdomain.com  CNAME  dkim2.mcsv.net

And a CNAME for return-path alignment:

mte1._domainkey.yourdomain.com  CNAME  mailchimp.com

Common mistake: Mailchimp's interface has both a "Verify Domain" button and an "Authenticate Domain" section. Domain verification sends a confirmation email and proves ownership. Domain authentication is the DNS record setup that enables DKIM signing. Many users click "Verify," see the green checkmark, and stop there. Your emails will still send without authentication, but they will use Mailchimp's domain in the DKIM signature instead of yours, which means DMARC alignment will fail.

Mailchimp Domain Authentication

Klaviyo

Klaviyo uses a dedicated sending domain approach. You create CNAME records that point a subdomain (typically send.yourdomain.com) to Klaviyo's infrastructure:

send.yourdomain.com      CNAME  cname.klaviyo.com
k1._domainkey.yourdomain.com  CNAME  dkim.klaviyo.com
k2._domainkey.yourdomain.com  CNAME  dkim2.klaviyo.com

Klaviyo handles SPF through the dedicated sending domain, so you typically do not need to add a separate SPF include for Klaviyo.

Klaviyo Email Deliverability

Brevo (Sendinblue) and ActiveCampaign

Both Brevo and ActiveCampaign follow a more traditional model. For SPF, you add their include mechanism to your record. For DKIM, you publish a TXT or CNAME record they provide.

• Brevo (Sendinblue) SPF and DKIM Setup
• ActiveCampaign Email Deliverability

---

Transactional Email Services

Transactional services handle password resets, order confirmations, account notifications, and other system-generated emails. These emails have higher urgency than marketing email, and authentication failures here create immediate customer support tickets. A customer who cannot reset their password because the reset email bounced is a customer you are about to lose.

SendGrid

SendGrid uses CNAME-based DKIM with automated key management. During domain authentication setup, SendGrid asks you to create three CNAME records:

s1._domainkey.yourdomain.com   CNAME  s1.domainkey.u12345.wl.sendgrid.net
s2._domainkey.yourdomain.com   CNAME  s2.domainkey.u12345.wl.sendgrid.net
em1234.yourdomain.com          CNAME  u12345.wl.sendgrid.net

The third CNAME handles return-path alignment for SPF. With this approach, you may not need to add include:sendgrid.net to your SPF record at all, because SPF checks against the return-path domain, which now points to SendGrid's infrastructure. This is actually a feature, as it saves you an SPF lookup.

Common mistake with subusers: If you use SendGrid subusers (common for organizations sending from multiple brands or domains), each subuser needs its own domain authentication. Messages sent from a subuser that has not completed domain authentication will use SendGrid's default domain, causing DMARC alignment failures.

SendGrid Deliverability Guide

Amazon Simple Email Service (SES)

Amazon SES requires explicit domain verification through the AWS console. For DKIM, SES uses "Easy DKIM," which generates three CNAME records:

abc123._domainkey.yourdomain.com  CNAME  abc123.dkim.amazonses.com
def456._domainkey.yourdomain.com  CNAME  def456.dkim.amazonses.com
ghi789._domainkey.yourdomain.com  CNAME  ghi789.dkim.amazonses.com

For SPF, you add include:amazonses.com to your record. SES also supports a custom MAIL FROM domain, which is important for SPF alignment. Without a custom MAIL FROM, the return-path domain is amazonses.com, meaning SPF passes for Amazon's domain but does not align with your From domain for DMARC purposes.

Critical requirement: SES mandates that you configure bounce and complaint handling via Simple Notification Service (SNS) topics. If you do not handle bounces and complaints programmatically, Amazon will suspend your sending. This is not a suggestion. SES has automated systems that monitor your bounce and complaint rates, and they will shut down your account if rates exceed their thresholds (bounce rate above 5%, complaint rate above 0.1%). [2]

Amazon SES Deliverability Guide

Mailgun

Mailgun requires DNS records for both SPF and DKIM. You add include:mailgun.org to your SPF record and publish the DKIM TXT record Mailgun provides. DMARC setup is separate and not handled by Mailgun's default configuration. You must set up your own DMARC record.

Mailgun DMARC Setup

---

Website and E-commerce Platforms

These platforms send transactional email (order confirmations, password resets) and sometimes marketing email. Their default email configuration often uses shared sending infrastructure with no domain authentication. This is where many businesses first discover deliverability problems, because the emails they care about most (order confirmations, shipping notifications) start landing in spam.

WordPress

WordPress sends email through PHP's mail() function by default. This typically fails SPF checks because the sending IP is your web hosting server, which is probably not in your SPF record. There is also no DKIM signing, because PHP's mail() function does not support it natively.

The solution for WordPress is always to use an SMTP plugin (like WP Mail SMTP, Post SMTP, or FluentSMTP) that routes email through a proper email service. This could be your existing Google Workspace account, SendGrid, Amazon SES, or any other authenticated service. The plugin replaces PHP's mail() function with an authenticated SMTP connection or API call.

Common mistake: Installing an SMTP plugin but configuring it with your personal Gmail credentials using "Less Secure Apps" access. Google deprecated this in 2022. [3] Use OAuth 2.0 or an app password, or better yet, use a dedicated transactional email service.

WordPress Email Deliverability

Shopify

Shopify handles transactional email (order confirmations, shipping notifications) from its own infrastructure. You do not control the sending IP or DKIM signing for these messages. Shopify sends them from a shops.shopify.com return-path, which means SPF alignment with your domain is not possible for transactional emails.

For marketing email sent through Shopify Email, Shopify has added domain authentication. You add CNAME records to your DNS that enable DKIM signing with your domain. This is a relatively new feature and is worth setting up even if your transactional email deliverability seems fine.

Shopify Email Deliverability

---

CRM Platforms

CRMs often send both marketing and transactional email, sometimes through different sending paths with different authentication requirements. This makes them one of the trickiest categories to configure correctly.

Salesforce

Salesforce email deliverability depends heavily on which sending path you use, and Salesforce has several.

Path 1: Salesforce core (Sales Cloud / Service Cloud). Emails sent from within Salesforce CRM (like sending an email from a contact record) use Salesforce's shared infrastructure by default. SPF requires include:_spf.salesforce.com. DKIM can be configured under Setup, then DKIM Keys, where you generate a key pair and publish the public key in DNS.

Path 2: Salesforce Marketing Cloud. Marketing Cloud has its own sending infrastructure that is completely separate from core Salesforce. It uses Sender Authentication Package (SAP), which involves creating delegated DNS records that point a subdomain entirely to Marketing Cloud's infrastructure. The SAP includes SPF, DKIM, return-path, and even branded tracking links.

Path 3: Connected ESP. Some organizations connect an external ESP like SendGrid (which Salesforce owns) to Salesforce. In this case, authentication follows the ESP's configuration, not Salesforce's.

Common mistake: Configuring authentication for core Salesforce and assuming Marketing Cloud is covered. They are separate systems with separate DNS requirements. If you use both, you need authentication records for both.

Salesforce Email Deliverability

---

Shared vs. Dedicated IPs: The Decision by Platform Tier

Most ESPs offer two sending options: shared IPs (your email is sent from IPs used by many customers) or dedicated IPs (your email is sent from an IP used only by you). The right choice depends on your sending volume, and the threshold varies by platform.

When Shared IPs Make Sense

If you send fewer than 50,000 emails per month, a shared IP is usually the better option. On a shared IP, you benefit from the collective reputation of all senders on that IP. Reputable ESPs actively manage their shared IP pools, removing bad senders and maintaining deliverability. The risk is that another sender's bad behavior could temporarily affect your deliverability, but good ESPs mitigate this with monitoring and enforcement.

When Dedicated IPs Make Sense

If you send more than 100,000 emails per month consistently, a dedicated IP gives you full control over your sending reputation. Your deliverability is determined entirely by your own behavior. However, a dedicated IP starts with no reputation at all, which means you must warm it up gradually. Sending 100,000 emails on day one from a brand-new IP will result in heavy throttling and possible blocking.

According to Validity's 2025 Sender Intelligence report, senders with fewer than 25,000 monthly emails who switch to a dedicated IP often see worse deliverability than they had on shared IPs, because they do not send enough volume to build and maintain a stable reputation. [4]

Platform-Specific Availability

• Google Workspace and Zoho: Not applicable. These are not bulk sending platforms. You send from Google's or Zoho's infrastructure.
• HubSpot: Dedicated IP available on Marketing Hub Enterprise plans. Minimum recommended volume is 100,000+ emails per month.
• Mailchimp: Dedicated IP available as an add-on on Standard and Premium plans. Mailchimp recommends a minimum of 5,000 emails per week.
• SendGrid: Dedicated IP available on Pro plans and above. SendGrid provides a built-in IP warmup feature.
• Amazon SES: Every SES account starts on shared IPs. You can request dedicated IPs, and SES offers a managed warmup feature called "Adaptive Warming."
• Klaviyo: Dedicated sending infrastructure is available on higher-tier plans, with Klaviyo managing the warmup process.

For a deeper comparison, see dedicated vs. shared IP and IP reputation explained.

---

Migrating Between Platforms Without Losing Deliverability

Platform migrations are one of the most common causes of deliverability drops. You switch ESPs, update your DNS records, and suddenly your emails start bouncing or going to spam. The problem is usually that the new platform's IP has no reputation for your domain, and your DNS changes may have introduced authentication gaps.

The Safe Migration Process

Step 1: Set up authentication on the new platform before sending anything. Configure SPF, DKIM, and return-path on the new platform. Verify everything passes using our deliverability checker and SPF Record Check. At this point, your SPF record should include both the old and new platform's records.

Step 2: Warm up the new platform. Start sending a small volume (a few hundred emails per day) through the new platform. Target your most engaged recipients first, as their opens and clicks will build positive reputation. Increase volume by 25% to 50% per day. Most warmup schedules take 2 to 4 weeks. See email warmup for detailed schedules.

Step 3: Run both platforms in parallel. During the warmup period, continue sending most of your email through the old platform. Gradually shift volume to the new platform as its reputation builds. Monitor delivery rates and spam complaint rates on both platforms throughout this period.

Step 4: Complete the transition. Once the new platform is handling 100% of your volume with stable delivery rates, remove the old platform's SPF include from your DNS record. Do not remove it before this point, as leftover emails in retry queues on the old platform will fail SPF if you remove the include too early.

Step 5: Clean up DNS. After a week with no traffic on the old platform, remove its SPF include and DKIM records from DNS. Verify your final DNS configuration using SPF Record Check and DKIM Test.

For a complete migration playbook, see email deliverability during migration.

---

How to Verify Your Setup After Configuration

Configuring DNS records is only half the job. You need to verify that the records are correct, that they have propagated, and that your emails are actually passing authentication checks. Here is a verification process you should follow for every platform you set up.

Step 1: Check DNS Records Directly

Use SPF Record Check to verify your SPF record. It will show you the full record, the lookup count, and any syntax errors. Use DKIM Test with your platform's selector to verify the DKIM public key is published correctly. Use DMARC Record Checker to verify your DMARC record syntax and policy.

Step 2: Send a Test Email and Check Headers

Send a test email from the platform you just configured. Send it to an account you control at Gmail, Outlook, or another major provider. Open the received message and inspect the email headers (in Gmail, click the three dots, then "Show original").

Look at the Authentication-Results header. You should see:

• spf=pass with the correct sending domain
• dkim=pass with the correct selector and your domain
• dmarc=pass with your domain

If any of these show fail, softfail, or none, the setup is not complete. Go back to the platform's authentication settings and verify each record.

Step 3: Run a Comprehensive Check

Use our deliverability checker to run a full check on your domain. It tests SPF, DKIM, DMARC, MX records, Brand Indicators for Message Identification (BIMI), and blacklist status in a single lookup. This catches issues that might not show up in individual protocol checks, like missing MX records or blacklist listings that predate your setup.

Step 4: Monitor for the First 7 Days

Authentication issues sometimes do not surface immediately. DNS caching can mask problems for up to 48 hours, depending on Time to Live (TTL) values. Some ESPs rotate DKIM selectors or sending IPs, which can reveal configuration gaps that were not present during initial testing. Check your ESP's delivery dashboard daily for the first week after any platform setup or DNS change.

---

Using Multiple Platforms Together

Most organizations send email through more than one platform: a workspace provider for business email, a marketing platform for campaigns, a transactional service for system emails, and possibly a CRM for sales outreach. Managing authentication across all of these is where things most commonly break.

The Multi-Platform SPF Challenge

Every platform needs to be authorized in your SPF record. Using the earlier example of Google Workspace + SendGrid + HubSpot at 7 lookups, here is what happens when you add Mailchimp and Salesforce:

v=spf1 include:_spf.google.com include:sendgrid.net include:mail.hubspot.net include:servers.mcsv.net include:_spf.salesforce.com ~all

That is 5 include mechanisms, which could resolve to 11 or more lookups depending on nesting. You are over the limit.

Solutions for Multi-Platform SPF

1. Use subdomains. Send marketing email from marketing.yourdomain.com and transactional email from notifications.yourdomain.com. Each subdomain gets its own SPF record with its own 10-lookup limit. See subdomain email strategy.

2. SPF flattening. Replace nested includes with the actual IP ranges they resolve to. This eliminates nested lookups but requires ongoing maintenance because IP ranges change. Several third-party services automate this.

3. Use CNAME-based return paths. Platforms like SendGrid and Mailchimp offer CNAME-based return paths that handle SPF alignment without needing an include in your root domain's SPF record.

See managing deliverability across multiple ESPs for a comprehensive guide to multi-platform authentication.

References

1. RFC 7208 — Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Section 4.6.4: DNS Lookup Limits. Internet Engineering Task Force (IETF), April 2014.
2. Amazon SES — Sending review process: bounce rate threshold of 5% and complaint rate threshold of 0.1%. Amazon Web Services Documentation.
3. Google — "Less secure apps & your Google Account." Google deprecated Less Secure Apps access for Google Workspace accounts on June 15, 2022, and for all Google accounts on September 30, 2024.
4. Validity — 2025 Sender Intelligence Report. Validity, Inc., 2025.