Vigil helps service-provider teams assess customer domains, process aggregate reports, identify sending sources, review SPF and DKIM evidence and guide policy progression. Your team chooses how much of the customer relationship and technical work it wants to own.
Compare partner models · Check your own domain
Why the work becomes difficult at scale
The DNS record is only the start. The operational work is discovering every legitimate sender, interpreting report data, coordinating provider-side authentication, handling exceptions and revisiting the configuration when a customer adds or changes a service. A repeatable workflow matters more than a one-off record generator.
What the workflow supports
- Point-in-time assessment of public DMARC, SPF, DKIM and MX signals.
- Aggregate-report processing and source identification.
- SPF review, lookup-limit analysis and optimisation support.
- DKIM selector discovery, evidence review, validation guidance and monitoring.
- Policy-stage recommendations grounded in report evidence.
- Provider-oriented reporting across customer domains.
Exact product access, branding, support and commercial scope are confirmed privately. This page does not promise DKIM key control, MTA-STS capability or a fully white-labelled platform.
Work through one customer before adding a portfolio
The following is an illustrative onboarding exercise, not a customer case study or a promise of automatic remediation. Use a domain your team is authorised to manage. Suppose its owner lists three sending services: staff email, an invoicing system and a newsletter service.
| Step | What to collect | Decision before moving on |
|---|---|---|
| Establish ownership | DNS administrator, owner of each sending service, approved contact and change process | Who can authorise a DNS change, and who can publish it? |
| Assess the domain | Public DMARC/SPF records, known DKIM selectors and headers from authorised test messages | Which record or provider setting needs investigation? A public check does not prove all senders are known. |
| Review observed sources | Aggregate-report period, sending sources and SPF/DKIM alignment results | Can each source be matched to the customer’s inventory? Ask the service owner before classifying an unfamiliar source. |
| Plan the correction | Exact provider instructions, proposed DNS values, responsible person and recovery steps | What change is needed, who approves it, and how will a mistake be reversed? |
| Validate and keep monitoring | Fresh DNS results, another controlled message and subsequent report evidence | Did the intended sending path align, and are any legitimate sources still unresolved? |
For example, the invoicing service might pass SPF using its own return-path domain while signing DKIM with the customer’s domain. An aligned DKIM pass can satisfy DMARC even when SPF does not align. Confirm the actual signing domain and result before deciding that SPF needs another entry. The aggregate-report interpretation guide works through those fields.
Agree who owns the next action
Vigil supports assessment, reporting and authentication review. The domain owner or authorised provider controls DNS publication; the sending-service administrator controls its configuration. Your selected partner model determines the agreed delivery responsibilities.
Record unresolved senders and business-critical mail paths before proposing stronger policy. A dashboard score or a completed DNS check is not approval to change a customer’s policy. For a first review, bring the domain, its sending-service list and the name of the DNS owner. Do not put credentials or private keys in an enquiry.
Choose responsibility deliberately
Referral suits teams that want to introduce the need and hand off delivery. Reseller suits teams that want to retain the customer and billing relationship with shared delivery. Self-service suits teams ready to own more of the technical workflow. Review all three before applying.
Compare partner models · Read the MSP service-delivery guide · Read the WISP scope and workflow guide
Boundaries to explain to customers
- DMARC addresses exact-domain authorisation; it is not inbound content filtering.
- A reject policy is a domain-owner request; receivers may apply local policy.
- Authentication does not guarantee deliverability or stop lookalike-domain abuse.
- Customer DNS and mail-provider changes remain important operational dependencies.
FAQ
Can a provider offer managed DMARC without building a report parser?
Yes. A managed workflow can process aggregate reports and present authentication evidence while the provider focuses on DNS ownership, customer communication and remediation decisions.
Does Vigil replace customer DNS management?
No. DNS remains under the domain owner or its authorised provider. The working model determines who publishes approved changes.
What happens when a customer adds a sending service?
The provider should identify the service, review its SPF and DKIM options, update approved DNS where needed and confirm alignment in subsequent report data.
Which partner model should we choose?
Choose based on responsibility: Referral for handoff, Reseller for a retained customer relationship with shared delivery, or Self-service for more direct technical operation.
Start with your own domain
Check the public records, then submit the context needed for guided onboarding.