Monitoring — Stage 1 of 8
Know when something changes. Before your client does.
Infraova continuously monitors the infrastructure behind every client domain — authentication, reputation, DNS, transport, and domain lifecycle. When something changes, your team knows first. Not the client.
The problem with reactive infrastructure management
You can't manage what you don't continuously see.
Infrastructure changes constantly. SPF records change. Nameservers change. Blacklist status changes. Certificates approach expiry. The problem is not that these things happen — it is that the agency may not know they happened until the client has a problem.
- Infrastructure changes silently.
- Nobody on your team notices.
- Deliverability degrades.
- Client notices something is wrong.
- Client contacts your team.
- Investigation starts under pressure.
- Fix applied reactively.
Your client became your monitoring system.
- Infrastructure changes.
- Infraova detects it on the next scan.
- Issue is prioritized by severity.
- Your team is alerted immediately.
- Investigation starts with full context.
- Diagnosis and remediation proposed.
- Fix applied before the client notices.
You knew before your client did.
What continuous monitoring enables
Don't inspect 150 domains. Know which ones need you.
One domain is easy to inspect manually. Ten becomes repetitive. Forty becomes operational overhead. At 150 or more, manual inspection fails. Infraova turns your entire client portfolio into a continuously monitored system — and surfaces only what actually needs attention.
Continuous inspection
Every client domain checked on a regular cadence across all 30 infrastructure signals. No manual scans required.
Portfolio-wide visibility
Every client domain, current health, open issues, and last scan state in one operational view. Know where to focus without checking each domain individually.
Attention queue
Domains with open critical or high-severity issues surfaced at the top. Your team sees what needs attention — not a flat list of every domain equally.
DNS change history
Every DNS record change across every client domain logged with timestamp and before/after values. When something breaks, you know when it changed and what it changed from.
Health score per domain
A single number per domain combining all 30 checks. A quick portfolio read — but the real value is what sits behind the score: the exact signals that contributed to it.
Instant re-scan
After applying a fix, trigger an immediate re-scan to verify resolution without waiting for the next scheduled check cycle.
What Infraova monitors
30 checks. The full infrastructure stack. Every domain.
The 30 checks are not the product — they are the coverage that makes monitoring useful. Grouped below by what they protect.
Email authentication
Sender Policy Framework — lists which mail servers are authorized to send email on behalf of your domain.
Why it matters: A missing or broken SPF record causes receiving servers to distrust your mail, increasing the chance of landing in spam or being rejected.
DomainKeys Identified Mail — attaches a cryptographic signature to every outgoing message, proving it was not altered in transit.
Why it matters: Without a valid DKIM signature, mailbox providers cannot verify message integrity. Failed or missing DKIM is one of the leading causes of deliverability failures.
Ties SPF and DKIM together and tells receiving servers what to do when a message fails both checks — nothing, quarantine, or reject.
Why it matters: A missing DMARC record leaves your domain open to spoofing and phishing. Google and Yahoo now mandate a DMARC record for bulk senders.
Checks whether the From header domain matches the domain that passed SPF or DKIM. A pass on one alone is not enough.
Why it matters: Misalignment is a common issue when sending through ESPs. Even with valid SPF and DKIM, misalignment causes DMARC to fail.
Checks whether your DMARC policy extends to subdomains via the sp= tag, or leaves them unprotected.
Why it matters: Unprotected subdomains are a common target for phishing attacks that impersonate your brand.
Checks whether your SPF record uses a hard fail (-all) rather than a soft fail (~all) or neutral (?all).
Why it matters: A soft fail tells receiving servers to accept mail from unauthorized senders but mark it. Hard fail actively rejects it — stronger spoofing protection.
Monitors whether your DMARC pct= tag is set to 100, meaning the policy applies to all failing messages.
Why it matters: Many domains set pct=10 during rollout and never increase it. Less than 100% means a portion of spoofed mail still gets through.
Checks whether your SPF record exceeds the 255-byte DNS string limit. Oversized records are truncated or rejected by some resolvers.
Why it matters: A truncated SPF record causes silent authentication failures across legitimate sends.
Checks the bit length of your DKIM public key. 1024-bit keys are considered weak; 2048-bit is the recommended minimum.
Why it matters: A weak DKIM key can be compromised, allowing attackers to forge signed mail from your domain.
Brand Indicators for Message Identification — lets your verified logo appear next to emails in Gmail, Apple Mail, and Yahoo Mail.
Why it matters: A published BIMI record increases brand visibility and signals authentication maturity. Requires DMARC at p=quarantine or stricter.
Checks whether unused or parked subdomains are protected against being used to send spoofed mail.
Why it matters: Attackers frequently exploit unprotected subdomains to send spoofed mail that bypasses parent-domain DMARC policies.
DNS infrastructure
MX records tell other mail servers where to deliver email addressed to your domain.
Why it matters: Missing MX records signal a misconfigured domain to receiving servers, reducing trust in outbound mail from the same domain.
A null MX record explicitly declares that a domain does not accept inbound mail — correct for send-only domains.
Why it matters: Without a null MX, some servers will attempt delivery anyway and may treat the missing record as a configuration error.
A PTR record maps your sending IP address back to a hostname. It is the reverse of a standard A record lookup.
Why it matters: Many enterprise mail servers reject or heavily penalize mail from IPs with no PTR record — critical for dedicated sending IPs.
Cryptographically signs your DNS records, allowing resolvers to verify they have not been tampered with or forged.
Why it matters: Without DNSSEC, an attacker who controls DNS resolution can silently redirect MX records or modify SPF and DMARC.
Certification Authority Authorization records restrict which CAs are permitted to issue TLS certificates for your domain.
Why it matters: Without CAA records, any CA in the world can issue a certificate for your domain, enabling unauthorized certificate issuance.
Uses TLSA records in DNS to cryptographically bind TLS certificates to your MX hosts.
Why it matters: When combined with DNSSEC, DANE eliminates reliance on Certificate Authorities for SMTP security.
Monitors your domain nameservers and alerts when they change between scans.
Why it matters: A nameserver change is the highest-severity DNS event — an attacker who controls nameservers controls all DNS for the domain.
Checks whether clientTransferProhibited status is set, preventing unauthorized domain transfers at the registrar level.
Why it matters: An unlocked domain can be stolen via social engineering at the registrar without DNS or hosting access.
Reputation & compliance
Real-time check against major IP and domain blocklists on every scan cycle.
Why it matters: A single major blacklist listing can cause immediate deliverability collapse. Early detection is the only way to resolve listings quickly.
Checks compliance with Google's requirements for senders exceeding 5,000 messages per day to Gmail.
Why it matters: Failing Google's bulk sender requirements results in messages being sent to spam or deferred. Enforced since February 2024.
Transport security
Forces TLS encryption on all inbound mail connections, preventing downgrade attacks.
Why it matters: Without MTA-STS, an attacker on the network path can strip TLS and read or modify mail in transit.
Enables receiving servers to send reports about TLS connection failures when delivering mail to your domain.
Why it matters: Without TLS-RPT, failed or downgraded TLS connections happen silently — problems stay invisible until they affect deliverability at scale.
Domain lifecycle
Tracks SSL certificate validity and expiry dates with tiered alerts before deadlines.
Why it matters: An expired certificate on your sending domain or tracking links can trigger spam filters and reduce click-through rates.
Domain registration details and age. Recently registered or fully privacy-protected domains are treated with more suspicion by spam filters.
Why it matters: Domains registered in the last 30 days or with redacted WHOIS score lower on sender reputation, affecting inbox placement.
From monitoring to detection
Monitoring isn't passive. When something changes, it creates a signal.
When Infraova detects a meaningful change — a record that broke, a blacklist entry, a certificate approaching expiry — it captures the full context: what changed, when it changed, which domain is affected, and what the current state is. That signal then moves into Intelligence.
Example: A client domain's SPF record changes.
Infraova detects the change on the next scan. It records what the record was before, what it is now, which domain is affected, when it changed, and what the severity is. That event is prioritized, diagnosed, and prepared for the remediation workflow — before your team has to manually investigate anything.
Where monitoring sits in the operational loop
Stop waiting for your clients to tell you something broke.
Infraova continuously watches the infrastructure behind every client domain. Your team knows when something changes — before the client does.