How to configure SPF, DKIM, and DMARC when sending marketing emails from a subdomain but signing with the primary domain?
Michael Ko
Co-founder & CEO, Suped
Published 25 Apr 2025
Updated 16 Aug 2025
9 min read
Many marketers face a common dilemma: they want to send marketing emails from a dedicated subdomain, like emails.mywebsite.com, to segment their email streams and protect the reputation of their primary domain. However, for branding consistency and recipient trust, they prefer the emails to appear as if they are directly from the main domain, such as mywebsite.com, in the 'From:' address. This setup implies that while the sending infrastructure uses the subdomain, the email authentication (specifically DKIM signing) should be tied back to the primary domain.
Achieving this configuration correctly is crucial for email deliverability. Misconfigurations of SPF, DKIM, and DMARC can lead to your emails being flagged as spam, ending up in junk folders, or even being rejected entirely. It requires a precise understanding of how each protocol interacts with different domains involved in the email's journey. The goal is to ensure that both the subdomain (responsible for sending) and the primary domain (responsible for the 'From:' address and signing) pass authentication checks.
This guide will walk you through the necessary steps to set up these critical DNS records. We'll clarify where each record should reside and how to ensure proper alignment, allowing you to send marketing emails from a subdomain while maintaining the primary domain's identity and strong authentication.
Understanding domain roles and email authentication
Before diving into the configuration, it's essential to understand the different domains at play in an email and how they relate to SPF, DKIM, and DMARC. This clarity helps in identifying where each DNS record needs to be published.
From: header domain: This is the address recipients see, for example, contact@mywebsite.com. In your scenario, this will be your primary domain.
Return-Path (or Mail-From/Envelope-From) domain: This is the address where bounces and other automated messages are sent. It's often set by your sending service or MTA (Mail Transfer Agent) and is typically a subdomain, like bounces.emails.mywebsite.com. This is the domain SPF checks against.
DKIM d= domain: This is the domain explicitly stated in the DKIM signature. It's the domain that publishes the public key used to verify the email's authenticity. In your case, you want this to be your primary domain, mywebsite.com.
The key to success lies in ensuring that DMARC can successfully validate your emails. DMARC requires either SPF or DKIM alignment (or both) to pass. Given your setup, DKIM alignment will be the primary mechanism for DMARC success, as SPF will typically align with the sending subdomain, not the primary domain.
Configuring SPF for the sending subdomain
SPF (Sender Policy Framework) is designed to prevent sender spoofing by allowing domain owners to specify which IP addresses are authorized to send mail on their behalf. Critically, SPF checks the Return-Path domain, not the From: header domain.
Therefore, when sending marketing emails from a subdomain (e.g., emails.mywebsite.com), your SPF record must be published on this specific subdomain. It should include all authorized sending IPs or include mechanisms provided by your Email Service Provider (ESP). You should not add the subdomain's sending IPs to your primary domain's SPF record, as this could inadvertently authorize unapproved senders for your main domain, or exceed the 10 DNS lookup limit. More on this is available in the article on how to configure SPF for a subdomain.
Example SPF record for a subdomain: emails.mywebsite.comtxt
Publish this SPF record as a TXT record for emails.mywebsite.com. This ensures that SPF passes for your marketing emails.
Implementing DKIM for primary domain signing
DKIM (DomainKeys Identified Mail) provides a cryptographic signature that verifies the sender's identity and ensures the email has not been tampered with in transit. The DKIM signature includes a d= tag, which specifies the domain that performed the signing. To achieve your goal of primary domain signing, this d= tag must be set to your primary domain (e.g., mywebsite.com), even though you're sending from a subdomain.
The public DKIM key, which corresponds to the private key used by your MTA or ESP to sign the emails, must be published as a TXT record on your primary domain. This record will typically follow the pattern selector._domainkey.yourprimarydomain.com. The selector is a unique name that allows you to have multiple DKIM keys for the same domain, which is useful for key rotation or different sending systems. For a detailed guide on setup, refer to resources like Agari's DKIM setup guide.
Example DKIM record for primary domain signingtxt
selector1._domainkey.mywebsite.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDnQ/o/X/l/g..."
The crucial part here is configuring your sending service (MTA or ESP) to sign emails with your primary domain, even when sending them out through a subdomain. Most reputable ESPs offer this functionality, allowing you to specify the signing domain. This is often referred to as custom DKIM, where you provide the public key to your DNS and your ESP uses the corresponding private key to sign the emails with your chosen domain. This topic is covered in more detail in our article, Can DKIM be set up on a subdomain?
Setting up DMARC for alignment
DMARC (Domain-based Message Authentication, Reporting, and Conformance) builds upon SPF and DKIM by instructing receiving mail servers how to handle emails that fail authentication. DMARC's primary function is to enforce domain alignment. This means that the domain checked by SPF (Return-Path) or DKIM (d= tag) must match the primary domain in the From: header (or a subdomain of it) for DMARC to pass.
Since your 'From:' header uses the primary domain (mywebsite.com) and you've configured DKIM to sign with this domain, your DKIM alignment will satisfy DMARC. Even though your SPF record is on the subdomain emails.mywebsite.com (and thus won't align with mywebsite.com for strict alignment), a passing DKIM authentication with alignment is sufficient for DMARC success. This is a common and effective setup for marketing emails.
Your DMARC record should be published on your primary domain (mywebsite.com) as a TXT record. It should begin with _dmarc. If you don't define a DMARC record for the subdomain, it will inherit the primary domain's DMARC policy by default. However, you can also define separate DMARC records for subdomains if you need different policies. Our guide on setting up DMARC records for subdomains provides further details.
Example DMARC record for primary domain
Publish this TXT record for _dmarc.mywebsite.com. The p=none policy allows you to monitor DMARC reports without affecting email delivery. Once confident in your authentication, you can gradually move to p=quarantine and then p=reject.
Monitoring your DMARC reports is essential to verify that your SPF and DKIM are correctly authenticating your emails and aligning with your primary domain. These reports will provide insights into which emails are passing or failing authentication and why, helping you troubleshoot any issues.
Important considerations and best practices
Beyond the basic SPF, DKIM, and DMARC setup, there are several nuances to consider for optimal email deliverability in this specific scenario.
Subdomain Reputation: While you're signing with the primary domain, the sending subdomain (e.g., emails.mywebsite.com) will build its own reputation. Monitor its performance, as poor practices on this subdomain could still impact your overall deliverability, even if DMARC passes via DKIM alignment. Keep an eye on Google Postmaster Tools and other sender reputation tools.
Bounce and Feedback Loop Addresses: Ensure that bounce addresses and any feedback loop addresses are correctly configured to receive data from ISPs. These should typically point to addresses on your sending subdomain.
Testing: After making any DNS changes, use an email deliverability tester to verify that SPF, DKIM, and DMARC are passing correctly. Pay close attention to the From:, Return-Path, and DKIM d= domains to ensure they align as expected. This will confirm that your primary domain is indeed doing the signing.
Views from the trenches
When setting up email authentication, especially with complex configurations involving subdomains and primary domain signing, it's beneficial to learn from the experiences of others.
Best practices
Always publish SPF records on the sending subdomain, not the primary domain, to maintain separation of concerns.
Configure your sending platform to explicitly sign emails with your primary domain if that is your desired 'From:' address.
Start your DMARC policy at 'p=none' to gather reports and analyze authentication results without impacting delivery.
Regularly monitor your DMARC reports to identify authentication failures and ensure proper domain alignment.
Use different subdomains for different email streams (marketing, transactional) to isolate reputation.
Common pitfalls
Attempting to include subdomain IPs in the primary domain's SPF record, which can lead to DNS lookup limit issues.
Not explicitly configuring your ESP to sign with the primary domain, leading to DKIM signing with the subdomain.
Expecting SPF alignment to pass when sending from a subdomain and displaying a primary domain 'From:' address.
Publishing DKIM records on the subdomain when the primary domain is intended to be the signing domain.
Not monitoring DMARC reports, leading to unnoticed authentication failures and deliverability issues.
Expert tips
An MTA can be configured to check the 'Sender:' header for the domain to sign with, providing flexibility.
DKIM configuration, including key generation and rotation, is highly MTA-specific, so consult your platform's documentation.
DMARC's relaxed alignment option can be helpful when mixing organizational and sub-domains for email sending.
Separate DMARC records can be published for subdomains if different policies are required, otherwise they inherit the primary's.
Ensure the Return-Path domain has its own SPF record for proper authorization of sending IPs.
Expert view
Expert from Email Geeks says you can send emails from the organizational domain, even if the A record points to a website. It is also possible to sign with the subdomain and not necessarily the organizational domain. The specific implementation depends on your MTA, and some MTAs can sign based on the Sender: header.
2021-11-09 - Email Geeks
Expert view
Expert from Email Geeks says you should configure the MTA to use the desired sending subdomain in the Envelope From address and then publish the SPF record for that specific subdomain including the sending IP addresses.
2021-11-09 - Email Geeks
Achieving harmonious email authentication
Successfully configuring SPF, DKIM, and DMARC when sending marketing emails from a subdomain but signing with the primary domain is a powerful strategy to balance brand consistency with email deliverability and reputation management. By correctly placing your SPF record on the sending subdomain and your DKIM and DMARC records on the primary domain, you ensure that your emails pass crucial authentication checks.
Remember that DKIM alignment will be the key to your DMARC pass in this scenario. Continuous monitoring of your DMARC reports is vital for maintaining optimal deliverability and promptly addressing any authentication issues. This approach not only protects your primary domain's reputation but also enhances recipient trust, leading to better inbox placement for your marketing campaigns.
