25 checks. One score. Zero surprises.

The problem

SPF records break silently. A DNS migration touches the wrong record. A new sending service gets added without updating the policy. The result: authentication failures that inbox providers use to justify sending email to spam or rejecting it entirely.

How Infraova helps

Infraova monitors SPF records continuously. When the record changes, when a syntax error appears, when the DNS lookup count exceeds the RFC limit, or when a new sending source falls outside the policy you know immediately.

What it detects

• Record changes and unauthorized modifications
• Syntax errors and malformed policies
• DNS lookup limit violations (exceeds 10)
• Missing includes for active sending services
• Misalignment with DMARC policy

The problem

DKIM keys get rotated, expired, or deleted often during migrations or platform changes without anyone updating the DNS record. The result is unauthenticated mail. Inbox providers notice before anyone on your team does.

How Infraova helps

Infraova validates that DKIM keys are present, correctly formatted, of sufficient length, and consistent with active sending configuration. When a key goes missing or stops resolving, you are alerted before messages start bouncing.

What it detects

• Missing or deleted DKIM records
• Weak key lengths (below 1024-bit)
• Selector mismatches and resolution failures
• Key rotation without DNS update
• Signing domain alignment issues

The problem

A DMARC policy set to p=none provides no protection. An incorrect rua tag means you never receive reports. A policy set to reject without proper alignment breaks legitimate mail. Each misconfiguration silently undermines your client's email reputation.

How Infraova helps

Infraova monitors DMARC policy enforcement level, reporting configuration, and alignment settings. When policy weakens, reporting breaks, or alignment gaps appear, you see it before it causes a deliverability incident.

What it detects

• Policy set to none when stricter enforcement is needed
• Missing or misconfigured reporting addresses
• Subdomain policy gaps
• SPF and DKIM alignment failures
• Record syntax and structure errors

The problem

DNS records are changed during migrations, platform moves, and agency handoffs and nobody updates the audit trail. A single wrong edit can break authentication for every email a client sends. It takes days to diagnose manually.

How Infraova helps

Infraova monitors DNS records for changes, propagation failures, and resolution errors. When any monitored record changes unexpectedly, you see it within the hour not after a client reports a problem.

What it detects

• Unexpected record changes
• DNS propagation failures
• Record deletion
• TTL anomalies affecting update speed
• Resolution failures from key nameservers

The problem

Blacklist entries appear without warning. A shared IP gets flagged. A client's sending volume triggers a reputation check. Deliverability drops immediately but the blacklist entry might not be discovered for days unless someone is actively checking.

How Infraova helps

Infraova checks client domains and IPs against major blacklists continuously. The moment a listing appears, you receive an alert. You have time to investigate, request removal, and fix the underlying cause before the client notices a deliverability drop.

What it detects

• IP address blacklist entries
• Domain blacklist entries
• New listings on major RBLs
• Repeated listing patterns
• Associated IP range flags

The problem

Without MTA-STS, an attacker positioned between sending and receiving mail servers can downgrade a TLS connection to plaintext and intercept email in transit. Most domains have no inbound TLS enforcement at all they rely on opportunistic TLS, which provides no actual security guarantee.

How Infraova helps

Infraova verifies that the MTA-STS DNS record is published, the policy file is reachable at the correct HTTPS endpoint, the mode is set to enforce (not testing or none), and the MX entries in the policy file exactly match your DNS MX records a mismatch causes legitimate mail to fail.

What it detects

• Missing MTA-STS DNS TXT record
• Policy file unreachable or misconfigured
• Policy mode set to testing or none
• MX entry mismatch between policy and DNS
• Alert on policy or DNS record changes

The problem

When inbound TLS connections fail due to certificate issues, MTA-STS policy violations, or DANE misconfigurations you have no way to know unless you are collecting failure reports. Without TLS-RPT, these failures are invisible until they affect deliverability at scale.

How Infraova helps

Infraova checks that a valid TLS-RPT record is published at _smtp._tls.<domain>. With TLS-RPT in place, remote mail servers automatically send failure reports to your designated address, giving you early visibility into TLS negotiation problems before they become delivery failures.

What it detects

• Missing TLS-RPT DNS TXT record
• Invalid or malformed v=TLSRPTv1 record
• Missing reporting URI (rua=)
• Alert on record changes or removal

The problem

SSL certificates expire silently. Auto-renew can fail without warning a misconfigured certbot job, a changed file path, or a lapsed DNS challenge. When the certificate expires, SMTP connections fail and mail stops flowing before anyone notices.

How Infraova helps

Infraova monitors certificate expiry dates and renewal status for mail-related hostnames. You receive alerts at 30, 14, and 7 days before expiry enough time to renew manually if auto-renewal has failed.

What it detects

• Certificate expiry within 30 days
• Expired certificates blocking SMTP
• Auto-renew not detected
• Certificate issuer changes
• Hostname mismatch on mail server cert

