Email authentication / SPF DKIM DMARC
Give security and infrastructure teams a clear view of sender identity, DNS alignment, policy readiness and ownership gaps.
Raising the DMARC policy from none to quarantine to reject sounds like a single configuration change, but it is the visible end of three operational pieces: who sends mail on behalf of the domain, how each sender is authenticated, and how exceptions are governed over time.
The first piece is a complete inventory of legitimate sending sources: corporate mail, marketing platforms, transactional systems, ticketing and helpdesk, and third-party SaaS that mails on the brand's behalf. Without the census, every alignment fix is guesswork.
SPF lookups have a hard limit, DKIM signing requires deployment per sender, and BIMI requires a verified mark certificate. Alignment work is precise but routine when the census is in hand and confused otherwise.
Forwarders, mailing lists and downstream relays are the surface where DMARC enforcement breaks unexpectedly. The dotNice approach maintains an exception register with a renewal cadence, so the policy holds without an emergency rollback every quarter.
Method
The method follows four steps: census of legitimate senders, SPF and DKIM alignment, DMARC policy progression, exception governance. Each step closes a specific risk before the next one is opened.
Inventory every legitimate sending source: corporate mail, marketing platforms, finance/HR transactional systems, ticketing, helpdesk, third-party SaaS that mails on the brand's behalf.
Reconcile SPF includes against the census, deploy DKIM signing on each sending source, fix alignment and identifier mismatches before any policy enforcement.
Stage policy progression: monitor (p=none) to read XML and forensic reports, quarantine for known-good senders, reject only after the population is clean and exceptions are documented.
Operate the policy: a register of exceptions, a renewal cadence for forwarder and relay handling, reporting to security and legal, change-control for new senders.
Operating model
The diagram makes the decision path inspectable: signals, owners, evidence and outputs for emailauthentication.eu.
The output is an operational plan: census of legitimate senders, SPF and DKIM alignment status per sender, DMARC aggregate and forensic report reading, transition criteria between none, quarantine and reject, exception register with review cadence. The plan is executable by IT and security without further reconstruction.
Mid-scope review
Before moving the DMARC policy from none to quarantine or to reject, it is prudent to stop briefly: the sender census is complete, SPF and DKIM alignment is verified, forwarder and relay exceptions are documented, aggregate and forensic reports are read weekly. A reject policy without these foundations has an immediate cost in legitimate mail loss.
What the first scope contains
The first advisory scope for a DNS/email programme covers: sender census including third parties that mail on the brand's behalf, SPF reconciliation including DNS lookup limits, DKIM signing distribution per sender, DMARC aggregate and forensic report reading, policy progression from none to quarantine to reject with explicit criteria for each step, and an exception register with a review cadence. The output is an operational plan with responsibilities and timelines IT and security can execute.
Executive context
A DMARC progression that holds depends on three foundations: a complete census of legitimate senders (corporate mail, marketing platforms, transactional systems, ticketing, helpdesk, third-party SaaS), correct SPF and DKIM alignment per sender, and exception governance for forwarders, mailing lists and relays with an auditable log. Without these three, raising the policy to reject exposes the domain to legitimate-mail loss and to rollback requests that cannot be reversed cleanly.
Decision readiness
The review should show which domains send business email, which systems authenticate correctly, which suppliers create alignment risk and where legacy sending still depends on undocumented DNS records. That gives IT and security teams a practical basis for remediation rather than a theoretical recommendation to improve email security.
For enterprise buyers, the decision is often about sequencing. The control view helps decide which sender issues can be fixed now, which require application owners and which domains should be removed from active sending.
The same view also helps identify where an authentication issue is a DNS problem, an application-owner problem or a supplier-governance problem. That distinction makes remediation easier to assign and easier to track.
The buyer can enter the discussion with a clear remediation question and a defined technical perimeter.
Form readiness check
A CIO or IT leadership can use the request form to scope the DNS/email programme. An IT manager, CISO or domain manager should use the request form when corporate sending sources have no current census, when SPF and DKIM have alignment gaps that block a stricter DMARC policy, when forwarders or relays generate false positives, or when leadership needs a controlled DMARC progression from p=none to quarantine to reject. The request is qualified when it names the primary domain, the current DMARC policy and the main sending sources.
Operating path
An enforced DMARC policy without incidents depends on order: census, alignment, monitoring, progression, governance. Contact the dotNice team to set the baseline, read the DMARC reports you already receive today, or plan the transition to quarantine or reject on a domain that is currently at p=none.
emailauthentication.eu
The form qualifies the primary domain, the current DMARC policy and the main sending sources. Provide useful references to anticipate the first conversation.