The 11 email infrastructure problems Infraova fixes automatically with your approval
Why automatic remediation matters
Most infrastructure tools stop at detection. They find the problem, fire an alert, and hand the work back to the team. The team then investigates, figures out the fix, makes the DNS change, verifies it worked, and documents what happened manually, every time.
Infraova is built to close that loop.
For 30 infrastructure checks per domain, Infraova monitors continuously. For 11 of those 30, when a problem is detected, Infraova doesn't just surface it it prepares the exact remediation. The current state, the proposed state, the evidence, the risk level, and the specific DNS record that will be created, modified, or removed.
Nothing executes until a human approves it. The approval can happen via Slack, email, or directly inside Infraova. What the administrator approves is exactly what Infraova executes no more, no less.
After execution, Infraova reads the live DNS record to confirm the expected state was actually reached. The issue is only marked resolved when verification confirms the fix worked.
This is what closing the operational loop means. And these are the 11 problems it closes.
1. DMARC missing
What it is
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a DNS record that tells receiving mail servers what to do with emails that fail SPF or DKIM authentication. Without a DMARC record, a domain has no enforcement policy anyone can send email appearing to come from that domain, and receiving servers have no instruction on how to handle authentication failures.
A missing DMARC record is not a minor configuration gap. It is the single most significant authentication vulnerability a domain can have. It exposes the domain to spoofing, prevents DMARC aggregate reports from being received, and means authentication failures pass silently with no visibility.
What Infraova does
When Infraova detects a missing DMARC record, it creates a proposal to add one with safe defaults p=none with Infraova's reporting address in the rua= tag.
p=none is the correct starting point: it establishes visibility and begins collecting aggregate reports without affecting email delivery. Infraova never creates a p=quarantine or p=reject record from scratch that would silently affect mail flow before the owner has verified DMARC alignment.
The proposed record is stored exactly as approved. The executor writes that value and nothing else.
2. DMARC RUA reporting setup
What it is
The rua= tag in a DMARC record specifies where aggregate reports should be sent. DMARC aggregate reports are XML files sent daily by Gmail, Yahoo, Microsoft, and other major providers they contain data about every email sent from a domain, whether it passed or failed SPF and DKIM, and what the receiving server did with it.
Without a rua= address, aggregate reports go nowhere. Authentication failures, unauthorized senders, and policy evaluation results are invisible.
What Infraova does
When a DMARC record exists but has no rua= address, or when Infraova's reporting address is not present, Infraova injects its reporting address into the existing record.
The injection follows a strict preservation rule: Infraova never overwrites or removes the customer's existing DMARC configuration. If a rua= address already exists, Infraova appends its address alongside it. If no rua= exists, it adds one. All other DMARC parameters policy, sp=, pct=, adkim=, aspf= are preserved exactly as-is.
Three scenarios:
Existing rua= present: rua=existing@provider.com becomes rua=existing@provider.com,infraova-address
No rua= present: The existing record gains ; rua=infraova-address appended cleanly, with trailing semicolons stripped first to prevent double-semicolon formatting bugs.
No DMARC record: Infraova proposes a minimal v=DMARC1; p=none; rua=infraova-address record.
Once reports begin flowing, Infraova uses the aggregate data to inform DMARC policy progression and subdomain protection evaluations.
3. DMARC policy progression
What it is
DMARC has three enforcement levels:
p=nonemonitoring only. Emails failing authentication are delivered normally.p=quarantinefailing emails go to spam or junk.p=rejectfailing emails are rejected outright.
Most domains with DMARC configured sit permanently at p=none. The policy exists but provides no protection. The domain remains exposed to spoofing because no action is taken against failing mail.
Why domains get stuck at p=none
Moving from p=none to p=quarantine, and from p=quarantine to p=reject, requires confidence that all legitimate email sources are correctly authenticated. Most teams don't move because they don't know when it's safe they have DMARC reports arriving but no system for reading them systematically. So p=none becomes permanent.
What Infraova does
Infraova monitors how long the current DMARC policy has been stable and proposes the progression only when the evidence supports it.
The progression logic:
From p=none to p=quarantine: Infraova waits for 30 or more days of stability at p=none before proposing the upgrade.
From p=quarantine to p=reject: The same logic applies 30 days of stable p=quarantine before proposing p=reject.
At p=reject: No further upgrade is proposed. Ever.
Before creating any proposal, Infraova reads the live DNS record and verifies that the current policy matches what it has tracked. If the live record differs from the tracked policy because someone changed it outside of Infraova no proposal is created. The system never acts on stale information.
If a domain's policy was previously at a higher level and was downgraded, Infraova detects the downgrade and handles it appropriately.
Only the p= tag changes. All other DMARC parameters are preserved exactly as-is.
4. DMARC pct enforcement
What it is
The pct= tag in a DMARC record controls what percentage of messages the DMARC policy is applied to. pct=100 means every message is subject to the policy. pct=50 means only half of messages are evaluated the other half bypass enforcement entirely.
Values below 100 are a transitional state intended for teams rolling out DMARC gradually to test the impact before full enforcement. Once DMARC has been stable, partial enforcement has no remaining value. A domain with p=reject; pct=50 is rejecting failing mail for only half its messages. The other half still gets through.
What Infraova does
Infraova proposes setting pct=100 when three conditions are met:
- The DMARC policy is
p=quarantineorp=rejectpct=100atp=noneadds no enforcement value since the policy is monitoring-only regardless of pct. - The current
pct=value is below 100. - The policy has been stable for 30 or more days Infraova uses
dmarc_policy_first_seen_atto confirm stability.
If no pct= tag is present in the record, DMARC defaults to 100 no change needed and no proposal is created.
Only the pct= tag changes. All other DMARC parameters are preserved exactly as-is.
5. DMARC subdomain protection
What it is
A DMARC record at the root domain applies to the root domain. Subdomains inherit the root policy unless a specific subdomain policy is defined using the sp= tag.
Without an explicit sp= tag, a domain at p=none leaves all subdomains completely unprotected anyone can send email appearing to come from mail.yourdomain.com, send.yourdomain.com, or any other subdomain with no DMARC enforcement.
What Infraova does
Infraova evaluates subdomain email activity using DMARC aggregate report evidence before creating any subdomain protection proposal. The evidence comes from dmarc_report_records the per-record data from ingested DMARC aggregate XML reports, with header_from, dkim_domain, and envelope_from as queryable columns.
Three explicit evidence states exist no implicit conversions:
confirmed_safe: At least 10 DMARC report records exist for the domain, and none of header_from, dkim_domain, or envelope_from contains a subdomain of the root domain. Infraova proposes sp=reject.
confirmed_active: Records exist and at least one subdomain sender is detected. Infraova does not propose sp=reject doing so would block legitimate mail. The subdomain activity is surfaced for manual review.
unknown: No records ingested yet, or fewer than 10 records exist. Infraova cannot make a safe determination. Unknown is never treated as safe. No proposal is created.
Infraova proposes sp=reject directly not sp=quarantine. For subdomains that send no legitimate mail, quarantine provides no additional value over reject.
The sp= tag is inserted or replaced surgically. All other DMARC tags are preserved verbatim.
6. SPF missing
What it is
SPF (Sender Policy Framework) is a DNS record that specifies which mail servers are authorized to send email from a domain. Without SPF, the sending server cannot be validated which affects deliverability and leaves the domain without a basic layer of sending authorization.
What Infraova does
When Infraova detects a missing SPF record, it first confirms the absence via live public DNS (Cloudflare 1.1.1.1 and Google 8.8.8.8) not just from the last scan result. This prevents creating a proposal for a record someone already published manually.
Infraova then infers the appropriate SPF includes from two sources:
DKIM selectors: Known selector patterns map to sending platforms. google → include:_spf.google.com, selector1/selector2 → include:spf.protection.outlook.com, s1/s2 → include:sendgrid.net, k1 → include:_spf.mlsend.com, resend → include:spf.resend.com, and others.
MX records: MX host patterns map to mail provider includes. Google MX hosts → include:_spf.google.com, Outlook hosts → include:spf.protection.outlook.com, and others.
The proposed record starts with ~all (softfail) the correct starting point. The SPF hardening evaluator handles the upgrade to -all once the record is stable.
If the proposed record would have 8 or more DNS lookups, Infraova skips too close to the 10-lookup limit. Manual consolidation is required first.
If the domain has no MX records at all, Infraova skips the domain may not send mail and the Null MX evaluator is the appropriate path instead.
7. SPF hardening
What it is
An SPF record ending in ~all (softfail) marks unauthorized senders as suspicious but doesn't instruct receiving servers to reject them. An SPF record ending in +all or ?all is worse it either passes all senders or returns a neutral result for any sender regardless of authorization.
-all (hardfail) is the correct enforcement posture it instructs receiving servers to reject email from senders not authorized in the SPF record.
What Infraova does
When Infraova detects a permissive SPF terminator (~all, +all, or ?all), it proposes hardening to -all.
Before proposing, Infraova checks the SPF lookup count. If the record already has 10 or more DNS lookups, Infraova skips tightening enforcement on a near-limit record doesn't fix the underlying problem and could mask delivery failures. Manual consolidation of SPF includes is required first.
Only the terminator changes. All existing include: mechanisms, IP authorizations, and other SPF parameters are preserved exactly as-is.
8. CAA records
What it is
CAA (Certification Authority Authorization) records specify which certificate authorities are permitted to issue SSL/TLS certificates for a domain. Without a CAA record, any certificate authority in the world can issue a certificate for the domain enabling certificate misissuance attacks. Certificate Transparency logs catch misissuance after the fact. CAA prevents it.
What Infraova does
When Infraova detects no CAA records exist for a domain, it reads the live TLS certificate via a direct TLS connection to determine which certificate authority is currently issuing the domain's certificate.
Infraova maps the certificate issuer's Organization field to a known CA domain using a recognized CA list: Let's Encrypt → letsencrypt.org, Google Trust Services → pki.goog, DigiCert → digicert.com, Sectigo → sectigo.com, Cloudflare → cloudflare.com, Amazon → amazon.com, GlobalSign → globalsign.com, Entrust → entrust.net, GoDaddy → godaddy.com.
If the issuer is not in the recognized list, Infraova skips it never authorizes a CA it cannot identify with confidence. Authorizing the wrong CA would break future certificate issuance.
The proposal adds two CAA records pointing to the detected CA: 0 issue "ca-domain" (regular certificates) and 0 issuewild "ca-domain" (wildcard certificates).
9. MTA-STS
What it is
MTA-STS (Mail Transfer Agent Strict Transport Security) allows domains to declare that inbound email must be delivered over encrypted TLS connections with a valid certificate. Without MTA-STS, email delivery to a domain can be downgraded to unencrypted connections through a man-in-the-middle attack.
MTA-STS requires two things: a DNS record at _mta-sts.domain and a policy file hosted at https://mta-sts.domain/.well-known/mta-sts.txt.
What Infraova does
Infraova checks whether the MTA-STS policy file is reachable before proposing the DNS record. If the policy file is not reachable at the well-known URL, Infraova skips and explains why: creating the DNS record before the policy file exists would direct mail servers to a missing policy, which can cause delivery problems.
When the policy file is confirmed reachable, Infraova proposes adding the _mta-sts DNS TXT record with a generated id= value in YYYYMMDDHHmmss format the standard timestamp-based identifier that changes whenever the policy changes.
If an MTA-STS record already exists, Infraova skips.
10. TLS-RPT
What it is
TLS-RPT (TLS Reporting) enables mail servers to send reports about TLS connection failures when delivering email to a domain. Without TLS-RPT, TLS failures during inbound mail delivery are invisible the domain owner has no way of knowing whether MTA-STS enforcement is causing delivery problems or whether TLS connections are failing for any reason.
TLS-RPT works alongside MTA-STS: MTA-STS enforces TLS, TLS-RPT reports when it fails.
What Infraova does
Infraova uses the same dmarc_token assigned to the domain for DMARC reporting to generate the TLS-RPT reporting address mailto:tls+token@reports.infraova.com correlating TLS reports with DMARC reports in the same reporting pipeline.
Two scenarios:
No TLS-RPT record exists: Infraova proposes creating v=TLSRPTv1; rua=infraova-tls-address.
Record exists but Infraova address not present: Infraova proposes appending its address alongside the existing rua= endpoint, preserving the existing reporting destination.
If Infraova's reporting address is already present, no proposal is created.
11. DKIM publishing
What it is
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing emails, verified by the receiving server against a public key published in DNS. Without DKIM, emails cannot be cryptographically authenticated affecting deliverability, weakening DMARC alignment, and leaving the domain without one of the three core authentication standards.
DKIM problems Infraova handles: missing DKIM record, revoked DKIM key (empty p= value), and weak DKIM key strength (1024-bit below the recommended 2048-bit minimum).
What Infraova does
DKIM is different from every other evaluator. DKIM keys are generated by the sending platform Google Workspace, Microsoft 365, SendGrid, Postmark, and others. Infraova cannot generate a DKIM key on behalf of a sending platform.
The flow is:
- The agency obtains the DKIM public key from their ESP and pastes it into the Infraova dashboard along with the selector
- Infraova stores the pending key and selector on the domain record
- When a DKIM issue is detected, Infraova checks whether a pending key is available
- If a pending key exists, Infraova performs a live public DNS lookup to confirm the record is genuinely missing or revoked at the pending selector not just stale scan data
- If confirmed missing or revoked, Infraova creates a proposal to publish the pending key
DNS states:
- missing (ENODATA/ENOTFOUND): Proceed record definitively absent
- revoked (empty
p=value): Proceed key was rotated, new key needed - exists (valid record with non-empty
p=): Skip pending key is stale - dns_error (SERVFAIL/timeout): Skip unknown state, never propose on bad data
The proposed DKIM TXT record format: v=DKIM1; k=rsa; p=<base64 public key>
The proposal reason adapts to the specific issue: key missing, key revoked, or key strength below recommended minimum.
The 19 checks Infraova detects but cannot automatically remediate
For completeness: the 19 of 30 checks that Infraova monitors but cannot automatically remediate are:
Authentication: DMARC alignment, DKIM key strength (detection only publishing handled by evaluator #11), BIMI, subdomain lockdown DNS and infrastructure: MX, PTR/reverse DNS, DNSSEC, nameserver changes, SPF record length, DANE/TLSA Security and transport: SSL certificate Reputation and compliance: Blacklist status, Google bulk sender requirements Domain: WHOIS, domain expiry, registrar lock Intelligence: Spoofing detection, Gmail reputation, DNS change monitoring
For each of these, Infraova detects the issue, evaluates severity, prioritizes it, and surfaces it with full context and a fix guide. The fix requires action outside the platform contacting a hosting provider, rotating a certificate, working with a registrar, or addressing a reputation problem with the relevant provider.
What the full remediation loop looks like
For every one of the 11 remediable checks, the sequence is the same:
Detected Infraova identifies the issue through continuous monitoring.
Diagnosed Infraova evaluates the current state, reads live DNS, confirms the issue is real and not stale scan data.
Proposed Infraova prepares the exact remediation: current state, proposed state, evidence, risk level, and the specific DNS change. The proposed record is stored verbatim the executor writes exactly this value without regenerating anything after approval.
Approved The operator reviews the proposal and decides. Via Slack, email, or inside Infraova. Nothing executes without this step.
Executed Infraova applies the approved change through the connected DNS provider.
Verified Infraova reads the live DNS record and confirms the expected state was reached.
Recorded The full operational history detection, proposal, approval, execution, verification is stored in the audit log.
Then monitoring continues.
Why approval is non-negotiable
Every one of these 11 remediations goes through human approval. This is a deliberate design principle, not a limitation.
Agencies are touching infrastructure that belongs to their clients. An automated system that modifies DNS records without explicit human authorization is not infrastructure management it is infrastructure risk.
Infraova removes the operational work surrounding the decision: the investigation, the diagnosis, the evidence evaluation, the proposal preparation. The human steps in at exactly the right moment the decision about whether the change should happen and then Infraova handles execution, verification, and recording.
What the administrator approves is exactly what Infraova executes. The approval is the boundary between intelligence and action, and it belongs to the human responsible for the infrastructure.
Infraova is an email infrastructure operations platform for agencies, MSPs, deliverability consultants, and businesses managing email at scale. Start operating your infrastructure →