"Can we just flatten the SPF record instead of using subdomains?"
Flattening works but the operational tradeoffs are significant. ESP IP ranges change without notice; SendGrid adds new ranges, Google rotates netblocks, the flattened record becomes stale within weeks. The choice is between paying for an automated re-flattening service that runs continuously or accepting silent SPF degradation. Subdomain segmentation routes each ESP to its own subdomain (marketing.example.com via Mailchimp, transactional.example.com via SendGrid) and each subdomain carries its own 10-lookup budget. dmarcian published the subdomain-vs-flattening analysis and Tim Draegen, DMARC coauthor, recommends subdomain segmentation explicitly. Flattening remains the right answer when subdomain segmentation is structurally unavailable, typically because the customer brand requires the apex domain for all marketing-facing email; in those cases EMP deploys flattening with an automated refresh service.
"Our DKIM is at 1024-bit and has been working fine. Why upgrade?"
RFC 8301 mandates 2048-bit minimum for senders. Gmail and Yahoo now explicitly prefer 2048-bit and may downgrade reputation signals for 1024-bit senders, which means the 1024-bit key works in the sense that DKIM verifies but the overall sender reputation carries a structural downgrade. 1024-bit RSA keys are at the edge of current computational attack capability; M3AAWG considers 2048-bit immune to brute-force in today's environment. The upgrade is straightforward with the rotation procedure: generate the new 2048-bit key, publish in DNS under a new selector, switch the signing service after propagation, deprecate the 1024-bit key. The transition happens without any visible delivery impact when executed in the right order. Customers with 1024-bit keys deployed years ago typically have several other authentication hygiene gaps that the inventory phase surfaces; the upgrade is rarely the only finding.
"How do we discover unauthorized senders during the inventory?"
The inventory uses three data sources to construct the complete sending surface. First, 30-60 days of DMARC aggregate reports parsed for every IP that has attempted to send as the domain; legitimate sources show up in volume, illegitimate sources show up as small-volume tails. Second, customer interviews with marketing operations, sales operations, customer success, and IT to identify SaaS tools deployed by individual teams; this captures the long tail of tools that send transactional email (DocuSign, Calendly, scheduling tools, payment processors). Third, vendor contract review against finance records to identify former employee accounts and deprecated services that still hold active sending credentials. The output is the sender inventory document which the customer security team uses as the authoritative list going forward. Common findings: 3-7 orphan accounts in mid-size organizations, 10-25 in enterprise.
"What is the relationship between this engagement and DMARC enforcement?"
SPF DKIM setup is the prerequisite for DMARC enforcement. DMARC defines the policy (none, quarantine, reject) and the alignment requirement (the From domain must match the SPF or DKIM domain). If SPF is in permerror or DKIM signing is broken, moving DMARC from p=none to enforcement creates immediate delivery failures for legitimate email. The SPF DKIM Multi ESP engagement followed by DMARC Push is the recommended sequence for organizations not yet at enforcement; the combined Plus DMARC Push tier runs both phases in a single engagement at a discount. Organizations already at enforcement with degraded authentication face a different remediation: SPF DKIM cleanup must execute without disrupting the enforcement that is already in place, which constrains the migration to additive changes only and is operationally more complex.
"Why does EMP recommend separate DKIM keys per service instead of one?"
Three reasons. Isolation: if a private key is compromised at one service (SendGrid breach, employee laptop stolen with Mailchimp credentials cached), the exposure is contained to that service rather than the whole signing surface. Independent rotation: each service rotates on its own schedule without coordination overhead; some ESPs require advance notice for selector changes that would otherwise force the rotation of all services in lockstep. Diagnostics: DMARC aggregate reports identify the source of signing problems by selector, so a DKIM failure from Mailchimp shows up in reports as the Mailchimp selector failing rather than as a generic domain failure. The selector naming convention follows the M3AAWG pattern: google-2026q3._domainkey for Google Workspace, sg-2026q3._domainkey for SendGrid, k1._domainkey for Mailchimp (Mailchimp uses k1, k2, k3 selectors by convention), freshdesk-2026q3._domainkey for Freshdesk.
"What if we discover during inventory that our SPF is already in permerror?"
The inventory phase commonly surfaces this finding when organizations have accumulated 4 or more ESPs over time. The remediation is the SPF DKIM Setup engagement itself; the subdomain segmentation strategy resolves the permerror by routing each ESP off the apex into its own subdomain with an independent budget. The engagement does not require any prerequisite work; if the customer is in permerror at discovery time, the engagement is exactly the right answer. The DMARC enforcement question is separate: if the customer is in permerror at p=none, the impact is degraded but not catastrophic because p=none does not act on the authentication failure; if the customer is in permerror at p=quarantine or p=reject, the impact is immediate delivery failure and the engagement must be expedited. EMP runs the expedited variant of the engagement (1 week for Single ESP, 1 week for Multi ESP) at 25 percent premium for organizations in active permerror at enforcement.
