Safeguard 9.5 Implement DMARC: requirements and evidence

What Safeguard 9.5 DMARC requires and why it is hard to finish

If an assessment or customer questionnaire has flagged Safeguard 9.5 as a gap, the request is usually to show that your domains publish a DMARC policy and that someone verifies it. Safeguard 9.5 asks for exactly that, built on the Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). SPF records name the servers allowed to send for a domain, and DKIM adds a cryptographic signature to messages. DMARC ties the two together and tells receiving mail servers what to do when a message fails both checks and does not align with the visible From domain. Without it, anyone can send an email that displays your domain in the sender line, which is how payment redirection, credential phishing and executive impersonation usually begin. Note that 9.5 sits in Implementation Groups 2 and 3, not IG1, so an IG1-only program may legitimately omit it, but a regulated enterprise or one that holds sensitive data is expected to have it.

The difficulty is rarely the DNS record itself. The first obstacle is unknown sending sources. Marketing platforms, billing systems, ticketing tools, HR systems and scanners often send mail as your domain, and each one must appear in SPF or be signed with DKIM before DMARC can pass. Confirm this by reviewing the aggregate reports (rua) that receiving providers return after you publish a monitoring policy, and by matching the source IPs against your software and service inventory, which is the reason the CIS Controls Assessment Specification treats the software inventory of Safeguard 2.1 as a prerequisite. The second obstacle is third-party senders. Each outside provider needs its own DKIM key or SPF entry, and you need a named owner who can confirm it, change it and remove it when the contract ends. The third obstacle is the move from monitoring to enforcement. A policy of p=none collects data without affecting delivery, but it does not reduce spoofing. Moving to quarantine or reject can silently block legitimate mail that was never inventoried, so the step should follow a period of clean reporting, a sender-by-sender remediation list and a rollback plan. Ask your team to document who approves each policy change, what evidence shows that legitimate mail passes, and how the result is reviewed. Those records are what an assessor will ask to see.

Which domains, senders and teams fall under DMARC scope

Safeguard 9.5 is only as complete as the list of domains and senders it covers. The cards below cover the scoping choices that decide how much work DMARC becomes, from the domains you own to the platforms and teams that send mail on your behalf.

Every domain you own

Start with the full set of domains the enterprise registers, including legacy brands, acquired companies and domains held only for defensive purposes. Each domain that could be used in a spoofed message needs a published policy, even if it never sends mail. Ask the domain registrar and the DNS provider for a complete export, because the registrar record is often the only place unused domains appear. An unmanaged domain is a common route for impersonation that DMARC cannot protect if no one publishes a record for it.

Subdomains and their inheritance

A DMARC record on the organizational domain applies to subdomains unless a subdomain has its own record, so the subdomain policy can quietly differ from the parent. Decide which subdomains send mail, which only receive it, and which should be set to reject unauthenticated mail. Check that any subdomain that sends mail has SPF and DKIM configured before the policy is tightened. A single unmanaged subdomain that sends mail can block a move to enforcement.

Marketing and transactional senders

Email marketing platforms, billing systems, support desks and HR tools often send from the corporate domain using their own servers. Each sender needs SPF authorization or DKIM signing with a key under the enterprise domain before enforcement, or its legitimate mail will be rejected. Build a table of each third-party sender, the subdomain it uses, the authentication method it supports and the owner who can change its configuration. This table is the most common source of delay in DMARC projects.

Network asset class ownership

Safeguard 9.5 is classified under the Network asset class, so it needs a named owner who can change DNS records and mail gateway settings. In many organizations DNS sits with network or platform teams, while mail routing sits with messaging or IT operations. Confirm in writing who approves record changes, who receives aggregate reports and who responds when a sender fails authentication. Without a clear owner, the policy often stays at monitoring mode indefinitely.

Software inventory as a sender prerequisite

Safeguard 2.1, the software inventory, is a prerequisite for measuring Safeguard 9.5 because it helps the enterprise find the mail-sending software and services it actually runs. Inventory mail servers, relays, scanners, self-hosted applications and SaaS tools that send messages, not only the email client on user devices. Compare that list against the DMARC aggregate reports after publishing a policy, since unfamiliar sources in the reports usually point to a sender missing from the inventory.

Scope for IG2 and IG3 enterprises