The problem

Many inbox providers and spam filters check that a sending IP resolves to a hostname via PTR record, and that the hostname resolves back to the same IP. A missing or mismatched PTR record is a common cause of soft rejections and increased spam scoring.

How Infraova helps

Infraova verifies forward and reverse DNS consistency for all monitored sending IPs. When a PTR record goes missing, fails to resolve, or no longer matches the forward record, you are alerted before deliverability degrades.

What it detects

• Missing PTR record on sending IP
• Forward/reverse DNS mismatch
• PTR hostname not resolving
• IP with multiple PTR records
• PTR record changes

The problem

Domain registrations lapse when renewal is missed, auto-renew fails, or a card on file expires. A lapsed domain takes the entire email infrastructure offline instantly and domain recovery from a squatter can take weeks or fail entirely.

How Infraova helps

Infraova monitors domain expiry dates for every monitored domain and alerts you at configurable thresholds 60 days, 30 days, and 14 days before expiry so you always have time to act before it becomes an emergency.

What it detects

• Domains expiring within 60 days
• Domains expiring within 30 days
• Domains expiring within 14 days
• Registrar auto-renew status changes
• Expiry date changes (unexpected renewal or lapse)

The problem

DMARC policy on the root domain does not automatically protect subdomains unless an explicit sp= tag is set. Without it, subdomains like mail.example.com or send.example.com inherit p=none by default leaving them completely unprotected and spoofable.

How Infraova helps

Infraova scans all active subdomains and checks whether DMARC policy applies to each one either via an explicit subdomain record or via sp= on the parent. Unprotected subdomains are flagged individually so you know exactly where the gaps are.

What it detects

• Subdomains with no DMARC record
• Subdomains inheriting p=none from parent
• Missing sp= tag on root DMARC record
• Subdomain policy weaker than root policy
• New subdomains with no policy

The problem

BIMI (Brand Indicators for Message Identification) enables brand logos to appear in Gmail, Yahoo, and Apple Mail inboxes but it requires DMARC at p=quarantine or reject, a valid BIMI DNS record, and a Verified Mark Certificate (VMC). Any gap silently breaks logo display.

How Infraova helps

Infraova validates the full BIMI prerequisite chain: DMARC enforcement level, BIMI DNS record presence and format, VMC validity, and logo URL reachability. When any component breaks, you know before clients ask why their logo disappeared.

What it detects

• Missing or malformed BIMI DNS record
• DMARC enforcement too weak for BIMI
• Expired or invalid VMC certificate
• Logo SVG unreachable or malformed
• BIMI record changes

The problem

Parked, dev, and staging subdomains are often forgotten after a project ends. Without SPF, DKIM, and DMARC coverage, any of these subdomains can be used to send phishing email that appears to come from your client's organization.

How Infraova helps

Infraova scans all subdomains for authentication coverage and flags any that lack DMARC policy or have weak SPF posture. Inactive subdomains with no sending policy are scored as high-risk even if they never send mail themselves.

What it detects

• Subdomains with no DMARC policy
• Subdomains with weak SPF (~all or +all)
• Parked domains with no null MX and no auth
• New subdomains with no authentication records
• Subdomains missing from DMARC sp= coverage

The problem

Gmail's Postmaster Tools provide domain reputation, IP reputation, spam rate, and authentication pass rates but only if you are actively monitoring them. Most agencies never check unless a client reports a deliverability problem, by which point reputation has already degraded.

How Infraova helps

Infraova pulls Postmaster data automatically and surfaces reputation changes as part of your standard domain health view. You see domain and IP reputation, spam rate trends, and authentication rates updated continuously without manual logins.

What it detects

• Domain reputation drops (High Medium Low)
• IP reputation degradation
• Spam rate increases above 0.1%
• Authentication pass rate drops
• Delivery errors and failure spikes

The problem

DNS changes during migrations and handoffs are the most common source of email deliverability incidents. Without a change log, diagnosing what broke and when requires reconstructing history from memory or incomplete records.

How Infraova helps

Infraova snapshots DNS records on every check cycle and maintains a timestamped change log for each domain. When a record changes, the before and after values are recorded. You can see exactly what changed, when, and correlate it with any deliverability events.

What it detects

• MX, SPF, DKIM, DMARC record changes
• Record deletions and new additions
• TTL changes that affect propagation speed
• Unexpected changes outside maintenance windows
• Change history for audit and diagnostics

The problem

Without DNSSEC, DNS responses can be spoofed via cache poisoning attacks redirecting mail to attacker-controlled servers. A misconfigured DNSSEC setup (broken DS record, expired DNSKEY) can also cause complete DNS resolution failure for a domain.

How Infraova helps

