Configure DNS records to send emails in CoquiAPPs

SPAM labels overview

Sometimes, emails from CoquiAPPs are misclassified by the different email providers and end up in spam folders. At the moment, some settings are out of CoquiAPPs’s control, notably the way the different email providers classify CoquiAPPs’s emails according to their own restriction policy and/or limitations.

It is standard in CoquiAPPs that emails are received from "name of the author" <>. In other words this can be translated to: "name of the author" <{ICP.mail.from.filter}@{mail.catchall.domain}>. In this case ICP stands for ir.config.parameters, which are the System Parameters. Deliverability is greatly improved with the notifications configuration.

In order for servers to accept emails from CoquiAPPs on a more regular basis, one of the solutions is for customers to create rules within their own mailbox. A filter can be added to the email inbox so that when email is received from CoquiAPPs ( it is moved to the inbox. It is also possible to add the CoquiAPPs database domain onto a safe senders list or whitelist on the receiving domain.

If an CoquiAPPs email server appears on a blacklist, notify CoquiAPPs via a new help ticket and the support team will work to get the servers removed from the blacklist.

Should the CoquiAPPs database be using a custom domain for sending emails from CoquiAPPs there are three records that should be implemented on the custom domain’s DNS to ensure deliverability of email. This includes setting records for SPF, DKIM and DMARC. Ultimately though, it is up to the discretion of the final receiving mailbox.

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 whether 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 CoquiAPPs, this domain corresponds to the value of the mail.catchall.domain key in the database system parameters.

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 a SPF record, create one using the following input: v=spf1 ~all

If the domain name already has a 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 CoquiAPPs 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:

CoquiAPPs._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 CoquiAPPs.

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.


DMARC: TXT record

v=DMARC1; p=none;

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. CoquiAPPs 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.

DMARC records are comprised of tags in the form of DNS records. These tags/parameters allow for reporting, such as RUA and RUF, along with more precise specification like PCT, P, SP ADKIM & ASPF. For best practice, the the DMARC policy should not start out being too restrictive.

The following chart displays available tags:

Tag Name




Protocol version



Percentage of messages subjected to filtering



Reporting URI for forensic reports


Reporting URI of aggregate reports


Policy for organizational domain



Policy for subdomains of the OD



Alignment mode for DKIM



Alignment mode for SPF


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

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 to configure records for other, lesser-known providers.