Safeguard 9.5 applies from Implementation Group 2 upward, so IG1 enterprises are not required to meet it under the Controls. Organizations that are not yet in IG2 still benefit from scoping their domains, because the same inventory supports phishing defense and later assessments. Confirm with the assessor and your contracts which Implementation Group applies to your enterprise, since regulators or customers may ask for DMARC even when the Controls do not.

How an assessor tests DMARC usage under the CAS

This table shows how an assessor is likely to approach the DMARC usage metric for Safeguard 9.5, with the evidence each element calls for and the findings that commonly hold up a result. The CAS defines what to measure, not how, so confirm the exact test steps and sampling with your assessor before you collect evidence. Read each row as a question to answer with records and reports, not as a checkbox.

Assessment element	What the assessor looks for	Evidence and common findings
Measures and metric	Six measures for Safeguard 9.5, combined into one DMARC usage metric	Ask the assessor which measures apply to your domains and how the combined result is scored
Domain scope	Every domain and subdomain that sends or could send email under the enterprise name	Domain inventory, including parked and unused domains. Common finding: forgotten domains with no DMARC record
Published DMARC record	A DMARC TXT record at _dmarc for each in-scope domain, with a policy tag	DNS record exports and dated lookups. Common finding: records missing on subdomains that send mail
Policy progression	Whether the policy is moved toward enforcement over time and the reasons for each step	Policy change history and approvals. Common finding: p=none held indefinitely with no reporting review
Aggregate reporting	Whether DMARC aggregate reports are received, parsed and acted on	Report mailbox or tool configuration and review records. Common finding: reports arrive but nobody reviews them
SPF and DKIM foundation	Valid SPF and DKIM configuration for each sending source before DMARC is enforced	SPF and DKIM records, selector list and signing configuration. Common finding: SPF lookup limits exceeded or DKIM signing missing on a third-party sender
Sender coverage	Whether every legitimate sending service is identified and aligned with SPF or DKIM	Sender inventory from report data. Common finding: unmanaged senders such as marketing platforms or ticketing tools failing alignment

How to roll DMARC out from SPF and DKIM to enforcement

The sequence moves from knowing which systems send mail for your domains, to aligned SPF and DKIM, to a monitoring DMARC record, and only then to a stricter policy. Each step produces evidence an assessor can inspect, so the enforcement decision rests on data rather than assumption.

Inventory every system that sends mail for your domains
The mail team, with help from the owners of marketing platforms, ticketing tools, HR systems, scanners and application servers, lists each service that sends email using your domains. Start from DNS records and mail gateway logs, then confirm each sender with its owner. The output is a sender register that names the service, the domain it uses, the authentication method it supports and an accountable owner. This register also supports the software inventory relationship noted in the CIS assessment specification, since Safeguard 2.1 is listed as a prerequisite for measuring Safeguard 9.5.
Publish and align the SPF record
Consolidate the authorized senders into one SPF record for each domain, keeping it within the lookup limits defined in the SPF standard, and end it with a clear all mechanism that matches your intent. Verify the record with a DNS lookup tool and test each sender against it. The output is a published SPF record per domain, plus test results showing that every sender in the register passes SPF for its envelope domain. Senders that fail go back to the owner before you move on.
Enable DKIM signing on each sending service
Ask each sending service owner to sign outbound mail with a DKIM key tied to your domain. Publish the public keys as DNS records under selectors that identify each service, and rotate keys on a schedule your team sets. The output is a DKIM signature on messages from every sender in the register, which you confirm by inspecting message headers from test sends. Record which selector and key belongs to which service so later reports can be traced back to an owner.
Publish a monitoring DMARC record
Publish a DMARC record at the domain's _dmarc subdomain with the policy set to monitor only, which collects reports without changing how receiving servers treat mail. Name a mailbox or reporting tool to receive aggregate reports, and include a forensic reporting address only if your privacy review allows it. The output is a live DMARC record for each domain in scope, with the reporting address documented. Confirm the record parses correctly with a DMARC checker before you rely on it.
Review aggregate reports and identify unaligned senders
Collect the XML aggregate reports sent by receiving mail systems and process them with a parser, either a commercial tool or an open-source one run inside your environment. Group results by source IP and by sending service, then flag any stream where SPF or DKIM fails alignment with the From domain. Keep the monitoring period long enough to cover your normal mail cycles, which is a judgment for your team to document. The output is a dated analysis showing pass and fail rates by sender, which becomes the main evidence that the sender inventory is complete.
Fix unaligned senders and retest
For each failing stream, the owner either corrects the configuration, such as adding the service's domain to SPF or enabling DKIM with your domain, or removes the sender. Record each change in the sender register with the date and the person responsible. Repeat the report review until the legitimate streams pass and the remaining failures are sources you have decided to block or cannot yet fix, with that decision written down. The output is a closed exception list with a justification for each unresolved source.
Move the policy toward enforcement
When the reports show legitimate mail aligning consistently, change the DMARC policy from monitor only to quarantine, then to reject, as your risk assessment allows. Review reports again after each change, because a sender missed in the inventory will now be affected. Keep the monitoring record, the sender register and the exception list together as the evidence package. The output is an enforced DMARC policy on each domain, supported by a dated history of policy changes and report reviews. Confirm with your mail administrators and your auditor how they want that history presented.

