Email authentication / the mechanisms
The four mechanisms are often treated as one checkbox, yet each answers a different question and fails in a different way. dotNice gives security and infrastructure teams a clear baseline of what is in place, what aligns and where the gaps are.
Teams often say "we have SPF, DKIM and DMARC" as if that were a single state. In practice each mechanism answers a distinct question: SPF authorises which servers may send, DKIM proves a message was not altered and came from the signing domain, DMARC ties those checks to the visible From address and tells receivers what to do, and BIMI displays a verified logo once enforcement is in place. A green pass on one is not protection on another — and the subtle failures are in alignment, not in the record itself.
A useful baseline starts from what actually exists: the SPF record and its include chain, the DKIM selectors and keys deployed per sender, the DMARC record and policy, and whether a BIMI record and verified mark certificate are present. dotNice reads these across the real sender estate — corporate mail, marketing, transactional systems, third-party SaaS — so the picture reflects how mail is sent, not how a single domain is configured in theory.
The recurring trap is treating an SPF or DKIM pass as DMARC compliance. DMARC requires that a passing mechanism also aligns with the visible From domain, and a message can pass SPF for a third-party envelope while failing alignment entirely. The baseline distinguishes a raw pass from an aligned pass per sender, because that distinction is what decides whether a stricter policy will protect the brand or break legitimate mail.
The output is not a maturity score; it is a per-mechanism gap list an engineer can act on: SPF includes over the lookup limit, senders with no DKIM signing, a From domain with no aligned mechanism, a BIMI record blocked by an unenforced DMARC policy. Each gap is tied to an owner and a fix, so the baseline becomes a work plan rather than an audit observation.
Operating model
The four mechanisms sit in a stack, each with a job, a home in DNS and a characteristic failure mode. Reading them side by side is what stops a team from assuming a passing check means a protected brand. The matrix is the baseline reference security and IT use to see, per mechanism, what is present and what is missing.
| Mechanism | What it proves | Where it lives | Failure mode |
|---|---|---|---|
| SPF | Which servers may send | TXT record on the domain | Over 10 lookups |
| DKIM | Message integrity and origin | Selector keys in DNS | Sender not signed |
| DMARC | Alignment + receiver action | _dmarc TXT policy | Pass without alignment |
| BIMI | Verified logo on delivery | BIMI record + VMC | Needs enforced DMARC |
Not sure whether your "pass" is actually aligned? Get a per-mechanism baseline before you change a policy.
Request an authentication baselineExecutive context
Email authentication is cross-functional and easy to misread, so leadership should reach the first call knowing which domains send business mail, which mechanisms are believed to be in place, and whether the goal is a baseline, a fix for a specific failure or readiness for a stricter DMARC policy or BIMI. It also means agreeing scope: a single corporate domain is one conversation, a sprawling estate of brands and third-party senders is another. The request form records which mechanisms are settled and which dotNice still needs to verify.
Naming owners early keeps the work moving. IT and DNS own the records and keys; deliverability and marketing own the sending platforms and any BIMI logo and certificate; security decides what an acceptable posture is and reads the reports. A domain can need a baseline urgently even when no single team has the full picture — that is exactly why the baseline exists, 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 domains in scope, the mechanisms believed to be in place, the main sending sources and the goal — a baseline, a specific fix, DMARC readiness or BIMI. With that, dotNice can separate a quick record check from a full estate baseline, an alignment fix or BIMI preparation — and recommend clearly what to inventory, align, enforce or display.
The review is most valuable when the buyer can describe the current gap: which domains send mail, which mechanisms are configured, which senders are third parties, and which internal team owns DNS and the sending platforms. A request is qualified when it states the domains, the mechanisms in place and the goal. The output is a scoped decision — a per-mechanism baseline with owners — not a service catalogue.
The cost of waiting belongs in the same record. Misaligned authentication leaves a brand spoofable and its legitimate mail at risk the moment anyone tightens a policy without the baseline, and a missing BIMI logo is a visible trust gap in crowded inboxes. Quantifying the exposure — spoofing and phishing risk, deliverability loss, brand visibility — is what moves an authentication baseline from a backlog item to a funded decision with an owner and a deadline.
Operating path
Email authentication is an ordered sequence: inventory the records, test alignment per sender, close the gaps, then enforce and display. Contact the dotNice team to baseline a domain, diagnose why a "passing" sender still fails DMARC, or prepare the estate for BIMI.
Talk to us
Describe the domains in scope, the mechanisms you believe are in place and the goal of the review. Your request is reviewed by dotNice specialists and routed to the right team.