DMARC for MSPs: how to run it across your client domains

How should an MSP run DMARC across client domains?

Run it as one repeatable process for every client, and let each client's reports decide when a domain moves on. RFC 9989 section 5.1 sets the same order for any domain owner. Align SPF and DKIM, collect aggregate reports, start at p=none, and fix legitimate mail before enforcing.

1. Inventory every domain each client owns, including parked and defensive ones.
2. Rank the work, so parked domains and money-moving clients go first.
3. Give every client its own reporting address, so evidence starts to arrive.
4. Fix each sender that fails, in that service's own settings.
5. Enforce one domain at a time, once its reports are clean.
6. Control DNS changes, whether or not you host the zone.

What did our audit of 192 UK MSPs find?

Nearly all the UK MSPs we audited had published DMARC on their own main domain, but fewer than four in ten had reached p=reject. Our UK MSP DMARC Audit: Q2 2026, published on 29 June 2026, graded 192 UK MSPs, each with a live MX record.

87% had a rua= reporting address, so the other 13% received no aggregate reports at all. The average provider earned a C on our Security Grade, and 6% earned an A or A+.

The Q1 2026 edition, published in March 2026, also checked each MSP's alternate brand domain, usually the .co.uk or .com counterpart. 80% had an alternate domain that was unprotected or not registered. The most common case, 117 MSPs (61%), was an alternate domain that existed with no DMARC record at all.

That edition also compared policy with where reports went. 54% of MSPs sending reports to a third-party tool were at p=reject. The figure was 26% for those using a mailbox on their own domain, and 3% for those with no reporting. That is a correlation, not proof of cause.

Both editions and their methods are on our research page. Check each client estate you take on for the same gaps.

Step 1: inventory every client domain, including parked ones

List every domain each client owns, not only the one its mailboxes use. An alternate or forgotten domain with no DMARC record can be spoofed as easily as the main one. Pull names from the client's registrar accounts and DNS zones, the domain list in Microsoft 365 or Google Workspace, website redirects and old renewal invoices. Ask about previous brand names and acquisitions too.

Record five things for each domain:

• Mail role: sends mail, only receives it, or neither (parked or defensive).
• DNS control: who hosts the zone and who can change it, whether you, the client, a web agency or the registrar.
• Current DMARC record, and where its rua= reports go today.
• Known senders: the services that send as the domain, first from the client's list, later from the reports.
• Renewal date and registrar lock, because a lapsed domain undoes the rest.

Our free SPF, DKIM & DMARC Checker reads each domain's current DMARC and SPF records, so the first pass needs no sign-up.

Step 2: decide which domains go first

Rank the work by what is at stake and by how little can break. A workable order:

1. Parked and defensive domains. Nothing legitimate sends from them, so they can go straight to refuse fakes (p=reject). Add the client's reporting address so attempts to use them still show up. If nobody can confirm a domain sends nothing, start it at p=none and read its reports first.
2. Sending domains with no DMARC record or no reporting address. Publish monitoring only (p=none) with a rua= tag, so evidence starts to arrive.
3. Clients whose email moves money. Invoices, payroll and supplier payments make a domain worth impersonating.
4. Domains whose reports are already clean. A domain at p=none or p=quarantine with every sender passing is the quickest step forward.

For a parked domain, the records look like this. Our guide to DMARC for parked domains adds the null MX record and DKIM clean-up.

_dmarc.example.org.  TXT  "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:client-a@reports.example.net"
example.org.         TXT  "v=spf1 -all"

Step 3: give every client its own reporting address

Reports are the evidence for every later step. A separate address per client keeps data and access apart, and when a client leaves, you change only that client's records and close one address.

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:client-a@reports.example.net"

Receivers check for permission when the address is on another organisation's domain. Under RFC 9990 section 4, they look for a TXT record starting v=DMARC1 at a name such as example.com._report._dmarc.reports.example.net, and skip the address if there is none.

A reporting service can publish one wildcard, such as *._report._dmarc.reports.example.net, to accept reports for any domain. If reports go to a mailbox on your own domain, that record is yours to publish. The SPF, DKIM & DMARC Checker flags an external reporting address that lacks it.