How the DMARC usage metric reads a domain set

A DMARC record with the policy set to p=none shows that a domain publishes a DMARC record and asks receivers to send reports about mail that claims to come from it. It does not prove that forged mail is blocked, because receivers still deliver messages that fail alignment. An enforced record uses p=quarantine or p=reject, which tells receivers to act on failing mail. Confirm with the assessor whether a monitoring-only record counts toward the DMARC usage metric and whether it can stand alone. Before moving from monitoring to enforcement, check that legitimate senders such as marketing platforms, ticketing tools and invoicing services pass SPF or DKIM with alignment, because enforcing too early can block genuine business mail.

Aggregate reports are the core evidence for this Safeguard. The rua tag in each record names where receivers send those reports, and the XML files show which sources sent mail as the domain, whether SPF and DKIM passed and how alignment turned out. An assessor can compare this data with the software inventory from Safeguard 2.1, which the CIS Controls Assessment Specification identifies as a prerequisite for measuring Safeguard 9.5. An unknown sending service appears in the reports as a failing source, and the team must either authorize it or retire it. Keep the reports for the assessment period, record who reviews them and document the outcome for each unexplained source. Confirm that the mailbox receiving reports is monitored and that any report-processing tool is itself documented.

Coverage is judged per domain, so the assessor will ask about every domain and subdomain the enterprise sends from or could be spoofed from. Illustrative example: an organization enforces a strict policy on its primary domain, but an older subdomain used by a sales tool has no record of its own and no subdomain policy. Subdomains inherit the parent policy unless the sp tag sets a different one, so check how inheritance applies to each name instead of assuming it. Parked domains that send no mail still need a record that rejects mail, and the registry inventory should capture them. Ask the assessor how partial coverage is scored, and keep a domain register that marks each domain as enforced, monitored or unused.

Evidence that passes a DMARC assessment

An assessor testing Safeguard 9.5 looks for proof that DMARC is published, that it is backed by working SPF and DKIM, and that someone reviews the results and acts on them. The cards below cover the artifacts that show this, and how each one stays current between assessments so it is not rebuilt the week before an audit.

DNS zone exports and records

Export the DNS records for every sending domain and keep dated copies. The export should show the SPF TXT record, each DKIM selector public key published under the _domainkey label, and the _dmarc TXT record with its policy tag. Assessors compare these exports against the sender inventory, so a record that exists in DNS but has no owner or sender behind it is a finding. Re-export after every DNS change and on a fixed schedule, and store the copies outside the DNS provider's console.

DMARC aggregate and forensic reports

Keep dated summaries of the aggregate (RUA) reports that receiving mail servers send back, along with any forensic (RUF) reports the organization chooses to receive. The summary should show message volume per sending source, the share that passed SPF and DKIM alignment, and the sources that failed. A summary with no failures can be as much of a concern as one with many, because it may mean the reports are not being read. Record who reviewed each summary and what was done about each failing source.

Sender inventory with owners

Maintain a list of every service that sends mail on behalf of the organization's domains, including marketing platforms, ticketing systems, payroll, and scanners or copiers. Each entry needs a named owner, the domain it sends from, the SPF include or DKIM selector it depends on, and the date its configuration was last confirmed. This is the document that links DMARC reports to accountable people, and Safeguard 2.1 software inventory data is often the starting point. Update it when a sender is added, retired or moved.

Change records for policy moves

