A DMARC proof of concept should test whether your team can investigate senders, review a proposed remediation, and verify an approved change with the product. Define the evidence required for acceptance before the pilot starts, including what would justify extending or rejecting it.

If you are still choosing vendors, start with the DMARC software evaluation checklist. This article begins after the team has agreed on a vendor and a test scope.

This pilot plan is written by Palisade and can be applied to any DMARC vendor. Its acceptance criteria are a proposed evaluation method, not results from a customer deployment.

Choose a representative scope

Select a domain you are authorized to evaluate and identify the people responsible for its DNS and sending applications. Include a normal employee-mail path and a business application relevant to the purchase. Where possible, include a source that still needs investigation.

Record the domain's existing policy and reporting configuration before making changes. Agree on whether the pilot is observation only or includes a specific approved remediation. Purchasing software and changing enforcement are separate decisions; a useful pilot can conclude without changing the DMARC policy.

Choose the observation period around actual sending activity. A service used for a monthly process may not appear in a short pilot. Record which business cycles were covered and which were not, rather than interpret a quiet period as proof that the service is unused.

Establish the starting evidence

Save the initial DNS values and the time they were collected. Record when reports begin arriving and which reporting sources are represented. Keep a list of expected applications supplied by their business owners so you can compare expected activity with observed activity.

Use Microsoft's DMARC guidance for the Microsoft 365 deployment context. When checking a sample message, distinguish authentication results from alignment with the visible From domain. A DMARC pass can come from an aligned SPF pass or an aligned DKIM pass; a passing authentication result without the required alignment is insufficient. The DMARC specification, RFC 9989, defines this identifier-alignment requirement.

Document gaps as gaps. Missing reports, an application that has not sent during the test, or a sample message that cannot be obtained can limit the conclusion without proving that the product failed.

Testing whether your team can resolve an unknown sender

For an internal IT team using Microsoft 365, an unresolved source is a useful pilot scenario. The buying question is whether the product helps an administrator gather enough evidence to make a defensible decision, and how much work remains with the team.

Use the unknown-sender investigation guide to define the evidence you will collect. Record a business owner and purpose, relevant report observations, a delivered-message sample where available, and the sending platform's configuration. An inconclusive result is appropriate when the evidence is incomplete.

The Domains overview in Palisade below shows the source-level reporting view used as a starting point. Test the remaining steps in your own pilot. The documented remediation workflow explains how an issue becomes a ticket; it does not replace your acceptance test.

Domains overview in Palisade showing sending sources and their DMARC, SPF, and DKIM results

Real Palisade product capture from the demo environment, showing the July 3 through 16 period. The displayed figures are illustrative product data, not a customer's measured outcome.

Run four acceptance tests

1. Can an administrator investigate a source?

Ask an administrator to open one observed source and explain how it was identified. Save the report evidence, the business owner's confirmation where available, and the remaining uncertainty. If the product only identifies a sending platform, your team may still need to establish which account or department uses it.

Palisade's Senders List documentation describes pending, confirmed, and discarded sources. The page requires DMARC monitoring and incoming reports. During a Palisade pilot, test both the source review and the availability of evidence behind your decision.

2. Can the team review a proposed fix?

Choose a genuine issue within the approved scope. Ask the vendor to explain the proposed record or configuration change, its prerequisites, and how the team will verify the result. Record how much administrator work this takes, using your own start and finish points.

For Palisade, the authentication remediation guide is a starting point for the walkthrough. A generated recommendation is an intermediate result. Acceptance requires the reviewer to understand why the change applies to the observed issue.

3. Can the correct person approve and verify the change?

If deployment is in scope, test only the agreed change through the authorized path. Preserve the prior value and a rollback procedure before publishing. Afterward, record the resulting DNS state and verify the relevant application behavior.

Palisade's DNS connection documentation describes publishing after approval. Verify the actual permission scope and zone access used in your pilot. If the team will publish manually, test that handoff instead.

Palisade also documents DNS History snapshots and record comparisons. Use available history as supporting evidence. Confirm separately whether your organization needs actor attribution, approval records, or export features beyond the documented snapshot fields.

4. Can another administrator continue the work?

Hand the evidence to a second administrator. Ask them to explain what changed, which questions remain open, and where they would look if the sender fails again. Keep the ownership record in your existing service desk if the evaluated product does not provide the fields you need.

This tests the operating process your team will inherit. A product can make investigation easier while leaving some coordination work outside the platform.

Write a defensible pilot result

Use a short record for each scenario:

Field	What to record
Scenario	Domain, sending service, business purpose, responsible owner
Observation	Reporting dates, sample evidence, expected activity not covered
Work performed	Investigation, proposed fix, approval, publication, verification
Result	Passed, failed, or inconclusive, with a reason
Remaining dependency	Owner confirmation, missing activity, permission, or product requirement
Decision	Accept, extend the specific test, or reject the fit

Avoid a universal pass-rate threshold. Your acceptance decision needs to account for the legitimate senders in scope, unresolved dependencies, and the business impact of a mistake. A calendar deadline alone does not establish readiness for stricter enforcement.

If you measure time saved, use comparable tasks and disclose the conditions. A single administrator's pilot result is useful to that buying team; it does not establish a general performance claim for every customer.

What should happen after the pilot?

For an accepted pilot, assign the remaining applications and domains to a rollout owner and agree on change review responsibilities. For an inconclusive pilot, extend the missing scenario rather than repeat the entire demonstration. For a rejected fit, preserve the evidence so the next vendor is tested against the same requirement.

Review your pilot scenario in a demo

Bring the domain scope, one unresolved sender, and the acceptance criteria your team needs to satisfy. Ask to see the investigation, proposed remediation, and approval steps before deciding which changes belong in the pilot.

Book a demo to discuss the pilot workflow. Your team remains responsible for approving any DNS or policy change.

DMARC Proof of Concept: A Pilot Plan for Internal IT