Scope the configuration to Moloni’s documented sender feature
Moloni's Portuguese support documentation describes sending documents and notifications either from its default address or from an eligible customer's own domain. This guide covers that Moloni feature, not Moloni ON or a generic Mailgun integration. Similar branding does not make another product's DNS recipe applicable. Confirm the actual product, account, plan and current sender setting before proposing changes. A website domain or mailbox hosted elsewhere is not automatically authorized for Moloni's sending infrastructure.
The sender-configuration guide identifies faturas@moloni.pt as the default address and describes custom sending for Plano Pro customers who can configure their domain. It excludes addresses on domains the customer does not control, giving examples such as Gmail, Sapo and Hotmail. Those boundaries are provider requirements, not an invitation to create DNS records for a public mailbox domain. No account eligibility or actual sending state has been verified here.
Establish eligibility before activating the custom address
The guide says customers outside Plano Pro who previously had the feature activated can request reactivation, with Moloni checking SPF and eligibility. That exception is not a general promise that every non-Pro account can enable the feature. Obtain a current account-specific eligibility decision through the organization's normal approved support process if needed. This article does not send a support message, make a purchase or assume that an upgrade has been authorized.
Inventory the message categories that use the configured sender. Moloni lists documents, identification templates, customers, pending-sales listings, scheduled events and stock alerts. A setting tested only on one manual document should not be assumed to cover every scheduled or automated category. Assign an owner for the business consequences of a sender change, especially where recipients rely on a familiar billing identity. Keep that operational concern separate from the technical question of whether the sending domain authenticates.
Review the current technical requirements with the DNS owner
Moloni's server-authorization guide describes SPF and DKIM and says its technical services perform prior verification. It publishes explicit sending IP addresses and a DKIM TXT example for a selector under the customer's domain. It also tells users of services such as Office 365 or G Suite to contact its technical services before making changes. Preserve that product-specific coordination requirement rather than treating the page as an unconditional copy-and-paste authorization.
The retained page does not establish that its printed public key and IP values are the current correct values for every account or route. Confirm their applicability before implementation. Do not invent account-generated selectors, replace existing key material or reuse another product's include because it appears in a third-party guide. The article's sample contains a DKIM testing flag; do not silently remove or reinterpret it without a reviewed current configuration. The actual DNS change should use the provider-confirmed owner and value for the intended deployment.
A public DNS value is not a private signing key. Never ask an administrator to paste a private key into this worksheet or a support message. The purpose of the technical review is to establish what public authorization and key lookup the receiving server should see, who controls the corresponding sender, and which operator approves the change. Those decisions remain open until the real account and domain owners supply evidence.
Preserve one coherent SPF policy
The Moloni guide's example adds authorization to an existing SPF record rather than creating a second independent policy. Follow that structural principle while reviewing the actual set of legitimate senders. Do not replace the organization's policy with an illustrative example that omits mailbox hosting, other applications or approved transactional services. Conversely, avoid retaining obsolete authorization forever merely because it once appeared in a migration document.
RFC 7208, sections 2.4, 3.2 and 4.6.4 govern the MAIL FROM identity, multiple SPF records and evaluated DNS-dependent term limits. Assess the real envelope identity used by the selected Moloni route rather than assuming the visible sender address is the SPF identity. Literal address mechanisms and DNS-dependent mechanisms have different evaluation behavior. A valid syntax check is useful, but it does not prove the listed infrastructure is still the correct authorized sender for the account.
Do not repeat the source's delivery guarantees as technical conclusions. Authentication configuration can address a specific authorization problem, but receiving systems still apply other policies. A correctly published policy does not guarantee that an invoice reaches the inbox, that its recipient reads it or that a payment follows. Those outcomes must be measured separately from SPF and DKIM evidence.
Apply the sender control only after its prerequisites
The documented user-interface sequence is Configurações, Empresa, the E-mails tab, then the sender setting. The guide includes a confirmation button labelled Confirmo que posso configurar o SPF before enabling the option, entering the desired address and choosing Atualizar to save. That confirmation represents a prerequisite decision; it should not be treated as a shortcut that makes the DNS configuration correct automatically.
Before saving, compare the intended address with the eligible domain and approved technical configuration. Record the previous setting and rollback owner. The current interface and exact account entitlement still need confirmation because a public help article does not expose the live tenant. A change to the displayed sender can affect recipient recognition and reply handling, so acceptance should include the practical correspondence path without claiming that reply routing itself proves authentication.
Validate signing and alignment with safe evidence
A proposed acceptance exercise should use an authorized harmless message, not an actual customer's invoice or financial details. Retain the minimum trusted receiver diagnostics needed to establish the route, author domain, envelope identity, signature domain and selector. RFC 6376, section 3.5 defines the relevant signature fields. RFC 9989, section 4.4 explains the alignment relationship between the visible author domain and a passing authentication identity.
A successful provider-side check is evidence of that check, not proof that every message category signs and aligns. Distinguish a default Moloni sender from a custom-domain sender in the acceptance record. If a test uses the default address while production uses the organization's domain, it does not establish custom-domain readiness. No message, DNS query, support request or external diagnostic upload was performed for this manuscript.
Fictional diagnosis: eligibility and DNS were conflated
A fictional wholesaler, Olive Harbour Supplies, enables a custom sender after assuming its previous access to the feature proves current eligibility. Its DNS owner has not reviewed the technical values, and scheduled stock alerts still need an explicit acceptance scope. The team labels the configuration complete because the address is visible in the settings screen.
The proposed correction is to separate the eligibility decision, provider-confirmed technical configuration, saved sender state and message-level evidence. The reviewer keeps scheduled categories open until their behavior is examined through an authorized exercise. This is a fictional workflow problem, not a claim that any real Moloni account has failed or that the provider's service is unreliable.
Blank acceptance worksheet and publication boundary
- Product, account, plan and confirmed feature eligibility: ______
- Default or custom sender and affected message categories: ______
- Current provider-confirmed SPF and DKIM requirements: ______
- Office 365 or other provider coordination, if applicable: ______
- Authoritative DNS owner, change approval and previous values: ______
- Complete SPF review and public-key owner/value evidence: ______
- Saved sender state, rollback owner and reply-path review: ______
- Trusted message authentication and alignment results by category: ______
- Remaining exceptions and release decision: ______
Original implementation evidence, current applicability, human subject-matter review, production routes, visual accessibility and owner release remain open. This source-scoped article does not certify the printed historical values for a tenant or claim a successful custom-domain deployment. The catalogue's broader implementation requirement remains unsatisfied until authorized operational evidence is available.