Record each change to the SPF, DKIM or DMARC policy with the date, the requester, the reason, the approver, and the expected effect. A move from monitoring (p=none) to quarantine or reject is the change that most often blocks legitimate mail, so keep the report data that justified it and the rollback step. Assessors look for evidence that policy tightening followed measured results rather than a one-time decision. Link each change record to the reports reviewed before it.

Review cadence record

Keep a dated log showing that DMARC reports were reviewed on a defined schedule, who performed each review, and what they found. The cadence should be written down in the organization's policy or procedure, and the log should show the schedule was followed, including reviews during staff changes. A gap in the log is the most common reason an otherwise well-configured domain fails to show ongoing operation. Confirm the cadence with the control owner before the assessment begins.

Keeping evidence current

Assign one owner to the evidence set and schedule the exports, report summaries and inventory reviews as recurring tasks rather than audit preparation. Store dated copies in a system with access control and retention that matches the assessment period, and confirm the retention length with the assessor or the control owner. Run a short internal check against each artifact type before the assessment to confirm the records are complete and consistent with one another.

What DMARC costs in tooling, effort and upkeep

This table breaks down the cost components of putting DMARC in place for Safeguard 9.5, showing who is paid for each, whether it is one-time or recurring, and what drives it up. No figures are supplied for this topic, so use the questions in the final column to request comparable quotes. The main takeaway is that the largest recurring effort usually sits with report review and sender remediation, not with the DNS record itself.

Cost component	Who is paid or who does the work	One-time or recurring	What drives it and what to ask for in a quote
DNS and SPF, DKIM and DMARC record setup	Internal DNS and mail administrators, or an implementation partner	One-time, then recurring on change	Number of domains and subdomains. Ask for the records to be written, tested and documented per domain.
Mail platform configuration for DKIM signing	Mail platform administrators or the email vendor's support	One-time per sending platform	Number of mail platforms and gateways. Ask which signing keys are created and how rotation is handled.
DMARC report collection and processing	Commercial report service, or self-hosted parser run by internal staff or a partner	Recurring	Volume of aggregate reports and number of domains. Ask whether the tool is priced per domain, per message or per seat, and what retention it provides.
Sender remediation for marketing, HR and application teams	Business and application owners who send mail through third-party services	Recurring during rollout, lower afterwards	Count of legitimate third-party senders. Ask who owns the sender inventory and how new senders are approved.
Policy progression from monitoring to enforcement	Security and email administrators	One-time per domain, with periodic review	How many legitimate flows fail alignment. Ask for a documented rollout plan with a review point at each policy step.
Ongoing review and change control	Internal security team, or a retainer with a support provider	Recurring	Frequency of new mail services and domain changes. Ask who approves DNS changes and how they are logged.
Evidence preparation for assessors	Internal compliance staff, with optional partner support	Recurring at each assessment cycle	Number of samples an assessor selects. Ask for DNS records, reports and change tickets to be kept in one place per domain.

Who owns DMARC work and what a partner can take on

Your team remains accountable for the Safeguard. Only your organization can decide which domains send mail, which third parties are authorized to send on your behalf, and what enforcement level the DMARC policy should reach after monitoring. These are business decisions that touch marketing platforms, billing systems, ticketing tools and customer notifications, so they need sign-off from the people who own those services as well as from security.

Domain and sender inventory: Decide which domains and subdomains are in scope and confirm every legitimate sending service, including SaaS mail tools and transactional providers.
Policy decisions: Choose the DMARC policy progression, the reporting addresses and the alignment mode, and record the rationale in a signed-off document.
Exception handling: Approve any sender that cannot yet pass SPF or DKIM and set a dated plan to fix it before enforcement.
Ongoing ownership: Assign a named owner for changes to DNS records and for reviewing aggregate reports on a set schedule.
Policy approval: Management approves the documented process, which is the evidence an assessor will look for.

Before starting, confirm with your leadership which person signs the DMARC policy and who receives the reports.

Common DMARC gaps and how to close them

Most DMARC programs stall at the same few points: a policy that never leaves monitoring mode, domains nobody remembered to cover, and authentication records that quietly break. Each card below names one gap, explains why it weakens the Safeguard 9.5 measure, and gives the fix to make and the check to run.

Policy stuck at p=none

A record that publishes p=none collects reports but blocks nothing, so spoofed mail from your domain still reaches inboxes. Organizations often leave it there because reports are noisy and nobody owns the decision to move forward. Fix this by reviewing aggregate reports for legitimate senders, adding missing ones to SPF or DKIM, and then moving to p=quarantine and later p=reject in steps. Confirm the current policy value in DNS for every domain you send from.

