Send an email with Flectra

Use an email domain in Flectra

Documents in Flectra (such as a CRM opportunity, a sales order, an invoice, etc.) have a discussion thread, called chatter.

When a database user posts a message in the chatter, this message is sent by email to the followers of the document. If a follower replies to the message, the reply updates the chatter, and Flectra relays the reply to the followers as a notification.

Messages sent in the chatter from internal database users to external users (such as partners, customers, or vendors) are relayed on behalf of the database users. Messages sent back to the chatter from external users will appear in the chatter from their respective email addresses, or as they are listed in their Contacts record.

If the Flectra database is hosted on the cloud (Flectra Online or, it is not necessary to add an outgoing email server to send emails from a custom domain.


The Flectra server is subject to a daily email limit to prevent abuse. The default limit is 200 emails sent per day for databases with an Professional subscription. This limit can be increased under certain conditions. See the FAQ or contact support for more information.

To ensure that emails sent to and from the chatter reach their intended contacts, instead of being considered spam, Flectra recommends configuring the domain name.

For the same reason, Flectra also recommends giving each database user an email address from the configured domain, rather than a generic email address domain (such as,, etc.).

Be SPF compliant

The Sender Policy Framework (SPF) protocol allows the owner of a domain name to specify which servers are allowed to send emails from that domain. When a server receives an incoming email, it checks if the IP address of the sending server is on the list of allowed IPs according to the sender’s SPF record.


The SPF verification is performed on the domain mentioned in the Return-Path field of the email. In the case of an email sent by Flectra, this domain corresponds to the value of the mail.catchall.domain key in the database system parameters.

See the documentation on incoming emails.

The SPF policy of a domain is set using a TXT record. The way to create or modify a TXT record depends on the provider hosting the DNS zone of the domain name. In order for the verification to work properly, each domain can only have one SPF record.

If the domain name does not yet have an SPF record, the content of the record to create it is as follows:

v=spf1 ~all

If the domain name already has an SPF record, the record must be updated (and do not create a new one).


If the TXT record is v=spf1 ~all, edit it to add v=spf1 ~all

Check if the SPF record is valid with a free tool like MXToolbox SPF.

Enable DKIM

The DomainKeys Identified Mail (DKIM) allows a user to authenticate emails with a digital signature.

When sending an email, the Flectra server includes a unique DKIM signature in the headers. The recipient’s server decrypts this signature using the DKIM record in the database’s domain name. If the signature and the key contained in the record match, this guarantees that the message is authentic and has not been altered during transport.

To enable DKIM, add a CNAME record to the DNS zone of the domain name:

flectra._domainkey IN CNAME


If the domain name is, make sure to create a subdomain whose canonical name is

The way to create or modify a CNAME record depends on the provider hosting the DNS zone of the domain name. The most common providers are listed below.

Check if the DKIM record is valid with a free tool like DKIM Core. If a selector is asked, enter flectra.

Check the DMARC policy

The Domain-based Message Authentication, Reporting, & Conformance (DMARC) record is a protocol that unifies SPF and DKIM. The instructions contained in the DMARC record of a domain name tell the destination server what to do with an incoming email that fails the SPF and/or DKIM check.

There are three DMARC policies:

  • p=none

  • p=quarantine

  • p=reject

p=quarantine and p=reject instruct the server that receives an email to quarantine that email or ignore it if the SPF and/or DKIM check fails.

If the domain name uses DMARC and has defined one of these policies, the domain must be SPF compliant or enable DKIM.


Yahoo or AOL are examples of email providers with a DMARC policy set to p=reject. Flectra strongly advises against using an or address for the database users. These emails will never reach their recipient.

p=none is used for the domain owner to receive reports about entities using their domain. It should not impact the deliverability if the DMARC check fails.

Check the DMARC record of a domain name with a tool like MXToolbox DMARC.

If a partner, customer, or vendor, uses DMARC and has defined one of these policies, the Flectra server cannot relay emails from this partner to the database users.

To solve this issue, handle user notifications in Flectra, or replace the email address of the partner with a default email address.

SPF, DKIM & DMARC documentation of common providers

To fully test the configuration, use the Mail-Tester tool, which gives a full overview of the content and configuration in one sent email. Mail-Tester can also be used for other, lesser-known providers.

Use a default email address

Access the System Parameters by activating developer mode and going to Settings ‣ Technical ‣ Parameters ‣ System Parameters menu.

To force the email address from which emails are sent, a combination of the following keys needs to be set in the system parameters of the database:

  • mail.default.from: accepts the local part or a complete email address as value

  • mail.default.from_filter: accepts a domain name or a full email address as value


The mail.default.from_filter works only for flectra-bin configurations, otherwise this parameter can be set using the from_filter field on ir.mail_server.

If the email address of the author does not match mail.default.from_filter, the email address is replaced by mail.default.from (if it contains a full email address) or a combination of mail.default.from and mail.catchall.domain.

If the from_filter contains a full email address, and if the mail.default.from is the same as this address, then all of the email addresses that are different from mail.default.from will be encapsulated in mail.default.from.