How to Set Up SPF, DKIM and DMARC for SparkPost (2026)

SparkPost (now part of Bird) is a cloud email delivery platform used to send transactional and marketing email at scale. Without SPF, DKIM, and DMARC records in place, mail sent through SparkPost on your domain is vulnerable to spoofing and may be rejected by receiving mail servers. Follow the steps below and you will have all three authentication layers configured and verified.

Before you begin

• DNS write access to the domain you are sending from (via your registrar or DNS host — Cloudflare, Route 53, GoDaddy, etc.)
• Admin access to your SparkPost account (or Bird account, if your account has been migrated)
• The ability to send a test email from your domain after records are published
• A text editor to stage records before pasting them into your DNS console
• TTL changes take effect in minutes for most DNS providers, but allow up to 48 hours for full propagation before troubleshooting

Step 1: Identify what's sending from SparkPost

SparkPost can send email on your behalf from shared IP pools, dedicated IPs, or custom bounce/tracking subdomains — sometimes all three within a single account. Each of these sending paths may originate from different IP ranges, and SparkPost may also use engagement-tracking subdomains that appear in your mail headers. Before you write a single DNS record, log in to your SparkPost admin, navigate to the sending domains section, and confirm exactly which domains and subdomains are associated with your account. If you are using a subdomain for sending (for example, mail.your-domain.com), the SPF and DKIM records described in the steps below must be published under that subdomain, not your root domain, unless the root domain is your actual sending address.

Step 2: Add the SPF include

SparkPost's sending infrastructure must be authorized in your domain's SPF record. SparkPost publishes an SPF include mechanism that covers its sending IP ranges. Based on general knowledge, this include is include:sparkpostmail.com, but you should verify the exact string in SparkPost's current DNS setup documentation before publishing, as include strings can change following platform migrations or infrastructure updates.

If you already have an SPF record for your domain, add the SparkPost include to the existing record — do not create a second TXT record with type v=spf1. A domain must have only one SPF record. Below is an example of a before and after:

# BEFORE — existing SPF record (example)
your-domain.com.  TXT  "v=spf1 include:_spf.google.com ~all"

# AFTER — SparkPost include added
your-domain.com.  TXT  "v=spf1 include:_spf.google.com include:sparkpostmail.com ~all"

If you have no existing SPF record, create a new TXT record at your root domain:

your-domain.com.  TXT  "v=spf1 include:sparkpostmail.com ~all"

SPF 10-lookup limit: The SPF specification allows a maximum of 10 DNS lookups during evaluation. Each include: mechanism counts as one lookup, and nested includes inside a vendor's SPF record count against the same limit. If you send from multiple platforms (Google Workspace, Salesforce, HubSpot, SparkPost, etc.), you can easily exceed this limit, causing SPF to return permerror rather than pass. Audit your current lookup count before adding a new include. Tools such as MXToolbox's SPF record checker will display your current lookup depth.

Step 3: Enable DKIM in SparkPost

DKIM requires you to publish a public key in DNS and configure SparkPost to sign outbound mail with the corresponding private key. The general workflow is as follows:

1. Log in to your SparkPost (or Bird) admin console.
2. Navigate to the sending domains or email authentication section. In SparkPost's interface this has historically been under Account → Sending Domains, but verify this path against current documentation if your account has been migrated to Bird.
3. Locate your sending domain and look for an option to generate or view DKIM credentials. SparkPost typically generates a DKIM key pair on your behalf and provides you with the DNS record to publish.
4. Copy the full DKIM public key value provided. It will be a long base64-encoded string.
5. Publish it as a TXT record in your DNS. The record name follows this pattern:

# Record name (Host field)
<selector>._domainkey.your-domain.com

# Record value (TXT data)
"v=DKIM1; k=rsa; p=<your-public-key-string>"

The selector name is assigned by SparkPost when it generates the key. Copy the exact selector from the SparkPost console — do not guess or invent it. The selector will be something like scph0316 or a similarly formatted string, but the exact value depends on when and how the key was generated in your account. Using the wrong selector name means DKIM lookups will fail entirely.

Once the TXT record is published, return to the SparkPost sending domains screen and trigger the domain verification step. SparkPost will perform a DNS lookup to confirm the public key is reachable before it begins signing mail with that key.

Long key values and TXT record splitting: Some DNS providers require DKIM public key strings longer than 255 characters to be split into multiple quoted strings within a single TXT record. If your DNS provider enforces this limit, the record value should look like this:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA" "3remainder-of-key-string-here=="

Receiving mail servers will concatenate the strings automatically. SparkPost's console or DNS setup guide should indicate whether splitting is needed for the key it generated.

Step 4: Publish your DMARC record

DMARC tells receiving mail servers what to do when SPF or DKIM fails, and where to send aggregate reports about authentication results. Publish a DMARC record at _dmarc.your-domain.com as a TXT record.