Forgotten subdomains and sending services

Subdomains used for marketing, support portals or old test systems often send mail without anyone listing them in the DMARC plan. Without an explicit subdomain policy, these names inherit the parent policy, and records that were never created leave spoofing room open. Inventory every domain and subdomain that can send mail, including third-party platforms, and publish a DMARC and SPF decision for each. This inventory is also where the Safeguard 2.1 software inventory helps.

SPF lookup limit exceeded

SPF evaluation allows a limited number of DNS lookups, and each included sending service adds to the count. When a record exceeds the limit, receivers may return a permanent failure, so legitimate mail fails authentication and DMARC alignment breaks. Count the lookups in your SPF record, remove retired senders, and flatten or consolidate includes where the sending service allows it. Recheck the count after every new vendor is added, because growth usually happens through small changes.

DKIM keys never rotated

DKIM signing keys that have been in service for years are more exposed if a private key leaks, and some older keys use weak lengths that receivers no longer favor. Many teams also keep retired selectors in DNS with no owner, which makes it hard to tell which keys still sign mail. Document each selector, its sending service and its rotation date, then publish a new key, switch signing, and retire the old selector once the mail flow shows the new key in use.

No owner for report review

DMARC aggregate reports arrive as XML from many receivers and are difficult to read by hand, so they often pile up in a mailbox that nobody checks. The Safeguard 9.5 measures look at whether DMARC is in use, but a policy with no review process drifts out of date as senders change. Name an owner, define who approves new senders and who acts on failures, and set a recurring review. Include this process in your written documentation so an assessor can trace it.

Policy changes without evidence

Teams often change DNS records through ad hoc tickets, so there is no record of why a policy moved to quarantine or reject, or which senders were validated first. An assessor reviewing the Safeguard will ask for the decision trail as well as the current record. Keep change records for each DNS update, save dated copies of the SPF, DKIM and DMARC records, and retain the report summaries that justified each step. Confirm with your DNS and mail platform what logs they keep and for how long.

DMARC questions buyers ask before hiring help

How long does a DMARC rollout take and what drives the timeline?

The timeline depends mostly on how many domains and sending services you run and how much of your mail flow you already understand. The work usually moves in stages: inventory every system that sends mail as your domain, publish or correct SPF and DKIM for each one, publish a DMARC record in monitoring mode, read the aggregate reports, fix the senders that fail, and only then move toward enforcement. Each stage waits on other teams, so the largest delays usually come from unknown senders such as marketing tools, billing platforms and HR systems rather than from the DNS edits themselves. Ask any partner to show the timeline as a written scope with named dependencies before work starts.

Can a small team implement DMARC without outside help?

Yes, a small team with DNS access and someone who can read mail headers can publish SPF, DKIM and a monitoring-mode DMARC record without help. The harder part is sustained: reading aggregate reports, keeping the sender list current and moving to enforcement without blocking legitimate mail. If nobody on the team has time for that cycle, or if many domains and third-party senders are involved, outside help is more likely to pay off. Confirm your own sender inventory before deciding, because the number of services that send mail is the main factor in effort.

What does DMARC need from engineering and marketing teams?

Engineering usually owns DNS records, mail server configuration and any self-hosted mail or application services that send email. Marketing owns the bulk and campaign senders, which often need their own DKIM keys and alignment with the From domain. Both teams need to agree on who approves a new sending service before it goes live, and who reviews DMARC reports on a regular schedule. Without that shared process, a new vendor can break alignment after enforcement is already in place.

What parts of DMARC are worth outsourcing?

Three parts are commonly outsourced: the initial sender inventory, the SPF and DKIM configuration for complex environments, and the design of the reporting and review routine. The organization keeps ownership of the policy, the risk decision to move toward enforcement, and the records that show it. Partners prepare systems, configuration and evidence, but they do not decide the policy for you or issue any assessment result. Ask for the deliverables in writing, including what evidence the enterprise receives at the end.

How does Safeguard 9.5 relate to Safeguards 9.1 through 9.7?

