Infraova
What we monitor

Everylayerofemaildeliverability.

Infraova runs 25 checks on every domain catching the issues that kill deliverability before your clients ever see them.

25

Check types per domain

24/7

Continuous monitoring

<5 min

Alert delivery

100%

Client data isolation

Authentication
6 checks

SPF Monitoring

CatchSPFfailuresbeforetheybreakauthentication.

SPF (Sender Policy Framework) tells receiving mail servers which IP addresses are authorized to send email on behalf of your domain. A misconfigured SPF record too permissive, too strict, or exceeding the 10-lookup limit causes authentication failures that hurt deliverability across every client using that domain.

What we check
Record presence and syntax validation
DNS lookup count (10-limit enforcement)
Overly permissive mechanisms (e.g. +all)
SPF alignment with the From domain
Record changes detected in real time

Outcome

Stop SPF failures from silently tanking client deliverability.

SPF Scan
clientdomain.com

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Record found
Syntax valid
DNS lookups
Mechanism ~all
SPF alignment
EnforcementSoft fail

DKIM Monitoring

Confirmsigningkeysarepublishedandvalid.

DKIM lets a sending domain attach a cryptographic signature to outgoing email. Receiving servers use the public key published in DNS to verify the signature. Rotated keys, deleted records, or short key lengths break this verification silently and most agencies only find out when deliverability drops.

What we check
Key presence across all configured selectors
Key length validation (minimum 1024-bit, flagging sub-2048)
Record format and syntax checking
Detection of deleted or changed keys
Alignment with the From domain header

Outcome

Never miss a rotated or deleted DKIM key again.

DKIM Key Check
clientdomain.com
google._domainkey
sendgrid._domainkey
s1._domainkey
Selectors checked0 / 3

DMARC Monitoring

Trackpolicystrengthandcatchweakconfigurations.

DMARC builds on SPF and DKIM to give domain owners control over what happens when authentication fails. But a DMARC policy set to p=none does nothing it only reports, it doesn't protect. Many domains sit at p=none indefinitely because nobody notices.

What we check
Policy strength (none / quarantine / reject)
Reporting address configuration (rua / ruf)
Subdomain policy (sp=) presence
Alignment mode settings
Policy changes detected in real time

Outcome

Move every client domain from p=none to enforcement.

DMARC Audit
clientdomain.com
Record found
Policy (p=)
Reporting (rua=)
Subdomain (sp=)
Coverage (pct=)

SPF Enforcement

DetectweakSPFendingsthatletunauthorizedsendersthrough.

An SPF record is only as strong as its final enforcement mechanism. ~all (soft fail) marks unauthorized senders but still delivers their mail. +all (pass all) lets anyone on the internet send as your domain.

What we check
Hard fail (-all) vs soft fail (~all) detection
Neutral (?all) enforcement gap detection
Pass-all (+all) critical misconfiguration detection
Bare "all" (defaults to +all per RFC 7208) detection
Missing "all" mechanism detection

Outcome

Ensure every SPF record actually rejects unauthorized senders.

SPF Enforcement
clientdomain.com

Current record ending

v=spf1 include:_spf.google.com ~all
+all (pass all)
~all (soft fail)
?all (neutral)
-all (hard fail)

DMARC Coverage

FlagpartialDMARCenforcementbeforeitcreatesafalsesenseofsecurity.

The DMARC pct= tag controls what percentage of messages the stated policy is applied to. A domain with p=reject; pct=10 is only rejecting 10% of unauthorized mail the other 90% gets through.

What we check
pct= value detection and parsing
Flag pct below 100% as partial enforcement
Severity scaling: pct 50-99 warning, pct <50 critical warning
Skips check when no DMARC record exists
Alert on pct= changes

Outcome

Ensure DMARC policy applies to 100% of mail, not a fraction.

DMARC Coverage
clientdomain.com
DMARC record
pct= tag

Subdomain DMARC

Checkwhethersubdomainpolicyissetorinheritingaweakparent.

Subdomains inherit the parent DMARC policy unless an explicit subdomain policy (sp=) is set. If the parent domain is at p=none, every subdomain is effectively unprotected too even if the main domain is on its way to enforcement.

