DMARCGuardian Practical help for DMARC, SPF, DKIM, and BIMI.

Blog · Dmarc

Should You Send Email Marketing from a Subdomain or Your Root Domain?

By DMARCGuardian Editorial Team ·

When you set up your marketing email platform, one of the first questions you face is deceptively simple: should the From address show newsletter.example.com or just example.com?

It looks like a cosmetic choice. It is not. The domain you send from determines your SPF and DKIM obligations, how you configure DMARC, and whether a reputation problem on your marketing mail can hurt your transactional mail. Get this wrong and you will spend months untangling authentication failures.

Here is how to decide correctly.

The Core Question: What Is Your Sending Domain?

Your sending domain is the domain that appears in the From address of your marketing emails. If your From address is hello@example.com, your sending domain is example.com. If it is hello@mail.example.com, your sending domain is mail.example.com.

This matters because every email authentication protocol - SPF, DKIM, and DMARC - operates at the domain level. The choice you make here shapes every authentication decision that follows.

Option 1 - Send from a Subdomain (e.g., mail.example.com)

Using a subdomain for marketing email is the approach most email infrastructure specialists recommend, and for good reasons.

SPF Implications

A subdomain has its own SPF record space. You can add your marketing platform to the subdomain's SPF record without touching the SPF record for your root domain. If your marketing platform is Klaviyo, you add include:sendgrid.net to mail.example.com and leave example.com untouched.

This matters when you use multiple email services. Transactional email from your app, marketing email from Klaviyo, and transactional alerts from SendGrid can each have their own subdomain with their own SPF record. The DNS lookup limits that apply to SPF (the infamous 10-DNS-lookup ceiling) apply separately to each subdomain, so you have more room to add include statements.

If you flatten your SPF record to stay under the lookup limit, a subdomain gives you a cleaner slate to work from.

DKIM Implications

Most major marketing platforms (Klaviyo, Mailchimp, Brevo, SendGrid) provide a DKIM key pair. You publish the public key in your DNS for the subdomain you send from, and the platform signs outbound mail with the private key. This is straightforward and works the same whether you use a subdomain or a root domain, but the subdomain keeps the signing key isolated from your other sending contexts.

DMARC Alignment and the sp Tag

This is where subdomain sending earns its reputation. When you set DMARC policy on your root domain with p=reject, you can use the sp tag to apply a different (usually softer) policy to subdomains:


v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc-reports@example.com;

This means your root domain mail must align perfectly (strict DMARC), but your subdomain mail that fails DMARC gets quarantined rather than rejected. It is a safety valve that lets you enforce the strictest policy on your primary domain while giving subdomain senders some room to fail safely.

Without the sp tag, a p=reject policy on your root domain does not automatically apply to subdomains. Subdomains that do not publish their own DMARC record inherit the parent policy. Subdomains that publish their own record are governed by it instead. Using explicit subdomains with their own DMARC records (or the sp tag) gives you granular control.

Reputation Isolation

If your marketing platform sends something that gets flagged - a campaign that trips spam filters, a list that generates complaints - the damage stays contained to mail.example.com. Your transactional email on example.com keeps its reputation intact.

For many organizations, this isolation is the main reason to use a subdomain. Marketing email volume is volatile and complaint-prone. Transactional email needs to land in the inbox reliably. Subdomain sending keeps those two risk profiles apart.

Option 2 - Send from Your Root Domain (e.g., example.com)

Sending marketing email from your root domain is simpler in some ways and riskier in others.

SPF Implications

When you send from your root domain, every email service you use must be included in a single SPF record on that domain. If you use Klaviyo for marketing, SendGrid for transactional, and Postmark for password resets, all three include must fit in example.com's SPF record.

The 10-DNS-lookup limit becomes a real constraint. SPF flattening helps, but flattened records are harder to maintain and can break silently when IP addresses change. If you add a fourth or fifth service, you may hit the ceiling and start seeing PermError responses that cause SPF to fail for all your mail.

DKIM Implications

DKIM works the same regardless of domain level. You publish the public key in DNS and the sending platform signs with the private key. The complication with root domain sending is that every platform that sends mail for you needs to sign with a DKIM key that aligns with your root domain. Some platforms can only sign from their own default subdomain (e.g., mailsender.platform.com), which does not align with your root domain.

Before committing to root domain sending, verify that every platform you plan to use can DKIM-sign from your exact domain. If a platform cannot, DMARC alignment will fail for that platform's mail.

DMARC Alignment Requirements

When your marketing mail uses the root domain, DMARC alignment requires either:

  • SPF alignment: the MAIL FROM domain matches example.com, or
  • DKIM alignment: the DKIM selector domain matches example.com

Both must be aligned. If any sending platform uses a different envelope domain or a DKIM selector in its own subdomain, DMARC fails for that mail. At p=reject, that means rejected mail.

The practical implication: root domain sending demands more authentication discipline. You need every sending service to be perfectly configured or your DMARC policy will bounce legitimate mail.

