DMARCGuardian Practical help for DMARC, SPF, DKIM, and BIMI.

Blog · Dmarc

The DMARC Onboarding Workflow for MSPs: From Discovery to p=reject

By DMARCGuardian Editorial Team ·

The DMARC Onboarding Workflow for MSPs: From Discovery to p=reject

Most DMARC disasters start the same way: someone enables p=reject without knowing what the domain is actually sending. For MSPs managing dozens of client domains, that mistake does not just break one inbox -- it creates an emergency call on a Friday afternoon.

The fix is a repeatable onboarding process that works regardless of whether your client uses Exchange Online, Google Workspace, a legacy SMTP relay, or all three at once. This is that process.

---

Why MSPs need a DMARC onboarding process

When you take on a new client, you audit their firewalls, their endpoint protection, their backup status. DMARC should be on that list. A domain without DMARC is a domain that can be spoofed on any mailing list, any forwarded message, any compromised internal tool.

But DMARC is unlike most security controls because enabling it incorrectly does not create a vulnerability -- it creates an outage. If you set p=reject before knowing what the domain sends, you will block legitimate email. Every MSP who has been through that call learns the same lesson: discovery first, policy second.

---

Step 1: Discover the client's sending infrastructure

Before you touch DNS, understand what the domain is actually used for.

Ask the client:

  • What email services do you use for sending? (Include marketing platforms, CRM systems, billing software, internal SMTP servers.)
  • Do any third parties send email on behalf of your domain? (Vendors, partners, SaaS tools with custom-domain sending.)
  • Are there any internal mail relays or devices that send server-to-server email?
  • What is the primary email platform for your users?

The answers tell you how many sending sources you need to account for. A client with one Exchange Online tenant and nothing else is a two-week onboarding. A client with Salesforce, Marketo, Zendesk, two SMTP relays, and a legacy ERP system is a two-month onboarding.

Do not skip this step. You cannot build an accurate DMARC policy if you do not know what is supposed to be sending.

---

Step 2: Audit existing DNS records (SPF, DKIM, DMARC)

Run a DNS lookup on the client's primary domain and check three records:

SPF record

Look for the TXT record at the root of the domain. Count the number of include: mechanisms. A healthy SPF record for most small businesses has fewer than ten includes. Records with twenty or more are fragile and commonly cause authentication failures when any single vendor changes IPs.

If there is no SPF record at all, that is a finding. SPF is not strictly required for DMARC alignment, but without it you have no sender authentication and you are relying entirely on DKIM.

DKIM record

Check for a CNAME or TXT record at selector._domainkey.yourdomain.com. A selector that exists and matches the selector published in email headers means DKIM signing is configured. If you see no DKIM record, the domain is not signing outbound email -- this is common for clients who have never set it up.

DMARC record

Look for a TXT record at _dmarc.yourdomain.com. If one exists, read the policy tag:

  • p=none means the domain is publishing DMARC but not enforcing it. This is the starting point.
  • p=quarantine means the domain wants suspicious mail quarantined. Rare as an initial setting.
  • p=reject means the domain is enforcing. If you see this on a new client, do not touch it until you have completed the audit. Someone may have enabled it by accident.

If no DMARC record exists, the domain has no DMARC posture at all. You are starting from zero.

Document what you find. This audit becomes part of the client record.

---

Step 3: Set an initial DMARC policy (p=none)

The first DMARC record you deploy should always be p=none.


v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; pct=100;

What each part does:

  • v=DMARC1 -- version, required
  • p=none -- monitor only, no action taken on failures
  • rua -- aggregate report destination (a mailbox the MSP controls, not the client)
  • pct=100 -- apply to 100% of messages (you can lower this during testing if needed)

The ruamailto address is important. Those reports go to a mailbox you control, not the client's IT team. If you send them to postmaster@clientdomain.com, you will have an incident when someone leaves the company and the mailbox gets deleted.

Do not add sp=none or pct=50 in the initial record unless the client specifically asks for a constrained rollout. Simpler is better at this stage.

---

Step 4: Read aggregate reports and identify legitimate senders

After deploying p=none, you wait. DMARC aggregate reports arrive daily, typically within 24-48 hours depending on the receiving domain's report frequency. Some large receivers (Gmail, Yahoo) send reports daily. Many domestic ISPs send weekly or not at all.

The reports tell you which servers are sending email purporting to be from the client domain and whether they pass or fail SPF and DKIM alignment.

Your job during this phase is not to fix failures. Your job is to build an inventory of legitimate senders:

  • Which IPs are authorized senders (they should pass SPF)?
  • Which DKIM selectors are in use (they should pass DKIM)?
  • Which IPs appear in reports but are not in the SPF record (a finding)?
  • Which IPs pass SPF but fail alignment (usually a forwarding or mailing list issue)?

If the client's email stack is simple, this phase takes one or two report cycles. If the client has fifteen third-party senders you did not know about, this phase takes longer.

The goal is a complete picture of what legitimate mail looks like before you start blocking anything.

---

Step 5: Resolve conflicts before moving to p=reject

Every failure source in your aggregate report needs a resolution before you touch the policy.

Common failure types and what to do:

Unauthorized senders found

If you find an IP sending mail from the client's domain that is not in the SPF record, first determine if it is legitimate. It often is -- a vendor the client forgot to tell you about, a internal server someone installed last year, a cloud function with its own SMTP relay. Add it to the SPF record if it is legitimate. Remove or block it if it is not.

SPF alignment failures (forwarding)

Forwarded email breaks SPF at the receiving side because the forwarding server's IP replaces the original sender's IP in the envelope. The message may still pass DKIM if the original sender DKIM-signed it correctly. In this case, DMARC fails because the RFC5321.MailFrom domain (the envelope sender) does not match the RFC5322.From domain (the visible From header).