What we check
Subdomain policy (sp=) detection
Inheritance chain analysis
Flag subdomains under weak parent policies
Detection of subdomain-specific DMARC records
Alert on subdomain policy changes

Outcome

Close the subdomain gap in DMARC coverage.

Subdomain DMARC
clientdomain.com
mail.clientdomain.com
send.clientdomain.com
outreach.clientdomain.com
Infrastructure
7 checks

Blacklist Monitoring

KnowthemomentaclientdomainorIPgetslisted.

A blacklist entry can appear overnight and cause immediate deliverability damage before anyone notices. By the time a client calls to say their open rates dropped, the entry may have been there for days. Infraova checks against major blocklists continuously.

What we check
Domain and IP checks against major blocklists
Continuous monitoring between manual scans
Immediate alert on new listing detection
Listing severity classification
Historical blacklist event log

Outcome

Catch blacklist entries in minutes, not days.

Blacklist Check
send.clientdomain.com
Spamhaus ZEN
Barracuda BRBL
SpamCop SCL
URIBL
Sorbs DUHL
Lists queried0 / 5

DNS Change Detection

LogeveryDNSchangesoyoucantraceproblemstotheirroot.

Most deliverability incidents have a DNS change at their root a record edited during a migration, a TTL change nobody documented, an MX record quietly updated by a hosting provider. Without a change log, tracing the incident means guesswork.

What we check
MX, A, CNAME, and TXT record change detection
Timestamped change log per domain
Alert on unexpected record changes
Historical diff view for each record type
Cross-client change visibility

Outcome

Trace any deliverability incident back to its root cause.

DNS Change Log
clientdomain.com
Timestamped diff all record types

MX Records

Validatemailexchangerecordsarepresentandresolving.

MX records tell the internet where to deliver email for a domain. Missing, misconfigured, or non-resolving MX records mean inbound email bounces often silently. Agencies frequently inherit domains where MX records were set up years ago and never audited.

What we check
MX record presence validation
Priority ordering check
Hostname resolution verification
Detection of missing or duplicate records
Alert on MX record changes

Outcome

Catch MX misconfigurations before inbound mail fails.

MX Record Check
clientdomain.com
1aspmx.l.google.com
5alt1.aspmx.l.google.com
10alt2.aspmx.l.google.com
20mail.backup-old.clientdomain.com
Priority order verified

SSL Certificates

Trackcertificatevalidityandexpiryacrosseverysendingdomain.

An expired SSL certificate on a client's sending domain triggers browser security warnings that destroy trust instantly. Most agencies manage enough domains that manual expiry tracking is unreliable.

What we check
Certificate validity status
Expiry date tracking with advance alerts
Certificate chain validation
Hostname match verification
Alert on certificate changes

Outcome

Never let a client SSL certificate expire unnoticed.

SSL Certificate
clientdomain.com
Certificate found
Chain valid
Hostname match
Expiry

Domain Expiry

Alertbeforeaclientdomainlapses.

A lapsed domain is one of the most avoidable disasters in email infrastructure and one of the most damaging. When a domain expires, email stops, the website goes dark, and in worst cases the domain gets picked up by someone else.

What we check
WHOIS expiry date monitoring
Multi-stage advance alerts (90 / 30 / 7 days)
Registrar information tracking
Auto-renewal status visibility
Alert on registration changes

Outcome

Prevent the most avoidable client infrastructure failure.

Domain Expiry
clientdomain.com
WHOIS lookup
Registrar
Auto-renew
Expiry date

PTR / Reverse DNS

ConfirmreverseDNSrecordsmatchthesendinghostname.

PTR records map an IP address back to a hostname. Many receiving mail servers check that the PTR record for a sending IP matches the hostname used in the SMTP greeting a mismatch is a common reason for messages being flagged or rejected.

What we check
PTR record presence for sending IPs
Forward-confirmed reverse DNS (FCrDNS) validation
Hostname match between PTR and SMTP greeting
Alert on PTR record changes
Missing PTR detection

Outcome

Eliminate a common and overlooked rejection cause.

