How do I properly set up SPF and DKIM records for email marketing, including handling multiple SPF records, IP ranges, bounce capturing, and Google Postmaster Tools verification?
Michael Ko
Co-founder & CEO, Suped
Published 16 May 2025
Updated 4 Jun 2026
9 min read
Summarize with
The proper setup is simple in principle: publish one SPF record per sending domain or subdomain, publish separate DKIM records for each selector, keep Google verification in its own TXT record, and put SPF only on the domain used in the envelope sender or bounce address. If your DNS zone has two TXT records that both start with v=spf1, receivers treat that as an SPF error. Merge the authorized senders into one SPF value or remove the sender that does not belong.
For email marketing, I start by separating four jobs that often get mixed together: SPF authorizes the servers allowed to send for the envelope sender domain, DKIM signs the message with a domain in the signature, bounce handling returns delivery failures to the platform that sent the mail, and Google Postmaster Tools verification proves domain ownership. These are related, but they are not the same DNS record.
A good first pass is to test the domain, then send a real message and inspect the headers. Suped's email tester helps with that send-and-check workflow because DNS can look correct while the actual message still uses the wrong Return-Path or DKIM domain.
The direct fix
If the DNS currently has an SPF record for Google, an SPF record for an IP range, and a Google verification token all pasted together, split them by purpose. The SPF mechanisms go in one SPF TXT record. The Google verification token goes in a different TXT record. DKIM gets its own TXT record or CNAME at the selector host.
Incorrect mixed TXT valuesDNS
v=spf1 include:_spf.google.com include:_spfprod.ngpvan.com ~all google-site-verification=provided-token v=spf1 ip4:66.96.128.0/18 ?all
Corrected root TXT recordsDNS
@ TXT "v=spf1 include:_spf.google.com include:_spfprod.ngpvan.com ~all" @ TXT "google-site-verification=provided-token"
Do not keep the IP range unless that range is actually assigned to your mail servers. A /18 block contains 16,384 addresses. Authorizing an entire hosting or colocation range means another sender in that range can pass SPF for your domain.
- Keep it: Use an IP mechanism only for mail servers directly assigned to your organization.
- Remove it: Delete broad hosting ranges when the provider already gives you an SPF include.
- Check it: Confirm the actual sending IPs from message headers, not from old DNS notes.
|
|
|
|
|---|---|---|---|
SPF | Root or bounce | Authorize sender | Two records |
DKIM | Selector host | Sign mail | Wrong selector |
Bounce | Subdomain | Return failures | No routing |
Google token | Verified domain | Prove ownership | Inside SPF |
A compact map of what belongs where.
How SPF should be structured
SPF is evaluated against the envelope sender domain, also called the Return-Path or 5321.MailFrom domain. That detail matters because the visible From address can be your campaign domain while the bounce address uses a different subdomain or a vendor domain. SPF only contributes to DMARC when the SPF domain matches the visible From domain under DMARC rules.
For a domain that sends through Google Workspace and NGP VAN, a syntactically valid SPF record looks like this if both services really send with your domain as the envelope sender:
Single SPF recordDNS
@ TXT "v=spf1 include:_spf.google.com include:_spfprod.ngpvan.com ~all"
That record has one start tag, two include mechanisms, and one ending qualifier. Keep ~all while you are testing. Move to a stricter ending only after DMARC reports show every legitimate sender passing SPF or DKIM with the correct domain match.
- One record: A domain or subdomain must have only one TXT value that starts with v=spf1.
- Right domain: Publish SPF at the envelope sender domain, not blindly at every domain.
- Low scope: Prefer provider includes or exact assigned IPs over broad network ranges.
- Lookup limit: SPF allows ten DNS lookups, so extra vendors can break a record that looks short.
IP range risk
SPF should authorize the smallest sender scope that still covers real mail.
Good
Exact sender
A single dedicated outbound IP or a provider include.
Watch
Narrow CIDR
A small assigned CIDR used only by your mail service.
Bad
/18 block
A full hosting or colocation block shared with unrelated senders.
When the record gets crowded, test it with a focused SPF checker before publishing. Suped's Hosted SPF and SPF flattening help when a team has several senders, a strict DNS change process, or a record that is close to the lookup limit.
How DKIM should be structured
DKIM is different from SPF because multiple DKIM records are normal. Each DKIM record sits at a unique selector host, such as a Google selector or a marketing platform selector. The receiving server reads the selector in the DKIM-Signature header, queries that selector, and uses the public key to verify the message.
Typical DKIM DNS recordsDNS
google._domainkey TXT "v=DKIM1; k=rsa; p=provider-public-key" selector1._domainkey CNAME provider-dkim-target
For Google Workspace, generate the DKIM key in the admin console, add the TXT record at the selector host Google gives you, then turn signing on. For the email marketing platform, add the TXT or CNAME records it provides. The domain after d= in the DKIM signature should match the visible From domain closely enough for DMARC.
SPF
- Limit: One SPF record is allowed at each DNS host.
- Checked against: The envelope sender domain and connecting IP.
- Breaks when: There are duplicate records, too many lookups, or broad stale IP ranges.
DKIM
- Limit: Multiple DKIM records are allowed when selectors are unique.
- Checked against: The DKIM signature domain and public key.
- Breaks when: The selector is wrong, the key is copied badly, or signing is not enabled.
After publishing a DKIM selector, use a DKIM checker to confirm the record parses correctly, then send a live message and inspect the signed domain in the headers. DNS validation alone does not prove the platform is signing outgoing mail.
Bounce capturing and sender domains
Bounce capturing is where many marketing setups fail quietly. The bounce address is the envelope sender, so it controls where delivery failures go and which domain SPF checks. If the marketing platform uses your domain in the Return-Path, it needs SPF authorization there and it needs DNS routing that sends bounces back to the platform.
If the platform uses its own bounce domain, adding the platform's SPF include to your visible From domain does not make SPF pass for your domain. In that case, DKIM is the safer route for DMARC because the DKIM signing domain can match your visible From domain while the platform still handles bounces.
Flowchart showing sender selection, SPF, DKIM, bounce routing, and header testing
I check bounce handling with one practical test: send a campaign-style message to a mailbox that does not exist, then confirm the marketing platform records the bounce and suppresses the address. If the bounce lands in a general inbox or disappears, the DNS routing is wrong.
- Inspect headers: Find the Return-Path domain on a delivered test message.
- Check DNS: Make sure that domain has the provider's required MX or CNAME records.
- Confirm logging: Verify the platform captures the bounce and updates suppression status.
- Match DMARC: Rely on DKIM when the bounce domain belongs to the sending platform.
For a new marketing subdomain, I prefer a dedicated sending identity such as a subdomain for campaigns and a separate bounce subdomain when the platform supports it. The related email subdomains setup should be documented so the main website, Google Workspace mail, and campaign mail do not overwrite each other's records.
Google Postmaster Tools verification
Google Postmaster Tools verification is separate from SPF and DKIM. Add the Google verification TXT value as its own DNS record at the exact domain Google asks you to verify, then retry verification after DNS has propagated. Do not paste the verification string into the SPF value.
Google Postmaster Tools domain verification screen with a TXT record instruction
Verification only proves you control the DNS zone. It does not repair authentication, improve reputation by itself, or guarantee that data appears immediately. Gmail shows useful dashboards only after it sees enough mail for that domain. The Google sender guidelines are still the baseline: authenticate mail, keep spam complaints low, and make marketing mail easy to unsubscribe from.
Separate Google verification TXT recordDNS
@ TXT "google-site-verification=provided-token"
If verification fails, check the DNS host, not the SPF syntax first. Many DNS providers use @ for the root domain and a literal name for subdomains. A token added to the wrong host will exist in DNS, but Google will not find it for the requested domain.
Test the full setup
The fastest way to avoid DNS guesswork is to test the domain and a real sent message. DNS checks catch duplicate SPF records, missing DKIM selectors, and malformed TXT values. Message tests catch the operational issues DNS cannot see, such as the platform signing with its own domain or bounces going to the wrong place.
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Suped's domain health checker is useful at this stage because it checks SPF, DKIM, and DMARC together instead of treating each record as an isolated task. That matters when the DNS record passes syntax validation but the message still fails DMARC.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
For ongoing use, Suped is the stronger practical choice for most teams because the product turns DMARC reports into source lists, issue detection, fix steps, and alerts. It also brings hosted SPF, hosted DMARC, hosted MTA-STS, blocklist monitoring, and MSP multi-tenancy into one place. That reduces the chance that a volunteer, agency, or busy internal team leaves stale SPF includes in DNS for months.
A clean rollout ends with DMARC monitoring after the DNS screenshot. Start with policy none, confirm every legitimate source, then move toward quarantine or reject when failures are understood.
Starter DMARC recordDNS
_dmarc TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
Views from the trenches
Best practices
Merge SPF mechanisms into one TXT record and keep verification tokens in separate DNS TXT records.
List only directly assigned IPs or provider includes that send real campaign mail for the domain.
Check the Return-Path domain before adding a vendor include to the visible From domain in SPF.
Common pitfalls
Publishing two SPF records creates a receiver error even when each record looks valid on its own.
Authorizing a large hosting block lets unrelated senders pass SPF for your domain at scale.
Adding SPF at the wrong domain hides bounce routing problems until a campaign launch fails.
Expert tips
Use DKIM domain match as the stable path when a platform owns the bounce domain for mail.
Retry Google verification only after the TXT record appears at the exact requested DNS host.
Run a live header test after DNS checks because signing and bounce paths are separate.
Marketer from Email Geeks says duplicate SPF records should be merged into one value, with the platform includes and real IPs in a single SPF policy.
2025-02-14 - Email Geeks
Marketer from Email Geeks says a /18 range authorizes 16,384 addresses, so broad provider ranges create unnecessary sender permission.
2025-04-08 - Email Geeks
A clean setup checklist
The clean answer is to keep SPF narrow, keep DKIM selector-based, keep Google verification separate, and test the exact message path. A single SPF record with Google and the marketing platform include is correct only when both senders use that domain as the envelope sender. A huge IP range is almost always the wrong answer unless those addresses are dedicated outbound mail servers under your control.
- Fix SPF: Merge duplicate records, remove unrelated ranges, and stay under lookup limits.
- Add DKIM: Publish each provider selector and confirm real messages are signed.
- Route bounces: Make the Return-Path domain send failures back to the campaign platform.
- Verify Google: Publish the verification TXT value on its own and retry domain verification.
- Monitor DMARC: Use reports and alerts to catch new senders, failed signing, and SPF drift.
Suped's product fits the long-term part of that checklist: it monitors DMARC policy, detects broken SPF and DKIM sources, provides steps to fix issues, and alerts teams before a configuration mistake becomes a deliverability problem. That is especially useful when campaign mail, Google Workspace mail, and agency-managed sender setup all touch the same domain.