Start with p=none. This monitoring-only policy does not affect mail delivery — it collects reports so you can see what is passing and what is not before you enforce anything. Do not move to p=quarantine or p=reject until you have at least 14 days of clean report data showing that legitimate mail is authenticating correctly.

# Minimum viable DMARC record — monitoring mode
_dmarc.your-domain.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-rua@dmarcbusta.pro"

Parameter reference for this record:

Once you have reviewed your aggregate reports and confirmed SparkPost mail is passing both SPF and DKIM alignment, you can progress the policy to p=quarantine, then eventually p=reject.

Step 5: Verify it works

Before sending a test email, confirm your DMARC record actually published. Use our free DMARC Checker to look up _dmarc.your-domain.com and verify the record is live, has the correct policy (p=none, quarantine, or reject), and is configured for aggregate reporting. While you are there, run the SPF Checker against your domain to make sure the SPF lookup tree is clean — once both records check out, the live email test below will give you the final confirmation.

After DNS records have propagated (allow at least 30 minutes for low-TTL zones), send a test email from your SparkPost-connected domain to a Gmail or Yahoo Mail address you control.

1. Open the message in Gmail and click the three-dot menu next to the reply button, then select Show original. In Yahoo Mail, use More → View Raw Message.
2. In the raw headers, look for the Authentication-Results header near the top. You are looking for all three of the following:

Authentication-Results: mx.google.com;
  spf=pass (google.com: domain of sender@your-domain.com designates <ip> as permitted sender)
  dkim=pass header.i=@your-domain.com header.s=<selector>
  dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=your-domain.com

• spf=pass — The sending IP was found in your SPF record. SparkPost's infrastructure is authorized.
• dkim=pass — The signature in the message header matched the public key in your DNS. The message has not been tampered with in transit.
• dmarc=pass — At least one of SPF or DKIM passed and the authenticated domain aligns with the From: header domain. This is the result that matters for enforcement and deliverability.

If any of these shows fail, softfail, or none, refer to the common errors section below before progressing your DMARC policy.

Common errors with SparkPost

• DKIM selector mismatch: The selector published in DNS does not match the selector SparkPost is using to sign mail. This happens when a new DKIM key is generated in the platform but the old DNS record is not updated, or when the DNS record was published with a typo in the selector name. Check the dkim= result in the raw headers — the header.s= value tells you exactly which selector the message was signed with. That string must match the left side of your ._domainkey.your-domain.com DNS record name.
• SPF permerror from lookup overflow: If you use several third-party sending services, adding SparkPost's include may push you past the 10-lookup limit. The Authentication-Results header will show spf=permerror. Audit your SPF record with an online checker and consolidate includes or use an SPF flattening service.
• DKIM key split incorrectly: If your DNS provider silently truncated the public key string or the split was formatted incorrectly, DKIM will fail with a key retrieval failed note in the headers. Query your published DKIM record with dig TXT <selector>._domainkey.your-domain.com and confirm the full key is present and the concatenated value matches what SparkPost provided.
• DMARC alignment failure despite SPF and DKIM passing: DMARC requires the authenticated domain to align with the From: header. If SparkPost is sending from a subdomain (e.g., mail.your-domain.com) but your From: address is @your-domain.com, you need relaxed alignment (the DMARC default) or you must ensure DKIM is signing with the organizational domain. Check whether adkim=r (relaxed) is in effect — if you have not set adkim=s, relaxed is the default and subdomain signing should still align.
• Domain not verified in SparkPost: SparkPost will not sign mail with DKIM until the sending domain is verified inside the platform. If you published the DNS records but DKIM is still failing, return to the SparkPost sending domains screen and confirm the domain shows a verified or active status. Re-trigger verification if needed.

How DMARC Busta helps

The steps above are a one-time setup for a single domain. If you manage multiple domains or need to maintain authentication as your sending infrastructure changes over time, manual DNS edits become a significant operational burden. DMARC Busta is designed to manage email authentication at scale — handling SPF record complexity through SPF Auto-Repair (automated delegation that keeps you under the 10-lookup limit as sources are added or removed), processing and surfacing aggregate DMARC reports so you are not parsing raw XML, and progressing DMARC policy through its Autopilot mode as authentication signals confirm readiness. The platform is built to handle 10,000+ domains from a single interface, making it practical for MSPs managing authentication across an entire client portfolio.

If you followed the steps above manually and want to avoid repeating them for every domain you manage, DMARC Busta's Autopilot mode handles DMARC policy progression automatically — moving from p=none to p=reject only when aggregate report data confirms it is safe to do so. SPF Auto-Repair handles source changes without requiring you to touch DNS records manually every time a new sending platform is added.

Start your free trial and put your email authentication on autopilot.