PTR / Reverse DNS
185.220.101.42
Sending IP
PTR record
Forward lookup
FCrDNS match
SMTP hostname

Null MX

Signalthatnon-sendingdomainsacceptnomail.

RFC 7505 defines the null MX record as the correct way to signal that a domain does not accept inbound email. Without it, sending servers attempt SMTP delivery and queue messages indefinitely when they get no response.

What we check
Null MX record presence (0 .) for non-sending domains
RFC 7505 coexistence violation detection
Distinction between no MX and correct null MX
Skip check for domains with real MX records
Alert on MX configuration changes

Outcome

Eliminate pointless delivery attempts to non-mail domains.

Null MX Check
no-mail.clientdomain.com
Domain purpose
MX records found
RFC 7505 compliance
Delivery attempts
Advanced
11 checks

MTA-STS

EnforceTLSoninboundmailtopreventdowngradeattacks.

MTA-STS lets a domain publish a policy that requires sending servers to use TLS when delivering inbound mail. Without it, an attacker can downgrade a TLS connection to plaintext and intercept email in transit.

What we check
MTA-STS DNS TXT record presence
Policy file reachability at mta-sts.<domain>
Policy mode (testing vs enforce)
MX entry match between policy file and DNS
Alert on policy or DNS record changes

Outcome

Protect inbound mail from interception and downgrade attacks.

MTA-STS Audit
clientdomain.com
_mta-sts TXT record
Policy file reachable
Policy mode
MX match
Max age

TLS-RPT

EnableTLSfailurereportingsodeliveryproblemsarevisible.

TLS-RPT lets remote mail servers report TLS negotiation failures back to your domain. Without a TLS-RPT record, you have no visibility into whether inbound TLS connections are failing.

What we check
TLS-RPT DNS TXT record presence at _smtp._tls
v=TLSRPTv1 version tag validation
Reporting URI (rua=) presence
Alert on record changes or removal

Outcome

Get visibility into TLS delivery failures before they compound.

TLS-RPT Check
clientdomain.com
_smtp._tls TXT record
Version tag
Reporting URI (rua=)
URI reachable

BIMI

Verifybrandlogodisplayiscorrectlyconfigured.

BIMI lets domain owners publish a verified logo that appears next to their emails in supported mail clients like Gmail and Apple Mail. A missing or misconfigured BIMI record means the logo never shows.

What we check
BIMI DNS TXT record presence at default._bimi
v=BIMI1 version tag validation
Logo URL (l=) presence and reachability
VMC authority record (a=) detection
Alert on record changes or removal

Outcome

Ensure every client domain shows its logo in the inbox.

BIMI Check
clientdomain.com
default._bimi TXT
Version tag
Logo URL (l=)
VMC authority (a=)

Spoofing Detection

Getalertedthemomentsomeoneimpersonatesaclientdomain.

Domain spoofing happens when an attacker sends email pretending to be one of your clients. DMARC aggregate reports contain forensic data about every message that claimed to be from your domain including unauthorized senders.

What we check
Automatic DMARC aggregate report ingestion
Unauthorized sender IP detection
Attacker hostname (reverse DNS) resolution
Email volume and policy outcome breakdown
One-click incident report generation for client delivery

Outcome

Catch impersonation attacks before the client ever finds out.

Spoofing Detection
clientdomain.com

DNSSEC

ProtectDNSrecordsfromtamperingandcachepoisoning.

Without DNSSEC, an attacker who controls DNS resolution can silently redirect MX records, modify SPF or DMARC, or intercept mail entirely. DNSSEC cryptographically signs your DNS records so resolvers can verify they have not been tampered with.

What we check
DNSKEY record presence detection
DNSSEC validation status
Chain of trust verification
Broken signature detection (SERVFAIL)
Alert on DNSSEC status changes

Outcome

Prevent DNS hijacking and MX record tampering.

DNSSEC Check
clientdomain.com
DNSKEY record
Chain of trust
DS record at parent
DNSSEC validation

CAA Records

RestrictwhichcertificateauthoritiescanissueTLScertificatesforyourdomain.

