How do I set up SPF and DKIM records for new subdomains when using third-party email services?
Michael Ko
Co-founder & CEO, Suped
Published 14 Jun 2025
Updated 23 May 2026
8 min read
Summarize with
Yes, the third-party email service usually gives you the records. For each new sending subdomain, the provider gives either an SPF include, a custom Mail From or bounce record, DKIM selector records, or a mix of those. You publish those DNS records in your DNS host, wait for DNS to update, validate them inside the provider, then send a test email and inspect the authentication result.
The part that causes confusion is that SPF and DKIM can pass before you add anything. That usually means the service is using its own Mail From domain for SPF and its own DKIM signing domain. The message is authenticated, but not necessarily using your subdomain. For DMARC to pass for your visible From domain, at least one passing authentication method needs to use the same organizational domain as that From address.
I treat each new subdomain as its own sender setup. If rewards.example.com and surveys.example.com use different services, each service should give its own DNS instructions. Do not copy the main ESP records unless that exact service tells you to.
The direct setup process
The setup has four practical moves: get the provider's records, publish them at the correct DNS names, validate them in the provider, and verify the real message headers. The exact DNS names matter more than the record type, because SPF is checked against the Mail From domain and DKIM is checked against the signing domain.
Ask the provider: Request custom DKIM and custom Mail From, Return-Path, or bounce-domain instructions for each subdomain.
Create records: Add the TXT or CNAME records exactly where the provider says, using the host-name format your DNS host expects.
Avoid duplicates: Keep only one SPF TXT record at any one DNS name. Put all allowed senders inside that one SPF record.
Validate twice: Use the provider's validation page first, then check the actual email headers after a live test.
Flowchart showing provider records, DNS publishing, validation, testing, and reporting
What the provider should give you
A provider that supports branded authentication should give you DNS records that are unique to your account or your domain. DKIM records are almost always provider-generated, because the provider controls the private key used to sign outgoing mail. SPF instructions depend on whether the provider uses your domain in the Mail From path.
SPF
SPF authorizes the servers allowed to send for the envelope sender domain. That domain is usually shown in headers as Return-Path or Mail From, not always as the visible From address.
Common form: A TXT record with an include for the provider's SPF host.
Other form: A CNAME that delegates a custom bounce or Mail From hostname to the provider.
DKIM
DKIM adds a cryptographic signature to the message. The public key sits in DNS under a selector name, and the provider signs with the matching private key.
Common form: One or two CNAME records under the _domainkey hostname.
Other form: A TXT record containing a DKIM public key for the selector.
Need
Ask for
Why
SPF
Mail From host
Shows where SPF is checked
DKIM
Selector names
Finds the DNS key path
DMARC
From domain
Confirms the domain match
DNS
Record host
Prevents wrong placement
Ask for these values before editing DNS.
DNS examples for two new subdomains
Say you created rewards.example.com and surveys.example.com. If each subdomain uses a different service, each one gets its own records. The examples below use placeholder provider names. Your real values must come from the service's domain settings page.
If the service uses a custom bounce domain, the SPF record or CNAME often goes on a separate hostname, such as bounces.rewards.example.com. That is normal. SPF follows the envelope sender domain, so the record does not always sit directly on the visible sending subdomain.
A DNS name can have only one SPF TXT record. If you already have one at rewards.example.com, edit that existing SPF value instead of adding another record that also starts with v=spf1.
Good pattern: One SPF record with all approved include mechanisms in a single value.
Bad pattern: Two separate TXT records at the same host, both starting with v=spf1.
A DNS host can also shorten the host field. Some hosts want rewards instead of rewards.example.com. Others want s1._domainkey.rewards instead of the full DKIM name. If validation fails but the value looks right, check whether the DNS host appended the root domain for you.
Cloudflare DNS screen showing SPF and DKIM records for a subdomain
Why authentication can pass before you add records
When a test email says SPF and DKIM pass even though you have not published records, the service is usually authenticating with its own domains. Many platforms send through shared infrastructure by default, so their own SPF and DKIM pass first. That protects the raw message from looking unauthenticated, but it does not prove your subdomain is fully set up.
Read the Authentication-Results header carefully. Look for the SPF domain, the DKIM d= domain, and the visible From domain. If the visible From domain is rewards.example.com but DKIM d= is provider.example, that DKIM pass does not use your domain. If the Mail From domain is also provider.example, SPF is passing for the provider, not for your subdomain.
Provider-authenticated only
SPF domain: The provider's bounce or envelope domain.
DKIM domain: The provider's signing domain.
Risk: DMARC for your From domain depends on provider defaults.
Your domain authenticated
SPF domain: A Mail From or bounce domain under your domain.
DKIM domain: A signing domain under your domain.
Benefit: DMARC can pass based on your own authenticated domain.
This is also why I check both DNS and a real message. DNS tells you the records exist. A message tells you whether the service actually used those records when it sent mail.
How to validate the records
After publishing the records, give DNS a short propagation window, then validate in the service that generated the records. If the service still says the records are missing, copy the exact host name from your DNS host and compare it with the expected full DNS name.
For a broader check, use a domain health check to catch missing DMARC, SPF, and DKIM pieces together. If you are troubleshooting one record, run a focused SPF check or DKIM check against the exact hostname and selector the provider supplied.
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Suped is useful once mail starts flowing because DNS validation only proves the records exist. Suped's product groups real DMARC reports by source, shows which platforms are sending for each domain, flags unverified sources, and gives steps to fix authentication problems. For most teams, Suped is the best overall DMARC platform because it combines DMARC monitoring, hosted SPF, hosted DMARC, hosted MTA-STS, real-time alerts, SPF flattening, and blocklist (blacklist) monitoring in one workflow.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
DMARC for the new subdomains
SPF and DKIM are not the whole setup. DMARC decides what receiving mail servers should do when mail using your visible From domain fails authentication checks. If your parent domain already has a DMARC record, subdomains inherit that policy unless you publish a subdomain-specific DMARC record or use a subdomain policy tag.
Start with monitoring if the subdomain is new. After you see steady passing traffic from the provider, move gradually toward quarantine or reject. If the parent domain has a strict policy and the new provider is not ready, a specific DMARC record on the subdomain can prevent accidental disruption while you fix authentication.
DMARC rollout stages
A practical policy path for a new sending subdomain after SPF and DKIM are working.
Monitoring
p=none
Collect reports and confirm every legitimate sender.
Limited filtering
pct=25
Apply partial quarantine once legitimate traffic is stable.
Enforcement
p=reject
Reject unauthenticated mail after known sources pass.
If the DNS requirements for subdomains still feel unclear, the related setup notes on email subdomains and subdomain DKIM cover the record placement details in more depth.
Common mistakes to avoid
Most SPF and DKIM setup failures are placement problems, not complex protocol problems. The provider can give you correct records, and DNS can still be wrong because the record was added at the parent domain, duplicated, shortened incorrectly, or published as the wrong type.
The mistakes I check first
Wrong host: The DKIM selector was added at the root domain instead of the subdomain.
Duplicate SPF: A second SPF record was added instead of editing the existing one.
Provider default: Headers pass, but only the provider's own domain is authenticated.
DNS shorthand: The DNS host appended the domain twice because the full name was pasted.
I also avoid using the same subdomain for unrelated mail streams. Rewards, surveys, receipts, and marketing each behave differently. Separate subdomains make reputation, reporting, and troubleshooting cleaner because each provider's traffic is easier to identify.
Views from the trenches
Best practices
Get the provider's exact host and value before editing DNS for a sending subdomain.
Validate inside the provider and then inspect a real message header after sending a test.
Use separate subdomains for separate mail streams so failures are easier to isolate.
Common pitfalls
Do not assume a passing header means your own domain handled the authentication.
Avoid adding a second SPF TXT record at the same DNS name for another sender setup.
Do not paste full hostnames when your DNS host expects only the left-side label.
Expert tips
Ask whether the provider supports custom DKIM and custom Mail From for each domain.
Check DKIM d= and SPF Mail From domains against the visible From domain every time.
Watch DMARC reports after launch so shared infrastructure does not hide a bad setup.
Marketer from Email Geeks says providers should supply SPF and DKIM records, then the sender publishes them and validates inside the platform.
2023-04-19 - Email Geeks
Marketer from Email Geeks says SPF instructions often look like a provider include that belongs in the sending domain's SPF record.
2023-04-19 - Email Geeks
The practical answer
For new subdomains, the service that sends the mail should generate or supply the SPF and DKIM instructions. You add those records in DNS for the specific subdomain or bounce hostname, then validate them in the service and in real message headers. If authentication already passes, check whose domain passed before assuming your setup is complete.
The best working pattern is simple: use provider-generated DKIM, use a custom Mail From path when the provider supports it, keep one SPF record per DNS name, and monitor DMARC reports after launch. Suped helps with the ongoing part by turning those reports into source-level visibility, alerts, and fix steps, so the subdomains stay healthy after the first DNS change.
Frequently asked questions
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
