DMARC for MSPs: A Service Delivery Guide

Managed DMARC is not a one-record service. An MSP needs a repeatable way to identify legitimate senders, coordinate DNS and provider changes, interpret aggregate reports, explain risk to customers, and progress policy without disrupting valid mail.

This guide describes that operating process. It does not prescribe commercial terms or promise that every customer domain follows the same timetable.

Define the service boundary first

Before onboarding a domain, decide who owns each responsibility:

Vigil uses three partner paths: Referral, Reseller, and Self-service. Review the partner models before promising a delivery split to a customer.

Prerequisites for offering managed DMARC

An MSP does not need to build its own report parser, but it does need operational discipline.

Minimum prerequisites include:

• permission to assess and work on the domain;
• a reliable DNS access and approval path;
• an inventory of known mail services;
• access to provider administrators when DKIM or sender settings must change;
• a named customer decision-maker;
• a documented rollback process for DNS and policy changes; and
• a support path for unexpected delivery impact.

A managed platform can process aggregate reports, help identify sending sources, and present authentication evidence. The MSP still coordinates authorised changes, customer communication, provider-side configuration, and exceptions according to the agreed operating model.

Choose the DNS access model

Customer-controlled DNS

The MSP prepares and verifies changes, while the customer or its DNS provider publishes them. This preserves customer control but can slow remediation if responsibilities are unclear.

For each change, provide:

• exact record name, type, and value;
• purpose and expected effect;
• TTL or change-window considerations;
• verification steps; and
• rollback instructions.

MSP-controlled DNS

Where the MSP is already authorised to manage the zone, changes can follow the MSP’s established DNS controls. Do not treat existing technical access as unlimited approval. Record the customer authorisation and keep an audit trail.

Delegated records

Some managed workflows use CNAME or other constrained delegation patterns for specific records. Delegation can reduce repeated changes at the customer zone, but it must be documented and limited to the agreed namespace. It does not transfer ownership of the customer’s domain.

The per-domain onboarding sequence

1. Confirm ownership and scope

Record the domain, customer contact, DNS operator, primary mail platform, known sending services, and intended partner model. Start with a domain the provider understands well—ideally its own organisation domain—before applying the process across a customer portfolio.

2. Assess current public DNS

Review:

• the effective DMARC policy and reporting destinations;
• SPF record count, syntax, authorised sources, and lookup chain;
• known or provider-supplied DKIM selectors;
• MX records and DNS health; and
• subdomains that send mail or require separate consideration.

The free DMARC checker provides a point-in-time public view. It cannot discover every DKIM selector or show actual sending behaviour.

3. Inventory legitimate senders

Ask business and technical contacts about:

• primary user mail;
• invoicing and accounting systems;
• CRM and marketing platforms;
• ticketing and helpdesk tools;
• website and application mail;
• monitoring and alert services;
• payroll or HR systems; and
• low-frequency or seasonal senders.

Do not rely only on the first report cycle. Periodic services may appear later.

4. Establish aggregate reporting

Publish or correct a monitoring record only after confirming the authorised reporting destination and any required external-destination verification. The public DNS record asks participating receivers to send aggregate data; it does not guarantee that every receiver reports.

5. Classify observed sources

For each material source, record whether it is:

• authorised and aligned;
• authorised but failing SPF or DKIM alignment;
• a known forwarder or mailing-list path;
• unknown and under investigation; or
• unauthorised or no longer required.

Use evidence from DNS, provider documentation, message headers, customer records, and aggregate reports. An IP address alone does not identify the responsible person or application.

6. Remediate authentication gaps

Typical work includes:

• consolidating duplicate SPF records;
• staying within the SPF 10-lookup evaluation limit;
• enabling provider-managed DKIM;
• correcting a DKIM selector or CNAME;
• aligning a provider’s envelope or signing domain with the visible From domain; and
• moving an obsolete service away from the customer domain.

Read SPF Records Explained and the DKIM setup guide before changing production DNS.

7. Progress policy using evidence

Move from monitoring only when normal and periodic legitimate sources are understood and aligned. A quarantine or reject policy expresses the domain owner’s requested handling; receiving systems may still apply local policy.

The policy-progression guide provides evidence gates and rollback considerations.

8. Continue monitoring

The work does not end at enforcement. New SaaS tools, provider migrations, key rotation, DNS changes, and forwarding paths can change authentication results. Review change events and report evidence according to the customer’s agreed service process.

Portfolio operations without unsupported shortcuts

Avoid claiming that a dashboard grade or single percentage proves that a domain is secure. Useful portfolio indicators include:

• current published policy;
• observed aligned and failing volume;
• unresolved legitimate sources;
• new or changed sources;
• DNS evaluation errors; and
• the date and owner of the next action.

Prioritise exceptions, but keep enough context to explain why an exception matters. A point-in-time score should not replace source investigation or customer approval.

The effort per domain varies with DNS access, number of sending services, provider support, forwarding, and the quality of existing documentation. Do not promise a fixed onboarding or remediation time before discovery.

Customer communication

At onboarding

Use plain language:

We are checking which systems are authorised to send using your domain, correcting authentication gaps, and using report evidence before asking receivers to apply stronger handling to failures.

Explain the boundary:

• DMARC addresses authorised use of the exact From domain;
• it is not an inbound spam or malware filter;
• it does not stop lookalike domains or compromised mailboxes; and
• authentication does not guarantee inbox placement.

During remediation

Tell the customer which legitimate service is affected, what evidence was observed, who needs to act, and whether a policy change is being delayed. Avoid converting technical counts into claims that an attack was blocked unless the evidence supports that exact statement.

During ongoing review

Report current policy, meaningful changes, unresolved sources, completed work, and the next decision. Call an authentication pass a pass—not “compliant”, “safe”, or “fraud-free”.

Partner-branded reporting

Partner-branded PDF reporting may be available when it is explicitly configured and agreed. That narrow capability does not imply full platform white-labelling, a separate branded application, or any particular commercial term.

What managed DMARC does not cover

• inbound content filtering, spam classification, or malware scanning;
• lookalike-domain monitoring;
• mailbox account security or MFA;
• legal or POPIA compliance determination;
• guaranteed delivery, inbox placement, or receiver enforcement;
• customer DNS changes without authorisation; or
• DKIM private-key control as a default Vigil service.

Frequently asked questions

Does an MSP need deep DMARC expertise before starting?

The team needs DNS competence, a controlled workflow, and the ability to coordinate provider settings and customer decisions. Start with the provider’s own domain and escalate unfamiliar cases rather than guessing.

Should every new domain start at p=none?

Use the current evidence. A new or poorly understood domain normally needs monitoring before stronger policy, but an existing domain may already have a valid enforcement policy. Do not weaken it automatically during onboarding.

What happens when a customer adds a new sending service?

Identify the service, confirm authorisation, review SPF and DKIM options, make approved changes, and verify later message and report evidence. Do not assume the service is safe or broken from one source IP alone.

Can an MSP promise a fixed time to reject?

No universal timetable is safe. Progress depends on the sending estate and evidence. Set a target and review gates, not a deadline that overrides unresolved mail flows.

Can reports carry the MSP’s brand?

Partner-branded PDF reporting may be available where explicitly configured and agreed. This is narrower than a fully white-labelled platform.

Start with the service-provider page, compare the partner models, and use the free checker for the first public-DNS assessment. WISPs can use the separate WISP scope and workflow guide to define DNS, customer, and escalation responsibilities without changing this broader MSP operating model.