A rua= tag can list several addresses separated by commas, so yours can sit beside one the client wants to keep. If a record still lists the NCSC Mail Check address, replace it: the address still accepts reports, but nothing reports back to you.

Expect the first reports within 24 to 48 hours. Reports come only from receivers that send them, on days they see the client's mail. A quiet day is not proof that nothing was sent. If nothing arrives after two days, check for a typo in rua=, a missing permission record or a change that never published.

Step 4: fix each client's senders

DMARC passes when SPF or DKIM passes for a domain aligned with the visible From address. Relaxed alignment, the default, accepts a subdomain such as mail.example.com for example.com.

Start with the mailbox platform. Microsoft 365 signs with the tenant's onmicrosoft.com domain until DKIM is enabled for the client's own domain, using the two CNAME records the tenant shows. Google Workspace needs a DKIM key generated, published and then switched on in its Admin console. Our guides to DMARC for Office 365 and DMARC for Google Workspace have the steps.

Then work through the other sources in the reports: marketing, CRM and helpdesk tools, invoicing and payroll services, website forms and scanners. Each needs one of three fixes:

• Aligned DKIM. Publish the vendor's DKIM record under the client's domain, so its signature carries d=example.com.
• Aligned SPF. Where the vendor allows it, set its bounce domain to a subdomain of the client's domain.
• A relay. Send through the mailbox platform, which then signs the mail itself.

Prefer DKIM. RFC 9989 section 7.4 says a domain at p=reject must not rely on SPF alone and must apply valid DKIM signatures. Forwarded mail also usually fails SPF but keeps its DKIM signature.

Do not paste every vendor into SPF either: SPF allows 10 DNS lookups, and a check that needs more returns an error, so even authorised mail can fail.

Reports name only the last server that handed the mail over, so a relay or signature service can hide the sender behind it. Our guide to understanding DMARC reports shows how to tie each source to a service.

Step 5: enforce on the reports, not the calendar

Move a domain to the next policy when its reports show every legitimate sender passing, not when a date arrives. RFC 9989 section 5.1.6 says legitimate mail that fails must be fixed before a domain moves to enforcement.

Use plain names with clients: monitoring only (p=none), send fakes to spam (p=quarantine) and refuse fakes (p=reject). Make the evidence window long enough to cover the client's monthly cycle: payroll, month-end invoices and any newsletter. A clean fortnight that misses the payroll run is not clean evidence.

v=DMARC1; p=quarantine; rua=mailto:client-a@reports.example.net
v=DMARC1; p=reject; rua=mailto:client-a@reports.example.net

Step the whole domain at once, and do not ramp with pct=. RFC 9989 removed it (Appendix A.6), and receivers on the older standard still apply a value below 100. That leaves part of the mail at the weaker policy. Leave sp= out, or set it to match p=, so subdomains move too.

Tell clients that p=reject asks receivers to refuse failing mail. RFC 9989 section 7.4 tells receivers to weigh it with their own analysis. It also says domains whose users post to mailing lists should not publish p=reject, because rejected list mail can get members unsubscribed.

Expect it to take time. Between the Q1 and Q2 2026 editions of our audit, 10 of the 192 MSPs moved their own policy forward and none moved back. Our none to reject guide covers each step in detail.

Step 6: control changes in DNS you do and do not host

Most steps above end in a DNS change, and you may not host every client's zone. Agree in each contract who may change the DMARC, SPF and DKIM records, and who tells whom.

Where you host the zone, treat a policy step as a normal change. Log the record before and after, get it approved, and avoid the client's busiest sending days. Lower the record's TTL a day ahead, so a rollback reaches receivers sooner. The rollback is the previous record, so keep it in the ticket.

Where the client, a web agency or the registrar hosts the zone, ask for delegated access or an API credential limited to that zone. Failing that, send the exact record text and confirm it with a lookup once it is live.

Then watch for drift. Website rebuilds, registrar transfers and well-meant edits can remove good records or add second ones. Two DMARC records at one name are both discarded, and two SPF records make receivers treat SPF as broken. Monitoring that alerts on DMARC policy and TXT record changes catches this when it happens, not at the next review.

How do you package and price DMARC as a managed service?

