Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Choose the Odoo deployment and outgoing transport first
Authenticate the server that actually sends the Odoo message. Odoo 19 documentation distinguishes its default sending service from an external outgoing server. The published Odoo SPF and DKIM instructions apply to the **Odoo email server with a custom domain**. They do not configure an independent SMTP provider merely because Odoo generated the invoice or campaign. Odoo 19 DNS configuration.
Record the Odoo version, hosting model, database, company and message type. Odoo Online, Odoo.sh and an on-premises deployment should not be treated as interchangeable. This article uses the versioned Odoo 19 documentation retrieved for research; confirm that it matches the installation before following a menu path. The tenant, live DNS and actual messages have not been inspected.
Identify three possible branches: an Odoo-managed subdomain using the default service, a custom domain using that service, or a custom domain using an external sender. Odoo documents its default subdomain configuration for Online and Odoo.sh as preconfigured for authentication. That does not establish the status of a modified database or guarantee every later workflow remains on that route. Capture a baseline quotation, invoice or other harmless notification from the actual application.
Also determine whether transactional mail and mass mailing use separate servers. If they do, create separate acceptance rows. A tested invoice cannot establish that a marketing campaign uses the same DKIM key, envelope domain or transport.
Map the alias domain and visible sender before DNS changes
Create a small route inventory for the company being changed. Include its alias domain, bounce alias, catchall alias, default From setting, outgoing-server selection and any template-specific From address. Keep these fields separate: the visible sender, the address receiving replies and the address receiving delivery failures can have different operational roles.
Odoo's DNS guide says the SPF check concerns the bounce address associated with the Alias Domain setting. Its outbound guide explains that FROM filtering and server selection can alter which transport and sender are used. Therefore, inspect the message that reaches the recipient rather than assuming that the author field in a business record becomes the final From identity. Odoo 19 outbound messages.
Before editing aliases, document how replies to existing messages will still reach the correct record. Retain forwarding or inbound routing that remains necessary. Authentication work should not silently break replies to an already-issued quotation. Have the application owner identify any shared domain used by multiple companies and whether a change would affect all of them.
A change request should describe the desired result in concrete terms: which company's workflow will display which From domain, which server sends it, where replies arrive and who processes bounces. If those answers are unresolved, pause the DNS change and settle the route first.
Configure the default Odoo relay branch from version-matched instructions
For a custom domain using Odoo's own sending service, obtain the current SPF and DKIM instructions from the version-matched documentation and verify that the account remains on that branch. The Odoo 19 page documents its service authorization and DKIM delegation. It specifically requires sending-domain DKIM configuration for Odoo Online to pass DMARC; do not use the general either-aligned-path protocol rule to skip that documented product step. This article does not supply a copyable policy because the existing zone and other legitimate senders are unknown.
Ask the DNS owner to inspect the exact owner required by the selected alias and sending configuration. If an SPF policy already exists there, merge the required authorization into that policy while preserving valid existing senders. Do not add a second SPF record or replace the entire policy with the page's simple example. Evaluate RFC 7208 §4.6.4’s ten evaluated DNS-causing-term limit, including nested dependencies, rather than counting only visible includes. RFC 7208, multiple records and lookup limits.
For the documented DKIM delegation, compare the required owner and target with the zone before adding it. Check for an existing CNAME or another record at that owner. Confirm whether the DNS editor expects a relative name or the complete hostname, and verify the resulting authoritative answer. Do not substitute an A record, a web redirect or a proxied website configuration for the required DNS delegation.
After public DNS is ready, complete the company alias-domain configuration described by the Odoo version's outbound guide. Keep a record of the prior value and the company assignment. Send a new controlled message and observe the actual DKIM d and s values. Publishing the documented delegation is only one stage; the accepted outcome requires a passing signature on the intended application message.
Configure the external sender branch at its real mail provider
If Odoo submits through an external SMTP provider, configure that provider's supported sending domain, DKIM and envelope identity. Odoo explicitly cautions that its own relay DNS instructions will not have the desired effect for an independent external server. Obtain that server's current tenant-generated records and follow its authentication and authorization requirements.
In the Odoo 19 interface, the documented path begins with enabling custom email servers in Settings, then creating an outgoing server with the provider's connection details. Treat a successful Test Connection as a connectivity check: the documentation warns that provider restrictions can still prevent actual sending. Do not record it as successful delivery or authentication. Odoo Online and Odoo.sh block outbound port 25; obtain a supported encrypted-submission configuration from the actual provider rather than treating a different port as proof of TLS. Keep credentials out of the worksheet and review package. Odoo outgoing server configuration.
Review FROM filtering, priorities and any dedicated marketing server selection against the intended route. If a sender falls outside the permitted filter, the resulting notification identity may differ from the one the business expected. Do not “fix” that by broadening permissions without understanding why the filter exists. Confirm the external provider permits the exact visible sender and any bounce address Odoo needs.
For an on-premises deployment, identify the configured MTA or relay and its owner. The default Online/Odoo.sh service assumptions are not an on-premises recipe. Keep that branch held until deployment-specific configuration and provider evidence are available.
Record the Odoo acceptance worksheet
Complete a separate worksheet for each company and transport. These are proposed fields, not observed results.
- Deployment: Odoo version, hosting model, database, company and application workflow.
- Transport: default Odoo service or named external provider, selected outgoing-server record, FROM filter, priority and dedicated marketing selection where applicable.
- Application identities: alias domain, default From behavior, template From, bounce and catchall routing, with secrets omitted.
- DNS plan: authoritative zone owner, existing SPF policy, required public records, record-purpose mapping and saved rollback values.
- Baseline and retest: UTC time, message identifier, controlled recipient, business workflow and whether the message arrived.
- Received identities: visible From domain, Return-Path domain, every DKIM d and s pair and trusted receiver SPF, DKIM and DMARC results.
- Operational checks: reply reaches the expected chatter or mailbox, delivery failure handling remains available and another unaffected workflow still works.
- Decision: passing aligned path, unresolved routes, responsible owners and human approval.
Use a received original message to identify the selector and signing domain, then compare the corresponding public DNS evidence. DKIM verifies a signature over selected message data; it is not encryption of the email. A published key does not demonstrate that the signature is valid. RFC 6376, DKIM signature and verifier actions.
Apply DMARC to the visible From domain. A passing SPF or DKIM path must also align under the applicable mode. Do not interpret a provider's shorthand about “SPF or DKIM failure” as meaning both paths must pass: one passing aligned path can satisfy DMARC. The receiver can still apply other delivery policy. RFC 9989, DMARC evaluation.
Diagnose a fictional invoice and marketing split
**Fictional illustration only. No Odoo database, DNS zone or message was tested.** A company expects invoice messages from accounts@harborworks.example. The imagined invoice is sent through an external provider and carries a valid DKIM signature for harborworks.example. Its envelope identity is different, but the receiver reports DMARC pass through DKIM.
A marketing campaign from the same Odoo database then fails in this fictional scenario. Its dedicated server is different and signs with an unrelated hypothetical service domain. The invoice's success proves nothing about that campaign's alignment. The correct next step is to inspect the dedicated marketing transport and configure its actual provider, not to add Odoo relay authorization to the root domain by reflex.
A second possible symptom is a message whose From changed to the database notification identity. Investigate FROM filtering and alias settings before editing DNS. The receiver may be accurately reporting the identity Odoo actually used, while the business requirement concerns a different identity. The worksheet makes that distinction visible.
Recover the affected route and preserve reply continuity
If the change fails, restore the prior selected server or alias configuration through the approved application rollback, and restore only the DNS values changed for that route when needed. Retest both outbound authentication and replies to representative existing messages. Preserve old inbound aliases or redirects until their dependencies are resolved.
Avoid solving a single Odoo route by weakening the whole domain's DMARC policy. Pause the affected campaign or workflow and resolve its exact transport instead. Live tenant inspection, authoritative DNS validation, received-message testing, visual review and human subject-matter approval remain pending for this candidate. An Odoo connection test, a documentation example and a syntactically valid record are useful inputs, but none substitutes for the completed route worksheet.