Infraova validates the full DNSSEC chain of trust: DNSKEY records, DS records at the registrar, zone signing status, and BOGUS validation errors. Both missing DNSSEC and misconfigured DNSSEC are flagged with actionable diagnostics.

What it detects

• DNSSEC not configured on monitored domains
• DNSKEY present but DS record missing at registrar
• BOGUS validation broken chain of trust
• Expired DNSKEY records
• Zone signing changes

The problem

Without CAA records, any certificate authority can issue an SSL/TLS certificate for a domain. This opens the door to rogue certificate issuance a real attack vector used in targeted phishing and man-in-the-middle campaigns against email infrastructure.

How Infraova helps

Infraova checks that CAA records are present and correctly restrict certificate issuance to approved authorities. Missing CAA records are flagged. Changes to existing CAA records which could indicate unauthorized CA additions trigger immediate alerts.

What it detects

• Missing CAA records on monitored domains
• CAA records allowing any CA (empty policy)
• Unauthorized CA additions to existing CAA records
• Wildcard issuance not explicitly restricted
• CAA record changes

The problem

Domain hijacking through unauthorized transfers is a real threat particularly for high-value client domains. Without clientTransferProhibited and clientDeleteProhibited locks set at the registrar, a social engineering attack on the registrar account can move or delete a domain entirely.

How Infraova helps

Infraova checks WHOIS data for the presence of registrar lock statuses on every monitored domain. Missing transfer locks are flagged as warnings. Changes to lock status which could indicate a hijacking attempt in progress trigger immediate alerts.

What it detects

• clientTransferProhibited not set
• clientDeleteProhibited not set
• Lock status changes (potential hijacking indicator)
• Domains without any registrar locks
• Registrar changes on monitored domains

The problem

A nameserver change is one of the highest-impact DNS events possible it redirects all DNS resolution for a domain through a new provider. Unauthorized nameserver changes are a common step in domain hijacking and can be used to intercept mail.

How Infraova helps

Infraova records the nameserver configuration for every monitored domain and compares it on every check cycle. Any change to NS records triggers an immediate alert with before/after values so you can verify whether the change was authorized.

What it detects

• Nameserver additions or removals
• Full nameserver migrations
• Unauthorized NS record changes
• NS changes not matching expected provider
• NS propagation inconsistencies across resolvers

The problem

RSA-1024 DKIM keys are considered cryptographically weak by current standards. Gmail and other inbox providers have begun deprioritizing 1024-bit keys and may eventually reject them entirely. Keys below 2048 bits are also vulnerable to factoring attacks.

How Infraova helps

Infraova checks the key length of every DKIM selector it discovers for a domain. Keys below 2048 bits are flagged as warnings. Keys below 1024 bits are flagged as failures. The check is separate from DKIM presence so weak keys are never confused with missing keys.

What it detects

• 1024-bit RSA keys (weak upgrade recommended)
• Keys below 1024 bits (critically weak)
• 2048-bit keys (pass current standard)
• Key strength changes after rotation
• Multiple selectors with mixed key strength

The problem

A single DNS TXT record is limited to 255 bytes. SPF records that grow beyond this limit through accumulated includes break silently some resolvers truncate them, others return errors, and the result is inconsistent authentication behavior across different mail providers.

How Infraova helps

Infraova measures the byte length of every SPF record and flags records approaching or exceeding the 255-byte single-string limit. Records that require TXT chunking are identified so you can restructure the policy before length causes authentication failures.

What it detects

• SPF records exceeding 255 bytes (single TXT limit)
• Records approaching the limit (200+ bytes)
• Records requiring TXT string chunking
• Length increases after new includes are added
• Records that may be truncated by some resolvers

The problem

DANE (DNS-Based Authentication of Named Entities) uses TLSA records to pin the certificate or public key a mail server should present, preventing SMTP MITM attacks even when a rogue CA has issued a fraudulent certificate. Without DANE, TLS provides transport encryption but not server authentication.

How Infraova helps

Infraova checks for TLSA records at the standard _25._tcp.<mail-hostname> location, validates the record format, and verifies that the certificate the mail server presents matches the pinned value. Missing or broken TLSA records are flagged with specific error diagnostics.

What it detects

• Missing TLSA record at _25._tcp location
• TLSA record format errors
• Certificate mismatch server cert does not match pin
• TLSA record changes (rotation tracking)
• DANE without DNSSEC prerequisite not met

The problem

Individual check results tell you what broke. They do not tell you which client needs your attention most right now. When you are managing dozens of domains, triage is the real challenge.

How Infraova helps

Infraova combines all 25 check results into a single composite health score per domain. Scores update after every check cycle. Historical trend data shows if a domain is improving or degrading over time so you can prioritise proactively, not reactively.

What it detects

• Overall infrastructure health at a glance
• Score degradation trends
• Multi-check failure patterns
• Historical comparison
• Cross-client prioritisation signals