Build the price around your time: sender fixes, DNS changes, alert handling and reviews. The platform fee is the easy part to work out. A structure that maps to the steps above:

• Onboarding, a fixed fee per client: the inventory, reporting addresses, parked domains to p=reject and the first round of sender fixes.
• Monthly management, per client: report review, alert handling, enforcement steps and the quarterly review. Tier it by sending domains and senders, not total domains, because a parked domain at p=reject needs little upkeep.
• Change requests for work outside the scope, such as a new marketing platform, a rebrand or an acquisition.

Write the scope in plain terms. At enforcement, DMARC lets receivers block mail that uses the client's domain in the From address and fails authentication. It does nothing about lookalike domains or display-name tricks.

Do not sell it as a Cyber Essentials requirement either. The scheme does not mention DMARC, SPF or DKIM, as our guide to NCSC and Cyber Essentials email requirements explains.

What should clients see each quarter?

A short branded report that shows progress against what you sold. Use the same layout each quarter, so movement is easy to see. Cover:

• Each domain's policy now and a quarter ago, in plain names.
• The share of the client's mail that passed DMARC, overall and for each sender.
• Senders fixed this quarter, senders still failing and senders newly seen.
• Failing mail from sources the client does not recognise, with volumes.
• Alerts and DNS changes since the last review, and what you did about them.
• Next quarter's steps, with an owner and a date for each.

Add one line on coverage: the figures describe what reporting receivers saw, not every message sent as the client.

What should you look for in a multi-tenant DMARC platform?

Ask each vendor on your shortlist the same questions, in writing.

• Client separation. Does each client get its own space and reporting address? Can you remove one client and its data cleanly?
• Domain counting. Is it per domain, per brand or a pool? Do parked and defensive domains cost the same as sending ones?
• Adding domains in bulk. Can you add a list at once? Each domain still needs its own DNS change before reports flow.
• Client reports. What can you brand: logo, colours, footer, the vendor's name, the sending address? Is there a PDF for the review meeting?
• Alerts. Which changes raise an alert, through which channels, and to whom?
• Client access. Do clients log in, or do they receive reports? Decide which you want before you compare.
• Integrations. If you need PSA tickets or an API, ask to see them working during a trial.
• Data and terms. Where is report data held, for how long, and with which sub-processors? Are prices published, and in pounds?

Our guide to the best DMARC monitoring tools in 2026 compares seven named platforms on pricing, features and data residency.

Where ShieldMarc fits

Prices exclude VAT, and ShieldMarc Ltd is not VAT-registered, so checkout adds none.

• Price. £130 a month, or £100 a month billed annually (£1,200 a year), for 100 domain slots. Each extra 50 slots costs £40 a month, added through support.
• Brand-grouped slots. Domains that share the name before the TLD, such as example.com and example.co.uk, take one slot within an organisation. The same brand in two client organisations takes two.
• Client organisations and tags. The account owner can add a client organisation for each client, with its own reporting address, drawing on the plan's shared slots. The MSP Portfolio page lists them with domain counts, the share past monitoring only, an alert count and a status, sorted by risk. Alternatively, tag each client's domains within one organisation.
• Branded reports. Settings, Branding holds your logo, company name, accent colour, footer contact line. Reports for client organisations carry it, and a tag can add the client's own name, logo and accent colour. Only the MSP plan can remove the “Powered by ShieldMarc” line. Reports come as PDF and CSV with a 7 to 180-day lookback, so one can cover a quarter's DMARC figures for each domain. Scheduled reports go out daily, weekly or monthly from ShieldMarc's mailbox, with replies to the reply-to address you set in Branding.
• Alerts and readiness. Alerts go by email to verified recipients. They cover DMARC policy changes, changes to a domain's A, MX, TXT and NS records, DKIM keys removed, revoked or weakened, certificates and domains near expiry, and new lookalike registrations. A “looks ready” to-do needs a verified domain with reports from at least 14 days and 95% of its mail passing DMARC (98% before p=reject).
• Hosting. Customer monitoring data is EU hosted by default, apart from the archive copy of each report email in Cloudflare R2, and dedicated UK hosting is an enterprise option on request.

Our page on DMARC services for UK organisations sets out what the plans include and what they do not. Full prices are on the pricing page.

Frequently asked questions