Email infrastructure audit checklist for agencies

Most agencies run an infrastructure audit once usually during client onboarding and then never again. The audit catches whatever was broken at the start, but says nothing about what breaks six months later when a client's IT team migrates DNS providers, or a forgotten subdomain starts sending unauthenticated mail that drags down the primary domain's reputation.

This checklist is built to be run repeatedly, not just once. Each section explains what to check, why it matters, and what "good" looks like.

1. SPF (Sender Policy Framework)

What it does: SPF tells receiving mail servers which sources are authorized to send email on behalf of a domain, via a DNS TXT record.

What to check:

• Does an SPF record exist for the domain?
• Does it include every legitimate sending source the agency's platform, the client's CRM, transactional email tools, internal mail servers?
• Is the record under the 10-DNS-lookup limit? (Records with too many include: statements silently fail validation on some receiving servers.)
• Does it end in -all (hard fail) or ~all (soft fail), and does that match the client's risk tolerance?

Why it breaks: New tools get added to a client's stack a new CRM, a new support platform, a new marketing automation tool and nobody updates the SPF record. The new tool's emails then fail SPF checks.

2. DKIM (DomainKeys Identified Mail)

What it does: DKIM adds a cryptographic signature to outgoing emails, allowing receiving servers to verify the message wasn't altered in transit and genuinely came from an authorized sender.

What to check:

• Is DKIM signing enabled and correctly configured for every sending platform?
• Do the DKIM DNS records (the public keys) match what each platform expects?
• Are there multiple DKIM selectors active if multiple platforms send on behalf of the domain?
• Has a DKIM key rotation happened recently, and if so, was the new key published to DNS before the old one was retired?

Why it breaks: DKIM is configured once during platform setup and then forgotten. If a platform rotates its signing keys (which reputable providers do periodically for security) and the new public key isn't published to DNS in time, signatures start failing often silently, since most mail clients don't surface DKIM failures to the recipient.

3. DMARC (Domain-based Message Authentication, Reporting & Conformance)

What it does: DMARC tells receiving servers what to do with emails that fail SPF or DKIM checks, and provides a reporting mechanism for the domain owner.

What to check:

• Does a DMARC record exist?
• What's the policy none, quarantine, or reject?
• Is the policy appropriate for where the domain is in its authentication journey? (A new domain with p=reject before SPF/DKIM are fully verified across all senders can silently block legitimate mail.)
• Are aggregate reports (rua) being sent somewhere that's actually monitored?
• Does the alignment mode (aspf/adkim, strict vs relaxed) match how the domain actually sends mail?

Why it breaks: DMARC is often set to p=none during initial setup "to be safe" and then never revisited. This means SPF/DKIM failures are reported but not enforced so spoofed emails impersonating the domain can still land in recipients' inboxes, and the domain gets no protection from the very thing DMARC exists to prevent.

4. MX Records

What it does: MX records specify which mail servers are responsible for receiving email for a domain.

What to check:

• Do the MX records point to the correct, currently-active mail servers?
• Are there orphaned MX records pointing to decommissioned services?
• Do MX record priorities make sense (lower numbers = higher priority)?

Why it breaks: When a client migrates email providers (e.g., from a legacy host to Google Workspace or Microsoft 365), MX records sometimes get updated incompletely old records left in place alongside new ones, creating ambiguity about where mail should actually be delivered.

5. Domain and IP Blacklist Status

What it does: Checks whether the sending domain or IP appears on any of the major DNSBL (DNS-based blackhole list) services used by mailbox providers to filter spam.

What to check:

• Is the domain listed on any major blacklists right now?
• Has it been listed recently, even if currently delisted? (Recent listings can still be suppressing deliverability during the reputation recovery window.)
• For shared IP environments, is the shared IP itself listed due to another sender's behavior?

Why it breaks: Sending spikes, list hygiene issues (high bounce rates, spam trap hits), or compromised accounts can trigger a listing at any time it's not something that's "fixed once" during onboarding.

6. DNS Record Hygiene

What to check:

• Are there subdomains with active mail-related DNS records (SPF, DKIM, MX) that are no longer in use?
• Do any subdomains lack their own SPF/DMARC policy, leaving them vulnerable to spoofing that could affect the parent domain's reputation?
• Is there a _dmarc record covering subdomains, or does the organizational domain policy apply (sp= tag)?

Why it breaks: Agencies and clients spin up subdomains for landing pages, microsites, and tools promo.clientdomain.com, app.clientdomain.com often without considering that these subdomains can send (or be spoofed as sending) email, and without their own authentication policies, they're a gap in the domain's overall security posture.

7. Sending Volume and Pattern Consistency

What to check:

• Has sending volume changed significantly compared to historical baselines?
• Are sends happening from new IP ranges or platforms that weren't part of the original setup?
• Do bounce rates and complaint rates fall within normal thresholds (typically under 2% and 0.1% respectively)?

Why it breaks: A new campaign type, a list import from an old database, or a new integration can all change sending patterns in ways that look suspicious to receiving mail servers even if the sender's intent is entirely legitimate.

How often to run this

The honest answer: every check on this list can change at any time, triggered by events the agency may not even be aware of a client's IT team rotating DNS providers, a new tool being added to the stack, a sending spike from an unrelated campaign.

A one-time onboarding audit catches the state of things on day one. It says nothing about day 47, when a DNS migration silently drops the DKIM record.

The practical answer is continuous monitoring automated checks running on a recurring schedule across every item on this list, for every client domain, with alerts when something changes. Not because every agency needs to manually re-run this checklist weekly, but because the things on this list don't stay fixed once they're fixed. They drift, get overwritten, expire, and break quietly, and usually right before someone notices the metrics that depend on them.