Without CAA records, any CA in the world can issue a certificate for your domain. CAA records prevent unauthorized certificate issuance before it happens.

What we check
CAA record presence detection
Issuer restriction validation
Alert on CAA record changes
Multi-CA configuration support
Wildcard issuance policy detection

Outcome

Prevent unauthorized TLS certificate issuance.

CAA Records
clientdomain.com
CAA record presence
Issuer restriction
Wildcard policy
iodef reporting

Nameserver Change

DetectunauthorizednameserverchangesbeforeattackerscontrolyourDNS.

A nameserver change is the highest-severity DNS event. If an attacker controls your nameservers, every other check becomes irrelevant - they can modify MX records, bypass SPF and DMARC, and intercept all mail.

What we check
Nameserver fingerprinting per domain
Change detection between scans
Immediate critical alert on any change
Historical nameserver log
Cross-scan comparison

Outcome

Catch DNS hijacking at the registrar level immediately.

Nameserver Monitor
clientdomain.com
Previous nameservers
Current nameservers
Change detected
Alert fired

Registrar Lock

Verifydomaintransferlockisenabledtopreventunauthorizedtransfers.

Registrar lock prevents unauthorized domain transfers without touching DNS or hosting. An unlocked domain can be stolen via social engineering at the registrar - no DNS access required.

What we check
EPP clientTransferProhibited status detection
Alert when lock is missing or removed
WHOIS-based lock status verification
Historical lock status tracking
Registrar information monitoring

Outcome

Prevent domain theft at the registrar level.

Registrar Lock
clientdomain.com
EPP status check
clientTransferProhibited
clientUpdateProhibited
Transfer risk

DANE/TLSA

CryptographicallybindTLScertificatestoyourMXhosts.

DANE uses TLSA records in DNS to bind TLS certificates to your MX hosts. When combined with DNSSEC, this eliminates reliance on Certificate Authorities for SMTP security and prevents TLS certificate substitution attacks.

What we check
TLSA record presence at _25._tcp.<mx-host>
MX host enumeration and checking
TLSA record format validation
Alert on TLSA record changes
Multi-MX host coverage

Outcome

Eliminate CA dependency for SMTP TLS security.

DANE/TLSA Check
clientdomain.com
MX hosts found
_25._tcp TLSA record
Certificate binding
DANE protection

SPF Record Length

CatchoversizedSPFrecordsbeforetheycausesilentauthenticationfailures.

SPF records that exceed the 255-byte DNS string limit are truncated or rejected by some resolvers. A truncated SPF record causes silent authentication failures with no obvious error.

What we check
SPF record byte length measurement
Flag records exceeding 255-byte limit
Alert on record length changes
Guidance on record compression
Detection of excessive include: chains

Outcome

Prevent silent SPF failures from oversized records.

SPF Record Length
clientdomain.com
SPF record found
Record byte length
255-byte limit
Truncation risk

DKIM Key Strength

FlagweakDKIMkeysbeforetheycanbeexploited.

A 1024-bit DKIM key can be factored with enough compute. A compromised key lets attackers forge signed mail from your domain, bypassing DKIM checks entirely. 2048-bit is the current recommended minimum.

What we check
DKIM public key bit length detection
Flag keys below 2048-bit threshold
Multi-selector key strength checking
Alert on key changes or rotation
Weak key upgrade guidance

Outcome

Ensure all DKIM keys meet current security standards.

DKIM Key Strength
clientdomain.com
DKIM selector found
Key type
Key bit length
Minimum standard
Reporting
1 checks

Health Scoring

Onenumberthattellsyouwhichdomainneedsattention.

Individual checks tell you what is broken. The health score tells you how serious the overall situation is. Infraova combines results from all 25 checks into a single 0-100 score per domain, weighted by severity.

What we check
Composite score across all 25 check types
Severity-weighted calculation
Continuous score updates
Historical trend tracking
Per-client and per-domain score views

Outcome

Turn 25 checks into one actionable priority signal.

Health Score
clientdomain.com

Composite Score

SPF
DKIM
DMARC p=none
Blacklist
SSL 11d
MTA-STS

See it working on your domains.

Start a free trial and add your first client domain in under two minutes.