Authentication alignment and policy review for multi-domain senders

Why multi-domain alignment is hard

A single-domain DMARC deployment has a manageable configuration surface: one SPF record, a small number of DKIM selectors, one DMARC record. The organization knows who sends mail, the vendors are few, and the alignment problem is contained. If something breaks, there is one record to investigate. The foundational DMARC story — what the protocol is, how early adopters rolled it out, and the lessons from the first wave — is documented in DMARC in practice: early lessons from the first wave of adopters.

A multi-domain deployment has none of those simplifications. The organization owns an organizational domain (example.com) and probably a dozen related domains — country-specific variants, acquired brands, product-line identities, legacy domains from prior campaigns. Each of those domains has its own sending pattern, its own set of third-party vendors, and its own DNS zone. A change that benefits one domain can silently break alignment on another. A vendor added to support the marketing team can introduce an SPF record that fails alignment for transactional mail on the same domain. Nobody notices until Gmail's aggregate reports start showing the failure pattern, by which point it has been affecting inbox placement for weeks.

The fundamental difficulty is that alignment is a per-message property evaluated by receivers. The sender's view of whether everything is configured correctly is incomplete. Only the DMARC aggregate reports, aggregated across the major receivers, show the truth of what is actually happening to your mail. Teams that don't read those reports regularly cannot know whether their multi-domain program is healthy.

What alignment actually requires

DMARC alignment is the property that ties authentication results (SPF or DKIM pass) to the From header domain the recipient sees. A message can pass SPF and still fail DMARC if the SPF-authenticated domain doesn't align with the From header. This is the single most common source of confusion when teams first investigate their own DMARC data.

The two alignment modes

Relaxed alignment is the default when the DMARC record omits the aspf and adkim tags. For most multi-domain programs this is correct; you almost always want the flexibility to sign from subdomains that share the organizational domain. Strict mode should be a deliberate choice for specific domains where the extra tightness is justified and the operational implications are understood.

What the DMARC check actually does

1. Evaluate SPF. Perform the SPF check against the envelope Return-Path (also called MAIL FROM). Record the result.
2. Evaluate SPF alignment. Compare the Return-Path domain to the From header domain. Pass if they share the organizational domain (relaxed) or match exactly (strict).
3. Evaluate DKIM. Verify each DKIM signature in the message. Record which ones validate.
4. Evaluate DKIM alignment. For each valid DKIM signature, compare the d= domain to the From header domain. Pass if they align.
5. DMARC pass. If either SPF passed AND aligned, OR any DKIM signature was valid AND aligned, DMARC passes.
6. DMARC fail. If neither SPF nor DKIM produced an aligned pass, apply the DMARC policy (p=) from the record.

SPF across many domains and the 10-lookup ceiling

RFC 7208 sets a hard limit of ten DNS lookups per SPF evaluation. Every include:, a, mx, exists, and redirect= mechanism counts against this limit. Exceeding it causes a permerror — SPF returns neither pass nor fail, and DMARC treats it as a fail. Multi-domain programs hit this ceiling faster than they expect because each third-party vendor typically requires at least one include.

How the limit is consumed

example.com SPF — lookups accumulate quickly# An organization using multiple common vendors:
example.com. IN TXT "v=spf1
    include:_spf.google.com          # 1 lookup (+ nested lookups inside)
    include:servers.mcsv.net         # 1 lookup (Mailchimp)
    include:sendgrid.net             # 1 lookup
    include:_spf.salesforce.com      # 1 lookup
    include:spf.mandrillapp.com      # 1 lookup
    include:mail.zendesk.com         # 1 lookup
    include:_spf.intuit.com          # 1 lookup
    ~all"
# Total direct lookups: 7
# But each include may itself trigger nested lookups.
# _spf.google.com, for example, includes multiple nested includes.
# Real-world count: often 12-15 lookups, over the limit.

The strategies that actually work

The dominant strategy at serious scale is subdomain delegation. Each high-volume third-party sender gets its own subdomain (marketing.example.com for the marketing platform, tickets.example.com for Zendesk, billing.example.com for invoicing). Each subdomain has its own SPF record containing only that vendor's include. The organizational domain's SPF stays small and focused. The trade-off is DNS setup complexity, which is modest and one-time.

