Establish which Notifii product sends the message
Treat a Notifii notification as a distinct business sending route before changing DNS. The Notifii LLC developer listing describes Notifii Connect as a communications hub for property managers to send email or text to individuals, groups and resident communities. That identifies the product and its notification purpose; it does not document a customer-controlled DKIM selector, SPF authorization or custom bounce domain. Notifii Connect developer listing.
This article is an evidence-gathering and conditional implementation guide. Custom-domain configuration remains on hold. The earlier documentary research recorded unsuccessful website and support retrievals. This review refreshed the readable developer listing only; it did not recover an authentication procedure or retry those restricted pages. This evidence gap does not establish that a feature is absent. They mean the article cannot responsibly supply a Notifii include, selector, public key, menu path or activation promise.
Confirm the exact application name, account, property or campus, notification type and domain the organization wants residents to see. Do not substitute documentation for Notifi, a differently named service, merely because its search result discusses custom email domains. Likewise, a record found in another customer's zone is not evidence that the same record is appropriate for this tenant.
The practical outcome is a clear decision: either the message already uses a provider-owned identity and needs provider investigation, or the tenant supports an organization-owned identity whose configuration must be obtained and verified. Neither decision requires speculative DNS changes.
Capture a harmless baseline from each notification workflow
Ask the application owner to select a test recipient under the organization's control. Use a synthetic message with no resident information, package details, unit numbers or access instructions. Trigger the same workflow that is failing, rather than sending a new message from the office mailbox. Record whether it is an announcement, an individual message or another application-generated notification. If more than one Notifii product is in use, capture each separately.
Save the received original message securely. Copy only the minimum header evidence into the review worksheet: visible From domain, Return-Path domain, each DKIM signing domain and selector, trusted receiver authentication results, message identifier and UTC timestamp. A friendly display name such as the property name is not the authenticated domain. A Reply-To address for the management office also does not establish which domain was evaluated for SPF or DMARC.
Document the intended destination of replies as a separate operational requirement. A resident being able to reply successfully is useful, but it cannot prove that the original notification was aligned. Similarly, an SMS arriving says nothing about the email path. Keep delivery outcomes, reply handling and authentication results in distinct fields so one success does not conceal a different failure.
If no message arrives, keep the outcome as undelivered or not observed. Check the application's available delivery evidence and the receiving system's logs through their owners. Do not manufacture a header interpretation from a screen that merely says a notification was submitted.
Obtain a tenant-specific answer before authorizing DNS
Prepare a short technical request for the verified Notifii support route available in the account or developer listing. Include the product and tenant identifier, sending workflow, intended From domain, a sanitized timestamp and the observed authentication domains. Do not send resident lists or full message bodies unless specifically needed and approved.
Request written confirmation of five points:
- Whether this exact product and tenant can send using the organization's visible From domain, and whether configuration is self-service or support-operated.
- Whether it can provide a passing DKIM signature aligned with that From domain, including the exact public DNS owner, type and value for this tenant.
- Whether the envelope sender is provider-owned or customizable, and which domain needs SPF authorization if customization is supported.
- Whether bounce handling or tracking requires additional records, and which records can safely coexist with the organization's current mail service.
- How activation, verification, key rotation and rollback work, including the expected identity if customization fails.
A response that says only “add us to SPF” is incomplete. Ask which SMTP envelope identity will use that authorization. A response that supplies only a branding or click-tracking CNAME is also incomplete unless it explains its relationship to the actual signing route. Keep the written response, date and tenant scope with the change request. A future operator should be able to tell why each DNS change exists.
Apply confirmed records without changing unrelated mail
Once a current first-party response identifies the supported route, compare its records with the authoritative DNS zone before editing. Have the DNS owner save the prior values and identify any collisions. A CNAME at a proposed name may conflict with another record already there. A requested MX record must be evaluated at its exact hostname; it must not replace the organization's main mailbox routing by assumption.
For any SPF change, preserve the legitimate senders that still use the same envelope domain. Publish a single SPF policy at that owner and assess the complete evaluation path, including nested includes and other DNS-querying terms. Counting only the includes visible on one line is insufficient. Do not add a service to the root domain merely because the company uses that domain in its logo. RFC 7208, SPF evaluation and DNS lookup limits.
For DKIM, publish only the provider-confirmed public value or delegation. Never request or place a private signing key in DNS, a support email or this worksheet. Confirm the DNS editor's handling of relative names and appended zone suffixes. The final owner must be the one requested, not a doubled domain. Then have Notifii complete whatever activation its written instructions require. A published key alone does not show that the service is using it. RFC 6376, signature and verification model.
Leave a deliberate hold if support cannot establish a supported aligned route. An operationally available provider-owned sender may be the appropriate option, but the business owner must approve that visible identity. Do not represent it as authentication of the organization's own From domain.
Complete the Notifii route worksheet
Use one copy per product, tenant and notification workflow. The fields below are a proposed acceptance procedure, not recorded test results.
- Product and tenant: exact application name, account identifier, property or campus, workflow and application owner.
- Intended identity: approved visible From domain, display name and reply destination.
- Provider evidence: support case or documentation URL, response date, custom-domain capability, exact public DNS instructions and activation responsibility.
- Baseline message: UTC time, message identifier, controlled recipient and observed delivery outcome.
- Authentication identities: From domain, envelope domain, every DKIM d and s pair, and trusted receiver results for SPF, DKIM and DMARC.
- DNS evidence: authoritative nameservers, exact owner/type/value, lookup time, prior configuration and conflict review.
- After-change message: fresh workflow execution, newly observed domains, alignment conclusion and expected reply behavior.
- Release decision: business owner, DNS owner, support confirmation, recovery route, unresolved evidence and human reviewer.
An aligned passing DKIM signature can establish DMARC success even when SPF uses an unaligned provider domain. Conversely, SPF and DKIM may both pass for provider-owned identities while DMARC fails for the organization's From domain. Apply the actual alignment mode and policy; do not infer alignment from matching display names. RFC 9989, identifier alignment and DMARC evaluation.
Diagnose a fictional resident announcement
Fictional illustration only. No Notifii tenant, DNS zone or message was tested. A property manager expects an announcement from notices@cedarcourt.example. The imagined received message has that From domain, but its SPF-authenticated envelope and passing DKIM signing domain belong to a different hypothetical service domain. The fictional receiver reports DMARC failure.
The diagnosis is an identity mismatch, not proof that all email authentication is broken. The passing mechanisms do not align with the visible From domain in this illustration. Adding a guessed SPF include at cedarcourt.example would not necessarily change the envelope identity evaluated by the receiver. The next action is to obtain the exact tenant's supported custom-domain route, or to use an approved supported sender identity. None of these example names or conclusions establishes Notifii's real infrastructure.
If the same hypothetical message instead acquired a passing DKIM signature aligned with the From domain, that would satisfy the DKIM path for DMARC. It would still not prove inbox placement, successful resident replies or coverage of another product's package notifications. Each operational claim needs its own evidence.
Recover and decide whether the guide can be released
If an authorized change disrupts notifications, stop further rollout and use the provider-confirmed rollback procedure. Restore only the records changed for this route when restoration is necessary, preserving unrelated sender permissions. Retest a controlled message after recovery. Do not lower an organization-wide DMARC policy simply to conceal one unresolved route.
The article remains unpublished and held for provider configuration evidence until a current first-party procedure or tenant-specific support response resolves the custom-domain questions. Live tenant inspection, authoritative DNS checks, real received-message testing, visual review and human subject-matter approval are also pending. The completed worksheet and support response are the required next inputs; the absence of documentation is not permission to fill the gaps with another vendor's settings.
Keep the support answer and observed route connected
File the dated answer against the exact product and workflow, then compare its expected identities with a new controlled message. A statement about another product or a successful text notification cannot close the email-domain question. The proposed request has not been sent and no tenant-specific capability is certified here.
Separate message acceptance from policy rollout
A passing aligned SPF result can satisfy a message evaluation, but does not alone justify moving an entire domain to reject. RFC 9989 Section 7.4 requires valid DKIM for domains publishing p=reject and warns about indirect-mail interoperability. Inventory all legitimate senders and indirect routes before the policy owner approves enforcement. No DNS change, tenant operation or received-message test was executed for this article.