Solutions: ARC (Authenticated Received Chain) can help here if the forwarding chain supports it. For mailing lists, setting ruf= with an mla= tag or using a third-party aggregation service can preserve authentication through forwarding.

Third-party senders without alignment

A very common finding: the client's CRM, billing system, or marketing platform sends email from @sendgrid.net or a similar shared infrastructure. This fails DMARC because the From domain does not match. These senders need to either send from the client's domain with proper DKIM signing, or be explicitly whitelisted in your understanding of acceptable mail.

DKIM failures

If legitimate senders are failing DKIM, the most common cause is the DKIM selector not being included in the sending domain's DNS, or the selector pointing to a key the sender is no longer using. Fix the DKIM configuration on the sending platform.

Do not move to p=reject until the failure sources in your aggregate report match your known inventory of legitimate senders.

---

Step 6: Move to p=reject safely

When the aggregate reports show zero or near-zero unauthorized sources, it is time to move to p=reject.

The safe progression is:

1. Confirm your DKIM signing is active for all primary sending domains
2. Confirm your SPF record includes every legitimate source
3. Change p=none to p=reject
4. Wait for the first aggregate reports after the change
5. If you see unexpected failures, roll back to p=none immediately and investigate

The rollback option is not a sign of failure. It is a sign of due diligence. Rolling back is faster than explaining to a client why their vendor invoices stopped arriving.


v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; pct=100;

A note on timing: most MSP engagements for a small business with a straightforward email setup reach p=reject readiness in three to six weeks. Complex environments with many third-party senders can take two to three months. Promising a client p=reject in one week is a lie unless you have already done this audit.

---

Step 7: Set up ongoing monitoring per client domain

This is where most MSP onboarding processes end. They deploy DMARC, they reach p=reject, they move on. Then something breaks six months later when the client adds a new SaaS tool and nobody updates the SPF record.

Ongoing DMARC monitoring means:

  • Reviewing aggregate reports weekly, not just after a change
  • Tracking new senders that appear in reports
  • Alerting when DMARC failures spike above a baseline threshold
  • Re-auditing DNS records whenever the client's email infrastructure changes

For MSPs managing dozens of client domains, reviewing each client's DMARC reports manually does not scale. A centralized DMARC monitoring platform that aggregates reports across all client domains and surfaces actionable failures is the practical solution. DMARCFlow is built for exactly this: you add a client's domain, point the DMARC rua destination at DMARCFlow, and get per-domain failure visibility without collecting any client credentials.

This is the MSP-specific advantage. Your clients get enterprise-grade DMARC monitoring. You get a single dashboard covering every domain you manage. Neither side has to share passwords.

---

DMARC onboarding checklist

Use this checklist for every new client DMARC engagement:

  • [ ] Inventory all email sending sources (internal and third-party)
  • [ ] Audit current SPF record (check include count, total DNS lookups)
  • [ ] Audit DKIM signing status (selector present, key active)
  • [ ] Check existing DMARC record (if any) and note the policy
  • [ ] Deploy initial DMARC record with p=none and MSP-controlled rua
  • [ ] Wait for first aggregate reports (24-48 hours minimum)
  • [ ] Build sender inventory from aggregate report data
  • [ ] Add any missing legitimate senders to SPF record
  • [ ] Fix DKIM configuration for any failing legitimate senders
  • [ ] Resolve or document any remaining unresolved failures
  • [ ] Change policy to p=reject
  • [ ] Monitor first post-reject reports for unexpected failures
  • [ ] Set up ongoing aggregate report monitoring (centralized preferred)
  • [ ] Document the final DNS configuration for the client record

---

FAQ

How long does DMARC onboarding take for a typical client?

For a small business using only Exchange Online or Google Workspace, three to six weeks from discovery to p=reject. For a client with multiple third-party senders, legacy SMTP relays, or a history of ad-hoc IT changes, expect two to three months. The variation is always in the aggregate report review phase.

What happens if a client has third-party senders we did not know about?

You find them in the first aggregate reports. This is why you start with p=none -- those reports reveal senders that are not in your inventory. Add the legitimate ones to your SPF record and DKIM configuration. Remove the illegitimate ones or flag them as a security concern.

Can we move to p=reject faster if the client has simple email infrastructure?

Yes, if the client's only sending source is their primary email platform (Microsoft 365 or Google Workspace) with no third-party senders, you can often reach p=reject readiness in two to four weeks. You still need aggregate report data to confirm. There are no shortcuts to the report review.

What SPF mechanisms cause the most DMARC failures during onboarding?

include: mechanisms pointing to large third-party platforms are the most common source of instability. When a vendor changes their SPF includes, your record can exceed the 10-lookup DNS ceiling and silently break. ~all (softfail) instead of -all (fail) in your SPF record masks these breakages instead of surfacing them. During onboarding, watch for SPF mechanisms that reference platforms not in your sender inventory.

How do we monitor multiple client domains without collecting their login credentials?

You do not need client credentials for DMARC monitoring. DMARC aggregate reports are sent to an email address you control, configured in the DMARC record itself. When you deploy a DMARC record for clientdomain.com with rua=mailto:your-msp@your-domain.com, all aggregate reports for that domain arrive in your inbox. No client login required. A centralized monitoring platform like DMARCFlow extends this further, parsing and alerting across all your client domains from a single pane of glass.

---

This workflow applies to MSPs onboarding new client domains to DMARC. It covers the discovery, audit, policy progression, and ongoing monitoring phases. If you are looking for a tool that handles the monitoring and alerting across all your client domains without requiring credential sharing, see DMARCFlow.