Sending campaigns or transactional email from the company's primary domain — the same domain used for employee email and the public website — means a single deliverability incident puts all corporate communication at risk. A reputation hit on company.com from a marketing campaign can cause ceo@company.com to land in spam at Gmail. RFC7489-s3 describes this failure mode implicitly: DMARC policy applied to the primary domain affects all mail from that domain, marketing or not. Domain isolation using a sending subdomain (mail.company.com) confines reputation impact to the sending infrastructure and leaves corporate email unaffected by campaign performance.
High because using the primary corporate domain for bulk sending creates a single reputation failure point — a bad campaign can block all company email, including transactional and employee-to-recipient communications, at major mailbox providers.
Move all bulk sending From addresses to a subdomain you authenticate independently from the corporate domain. Authenticate the subdomain with its own SPF, DKIM, and DMARC records:
// Change this:
const from = 'noreply@company.com'
// To this:
const from = 'noreply@mail.company.com'
Then publish DNS records for mail.company.com independently:
# SPF for mail.company.com
mail.company.com TXT "v=spf1 include:sendgrid.net ~all"
# DKIM selector for mail.company.com
k1._domainkey.mail.company.com TXT "v=DKIM1; k=rsa; p=<pubkey>"
# DMARC for mail.company.com
_dmarc.mail.company.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@company.com"
The corporate company.com DMARC policy remains separate and is unaffected by mail.company.com reputation. Track both sets of records in infrastructure-as-code.
ID: deliverability-engineering.domain-ip-strategy.domain-isolation
Severity: high
What to look for: Count all From header domains used across the codebase. Check the From header domain used in outgoing emails. Verify it is not the company's primary corporate domain (e.g., company.com used for website and company email). Look for sending-specific subdomains or sister domains: mail.company.com, em.company.com, send.company.com, or company-mail.com. A reputation hit on the sending domain should not affect deliverability of employee email at company.com.
Pass criteria: Email is sent from a subdomain or sister domain distinct from the primary corporate domain. The primary company.com domain is reserved for corporate email and website, and not used for bulk sending.
Fail criteria: Email campaigns or transactional sends use the primary corporate domain as the From address, meaning a reputation hit would block all company email.
Skip (N/A) when: The project is a small startup sending fewer than 1,000 emails per month where domain isolation is not yet practical.
Detail on fail: "Email campaigns sent from 'noreply@company.com' — a reputation incident would affect employee@company.com deliverability and vice versa" or "No sending subdomain configured — primary corporate domain used for all email"
Remediation: Configure a dedicated sending subdomain:
// Bad: Primary domain used for sending
const from = 'noreply@company.com'
// Good: Sending subdomain isolated from corporate email
const from = 'noreply@mail.company.com'
// Then authenticate mail.company.com independently with SPF/DKIM/DMARC:
// SPF: mail.company.com TXT "v=spf1 include:sendgrid.net ~all"
// DKIM: k1._domainkey.mail.company.com TXT "v=DKIM1; k=rsa; p=..."
// DMARC: _dmarc.mail.company.com TXT "v=DMARC1; p=quarantine; rua=..."