Safeguard 9.5 covers sender authentication for your domains, while the other Control 9 Safeguards address the browser and email client software you allow (9.1), DNS and URL filtering (9.2 and 9.3), extensions (9.4), file type blocking (9.6) and email server anti-malware (9.7). DMARC does not stop malicious links or attachments from legitimate senders, so it works alongside the filtering and anti-malware Safeguards rather than replacing them. Safeguard 9.5 sits in IG2 and IG3, so it is not part of the IG1 baseline. Check the CIS Controls Navigator for the mappings that apply to your assessment.

Does DeployOpen issue a DMARC assessment result or certificate?

No. DeployOpen plans, implements and documents the email authentication configuration and the evidence that supports it, but it does not issue audit reports, attestations or certifications. Any formal assessment against CIS Controls or a related framework must be performed by an independent assessor or certification body. Ask a prospective partner which evidence they will hand over, and confirm with your assessor in advance which artifacts they will accept for Safeguard 9.5.

What evidence should I keep to show DMARC is working?

Keep the published SPF and DKIM records, the DMARC policy record and its change history, the sender inventory with owners, and a log of aggregate report reviews with the actions taken. Assessors look for proof that the policy is in place and that someone verifies it, so the review log matters as much as the DNS records. If you use a self-hosted platform that logs administrative changes, such as Nextcloud's admin_audit app writing to audit.log, that log can support change tracking for supporting systems. Confirm the format your assessor expects before you collect anything.

Open-source support for DMARC evidence

The evidence for Safeguard 9.5 is mostly DNS records, published policy and the reports that receiving mail servers send back, so the first question for a self-hosted mail estate is whether the organization can show its DMARC policy, SPF and DKIM records and report-handling process at any point in time. The supplied facts do not cover DMARC report tooling, so the open-source options for aggregate and forensic report parsing, DNS record monitoring and mail flow reporting are not confirmed here. Before committing to a stack, ask the implementation partner and each candidate project to confirm which DMARC report formats they parse, whether they retain report history, and whether they run fully inside your own network.

The supplied facts do cover two self-hosted platforms that record who changed what and when, which is useful supporting evidence for the operational side of the Safeguard. Nextcloud's admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit, so a team that keeps shared DMARC runbooks, DNS change requests or report review notes on a Nextcloud instance can show who edited them. OpenBao audit devices keep a detailed JSON log of every API request and response, including errors, with most sensitive values hashed with HMAC-SHA256. If DNS records are managed through automation that calls OpenBao for credentials, those logs can show which identity made a change. Neither platform proves that a DMARC policy is enforced or that its reports were reviewed, so treat them as change and access records alongside the policy evidence.

Confirm three things with your assessor and your platform team before relying on these logs: that the log destination is protected and retained for the period your audit window requires, that the audit.log path and OpenBao audit device are enabled in the production configuration, and that DNS change tickets link to the log entries. An illustrative example: a DMARC policy moved from monitoring to enforcement should have a change record, a named approver, a DNS diff and a log entry showing the change was made by an authorized identity. Your organization owns the control and the assessor issues any conclusion; the implementation partner's role is to prepare these systems and collect the records.

How DeployOpen prepares DMARC evidence for your assessment

DeployOpen works on Safeguard 9.5 as a fixed-scope implementation inside your own domains and mail infrastructure. We prepare the SPF, DKIM and DMARC configuration and the evidence that shows it running, while your organization owns the policy decisions and an independent assessor reviews the result.

How we scope

Inventory every domain and subdomain that sends mail, including third-party senders, before any record changes.
Agree in writing which mail platforms, DNS providers and sending services fall within the Safeguard 9.5 scope.
Confirm with your team which assessment measures apply and which Safeguard 2.1 software inventory data will be reused.

How we build

Publish and validate SPF and DKIM records for each sending source, then confirm alignment with the sending domain.
Configure DMARC in monitoring mode first, collecting aggregate reports so legitimate senders are identified before enforcement.
Move the policy toward enforcement only on the approval of your owners, documenting each change and its rollback path.

How we hand over

Deliver a record of each DMARC, SPF and DKIM configuration with its date, owner and validation result.
Provide report summaries and configuration exports that show the policy is published and checked over time.
Document the operating process so your team can answer assessor questions about who reviews reports and how exceptions are handled.

How we support

Ongoing support, upgrades and continuous checks of DNS records are available as a retainer after handover.
Retainers can cover periodic review of DMARC reports as new sending services are added to your domains.
Assessment readiness work stays with you and your auditor: DeployOpen prepares evidence but does not issue any report or certificate.