Why email infrastructure audits aren't enough and what continuous operation looks like instead
The problem with infrastructure audits
An email infrastructure audit is a snapshot. It tells you the state of your infrastructure at the moment the audit was run. SPF configured correctly check. DKIM signing active check. DMARC at p=none noted. Blacklist status clean check.
The audit produces a report. The report produces a remediation list. The team works through the list. Six months later, someone suggests running another audit.
In between those two audits, a great deal happens. DNS records change. A new sending platform gets added without updating SPF. A DKIM key gets rotated by the ESP and the old DNS record stays in place. A nameserver change goes unnoticed. A domain sits at p=none for a year and nobody reviews whether it is safe to progress. A blacklist hit appears at 2am on a Tuesday and isn't discovered until Friday when the client calls.
Authentication problems usually don't break badly. They degrade quietly. A few inbox placement points here, a few trust signals there, and over six months a 34% open rate becomes a 26% open rate. Everyone blames the content. The infrastructure never gets looked at.This is the fundamental limitation of an audit: it is a point-in-time check on infrastructure that changes continuously. Running a better audit more frequently is not the solution. The solution is continuous operation infrastructure that is monitored, scored, and acted on every day, not every six months.
What changes between audits
For an agency managing client infrastructure across dozens of domains, here is a partial list of what can change between one audit and the next:
DNS record changes: A client migrates to a new email platform. The new platform requires updating the SPF record. The update happens but introduces an error a stray include that pushes the record past the 10-lookup limit. The SPF record that passed the last audit is now broken.
DKIM key rotation: An ESP rotates DKIM keys as a security practice. The new public key needs to be published in DNS. The rotation happens; the DNS update doesn't. DKIM fails silently. Open rates decline. The next audit will catch it.
DMARC policy drift: A domain was at p=none when the last audit ran. It is still at p=none when the next audit runs. Nobody evaluated whether the 30 days of aggregate report data supported progression. The domain has been unprotected against spoofing for six months.
Nameserver changes: A client moves their domain to a new registrar without notifying the agency. The nameservers change. The DNS records that the agency manages may or may not have been migrated correctly. Nameserver changes are one of the most common causes of unexpected infrastructure failures.
Blacklist hits: A sending platform's shared IP accumulates complaint reports from another sender. The IP appears on Barracuda or URIBL. Every domain sending through that IP is now delivering to spam filters that check those lists. The next audit is three months away.
SSL certificate expiry: A certificate expires. Not catastrophic for email delivery in most configurations, but a signal of infrastructure drift that Infraova monitors not because it deducts from the health score, but because an expired certificate on a mail-related subdomain is worth knowing about.
Registrar lock status: A domain's registrar lock is removed during a transfer and never re-enabled. The domain is now vulnerable to unauthorized transfer. The audit checklist had "registrar lock: enabled." That was six months ago.
None of these changes are unusual. All of them happen regularly across client portfolios. All of them are invisible between audits.
What Infraova monitors continuously
Infraova runs 30 infrastructure checks per domain on every scan and calculates a health score from 0 to 100. The score is not a static number it is recalculated every time a scan runs, reflecting the current state of the infrastructure.
The checks are organized into four categories, each with its own category score:
Authentication
The authentication category covers the core email authentication stack SPF, DKIM, DMARC, and their enforcement posture.
SPF (up to -20 points): Whether a valid SPF record exists, whether it correctly authorizes the domain's sending sources, and whether it stays within the 10-lookup limit.
DKIM (up to -15 points): Whether DKIM signing is active, whether the public key is correctly published in DNS, and whether the key has not been revoked.
DMARC (up to -25 points): Whether a DMARC record exists and whether it is correctly configured. DMARC is the highest-weighted authentication check a missing or broken DMARC record has the largest single impact on the authentication score.
DMARC alignment (up to -15 points): Whether SPF and DKIM are aligned with the From domain as DMARC requires. A domain can have SPF and DKIM passing while still failing DMARC alignment if the authenticated domains don't match the From domain, DMARC enforcement doesn't apply correctly.
SPF enforcement (up to -20 points): Whether the SPF record's terminator is enforcing correctly. A record ending in +all or ~all instead of -all is weaker than it should be.
DMARC pct (up to -10 points): Whether the DMARC record's pct= tag is set to 100. Partial enforcement means some percentage of failing mail bypasses the DMARC policy entirely.
Delivery
The delivery category covers the infrastructure that determines whether email reaches recipients.
MX records (up to -20 points): Whether valid MX records exist and are correctly configured. A missing or broken MX record means the domain cannot receive email a critical infrastructure failure.
Null MX (up to -5 points): Whether non-sending domains have a Null MX record explicitly declaring they accept no mail.
PTR/Reverse DNS (up to -5 points): Whether the sending server's IP has a valid reverse DNS record. Many receiving mail servers check PTR records as a basic spam filter signal.
Google Bulk Sender requirements (up to -15 points): Whether the domain meets Google's 2024 bulk sender requirements authentication, unsubscribe headers, spam rate thresholds. These requirements apply to domains sending more than 5,000 messages per day to Gmail.
BIMI (up to -2 points): Whether a BIMI record is configured for brand logo display in supported email clients.
Security
The security category covers infrastructure that protects the domain from attack and unauthorized access.
Subdomain DMARC (up to -10 points): Whether subdomains have explicit DMARC protection via the sp= tag, or whether they silently inherit a potentially inadequate root domain policy.
Subdomain lockdown (up to -5 points): Whether subdomain DNS is protected against unauthorized zone creation.
DNSSEC (up to -8 points): Whether DNS records are cryptographically signed to prevent DNS cache poisoning and record tampering.
CAA records (up to -3 points): Whether certificate authority authorization records restrict which CAs can issue TLS certificates for the domain.
Registrar lock (up to -5 points): Whether the domain's registrar lock is active, protecting against unauthorized domain transfers.
Nameserver change (up to -10 points): Whether the domain's nameservers have changed unexpectedly one of the most significant signals of potential domain compromise or unauthorized transfer.
Blacklist (up to -30 points): Whether the domain appears on Tier 1 (Spamhaus, Barracuda), Tier 2 (URIBL, SURBL, SpamCop), or Tier 3 (minor/regional) blacklists. Blacklist status carries the highest single-check weight in the scoring system a Tier 1 blacklist hit deducts 30 points and moves most domains from healthy to critical immediately.
SSL (monitoring only, no score deduction): SSL certificate status is monitored for awareness expiry dates, issuer, validity but does not deduct from the health score by product decision. It appears in the infrastructure view for visibility.
Infrastructure
The infrastructure category covers technical configuration that affects sending security and operational hygiene.
MTA-STS (up to -3 points): Whether inbound email encryption enforcement is configured.
TLS-RPT (up to -2 points): Whether TLS failure reporting is enabled.
SPF record length (up to -5 points): Whether the SPF record is approaching or exceeding the 10-lookup limit a common problem as sending platforms accumulate.
DKIM key strength (up to -10 points): Whether the DKIM signing key meets the current recommended minimum of 2048 bits. A 1024-bit key is below the NIST SP 800-131A recommendation.
WHOIS (up to -25 points): Whether the domain's WHOIS registration is current, not expired, and correctly configured. WHOIS carries significant weight in the infrastructure score a domain with lapsed or incorrect registration is a serious operational risk.
DANE (up to -2 points): Whether DANE/TLSA records are configured for additional transport security.
How the health score works
Every domain in Infraova has a health score from 0 to 100, calculated from the 30 checks across the four categories.
The score starts at 100 and deducts points for each check failure the deduction amount determined by the severity of the issue. A missing DMARC record deducts up to 25 points. A Tier 1 blacklist hit deducts 30 points. A missing BIMI record deducts 2 points.
Three status thresholds:
- 80 or above Healthy: The domain's infrastructure is in good shape. Issues may exist but are not materially affecting deliverability or security posture.
- 60 to 79 Warning: The domain has meaningful infrastructure gaps that need attention. Deliverability or security may be affected.
- Below 60 Critical: The domain has serious infrastructure failures requiring immediate action.
The score also tracks trend direction:
- Improving: Score increased by more than 5 points since the last scan
- Stable: Score changed by 5 points or fewer
- Declining: Score dropped by more than 5 points
- Critical decline: Three or more consecutive declines, or score below 60
A domain trending toward critical decline is showing a pattern of infrastructure degradation not a single failure but a compound accumulation of issues. The trend signal gives the team visibility into domains that need attention before they reach a crisis state.
Acknowledged issues
Not every infrastructure gap is immediately actionable. A domain managed by a third-party provider may have limitations on what the agency can configure. A client may have business reasons for not enabling a specific feature. A risk may be understood and accepted.
Infraova allows agencies to acknowledge specific issues the issue remains visible in the infrastructure view and in the breakdown, but it does not deduct from the health score. The agency's informed decision to accept the risk is recorded, and the issue continues to be monitored for changes.
This is the operational equivalent of a known risk register. The agency is not pretending the issue doesn't exist they are documenting that it is known, accepted, and being watched.
The difference between auditing and operating
A one-time infrastructure audit answers the question: "What is the state of this domain's infrastructure right now?"
Continuous infrastructure operation answers a different set of questions:
- What changed since the last scan?
- Is the score trending up, stable, or declining?
- Which domains in the portfolio need attention today?
- Which issues are new versus persistent?
- What is the portfolio-wide health picture?
- Which clients have the most infrastructure risk right now?
These are operational questions, not audit questions. They require continuous data, not periodic snapshots.
For an agency managing 50 client domains, a periodic audit produces a list of issues to fix. Continuous operation produces a live operational picture which domains are healthy, which are at warning, which are critical, which are declining, and what needs attention in priority order.
For agencies managing dozens of domains, manual audits can consume entire workdays. Automated solutions reduce this to minutes by continuously monitoring all domains and flagging issues that need attention.The shift from auditing to operating changes the agency's relationship with client infrastructure. An agency that audits infrastructure periodically is reactive discovering problems after they have compounded. An agency that operates infrastructure continuously is proactive catching problems the moment they occur, before they affect deliverability or the client notices.
What the operational picture looks like in practice
Consider a portfolio of 40 client domains. On any given day:
- 32 domains are healthy (score ≥ 80)
- 6 domains are at warning (score 60–79)
- 2 domains are critical (score < 60)
The 2 critical domains need immediate attention. One has a Tier 1 blacklist hit that appeared overnight a Spamhaus DBL listing on a domain that is actively running cold outreach campaigns. The other has a nameserver change that wasn't flagged by the client the domain moved to a new registrar and the DNS records weren't migrated correctly.
Of the 6 warning domains, 3 are declining their scores have dropped more than 5 points across the last 3 scans. Two of them have DMARC policies that have been at p=none for more than 30 days, and aggregate report evidence now supports progression. One has an SPF record that has grown to 9 lookups after a new sending platform was added one more include and it will break.
None of this information was visible from the last audit. All of it is available in Infraova's dashboard right now.
The team addresses the two critical domains first. The blacklist hit gets investigated shared IP, Spamhaus DBL, the delisting URL is surfaced directly in Infraova. The nameserver change gets escalated to the client for explanation.
For the declining warning domains, Infraova has already generated DMARC progression proposals for the two domains ready to advance. The team reviews and approves them. Infraova executes the changes and verifies the live DNS records. The SPF record approaching the lookup limit gets flagged for manual consolidation.
This is what infrastructure operation looks like. Not a checklist run once before a campaign. A continuous operational loop that surfaces what needs attention, prepares what can be automated, and verifies what was changed.
Where audits still belong
One-time audits are not obsolete. They serve specific purposes:
New client onboarding: Before taking on a new client's infrastructure, a comprehensive audit establishes the baseline what exists, what is broken, what is missing, what needs immediate attention.
Post-incident review: After a significant deliverability failure, blacklist hit, or security incident, a structured audit helps identify the root cause and all contributing factors.
Pre-campaign validation: Before a major sending campaign, confirming that all authentication is correctly configured and the domain is clean reduces the risk of campaign-level failures.
Domain acquisition: Before purchasing a domain with existing history, an audit checks for inherited reputation problems, blacklist status, and DNS configuration issues.
In all of these cases, the audit is a starting point establishing a known state before ongoing operation takes over. The audit produces the baseline. Continuous operation maintains it.
The mistake is treating the audit as the solution rather than the starting point. Infrastructure that was audited and fixed six months ago is not necessarily healthy today. The DNS records, authentication configuration, and blacklist status that passed the audit may have changed in ways that the audit will never catch until someone runs it again.
Continuous operation is what keeps the audit's findings from expiring.
Infraova is an email infrastructure operations platform for agencies, MSPs, deliverability consultants, and businesses managing email at scale. Infraova runs 30 infrastructure checks per domain on every scan, calculates a health score across four categories, tracks score trends over time, and surfaces what needs attention before it affects deliverability. Start operating your infrastructure →