What are the best methods for identifying email sending vendors for DMARC enforcement?

Key findings

• DMARC report limitations: DMARC aggregate reports provide IP addresses, the 5322.From domain, the 5321.From (SPF) domain, and DKIM signing domains and selectors. However, they do not typically include the individual sender's email address due to privacy concerns.
• Vendor identification gap: While reports show the technical sending source (e.g., Mailgun, AWS SES), they do not link it directly to the end-user or department within an organization that uses a higher-level service, which in turn uses these backend ESPs.
• Enterprise complexity: Large organizations often struggle to maintain a comprehensive list of all their email sending vendors, as various departments may independently onboard services that send email on the company's behalf.
• Phased DMARC deployment: Transitioning from a p=none (monitoring) policy to quarantine or reject is crucial for identifying unknown or unaligned senders without immediately disrupting mail flow.

Key considerations

• Proactive vendor audit: Before DMARC enforcement, conduct a thorough audit of all existing and potential email sending vendors across all departments. This is detailed further in our guide on DMARC implementation best practices.
• Cross-reference with finance: Leverage financial records (invoices, expense reports) to identify billing entities that might correspond to unlisted email vendors. This can reveal unexpected sending sources.
• Establish internal processes: Implement a formal process for vetting and approving new email sending vendors to ensure DMARC compliance and proper configuration from the outset. This minimizes future surprises and streamlines the setup with multiple email senders.
• Leverage DMARC aggregate reports: Use these reports to detect unrecognized IPs or domains sending on your behalf. While they don't provide individual user data, they are invaluable for discovering shadow IT or unapproved senders. More information about aggregate reports can be found in this article on third-party email abuse.

Key opinions

• Data granularity: Marketers frequently express frustration that DMARC reports do not show enough information, specifically wishing for the individual sender's email address alongside the IP, rather than just the domain.
• Vendor obscurity: It is common for clients to know they use a specific service (e.g., an invoicing company) but be unaware that this service uses a backend ESP like AWS SES, Mailgun, or SendGrid, making direct vendor identification difficult.
• Decentralized sending: In large enterprises, numerous individuals or departments might set up their own email sending accounts (e.g., multiple Mailchimp accounts), leading to a fragmented and hard-to-track email ecosystem.
• Communication silos: Sales and marketing teams often do not consult with DNS or compliance teams when setting up new email sending services, creating blind spots for DMARC implementation.

Key considerations

• Leverage p=none: Initially setting a DMARC policy to p=none allows for monitoring without disrupting mail flow, providing time to identify all legitimate senders and address any authentication issues. This is a critical first step as explained in DMARC policy examples.
• Proactive communication: Actively engage sales and marketing teams to compile a list of all email sending platforms they use, including those that might employ backend ESPs.
• Phased enforcement strategy: Utilize the quarantine policy with a low percentage as a soft block to draw attention to unauthenticated mail without completely stopping it, making it easier to safely transition your DMARC policy.
• SPF record review: Perform regular SPF lookups on your domain to identify any include: mechanisms that point to approved ESPs, providing a quick way to identify known major senders as discussed in this article on email authentication best practices.

Key opinions

• Holistic discovery: A comprehensive discovery phase for DMARC implementation should span at least six months, encompassing major holiday periods to capture seasonal or irregular email sending activities.
• Project management focus: Identifying and managing email sending vendors is largely a basic project management task, requiring the appointment of supplier managers for each business unit to drive the process.
• DNS log analysis: Reviewing DNS change committee logs can reveal historical SPF-related entries or other DNS modifications linked to new email sending services.
• DMARC reports for unknowns: While internal processes are key, DMARC aggregate reports are indispensable for uncovering unknown email sending sources that existing governance structures might miss.

Key considerations

• Avoid disrupting legitimate mail: Cutting off legitimate email flow during DMARC enforcement indicates a failure in the identification and alignment process. The goal is to correct, not to break.
• Establish new approval processes: It is vital to create a clear process for approving new email vendors and domains. This ensures that all future email sending services are onboarded with DMARC compliance in mind from the start, as explored in DMARC setup best practices.
• Address underlying policy issues: Situations with multiple unmanaged email accounts (e.g., 30 Mailchimp accounts) highlight deeper organizational policy issues beyond DMARC, such as brand guidance and anti-spam compliance.
• Consider delegation mechanisms: Experts advocate for future improvements, such as the ability to delegate third-party DKIM signers, which would simplify DMARC for complex organizational structures like subsidiaries or brands operating under a parent company’s domain. This could simplify DMARC implementation complexities.

Key findings

• Aggregate report structure: DMARC aggregate reports (RUAs) provide summarized XML data including sending IP addresses, counts of messages, and authentication results (SPF and DKIM alignment status) for a given domain over a period.
• Forensic reports (limited): While DMARC includes a forensic reporting (RUF) mechanism intended to provide detailed message headers for failed emails, these reports are rarely sent by mailbox providers due to privacy concerns and potential for abuse.
• Domain-level focus: DMARC primarily operates at the domain level, verifying the alignment of the From: header domain with SPF and DKIM authenticated domains, rather than focusing on individual email addresses.
• Policy enforcement: The core function of DMARC, as specified in its RFC, is to allow domain owners to instruct receiving mail servers on how to handle emails that fail DMARC authentication (e.g., none, quarantine, or reject). More information about this can be found in our list of DMARC tags and their meanings.

Key considerations

• Data interpretation: Domain owners must effectively interpret DMARC aggregate reports to identify non-compliant sending IPs and domains. This requires understanding the report format and extracting actionable insights, as detailed in how to interpret DMARC reports.
• Alignment requirements: For DMARC to pass, either SPF or DKIM must align with the organizational domain. Understanding this alignment process is crucial for configuring third-party senders correctly. More on this is available in the email authentication guide.
• DNS configuration: Proper DMARC enforcement relies on accurate DNS records for SPF and DKIM. Any email sending vendor must be correctly added to the domain's SPF record and set up with DKIM signing to ensure alignment.
• Monitoring and iteration: DMARC implementation is an iterative process. Continuous monitoring of reports and adjusting configurations based on findings is necessary to gradually move to stricter enforcement policies like p=reject. Our guide on testing email deliverability covers ongoing verification.