DIY or managed DMARC? Compare the work behind the price

Publishing a record and running DMARC are different milestones

DMARC is a public email authentication standard, not one vendor’s paid product. A company publishes policy in DNS, and receivers use it alongside authentication results and their own handling rules. A management subscription is not a prerequisite for using the standard. The DMARC standard, RFC 9989 ↗

Still, “the record resolves” and “the company’s email environment is covered” are different findings. Employee mail may authenticate correctly while the external service sending your invoices remains unconfigured. Google’s rollout guidance explicitly calls for checking third-party senders. Google’s DMARC setup guidance ↗

The work should leave useful records: an inventory of sending services and their owners, evidence that legitimate mail was tested, investigations of unknown senders, and the old and new DNS values with approval history. The next administrator needs to know what changed, who approved it, and why.

Our RUA report guide explains what the data contains. Here, the question is who investigates and acts on what it shows.

Compare who does the work in each model

With DIY management, an internal owner chooses how to collect reports, interprets the results, and coordinates changes with sending providers and DNS administrators. Free checkers and open-source reporting software may help. Free software still requires time to install, maintain, and use in an investigation.

A reporting tool collects reports into a readable interface and helps compare authentication by sender or over time. It can reduce repetitive data handling. Someone still needs to verify whether the company actually approved a service shown on the dashboard. Also distinguish support that explains the interface from support that investigates your mail configuration.

A managed service assigns people to investigation, configuration guidance, and verification within an agreed scope. Products sold under that name can cover very different work. Do not assume a monthly report includes discussions with your CRM vendor or implementation of DNS changes; ask about each task.

Automatic identification and business approval are different decisions. Recognizing an IP as belonging to a known email vendor does not prove the company authorized the mail. Someone inside the business still has to confirm the purpose and responsible team.

Follow the work behind a month-end invoice

Fictional Gaon manages two domains and four sending paths: employee email, a sales CRM, website inquiries, and an invoicing service. One person handles IT. The following examples illustrate operating work and costs; they are not customer incidents or service results.

Month-end: establish that a failing invoice is legitimate

Before tightening policy, Gaon reviews month-end invoices. In a received copy, SPF and DKIM pass for the invoicing provider’s domain, while the visible From uses Gaon’s domain. DMARC fails. The administrator confirms the service with accounting and matches sending times to the provider’s logs. An unfamiliar IP does not go straight into SPF before its role is established.

In this example, the invoicing service supports company-domain DKIM. The administrator publishes the values issued for Gaon, enables signing, and sends a fresh invoice test. The received original must show the company-domain signature and a DMARC pass. Microsoft’s operational guidance also discusses this alignment problem with external senders. Microsoft’s guidance on external senders and alignment ↗

Under DIY management, the internal IT owner does this work. A reporting tool may make the failing source easier to find, but it does not automatically confirm accounting’s use of it or coordinate with the vendor. Under a managed contract, the provider may handle the technical investigation while Gaon confirms use and approves changes. In every model, completion requires a verified test message as well as a successful DNS lookup.

CRM replacement: open the new path and retire the old one

Adding the new CRM’s name to a list is not enough. Check whether quotes, individual sales messages, and automated follow-ups use the same path, then test the actual workflows. Advance notice from the sales team makes that possible before launch. Discovering the service in reports after it starts sending is a late start.

After the switch, check the old CRM for scheduled sends and retries. Review dependencies before removing unused sending permissions and DNS entries, and record why they were removed. A service quote should account for retiring old senders as well as adding new ones.

Staff handover: keep the investigation from starting over

If reports and support replies live only in the outgoing employee’s mailbox, the new owner may have to reconstruct the setup. Hand over a shared sender inventory, DNS history, vendor contacts, and an alternate approver. A managed service still needs a named company contact; otherwise, change approvals can stall.

Decide which work your team can own

The deciding factors are often how much the mail environment changes and who has time to handle it, rather than employee count. A small company that frequently changes external services can generate substantial work. A larger, stable environment with a clear operating process may be manageable internally.

DIY management fits when the team can explain its approved senders, inspect DNS and headers, test before changes, and act when something fails. Schedule regular reviews and a backup owner. Running DMARC internally can be a sound choice.

A reporting tool fits when the team can make technical decisions and work with providers but spends too long collecting and comparing reports. During a trial, test whether you can find a newly appearing path, export its evidence, and compare it with earlier results. The number of charts is less useful than those tasks.

A managed service fits when there are many senders or frequent changes, too little time to investigate, or several vendors to coordinate. The company still decides whether a sender is authorized, whether its work can pause, and when changes are acceptable. Completing a sender inventory makes the support scope easier to define.

Domain count is only one part of a quote

Two companies with one domain can have very different workloads. One may use only employee email; another may have separate sending services in several departments. Ask for the charging basis and the actual work included. “Management included” does not make two proposals equivalent.

If pricing uses message counts, ask whether that means total company sends, messages observed in reports, or data processed. Unexpected traffic or seasonal increases can affect costs differently under each model. Check whether exceeding a limit stops collection or creates extra charges.

