DMARC advisory / staged rollout
Setting p=reject is one line in DNS — and the fastest way to drop real invoices and onboarding mail if the groundwork is missing. dotNice runs the staged path: census, alignment, reporting, then enforcement, each step gated by evidence.
Publishing a DMARC record at p=none is easy and tells attackers nothing will be blocked. The value is in the progression to enforcement, and that progression breaks when teams skip the groundwork: an incomplete picture of who sends mail, SPF and DKIM that do not align, and forwarders or relays that fail authentication in ways nobody mapped. dotNice treats DMARC as a staged programme where each policy step is opened only when the evidence says legitimate mail will survive it.
The programme starts with a complete inventory of legitimate sending sources: corporate mail, marketing platforms, transactional and billing systems, ticketing and helpdesk, and third-party SaaS that sends on the domain's behalf. Without the census every alignment fix is guesswork and every policy step risks dropping mail the business depends on. dotNice builds the census first, then recommends a stage — never the other way round.
SPF has a hard ten-lookup limit, DKIM must be signed per sender, and DMARC only passes when one of them aligns with the visible From domain. The advisory work reconciles SPF includes against the census, deploys DKIM on each source, and fixes identifier alignment — so that raising the policy changes the outcome for attackers, not for legitimate senders.
Aggregate (RUA) reports are the instrument that tells you whether a stage is safe to advance. dotNice reads them rather than filing them, distinguishes a misconfigured legitimate sender from genuine abuse, and maintains an exceptions register with a renewal cadence for forwarders and relays — so enforcement holds without an emergency rollback each quarter.
Operating model
DMARC adoption is a short ladder, and each rung has a distinct purpose, a distinct prerequisite and a distinct failure mode if it is reached too early. The matrix is the decision aid leadership uses to agree where the domain is today and what must be true before the next step — and it records why a stage was advanced or held.
| Stage | Purpose | Prerequisite | Risk if rushed |
|---|---|---|---|
| Monitor (p=none) | See who sends, collect reports | Record + RUA mailbox | False sense of protection |
| Quarantine | Send failing mail to spam | Known-good senders aligned | Legitimate mail in spam |
| Reject | Block unauthenticated mail | Clean population + exceptions | Lost invoices and onboarding |
| Reporting (RUA) | Decide when to advance | Reports read, not filed | Flying blind on each step |
Stuck at p=none, or unsure whether reject is safe? Scope the rollout before a deadline forces a risky change.
Request a DMARC reviewExecutive context
DMARC enforcement is a structured progression, not a single switch, and leadership should reach the first call knowing where the domain sits today, which sending sources are already inventoried, whether SPF and DKIM align, and what target stage the business actually needs — some domains warrant reject, some only quarantine, some are parked and should reject immediately. It also means agreeing the threshold and the timeline: a deliverability or compliance deadline often drives the decision, and the request form records which prerequisites are settled and which dotNice still needs to establish.
DMARC is cross-functional, and naming owners early stops the rollout stalling. IT owns the DNS records and DKIM deployment; deliverability and marketing own the sending platforms; security reads the reports and decides on abuse; legal and compliance hold any regulatory driver. A domain can need enforcement urgently even when its sender population is messy — the decision still needs structure, and dotNice coordinates across these roles rather than replacing them.
Qualification
For CISO, CIO, IT and deliverability roles, the request form works best from a concrete decision record rather than a generic brief. It should name the primary domain, the current DMARC policy, the main sending sources, the target stage and any deadline driving the change. With that, dotNice can separate a quick record fix from a full staged rollout, a reporting-only engagement or a rescue of an enforcement that broke mail — and recommend clearly whether to monitor, advance to quarantine, advance to reject or hold.
The review is most valuable when the buyer can describe the current gap: which domain is in scope, the policy in place, which senders are known and which are suspected, and which internal team owns DNS and the sending platforms. A request is qualified when it states the domain, the current policy and the main sources. The output is a scoped decision — a recommended next stage with criteria and an owner — not a service catalogue.
The cost of waiting belongs in the same record. A domain left at p=none stays spoofable in phishing and business-email-compromise, while a reject set without groundwork silently drops legitimate mail — both carry real cost. Quantifying the exposure — phishing and BEC risk on one side, lost transactional and onboarding mail on the other — is what moves DMARC from a backlog item to a funded decision with an owner and a deadline.
Operating path
DMARC advisory is an ordered sequence: census, alignment, monitor, advance, govern. Contact the dotNice team to set the baseline, read the aggregate reports you already receive, or plan a safe transition to quarantine or reject on a domain currently at p=none.
Talk to us
Describe the primary domain, the DMARC policy in place today and the main sources that send mail for it. Your request is reviewed by dotNice specialists and routed to the right team.