Enterprise Email Deliverability & Infrastructure Fix

Background

Emails were going to spam. Not occasionally — consistently. Client communications, transactional notifications, regulatory alerts. All of it either landing in junk or being silently rejected by Google, Microsoft, and enterprise mail gateways.

The organization ran multiple domains, and each team had set up their own sending configurations independently. The CRM team had their SPF records. Marketing used a separate platform with different sending IPs. Transactional notifications came from a third-party service. Nobody held a complete picture of all the systems sending on behalf of the organization's domains — which meant nobody could see the conflicts.

By the time the problem was escalated, client relationships were already affected. Important emails weren't reaching inboxes. Regulatory notifications were failing delivery. The risk was real on both sides.

Anil Choudhary led the full audit, remediation, and enforcement implementation.

The Challenge

SPF Record Conflicts and Lookup Limit Violations

SPF (Sender Policy Framework) records authenticate the IP addresses and services permitted to send email on behalf of a domain. The existing SPF records had two critical problems:

Excessive lookup depth — SPF allows a maximum of 10 DNS lookups during evaluation. The existing records used nested include: directives that exceeded this limit, causing SPF evaluation to return permerror — which major providers treated as a fail:

# Existing SPF record (simplified) — exceeded 10 lookups
v=spf1 include:spf.provider1.com include:spf.provider2.com include:spf.crm.example.com include:spf.marketing.example.com include:mail.example.com include:smtp.transactional.com ~all

Each include: directive itself pulled in further include: records, creating chains that violated the limit.

Conflicting policies — Different teams had added their own SPF directives without coordinating, resulting in some legitimate senders being implicitly excluded while others were double-counted.

No DKIM Signing on Key Domains

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to outgoing emails, allowing receiving servers to verify the email wasn't modified in transit and genuinely originated from an authorized sender.

The audit found:

• The primary sending domain had DKIM configured only for the main mail platform — not for the CRM or marketing platform
• Two secondary domains used for transactional email had no DKIM configuration at all
• One domain had DKIM configured but the DNS record had a key length below the current recommended minimum (1024-bit vs 2048-bit)

Without DKIM, emails lacked a critical authentication signal that modern spam filters rely on heavily.

No DMARC Policy — Open to Spoofing

DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receiving servers what to do with emails that fail SPF or DKIM checks, and where to send reports about authentication results.

None of the organization's domains had any DMARC record. This meant:

• There was no instruction to receiving servers about handling authentication failures
• The organization had no visibility into who was sending email claiming to be from their domains (legitimate systems or attackers)
• The domains were openly spoofable — an attacker could send phishing emails appearing to be from the organization's domain with no technical control preventing it

Inconsistent DNS State

A legacy DNS cleanup had never been completed. The audit found:

• Duplicate MX records pointing to deprecated mail servers that no longer existed
• Multiple SPF records on the same domain (only one is valid — having two causes permerror)
• Old DKIM selector records from decommissioned providers still present in DNS
• Inconsistent TTL values making propagation verification slow

Implementation

Phase 1: Full Sending Audit

Before changing anything, a complete inventory of all legitimate email senders was built:

This inventory became the authoritative reference for SPF and DKIM configuration.

Phase 2: SPF Re-Architecture

The SPF records were rebuilt from the inventory upward, with a hard constraint of staying under 10 DNS lookups:

# Strategy: flatten nested includes where possible, use ip4/ip6 directly for known IPs

# Primary domain — rebuilt SPF
v=spf1 
  include:spf.protection.outlook.com    # M365 (1 lookup, resolves to ~4)
  include:_spf.salesforce.com           # Salesforce CRM (1 lookup)
  include:servers.mcsv.net              # Mailchimp (1 lookup)
  ip4:167.89.0.0/17                     # SendGrid IPs — direct (0 lookups)
  ip4:10.0.0.50                         # Internal SMTP — direct (0 lookups)
  -all                                   # Hard fail — anything else is unauthorized

Lookup count: 3 DNS lookups (well within the 10-lookup limit).

The -all (hard fail) qualifier replaced the previous ~all (soft fail) — soft fail had been contributing to spam classification because it signalled uncertainty rather than authority.

For secondary domains that only received email and never sent, a minimal restrictive record was added:

v=spf1 -all

This tells receiving servers that no email should ever be sent from these domains — any email claiming to originate from them is unauthorized.

Phase 3: DKIM Implementation

2048-bit DKIM keys were generated and published for every legitimate sending platform on every domain:

Microsoft 365 DKIM

# DNS CNAME records added:
selector1._domainkey.example.com → selector1-example-com._domainkey.example.onmicrosoft.com
selector2._domainkey.example.com → selector2-example-com._domainkey.example.onmicrosoft.com

DKIM signing was then enabled in the Microsoft 365 admin center for each domain.

Mailchimp DKIM Domain authentication was configured within the Mailchimp account, publishing the required CNAME records pointing to Mailchimp's signing infrastructure.

SendGrid DKIM Domain Authentication was set up in SendGrid, publishing both the DKIM CNAME records and a branded return-path subdomain for improved reputation signalling.

Old DKIM selector records from decommissioned providers were removed from DNS to eliminate confusion and reduce the potential for key reuse.

Phase 4: DMARC Rollout

DMARC was rolled out in stages, starting with monitoring to understand the traffic baseline before enforcing any policy.

Stage 1 — Monitor (p=none)

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-failures@example.com; fo=1; pct=100

This collected aggregate (rua) and failure (ruf) reports without taking any action on authentication failures. Reports were reviewed daily for 3 weeks to identify any legitimate senders not yet covered by SPF/DKIM.

Stage 2 — Quarantine (p=quarantine) After confirming all legitimate senders were passing authentication, the policy was tightened:

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

Emails failing authentication were directed to spam/quarantine rather than the inbox. The sp=reject applied strict rejection to all subdomains.

Stage 3 — Reject (p=reject) After one week of quarantine with no legitimate email impacted:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s; pct=100

The strict alignment flags (adkim=s; aspf=s) required the DKIM signing domain and SPF domain to match the From: header exactly — the strongest available authentication posture.

DNS Cleanup

Alongside the authentication remediation:

• Duplicate MX records removed — single authoritative record per domain
• Deprecated DKIM selector records removed
• Legacy SPF records removed (only one SPF record per domain)
• TTL values standardized to 3600 seconds across authentication records
• BIMI record added on primary domain with verified logo (improved visual trust in supporting clients)

Results

The p=none to p=reject transition took four weeks. But the inbox placement improvement showed up within days of fixing the SPF records — most of the immediate gain came from resolving the permerror state, which had been actively damaging sender reputation with every single sending attempt. The damage had been compounding quietly for a long time.