Scenario: Customers use domain endpoints to add/update domain records programmatically.

Outcome: Simplifies multi-domain management.

Scenario: A customer centrally manages subdomain DMARC coverage (e.g., enabling/disabling subdomain monitoring or applying consistent policy inheritance) by updating subdomain-related settings within the Configuration API for a parent domain.

Outcome: Consistent enforcement and visibility across subdomains with reduced manual configuration drift.

Scenario: A customer audits subdomain configurations to identify which subdomains are missing required email authentication controls, then programmatically applies the approved configuration baseline.

Outcome: Faster remediation of gaps and improved overall domain posture at scale.

Scenario: Identify domains with weak policies and strengthen DMARC posture.

Outcome: Reduced risk of phishing and spoofing.

Scenario: Link third-party email services (SendGrid, Mailgun, etc.) to domains.

Outcome: Streamlined setup and onboarding.

Scenario: Pull netblocks to validate SPF coverage across legitimate mail sources.

Outcome: Reduced false positives and improved authentication alignment.

Scenario: A customer publishes or updates MTA-STS policy settings for one or more domains through the Configuration API as part of a standardized “secure email” rollout.

Outcome: Improved transport security by enforcing TLS requirements for inbound mail delivery.

Scenario: A customer rotates MTA-STS policy versions and validates changes during staged deployments (dev → pilot → production) using API-driven updates rather than manual DNS/web hosting changes.

Outcome: Safer rollouts with fewer misconfigurations and clearer change control.

Scenario: A customer enables TLS-RPT reporting for domains and configures the reporting destination(s) using the Configuration API to receive automated feedback on TLS negotiation failures.

Outcome: Increased visibility into delivery issues and misconfigurations impacting encrypted transport.

Scenario: A customer periodically reviews TLS-RPT configuration state across many domains, then standardizes reporting URIs and settings to ensure consistent telemetry.

Outcome: Reliable, account-wide transport reporting with simplified operational oversight.

Scenario: A customer uses SCIM-based user and group provisioning to automatically create, update, and deactivate users in Valimail when changes occur in their identity provider (e.g., Okta, Azure AD).

Outcome: Reduced administrative workload and improved security through timely deprovisioning and least-privilege access.

Scenario: A customer synchronizes role-based access by mapping identity provider groups to application permissions, ensuring the correct teams have access to the correct accounts and domains.

Outcome: More consistent access control with fewer manual errors and faster onboarding/offboarding.

Use Case: The DMARC Configuration API facilitates seamless domain management by automating domain record additions and updates across large domain portfolios.

Outcome: Reduced operational overhead, improved efficiency, and accelerated compliance with email security standards.

Use Case: Managed Service Providers (MSPs) use the API to centrally manage DMARC records and email authentication configurations for multiple customer domains, using bulk updates to streamline administration.

Outcome: Enhanced operational efficiency, improved compliance, and simplified management across customer accounts.

Use Case: Customers centrally manage subdomain DMARC coverage by updating subdomain-related settings for a parent domain (e.g., enabling/disabling subdomain monitoring or enforcing consistent inheritance/overrides).

Outcome: Consistent enforcement and visibility across subdomains with reduced manual configuration drift.

Use Case: Customers audit subdomain configuration state at scale to identify gaps (e.g., missing required controls), then programmatically apply an approved configuration baseline across subdomains.

Outcome: Faster remediation of gaps and improved overall domain posture at scale.

Use Case: The API identifies domains with weak or non-existent DMARC policies (e.g., set to “None”), enabling partners or customers to take proactive steps to strengthen posture.

Outcome: Reduced risk of phishing, spoofing, and other email-based threats, with stronger email authentication practices.

Use Case: Businesses programmatically update DMARC policies during onboarding, progressing from “None” to “Quarantine” or “Reject” as domains move toward full enforcement.

Outcome: Seamless domain onboarding, improved email security, and uninterrupted email operations.

Use Case: Businesses track the enforcement status of all domains in a customer’s account and generate compliance reports for regulators, auditors, or internal stakeholders.

Outcome: Transparency, accountability, and adherence to contractual obligations and regulatory compliance standards.

Use Case: The API retrieves domain sending statuses (e.g., “Active” vs. “Blocked”) and last report dates, enabling prioritization of security improvements for actively used domains first.

Outcome: Enhanced security and deliverability by focusing efforts on high-impact domains and reducing vulnerabilities.

Use Case: Businesses implement a tiered security strategy by progressively transitioning domains to stricter DMARC policies, starting with less restrictive settings to reduce disruption.

Outcome: Stronger email security adoption that aligns with best practices while maintaining operational stability.

Use Case: Integrating the API with monitoring tools enables businesses to detect and alert customers about configuration issues, such as missing or misconfigured DMARC, SPF, or DKIM records.

Outcome: Faster resolution of issues, reduced risk of email delivery failures, and improved customer satisfaction.

Use Case: The API provides netblock (IP range) data associated with each domain, allowing businesses to visualize coverage and confirm SPF includes all legitimate email sources.

Outcome: Reduced chances of legitimate emails being flagged as spam due to incomplete SPF configurations.

Use Case: Customers enable TLS-RPT and configure reporting destinations to receive automated telemetry on TLS negotiation failures and transport misconfigurations.

Outcome: Increased visibility into delivery issues and misconfigurations impacting encrypted transport.

Use Case: Customers periodically review TLS-RPT configuration state across many domains and standardize reporting URIs/settings to ensure consistent telemetry and operational workflows.

Outcome: Reliable, account-wide transport reporting with simplified oversight and fewer blind spots.

Use Case: The API simplifies linking third-party email services (e.g., SendGrid, Mailgun) to a customer’s domain. Programmatic sender connections reduce friction during integration and onboarding.

Outcome: Faster onboarding processes, smoother customer transitions, and improved sender authentication.

Use Case: Customers publish or update MTA-STS policy settings through the Configuration API as part of a standardized secure email rollout across one or more domains.

Outcome: Improved transport security by enforcing TLS requirements for inbound mail delivery.

Use Case: Customers rotate MTA-STS policy versions and validate changes during staged deployments (e.g., dev → pilot → production) using API-driven updates to improve change control.

Outcome: Safer rollouts with fewer misconfigurations and clearer operational governance.

Use Case: Customers use SCIM-based provisioning to automatically create, update, and deactivate users in Valimail when changes occur in their identity provider (e.g., Okta, Azure AD).

Outcome: Reduced administrative workload and improved security through timely deprovisioning and least-privilege access.

Use Case: Customers synchronize role-based access by mapping identity provider groups to application permissions, ensuring the correct teams have the right access to the right accounts and domains.

Outcome: More consistent access control with fewer manual errors and faster onboarding/offboarding.