subdomain-delegated SPF records# Organizational domain: only in-house sending
example.com. IN TXT "v=spf1 mx include:_spf.google.com ~all"
# 2 direct lookups; plenty of headroom.

# Each vendor gets its own subdomain
marketing.example.com. IN TXT "v=spf1 include:servers.mcsv.net ~all"
tickets.example.com.   IN TXT "v=spf1 include:mail.zendesk.com ~all"
billing.example.com.   IN TXT "v=spf1 include:_spf.intuit.com ~all"
notifications.example.com. IN TXT "v=spf1 include:sendgrid.net ~all"

# The vendor sends From: marketing@marketing.example.com
# SPF check passes against the subdomain
# DMARC alignment passes because marketing.example.com is a subdomain of example.com
# (relaxed alignment; default)

DKIM signing for third-party senders

DKIM alignment works by having the third-party vendor sign outbound mail with a key published under your domain. The signing domain (d= in the DKIM header) must match or be a subdomain of the From header for alignment. Most major vendors support this pattern; the setup is one of the more valuable pieces of DMARC preparation work. The underlying DKIM signing mechanics, which most vendors abstract away but which you need to understand when troubleshooting, are covered in DKIM signing for transactional email.

The vendor-signing pattern

CNAME-based DKIM delegation# Vendor provides you with CNAME records to publish.
# They generate and manage the actual key; you point to it via DNS.

# Example: SendGrid DKIM setup
s1._domainkey.example.com. IN CNAME s1.domainkey.u12345.wl.sendgrid.net.
s2._domainkey.example.com. IN CNAME s2.domainkey.u12345.wl.sendgrid.net.

# Example: Mailchimp (Mandrill)
k1._domainkey.example.com. IN CNAME dkim.mandrillapp.com.

# The vendor signs outbound mail with:
#   From: newsletter@example.com
#   DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; ...
# The selector s1 is looked up at s1._domainkey.example.com
# DNS resolves to the CNAME, which resolves to the vendor's key
# DKIM validates; the d= domain is example.com (your org domain)
# DKIM alignment with From header: pass
# DMARC: pass

When the vendor won't support DKIM with your domain

A handful of less-mature vendors still sign with their own domain by default and don't support signing on your behalf. For these, your options are: push the vendor to add support, accept that DMARC won't pass for mail through this vendor, or replace the vendor. The third option is increasingly practical because DMARC-compliant vendors have become the norm over the past two years; a vendor that can't align DKIM in 2017 is behind the market.

DMARC policies per organizational domain

The DMARC record at _dmarc.example.com governs policy for the organizational domain and, via the sp= tag, inherits policy for subdomains. Multi-domain programs need one DMARC record per organizational domain. A program with three distinct organizational domains (example.com, example.co.uk, example.de) needs three DMARC records.

DMARC record anatomy_dmarc.example.com. IN TXT
  "v=DMARC1;
   p=quarantine;           # policy for example.com itself
   sp=reject;              # policy for subdomains (marketing.example.com, etc.)
   adkim=r;                # DKIM alignment: relaxed
   aspf=r;                 # SPF alignment: relaxed
   pct=100;                # apply to 100% of failing mail
   rua=mailto:dmarc-agg@example.com;  # aggregate reports
   ruf=mailto:dmarc-forensic@example.com;  # forensic reports (less common)
   fo=1;                   # generate forensic report on any failure
   ri=86400"               # aggregate report interval: 1 day

Tag by tag — what to set and why

Subdomain policies and the sp tag

The sp= tag is the mechanism that makes multi-domain programs tractable. Without it, every subdomain needs its own DMARC record to specify policy; with it, subdomains inherit from the organizational domain automatically.

The inheritance pattern

A DMARC record at _dmarc.example.com applies to:

• example.com itself — policy governed by p=
• Every subdomain of example.com that does not have its own DMARC record — policy governed by sp=
• Subdomains that do have their own DMARC record — their own record takes precedence

Hierarchical DMARC policy# Organizational domain
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-agg@example.com"
# All subdomains without their own record → p=reject

# Subdomain with its own relaxed policy (override)
_dmarc.marketing.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-agg@example.com"
# marketing.example.com → p=quarantine (override)
# subdomains of marketing.example.com (e.g., newsletter.marketing.example.com)
#   without their own record → inherit marketing.example.com's policy via its own sp=
#   (if sp= omitted, defaults to match the subdomain's p= value)