EasyDMARC’s public vendor-selection guide also discusses report analysis, support, integrations, and pricing considerations. It is vendor-authored material, useful for finding questions missing from a proposal rather than establishing which provider is best. EasyDMARC’s vendor-selection guide ↗

Include internal time in the cost comparison

Total operating cost combines the subscription with work the company still has to do. Separate the first year’s setup from later maintenance too. Omitting one proposal’s setup fee or treating time spent on a free tool as free makes the comparison misleading.

First-year total cost
= External implementation and onboarding fees
+ Annual subscription and out-of-scope support
+ Internal hours × the company’s hourly cost assumption
+ Separate infrastructure, storage, and migration costs

For later years, remove initial tasks that will not recur and recalculate.

Count an employee’s setup time once under internal hours. Keep it distinct from external implementation fees so the same work is not accidentally charged twice in the calculation.

Suppose Gaon estimates the following first-year DIY workload. The hours and the rate of KRW 50,000 per hour are fictional internal cost assumptions. They illustrate the arithmetic, not market prices, provider quotes, or typical working hours. The figures remain in Korean won (KRW); no currency conversion is implied. Replace them with your own time records and costing method.

Now make a second explicit assumption: after reviewing a particular managed service’s division of work, Gaon expects to retain 28 internal hours in the first year. That costs KRW 1,400,000, a difference of KRW 1,800,000 from DIY. If other external costs and quality are equal, compare the provider’s first-year charges with that difference. Include setup and additional support as well as monthly fees.

This does not claim that every company saves 36 hours by using a service. If approvals and vendor checks all remain internal, retained time may be much higher. Evaluate a reporting tool the same way: separate time saved on aggregation from investigation that still has to happen.

Nor is KRW 1,800,000 necessarily cash saved in a bank account. It may represent existing employees having time for other work. If you want to assess fewer incidents as a benefit, use your own incident records separately. Unsupported probabilities and dramatic loss amounts do not make a cost comparison more reliable.

Ask about approval, recovery, and leaving the service

A demo makes it easy to see a dashboard working normally. A proposal should also explain what happens when mail breaks or the contract ends. Written answers reduce the chance that both parties assume the other owns a task.

Who changes DNS, and who approves it?

Establish whether the provider supplies values for your team to apply or makes changes through restricted access. Assign ownership of the old value, reason, approval, application time, and verification record. Keep control of domain ownership and DNS access within the company, and avoid granting broader access than the work requires.

What happens if legitimate mail stops arriving?

Replace “fast support” with specifics: working hours, an urgent contact route, first-response terms, investigation scope, and the person authorized to approve recovery. Acknowledging a ticket and restoring delivery are different milestones. If another provider must act, establish who contacts it and what evidence is supplied.

Recovery does not automatically mean switching the entire domain to p=none. Choose a response based on the cause and impact. If you roll back a value, record it and the conditions for restoring the policy. DNS caches also mean a reverted record may not reach every receiver immediately, so verify actual sending. Our DMARC policy guide covers these decisions.

Which data is retained, where, and for how long?

Ask separately about raw reports, processed aggregates, sender names your team adds, and change history. If support collects headers or logs, confirm access and deletion arrangements. “Export available” is not enough: check the format, date limits, charges, and a sample export you can actually use.

Can the next owner continue after the contract ends?

Export approved senders and operating records before cancellation, and plan a new reporting destination. Check any required authorization for external report delivery and confirm that collection actually works. Do not assume historical data transfers automatically to the next service. EasyDMARC’s migration guidance likewise recommends preserving needed history before cancellation. Preserving records during a DMARC provider migration ↗

The migration differs depending on whether the provider only receives reports or also hosts services used by SPF and DMARC records. In the latter case, prepare replacement records and a sequence first. Keep functioning authentication in place through the transition, verify collection and sending in the new setup, then remove unused dependencies.

Prepare four things before a conversation with a provider

You do not need a perfect technical document. Start with your domains, services that send using company addresses, current problems, and work your team can own. That is enough to make the discussion about scope concrete.

Domains: Separate active sending domains from domains held only
Sending services: Employee mail, CRM, invoices, contact forms, and others
Current problems: Full bounce responses, authentication failures, new services
Internal responsibilities: DNS changes / report analysis / vendor coordination
Support needed: Initial setup / regular review / changes and incident investigation
Planned changes: Service replacements, new domains, staff handovers

Genharden DMARC gives every plan, Free included, the report address, sender identification, daily DNS checks and next-step guidance. Plans differ in limits such as domains and history and in some features, such as encryption checks of mail servers you run yourself; what each plan includes and its price are on the pricing page. Managed, where our team sets it up and runs it, is scoped and quoted for your environment.

If bounces or spam placement are already a problem, gather evidence using the bounce investigation guide and the guide to authenticated messages landing in spam. A useful proposal should make clear which work you are buying and what evidence will show it is complete.