Reputation Risk from Mixing Sending Contexts

This is the biggest risk of root domain sending. Your marketing email and your transactional email share the same domain reputation. A badly timed spam complaint, a sudden jump in volume that trips filters, or a deliverability problem at one sender affects everything.

If your marketing campaign lands in spam, your password reset emails and invoice confirmations may follow. There is no isolation.

The Decision Framework - Which Should You Choose?

Here is a practical way to think about it.

Use a subdomain if:

  • You send both transactional and marketing email from the same domain
  • You use more than two email sending services
  • You want the ability to set p=reject on your root domain while keeping subdomain mail manageable
  • Your marketing volume is high or variable
  • You share the domain with third parties who send on your behalf

Use your root domain if:

  • All your transactional and marketing email uses a single integrated platform
  • You only have one or two sending services
  • You have strong internal processes for managing authentication records
  • You do not mind the tighter coupling between marketing reputation and transactional deliverability

The deciding question is usually this: does anything else besides marketing send from your domain? If yes, go with a subdomain. If your domain is dedicated exclusively to marketing and you control every byte of sending, root domain sending can work - but subdomain sending still gives you more flexibility long-term.

How to Set Up DMARC for Each Approach

DMARC Setup for Subdomain Senders

  1. Choose a root domain DMARC policy. If you have other important subdomains (e.g., for transactional email), start with p=quarantine and move to p=reject once you have validated alignment for all senders.
  2. Add an sp tag with quarantine or none for subdomains you cannot yet fully validate: v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:dmarc-reports@example.com;
  3. Set up monitoring on your root domain. You want to see failures from all subdomains, not just your main sending subdomain.
  4. Validate each subdomain sending context individually before tightening its policy.
  5. Once a subdomain's sending platform is stable and aligned, you can move that specific subdomain to p=reject by publishing a separate DMARC record on it.

DMARC Setup for Root Domain Senders

  1. Audit every sending service you use before going live. Verify SPF and DKIM configuration for each.
  2. Publish a v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; record and monitor for at least 2 weeks.
  3. Review aggregate reports to identify any senders misaligned with your domain.
  4. Move to p=quarantine once you have resolved alignment failures.
  5. Move to p=reject only when aggregate reports show zero failures across all legitimate senders.

The key discipline for root domain sending: never add a new sending service without first verifying it DKIM-signs from your exact domain. A single misconfigured sender can break your entire domain's mail under p=reject.

How to Monitor Your Sending Domain Authentication

Whichever approach you choose, you need to watch your DMARC reports. Aggregate reports show you every sending source that is passing or failing DMARC alignment for your domain. Without that visibility, you will not know that a new marketing platform is misaligned until your mail starts bouncing.

With subdomain sending, the number of active sending contexts grows quickly - your marketing platform, your transactional service, your product email, each with its own SPF include and DKIM key. DMARCFlow monitors aggregate reports across all of them in one place, flags senders that drop out of alignment, and alerts you before a misconfigured platform starts generating reject-mode failures. For subdomain senders especially, this cross-context visibility is the difference between catching a new platform's first alignment failure and discovering it when a batch of invoice emails gets rejected.

FAQ

Can I change my marketing sending domain later?

Yes, but it requires DNS changes and DNS propagation takes time. Most major email providers (Klaviyo, Mailchimp, Brevo) allow you to add a new sending domain and verify it before switching over. Plan for at least 48-72 hours of DNS propagation before expecting full deliverability from a new domain.

What happens to my root domain reputation if my subdomain sends spam?

If you use a subdomain for marketing and that subdomain gets flagged, your root domain reputation is generally protected - provided they are truly separate DNS records and not sharing authentication. The SPF, DKIM, and DMARC contexts are separate. This is why subdomain sending is preferred when you have any other important sending from your domain.

Do I need separate SPF records for my subdomain and root domain?

Yes. Each DNS zone (root domain and each subdomain) has its own SPF record. Adding an include to your root domain does not affect your subdomain's SPF, and vice versa. If you use the same sending platform for both contexts, you will need to add the same include statement to both records.

Can I use the same DKIM key for both subdomain and root domain sending?

Not directly. DKIM keys are published for a specific selector-domain pair. If you want to DKIM-sign from both example.com and mail.example.com, you typically need separate selector records - one for the root domain and one for the subdomain. Most marketing platforms handle this automatically when you add their DKIM record to your DNS.

How does the DMARC sp tag work with subdomain sending?

The sp tag applies a policy specifically to subdomains of the domain where your DMARC record is published. If you publish v=DMARC1; p=reject; sp=quarantine; on example.com, then mail from mail.example.com that fails DMARC gets quarantined rather than rejected. This gives you a softer policy for subdomain senders without weakening your root domain policy. Without the sp tag, subdomains are not automatically subject to a different policy - they either inherit the parent record or have their own explicit DMARC record.