# Subdomain explicitly set to none during transition
_dmarc.legacy.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com"
# legacy.example.com → p=none (monitoring only, while legacy senders are identified)

The common mistake: forgetting sp

Many organizations publish a DMARC record with p=reject and omit sp=. The default behavior is for sp to match p, which means every subdomain inherits p=reject. If a forgotten legacy subdomain is still sending unauthenticated mail, that mail starts getting rejected globally. Teams discover this when internal systems or archived applications stop sending.

The safer pattern for multi-domain programs: during the enforcement transition, set sp= explicitly. Start with p=reject; sp=none, then move subdomains individually as you verify each one is aligned. Once all subdomains are verified, tighten to sp=reject. This prevents the "switched to reject and broke forgotten systems" incident.

Delegating to vendors without losing alignment

Every major email vendor in 2017 supports DMARC alignment if configured correctly. The configuration differs per vendor, but the principles are consistent: either the vendor sends from a subdomain you delegate to them (SPF alignment via the subdomain's SPF record) or the vendor signs DKIM with a key published under your domain (DKIM alignment via CNAME). Usually both.

The vendor-by-vendor pattern

The pattern is consistent: subdomain delegation is the scalable strategy. Vendors that require their own includes in your organizational SPF are increasingly exceptions rather than the rule. When evaluating new email-sending vendors, DMARC compliance should be in the procurement checklist alongside the usual feature requirements.

Aggregate reports and what they actually tell you

DMARC aggregate reports (the XML files sent to the rua= address) are the single most valuable data source for understanding a multi-domain program's health. They contain per-receiver summaries of every message the receiver processed from your domain: how many, from which sending IPs, SPF/DKIM/alignment results, and what action the receiver took.

What aggregate reports catch that nothing else does

1. Unauthorized senders. If someone is spoofing your domain, their IPs appear in aggregate reports as failed-authentication sources. This is the single most important security benefit of reading reports.
2. Forgotten legitimate senders. Services the IT team lost track of — an old CRM, a legacy billing system, a forgotten vendor integration — show up in aggregate reports. Each one needs to be either authorized (updated SPF, DKIM, or subdomain delegation) or decommissioned.
3. Alignment failures on authorized senders. Vendors that are supposed to be configured correctly sometimes aren't. Aggregate reports reveal when alignment is broken even though the team thinks everything is set up.
4. Forwarding patterns. Forwarded mail often breaks SPF but preserves DKIM. Aggregate reports show which forwarding patterns are healthy (DKIM alignment survives) and which are not.
5. Receiver-specific behavior. Different receivers handle the same configuration slightly differently. Reports let you see how Gmail, Microsoft, and others are interpreting your mail.

Processing raw aggregate reports at scale

Raw DMARC XML is unreadable by hand. Every serious multi-domain program uses a processing service to ingest, parse, and visualize the aggregate data:

The right choice depends on program scale and organizational appetite for operational work. For multi-domain programs of any material size, a commercial DMARC service is usually the right call — the time saved on parsing, visualization, and alerting outweighs the license cost. Self-hosting parsedmarc works fine for smaller programs but becomes operational overhead at scale. The broader ecosystem of complaint handling and feedback loops that complements DMARC reporting is covered in feedback loops and complaint handling for bulk senders.

The policy progression from none to reject

The purpose of DMARC is to move from monitoring (p=none) to enforcement (p=reject). Teams that stop at monitoring get the reporting benefits but not the protection benefits. The progression is the point.

The DHS BOD 18-01 moment

Last week, the US Department of Homeland Security issued Binding Operational Directive 18-01, requiring all US federal civilian executive branch agencies to adopt DMARC and progress to p=reject within twelve months. The directive is narrow in scope — it applies to federal agencies, not private enterprises — but it is moving the broader conversation about email authentication in ways that will affect every multi-domain program over the next year.

Three observations about the directive's significance:

For multi-domain programs specifically, the BOD 18-01 directive is useful ammunition when making the internal case for investment. "We should do this because it's a security best practice" is a softer argument than "we should do this because US federal agencies are being required to and the standard will land on us next." Both are true; the second one gets budget faster.

Auditing a multi-domain program quarterly

A multi-domain DMARC program needs quarterly maintenance. Configurations drift, vendors change, subdomains get added, and aggregate reports accumulate. Without a structured audit, programs decay even when they started healthy.

The quarterly checklist

The audit takes a couple of hours per quarter for a program with ten or twenty domains. That time pays for itself many times over in prevented incidents — a program without the audit drifts into a state where nobody quite knows the current configuration, and the first sign of trouble is aggregate reports showing unauthenticated sending that should have been caught months earlier.

Frequently asked questions

Should every subdomain have its own DMARC record?

Usually no. The organizational domain's DMARC record, with a correctly-set sp= tag, covers most subdomains. Individual subdomain records are warranted only when a subdomain needs a different policy than the organizational default — typically during the progression, when some subdomains are ready for p=reject while others are still at p=none.

What if a vendor can't support DKIM alignment?

Two options. Use a subdomain for that vendor so SPF alignment handles the DMARC pass. Or, if the vendor is low-volume and both SPF and DKIM alignment will fail, accept that DMARC will fail for mail through this vendor and decide whether the impact matters. A vendor that can't do either is a vendor that should be replaced; this was true as of a year or two ago and is even more true now.

How do we handle mailing lists that break authentication?

Mailing lists often modify messages in ways that break both SPF (source IP changes) and DKIM (body modifications invalidate the signature). The practical workaround is that most list software rewrites the From header to the list's own domain, so DMARC is evaluated against the list's domain rather than the original sender. Modern list management tools handle this correctly; older or misconfigured ones produce DMARC failures for every list message.

What about forwarding?

Forwarding also breaks SPF because the forwarder's IP isn't authorized. DKIM usually survives forwarding if the forwarder doesn't modify the message. This is one reason DKIM alignment is more important than SPF alignment in practice — DKIM works in more real-world scenarios.

Is it worth setting up ruf= for forensic reports?

Usually not. Gmail and several other major receivers don't send forensic reports at all (privacy policy reasons). The reports that do arrive are limited. Skip ruf= unless you have a specific forensic need; focus on rua= aggregate reports.

How do we prove DMARC compliance to auditors?

Provide the DMARC records (publicly visible via DNS), aggregate report summaries from your DMARC processor showing authentication pass rates, and documentation of the progression journey (policy history, subdomain inventory, vendor alignments). Most DMARC processors export compliance-friendly reports; that's usually sufficient for audit purposes.

What happens if our aggregate report destination stops working?

Receivers keep trying for a while, then give up. If the receiving server sends bounces, some receivers may reduce reporting frequency. If aggregate reports stop arriving, first check the report destination's health, then verify the DMARC record is still published correctly, then investigate whether the receiver is having its own issues.

Closing perspective

Multi-domain DMARC is solvable. The specification is clear, the tooling is mature, and the organizations that have successfully reached p=reject across multiple domains are not exotic — they applied the discipline over six to twelve months, read their aggregate reports consistently, and progressed the policy when the reports justified advancing. Nothing in the path is secret; what's scarce is the organizational attention to actually do the work through to completion.

The BOD 18-01 announcement last week is the nudge that will move this from "something the security team has been advocating" to "something the business has to prioritize" for many organizations. Federal agencies have a year to reach p=reject. The private-sector mirror of that pressure — from auditors, insurers, procurement teams — will land within eighteen months. Teams that start the work now will be ahead when the pressure arrives. Teams that start when the pressure arrives will be behind.

The other pattern worth internalizing: the discipline is reading aggregate reports, not configuring records. Records are one-time work. Reports are ongoing work. The programs that reach p=reject successfully are the ones that built the habit of weekly report review early and kept it as the program expanded. The programs that stall at p=none built the records and never built the review habit. Technically, both are "doing DMARC." Operationally, only one is protecting the domain.

For organizations starting this work today, the honest sequencing: inventory your sending domains and vendors first. Publish DMARC records at p=none across all organizational domains. Set up a DMARC processor and start reading reports. Fix alignment issues one by one as they surface. Begin the progression on the domains that show clean reports the soonest; leave the complicated ones for later in the journey. And plan for twelve months; the timeline is what it is. The reason the work matters at all — the underlying sender-reputation model that filters use to decide who to trust — is covered in sender reputation fundamentals.