What Is Valimail? A Hosted DMARC Fit Test

Valimail is an email-authentication platform with two distinct DMARC jobs: Monitor collects and presents DMARC data for visibility, while Enforce is the paid product for managing authentication and maintaining a restrictive DMARC policy. The hosted model can reduce repeated DNS edits by letting operators manage delegated DMARC, SPF and, where supported, DKIM configuration in Valimail. It does not remove the need for a DNS owner, sender inventory, business approvals or a controlled change process.

What Valimail Does

Valimail turns DMARC aggregate data into named sender and authentication views, then offers a paid path for managing enforcement. Its Monitor product page describes free visibility into services sending from a domain, DMARC pass and fail status, aligned SPF and DKIM and unidentified sources. Those are vendor-described capabilities, not an independent guarantee that every service will always be identified correctly.

The product boundary matters. Valimail's Monitor setup documentation says Monitor is solely for visibility into DMARC data. It explicitly says Monitor does not let customers manage DMARC policy or sender SPF and DKIM configuration. Monitor receives aggregate reports after the domain's _dmarc TXT record includes Valimail's reporting address.

Valimail Enforce is the hosted enforcement product. Valimail describes automation, sender identification, one-click authorization, auto-configuration, updates and alerts. Keep those statements attributed to the vendor and validate them against your real services during evaluation.

Our view: the meaningful Valimail decision is not free versus paid reporting. It is whether the organization should delegate parts of authentication DNS to a hosted control plane. That is an operating-model and change-control decision before it is a dashboard decision.

Monitor and Enforce Solve Different Problems

Monitor is a good discovery layer when the immediate question is who sends using the domain and where authentication fails. It can reveal work, but the team must still complete that work in its DNS and sending services.

Enforce changes where more of the work happens. Valimail's self-onboarding guide says hosting DMARC, SPF and DKIM records in Enforce allows those activities to be managed from one application and minimizes repeated DNS changes. The same guide still tells customers to appoint a project leader, add domains and users, prepare SPF configuration, identify authorized services and point records to the platform. Hosted does not mean ownerless.

What Hosted DMARC Enforcement Changes

For DMARC policy management, Valimail's record-management guide says a domain must point DMARC to Valimail with an NS or CNAME record. Sending reports through a TXT rua address lets Valimail receive aggregate feedback, but it does not let the customer manage the DMARC record in Enforce.

That distinction is the center of the fit test. Reporting sends data to a vendor. Delegation gives the hosted service control over answers for a defined DNS name. Once configured, authorized users can make supported policy changes in the platform rather than asking the primary DNS team to edit the zone for every change.

SPF uses a different mechanism. Valimail's SPF setup article tells Enforce customers to back up and remove the existing SPF record, then publish a Valimail include that uses SPF macros. The platform then manages which approved senders are represented through that path.

DKIM management requires another explicit boundary. The DKIM delegation article says customers must first copy current DKIM keys into Valimail, then add an NS record for the _domainkey subdomain. It also says that if the DNS host does not support custom NS records, DKIM cannot be managed by Valimail and must remain in the customer's DNS.

These are not one-click changes. They alter production authentication and need backups, staged validation and rollback instructions.

What the DNS and Application Teams Still Own

The DNS team still controls the parent zone and decides whether to publish the TXT, CNAME or NS changes. It must preserve the prior state, verify delegation and retain a tested exit path.

Application owners still decide which services are legitimate. Recognition cannot determine whether an old recruiting tool, regional account or contractor platform remains approved. Every sender needs an owner, purpose and review date.

Sending-service administrators still configure DKIM and custom return paths where required. Hosting the policy does not repair a service that signs with an unrelated domain or uses an unaligned envelope sender.

Governance owners still control access, approvals and evidence. Decide who can authorize a sender, change a policy, manage a key and view reports. Export the configuration and user list on a schedule.

LeadHaste practice: require two approvals before authorizing a newly discovered sender: the business owner confirms the service is needed, and the authentication owner confirms how it will align. This is an editorial control, not a Valimail feature claim.

Use a Fit Test Instead of a Domain Threshold

No source establishes a universal number of domains or senders at which Valimail becomes necessary. One domain with many changing services can create more work than several stable, non-sending domains.

Score the recurring workload instead:

A strong fit exists when the quote replaces measurable review, DNS and incident work while preserving clear ownership. A weak fit exists when the organization has not identified its senders, cannot assign owners or expects the vendor to decide which traffic is legitimate.

Test the Hosted Model Before Approval

Start with an inventory of domains, subdomains, sending services, current SPF content, DKIM selectors, DMARC policy and report destinations. Include non-sending domains because they may need an explicit protection decision even though they have no legitimate sender list.

Then require a controlled evaluation:

1. Connect one representative domain to reporting and compare identified services with the internal register.
2. Investigate every unknown source rather than accepting an automatic label as authorization.
3. Configure one approved service and validate SPF or DKIM alignment with real headers.
4. Stage the exact DNS delegation proposed for production, including backups and rollback.
5. Test user roles and require an approval trail for sender and policy changes.
6. Remove a test sender and confirm both the platform state and public DNS response change as intended.
7. Export configuration, report history and user access, then review offboarding steps.

Do not use a high-volume or business-critical domain as the first migration. A representative lower-risk domain reveals DNS-host limitations, ownership gaps and service-specific DKIM work without putting every mail stream behind an untested process.

Decide What Hosted Enforcement Is Buying

The approval case should name the manual work Enforce replaces: classifying services, maintaining SPF, managing delegated DKIM, changing policy, watching for regressions and coordinating DNS tickets. Compare that workload with the written quote. Keep Monitor when the internal team can perform the fixes directly.

Valimail fits when delegation creates a cleaner, governed operating loop. It does not fit merely because DMARC feels complicated. First establish who owns each sender and each production change. Then decide whether hosting the control surface reduces enough work and risk to justify another critical dependency.

If you want to map your sending estate, DNS ownership and hosted-enforcement fit before a vendor conversation, book a free ICP and campaign-fit discovery call →.