How to configure SPF, DKIM, and DMARC when sending marketing emails from a subdomain but signing with the primary domain?
Updated on 19 Oct 2026: We clarified subdomain SPF and primary-domain DKIM setup, corrected DMARC matching guidance, and added reputation and validation checks.
Publish SPF on the subdomain used in the Return-Path, publish the DKIM public key under the primary domain if the DKIM signature uses d=mywebsite.com, and publish DMARC on the visible From domain. You do not add the sending subdomain to the primary domain's SPF record just because the visible From address is contact@mywebsite.com.
Gmail's mailed-by and signed-by fields identify the envelope-sender domain used for SPF and the DKIM signing domain. They can show emails.mywebsite.com and mywebsite.com respectively. Check the receiving server's Authentication-Results header for dmarc=pass rather than inferring a DMARC pass from those displayed names.
A reliable marketing configuration uses a Return-Path such as emails.mywebsite.com or bounce.emails.mywebsite.com while the header From remains contact@mywebsite.com. Watch DMARC reports until the stream is stable before moving to enforcement.
Configure subdomain SPF and primary-domain DKIM
Use the subdomain for bounces and the primary domain for DKIM
Use the subdomain for the envelope sender and SPF. Use the primary domain in the DKIM signature if you want signed-by to show the primary domain. Use the primary domain's DMARC record because the visible From address is on the primary domain.
- SPF: Publish the SPF TXT record at emails.mywebsite.com or the exact Return-Path host.
- DKIM: Configure the MTA to sign with d=mywebsite.com and publish the selector under the primary domain.
- DMARC: Publish the DMARC record at _dmarc.mywebsite.com because the visible From domain is mywebsite.com.
- MTA: Set the envelope sender to the subdomain, then set the DKIM signing domain to the primary domain.
For normal marketing mail with a nonempty MAIL FROM address, SPF checks that address's domain. The receiving server records the envelope sender in Return-Path. Set the custom MAIL FROM, also called the bounce domain, in your sending platform or MTA; adding a Return-Path header by hand does not change SPF.
If your visible From address changes to a subdomain later, the DMARC lookup changes too. For that separate case, the setup rules for subdomain DMARC records become more important.
How the domains fit together
There are three names in play. The visible From domain is what the recipient sees. The Return-Path domain is where bounces go and where SPF is checked. The DKIM d= domain is the domain that signs the message body and selected headers.
DMARC does not require SPF and DKIM to use the same exact host. It requires at least one passing authentication result whose domain matches the visible From domain under the published matching mode. This domain relationship is called DMARC alignment. Here, a valid DKIM signature with d=mywebsite.com exactly matches the domain in contact@mywebsite.com.
Authentication flow for a subdomain Return-Path, primary-domain DKIM signature, and DMARC evaluation of the From domain.
|
|
|
|
|---|---|---|---|
Header From | mywebsite.com | DMARC | _dmarc.mywebsite.com |
Return-Path | emails.mywebsite.com | SPF | emails.mywebsite.com |
DKIM d= | mywebsite.com | DKIM | selector1._domainkey.mywebsite.com |
Applicable DMARC policy | p=none, quarantine, or reject | DMARC | _dmarc.mywebsite.com |
The key identifiers for a primary-domain From address with subdomain sending.
DNS records to publish
Start with the domain used in the envelope sender. If the message bounces to emails.mywebsite.com, that exact domain needs SPF authorization for the IP address or sending service. The SPF record at mywebsite.com is not inherited; SPF starts at the exact envelope-sender domain.
SPF on the mailed-by domaindns
emails.mywebsite.com. 3600 IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.example.net -all"
This SPF value contains documentation placeholders. Replace the IP address and include with the values supplied for your account. Keep one SPF record at the Return-Path domain; merge new mechanisms before the final -all or ~all instead of publishing another SPF record. RFC 7208 limits evaluation to 10 DNS-querying mechanisms and modifiers, including nested includes; exceeding that limit produces permerror.
Next, configure your MTA to sign with the primary domain. That means the DKIM-Signature header has d=mywebsite.com. Because the selector is selector1, the receiver looks up the public key at selector1._domainkey.mywebsite.com.
DKIM key under the primary domaindns
selector1._domainkey.mywebsite.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQE..."
Relevant DKIM-Signature fieldstext
DKIM-Signature: v=1; a=rsa-sha256; d=mywebsite.com; s=selector1; h=from:to:subject:date; bh=...; b=...
The DKIM key is an abbreviated example, not a usable public key. Use the TXT value or CNAME target supplied by the sender, and confirm that the selector and d= domain in a test message lead to the same DNS name. Publish a selector as either TXT or CNAME; a CNAME cannot coexist with a TXT record at the same name, as specified in RFC 2181. Check whether your DNS provider appends mywebsite.com automatically so the host name is not duplicated.
Finally, publish DMARC on the visible From domain. For contact@mywebsite.com, the record belongs at _dmarc.mywebsite.com. If a DMARC record already exists, edit it rather than adding another, and preserve its enforcement policy unless a deliberate policy change is required. For a new deployment, start in monitoring mode until reports identify all legitimate senders.
DMARC on the visible From domaindns
_dmarc.mywebsite.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@mywebsite.com; adkim=r; aspf=r"
The rua mailbox must exist and be able to receive aggregate XML reports. To send reports to Suped, use the report address and any external reporting authorization supplied during domain setup.
If you need to create the policy record instead of editing one by hand, Suped's DMARC record generator gives you a clean TXT value for the policy, report address, and matching mode.
Confirm provider support and limit DKIM access
A third-party marketing sender must support both a custom Return-Path and DKIM signing with your domain for this exact design. If it keeps its own bounce domain, SPF can pass without matching mywebsite.com. DMARC can still pass through DKIM, provided the sender signs with d=mywebsite.com and the signature verifies.
- Custom Return-Path: Confirm the sender can use a bounce subdomain you control. Publish its required MX and SPF records, or follow its CNAME delegation instructions. A CNAME cannot share its name with TXT or MX records.
- Custom DKIM domain: Confirm the outgoing signature will use d=mywebsite.com, not the sender's shared domain.
- DNS delegation: Publish the supplied DKIM TXT record or selector CNAME exactly as provided. Give the sender access only to the required selectors.
- Selector control: Give each sender a unique selector so its key can be rotated or removed without affecting other mail.
Anyone holding the private key for a selector under mywebsite.com can create a valid DKIM signature for that domain. Restrict administrative access, rotate keys on the sender's schedule, and remove the TXT record or CNAME when the service is retired. If policy forbids third parties from signing as the primary domain, use a dedicated visible From subdomain and publish or inherit the appropriate DMARC policy for it. A subdomain signing key can still satisfy relaxed DMARC matching for the primary domain. Where exact-domain authorization is required, review both adkim=s and aspf=s across every legitimate sender before enabling them.
DMARC policy choices
Because the visible From address is contact@mywebsite.com, p= in the primary-domain DMARC record is the applicable policy. The sp= tag is for mail using an existing subdomain in From when the parent policy applies; without sp=, p= is the fallback. A subdomain Return-Path alone does not activate sp= or inherit the primary domain's SPF authorization.
Policy staging
A current DMARC rollout under RFC 9989 for a domain with several mail streams.
Monitoring
p=none
Collect reports and identify every legitimate sender.
Quarantine
p=quarantine
Request spam placement for messages that fail DMARC.
Reject
p=reject
Request rejection after legitimate streams pass consistently.
Isolated rollout
Separate subdomain
Use a visible From subdomain when one stream needs a separate policy.
RFC 9989 removed pct because percentage sampling was applied inconsistently. Do not rely on pct=25 for a staged rollout. Keep p=none while fixing legitimate sources, then move to quarantine and reject after testing direct and forwarded mail. Give a visible From subdomain its own DMARC record when it needs a separate rollout.
Relaxed matching is usually the right starting point for mixed subdomain setups. With adkim=r, a DKIM signature using d=emails.mywebsite.com can still satisfy DMARC for a From domain of mywebsite.com because both share the same organizational domain. With adkim=s, the DKIM d= domain must be exactly mywebsite.com. RFC 9989 determines organizational domains with a DNS tree walk; check receiver reports if you introduce explicit organizational boundaries with psd= tags.
The same distinction applies to SPF. A Return-Path of emails.mywebsite.com matches a From domain of mywebsite.com under aspf=r, but not under aspf=s. Exact DKIM with d=mywebsite.com still gives this design a DMARC pass when SPF is not a matching identifier.
Recommended pattern
Use contact@mywebsite.com as the visible From, emails.mywebsite.com as Return-Path, and d=mywebsite.com for DKIM.
- Authentication: DKIM gives an exact primary-domain match for DMARC.
- Operations: Marketing bounces stay separate without changing the visible From address.
Subdomain signing pattern
Use contact@mywebsite.com as the visible From, but sign with d=emails.mywebsite.com.
- Authentication: A passing subdomain DKIM signature satisfies relaxed matching. With strict DKIM matching, DMARC can still pass through matching SPF or another valid, exact-match DKIM signature.
- Operations: You manage DKIM keys under the subdomain instead of the primary domain.
Does a bounce subdomain isolate the primary domain's reputation?
A separate Return-Path makes bounce handling easier to manage. With contact@mywebsite.com in From and d=mywebsite.com in DKIM, the primary domain remains the authenticated DKIM signing identity. Treat this setup as operational separation; it does not guarantee reputation isolation or inbox placement. If you need a distinct marketing identity, use a dedicated From subdomain and DKIM signing subdomain, while continuing to monitor effects on the primary domain.
Gmail also combines sending volume across a primary domain and its subdomains when determining bulk-sender status. Creating extra subdomains does not reset that threshold. Google documents this in its sender guidelines FAQ.
How to validate the setup
After DNS is live, send a real message to a mailbox and inspect the headers. Check four things: the header From is still contact@mywebsite.com, SPF passes for the Return-Path domain, DKIM passes with d=mywebsite.com, and DMARC passes for mywebsite.com. Allow for cached DNS answers to expire according to their TTL before diagnosing a new record as missing.
Gmail's bulk-sender requirements apply to senders reaching about 5,000 messages or more to personal Gmail accounts within 24 hours. They require both SPF and DKIM, a DMARC record with p=none or stronger, and a match between From and at least one passing authentication domain. Marketing and subscribed mail also need one-click unsubscribe and a visible unsubscribe link in the message body. See Google's email sender guidelines.
A DNS-level check catches missing TXT records, bad syntax, duplicate DMARC records, and common SPF issues before you send. Suped's domain health check is a practical first pass because it checks SPF, DKIM, and DMARC together.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
DNS validation is not enough by itself. DKIM depends on the actual message header your MTA creates, and SPF depends on the IP address that connects to the receiver. A real test message proves the records and the sending system are working together. Forwarding often breaks SPF because the connecting IP changes; matching DKIM can preserve a DMARC pass if signed content remains intact.
- Header From: Confirm it remains contact@mywebsite.com and inspect the receiving server's trusted Authentication-Results header.
- SPF: Confirm spf=pass and smtp.mailfrom=emails.mywebsite.com, or the custom bounce domain you selected.
- DKIM: Confirm dkim=pass, header.d=mywebsite.com, and the expected selector in DKIM-Signature.
- DMARC: Confirm dmarc=pass and header.from=mywebsite.com; SPF, DKIM, or both must pass with a matching domain.
Illustrative results added by the receiving servertext
From: contact@mywebsite.com Return-Path: <bounce-id@emails.mywebsite.com> Authentication-Results: receiver.example; spf=pass smtp.mailfrom=emails.mywebsite.com; dkim=pass header.d=mywebsite.com header.s=selector1; dmarc=pass header.from=mywebsite.com
Monitor the marketing sender in Suped
Record which sender owns each Return-Path and DKIM selector. Suped's DMARC platform turns aggregate reports into sender-level authentication status, issue alerts, and fix steps for this workflow.
For ongoing DMARC monitoring, Suped tracks authentication sources and flags new or failing senders as you prepare policy changes.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
The practical workflow in Suped is to add mywebsite.com, enable aggregate reporting, identify the marketing sender, then compare its SPF and DKIM domains with the visible From domain. Use the reports and diagnostics to investigate missing selectors, authentication failures, or unapproved sources before changing policy. Keep watching for new senders, SPF lookup limits, and policy drift.
- Hosted DMARC: Stage policy changes without editing DNS for every adjustment.
- Hosted SPF: Manage senders and SPF lookup pressure when marketing sources change.
- Alerts: Get notified when a new source appears or authentication starts failing.
Common mistakes
A common mistake is treating the primary SPF record as a master allowlist for every subdomain. SPF is scoped to the domain being checked. If the Return-Path is emails.mywebsite.com, the receiver queries the SPF TXT record at emails.mywebsite.com.
Mistakes that cause confusing DMARC results
- Root SPF: Adding a subdomain or IP to mywebsite.com does not authorize emails.mywebsite.com.
- Wrong selector: If s=selector1 and d=mywebsite.com, the key belongs under the primary domain.
- Strict matching: adkim=s and aspf=s require exact domain equality.
- Duplicate DMARC: A domain must have one DMARC TXT record at the queried _dmarc name.
Another common mistake is enforcing too early. A marketing platform, web server, CRM, support desk, or old automation can still send as the primary domain. Move to quarantine or reject only after reports show every legitimate stream is authenticated.
Views from the trenches
Best practices
Publish SPF on the Return-Path host, not the visible From domain, for subdomain sending.
Publish primary-domain DKIM keys at the selector name, using TXT or a provider CNAME.
Review matching modes and sender results separately before changing DMARC enforcement.
Common pitfalls
Adding every subdomain to the root SPF record creates noise and does not help SPF checks.
A provider-owned Return-Path can pass SPF without matching the visible From domain.
Strict DKIM matching excludes a subdomain signature for DMARC; matching SPF can still pass.
Expert tips
Name selectors by stream or vendor so key rotation stays clear during later change work.
Separate marketing and transactional Return-Path hosts so reports map to real sources.
Confirm valid, matching DKIM survives your forwarding paths before moving to p=reject.
Marketer view
Marketer from Email Geeks says SPF must be configured on the Return-Path domain because that is the domain receivers check against the sending IP.
2021-11-09 - Email Geeks
Marketer view
Marketer from Email Geeks says DKIM signing with the primary domain means the public key belongs at selector._domainkey.mywebsite.com.
2021-11-09 - Email Geeks
Frequently asked questions
No. Publish SPF on the Return-Path domain that sends the mail. If the Return-Path is emails.mywebsite.com, SPF belongs at emails.mywebsite.com.
Yes. Mailed-by usually reflects the envelope sender domain used for SPF. Signed-by reflects the DKIM d= domain. They can differ and still pass DMARC.
For this goal, sign with the primary domain. Configure the MTA to use d=mywebsite.com, then publish the selector at selector._domainkey.mywebsite.com.
Not for messages whose visible From address is contact@mywebsite.com; DMARC uses mywebsite.com. If a subdomain later appears in From, an applicable parent policy can cover it. Publish a subdomain DMARC record when that From subdomain needs its own policy or reporting settings.
Confirm legitimate sources authenticate with a matching domain, verify DKIM on direct and forwarded mail, and review aggregate reports before changing policy. Investigate unknown sources to distinguish forgotten legitimate senders from unauthorized traffic; keep unauthorized traffic out of SPF and DKIM permissions.
