Managed DMARC for WISPs: Scope, Workflow and Boundaries

A WISP may already coordinate connectivity, DNS, hosting, or technical support for some business customers. Where the WISP is authorised to work with a customer’s domain, those relationships can support a managed DMARC service—but DNS access alone is not enough.

The service needs a defined scope, a verified sender inventory, controlled changes, report review, customer approval, and clear escalation boundaries. This guide explains that operating model without assuming a particular customer profile or promising a fixed business outcome.

What DMARC contributes

DMARC evaluates whether SPF or DKIM passes and aligns with the domain visible in the From address. A domain owner can request aggregate reports and publish a policy asking participating receivers how to handle failures.

This can help the owner:

• see evidence of systems observed using the exact domain;
• identify legitimate senders with authentication or alignment gaps;
• document which services are authorised to send;
• request stronger handling after legitimate mail is understood; and
• monitor later changes in the sending surface.

DMARC is a domain-authentication control. It is not inbound spam filtering, message-content inspection, mailbox security, encryption, or a complete anti-phishing or anti-fraud solution. It does not stop lookalike domains or messages sent from a compromised authorised account.

For the protocol foundation, read What is DMARC?.

When the service may fit a WISP

A WISP can evaluate managed DMARC when it has, or can establish:

• an authorised relationship with the domain owner;
• a reliable way to identify the customer’s mail and DNS owners;
• access to publish approved DNS changes, or a controlled handoff to the person who can;
• a process for confirming legitimate sending services;
• a report destination and review workflow;
• a way to record decisions, exceptions, and rollback criteria; and
• an escalation path for provider-specific SPF, DKIM, forwarding, or delivery issues.

The service should not be offered merely because a domain has no DMARC record. First establish who owns the domain, whether it is used for mail, and who can authorise changes.

A practical division of responsibility

The domain owner

The customer confirms which domains and sending services are legitimate, identifies business owners, approves policy and DNS changes, and accepts the agreed service scope. The customer also needs to notify the provider when a new service will send mail.

The WISP or service provider

The provider can coordinate assessment, customer communication, authorised DNS changes, provider-side configuration tasks, evidence review, exception handling, and ongoing service records. Its exact responsibility depends on the agreed partner and support model.

Vigil

Vigil supports managed DMARC assessment, aggregate-report processing, source identification, SPF review and optimisation support, DKIM discovery and evidence review, monitoring, reporting, and policy-progression guidance. Vigil does not take default control of customer DNS or DKIM private keys.

Partner-branded PDF reporting may be available where explicitly configured and agreed. That narrow capability does not imply a fully white-labelled platform or define commercial terms.

The service-provider page explains the wider Vigil workflow, while this article focuses on WISP delivery responsibilities.

A controlled delivery workflow

1. Confirm authority and scope

Record the customer, domain owner, DNS operator, mail-platform administrator, service contacts, and approved domains. State what the service includes and what remains outside scope.

Do not request passwords, DNS credentials, API keys, or DKIM private keys through Vigil’s public forms.

2. Assess public records

Review the effective DMARC policy, the SPF record and observable dependency chain, supported DKIM selector results, MX records, and DNS diagnostics.

The Vigil DMARC checker provides a point-in-time view of public DNS. It does not discover every DKIM selector, prove that provider-side signing is enabled, or show every system that sends mail.

3. Build the sender inventory

Ask the customer to identify primary mail, invoicing, marketing, support, website, application, monitoring, and periodic sending services. Confirm each system with a business or technical owner.

Do not authorise an unfamiliar source from an IP address alone. Use provider configuration, message headers, return-path domains, DKIM signing domains, and internal ownership evidence.

4. Establish aggregate reporting

Publish or correct a monitoring record only after confirming the report destination and any required external-destination authorisation. The DNS change follows the domain owner’s approval and the responsible operator’s change process.

Report arrival depends on relevant mail reaching participating receivers and their reporting schedules. There is no universal arrival time or complete receiver view.

5. Correct legitimate authentication

For each approved sender, determine whether aligned SPF, aligned DKIM, or both are available. Follow the sending provider’s current documentation and verify with controlled message samples.

SPF work can include removing obsolete authorisations, checking the 10-querying-term limit, and considering a provider-supported design or managed flattening where appropriate. DKIM work stays within discovery, evidence review, validation, monitoring, and guidance unless a separate scope explicitly assigns provider-side changes.

The MSP service-delivery guide gives the broader authentication and customer-coordination workflow for cases that need more detail.

6. Progress policy using evidence

Move beyond monitoring only when normal and periodic legitimate senders are understood, material gaps are resolved or accepted, and the customer approves the change and rollback plan.

Quarantine and reject are domain-owner requests to participating receivers. Receivers may apply local policy, so enforcement does not create a universal delivery outcome.

Use the policy-progression guide for the evidence gates.

7. Monitor change

New services, migrations, key rotation, DNS changes, and forwarding paths can alter authentication. Review report evidence and known change events according to the agreed service process. Investigate before removing a sender or publishing a stronger policy.

Customer communication without overclaiming

A clear explanation is:

DMARC helps us understand and improve authorised use of your exact email domain. We review observed sending sources, correct legitimate authentication gaps, and use the evidence before asking participating receivers to apply stronger handling to failures. It does not replace mailbox security or stop every form of impersonation.

Avoid promising that DMARC will eliminate spoofing, guarantee delivery, stop fraud, or secure the customer’s whole email environment.

Operating records to maintain

For each managed domain, retain:

• the domain owner and authorised contacts;
• the current DNS and mail operators;
• a legitimate-sender inventory with named owners;
• approved DNS values and change evidence;
• SPF, DKIM, and DMARC validation results;
• report-derived findings and remediation tasks;
• policy decisions, exceptions, and rollback criteria; and
• the next review owner and trigger.

These records support consistent service delivery and handover. A single dashboard label, percentage, or policy value is not proof that the domain or organisation is secure.

POPIA context

POPIA does not name or require DMARC. Depending on the organisation’s risk assessment, email authentication may be considered as one possible technical safeguard within a much wider security and governance programme.

DMARC does not prove POPIA compliance, create a compliance certificate, or replace legal advice. Read POPIA, email security and DMARC: a technical perspective for the carefully limited context.

Frequently asked questions

Does a WISP need specialist capability to offer managed DMARC?

The provider needs more than basic DNS access. It needs a documented process, appropriate technical understanding, customer and provider coordination, evidence review, safe change control, and an escalation path for cases outside its competence.

Does the WISP need to host the customer’s DNS?

No. If another party hosts DNS, the service needs an authorised and reliable change handoff. Hosting DNS can simplify coordination, but it does not remove customer approval or change-control responsibilities.

How long does implementation take?

There is no standard timetable. It depends on domain ownership, DNS access, the number and complexity of legitimate senders, provider support, periodic mail, and the quality of available evidence. Policy should progress when the evidence supports it, not when a sales or project deadline expires.

Does Vigil automatically publish customer DNS changes?

No default automatic-publication claim is made. DNS remains with the domain owner or its authorised operator, and production changes follow the agreed responsibility and approval model.

Can reports carry the WISP’s brand?

Partner-branded PDF reporting may be available where explicitly configured and agreed. This does not promise a separately branded application, complete brand separation, or any particular commercial arrangement.

Does managed DMARC replace inbound email security?

No. DMARC evaluates aligned domain authentication and publishes a receiver-facing policy. Inbound filtering, account protection, content inspection, and user security remain separate controls.

Next step

Begin with a domain the provider is authorised to assess. Use the free checker and compare the partner models before defining customer responsibilities.