Domain settings

This guide contains examples of records that should be added for your domains.

The following IP addresses are used as examples. They only exist within this documentation and cannot be used as working addresses.

• 192.0.2.1 — IPv4 address for the admin panel;
• 192.0.2.2 — IPv4 address for message tracking;
• 192.0.2.3 — IPv4 address for website tracking;
• 192.0.2.4 — IPv4 address for the sender (AKMTA).

Admin panel domain settings

Choose a subdomain and add an A record.

Domain	Record type	Contents
altcraft.example.com.	A	192.0.2.1

Where else this is configured

The domain and IP are set in main.json: WEBCONTROL_HOSTNAME and WEBCONTROL_PUBLIC_IP.

Message tracking domain settings

Choose a subdomain for your from-domain and add an A record.

Domain	Record type	Contents
click.example.com.	A	192.0.2.2

Additionally, you can use as many tracking domains as needed. The settings will be the same, or you can use CNAME records.

Where else this is configured

The domain and IP are set in main.json: TRACKING_HOSTNAME (or TRACKING_PREFIX + WEBCONTROL_HOSTNAME) and TRACKING_PUBLIC_IP. In the UI when creating a resource, the Tracking Domain field allows you to set a domain for a specific resource.

Web site tracking domain settings

Choose a subdomain and add an A record.

Domain	Record type	Contents
pxl.example.com.	A	192.0.2.3

Additionally, you can use as many tracking domains as needed. The settings will be the same, or you can use CNAME records.

Where else this is configured

The domain and IP are set in main.json: COOKIESAVER_PUBLIC_HOSTNAME and COOKIESAVER_PUBLIC_IP.

Sender domain settings (AKMTA)

Choose a domain or subdomain and configure the following records in your domain's DNS zone:

Domain	Record type	Contents
mta-1.example.com.	A	192.0.2.4
example.com.	MX	mta-1.example.com.

The PTR record is not configured in the domain's DNS zone, but in the reverse zone with your IP address provider:

Reverse zone	Record type	Contents
4.0.2.192.in-addr.arpa.	PTR	mta-1.example.com.

Where else this is configured

• A-record — the domain and IP are set in the Admin Panel when creating a Node (sender IP). The A-record must point to the same IP.
• PTR-record — configured with your hosting provider or IP management panel (reverse zone). The PTR value must match the A-record (e.g., mta-1.example.com).
• MX-record — points to the A-record domain of the sender.

SPF settings

Sender Policy Framework (SPF) is a technology that allows verifying whether the sender domain has been spoofed. To make it work, you need to add a special TXT record to your sending domain (sender domain, from domain), which defines the policy for allowing this domain to send from various hosts.

We recommend adding records for different versions:

Domain	Record type	Contents
example.com.	TXT	v=spf1 ip4:192.0.2.4 -all
example.com.	TXT	spf2.0/pra ip4:192.0.2.4 ~all

A domain can have only one SPF record

If an SPF record already exists on your domain, do not create a new one — it will overwrite the existing one. Instead, add ip4:<your_IP> to the existing record.

Check the current record with:

dig example.com TXT

Example output if a record already exists:

; <<>> DiG 9.18.28 <<>> example.com TXT
;; ANSWER SECTION:
example.com.            300     IN      TXT     "v=spf1 include:sendgrid.net ~all"

Good result: ANSWER SECTION contains one record starting with v=spf1. Bad result: NXDOMAIN (record not found) or multiple v=spf1 records (this violates the standard).

If a record is found, combine mechanisms into a single line:

Was	Became
v=spf1 include:sendgrid.net ~all	v=spf1 include:sendgrid.net ip4:192.0.2.4 -all

The directive -all (or ~all) must remain single and be placed at the end of the record.

Where else this is configured

The domain used for MAIL FROM is determined in the Admin Panel:

• Senders — mail_from_type (from_email, ptr, custom, aligned), sender_domain, mail_from_subdomain, pool_id
• Sender pools — Sender domain, SPF domain, Sender subdomain

Make sure the SPF record for your domain allows sending from the domain that will be used in MAIL FROM.

:::

DKIM settings

DomainKeys Identified Mail (DKIM) technology adds a digital signature to the email, linked to the from-domain. The signature is automatically verified on the recipient side, then used to refine reputation and marked for the user. To sign the email, a private key is used, which is set up on the sender side and is unknown to anyone else. The public key is placed as a special TXT record on a subdomain of the from-domain.

In the platform Admin Panel, you can generate or add an existing key. Choose a selector — for example, altcraft. The selector is the prefix in the DKIM subdomain name. Selectors allow different senders to use the same domain: for example, altcraft._domainkey.example.com for Altcraft and mail._domainkey.example.com for another service.

Domain	Record type	Example contents
altcraft._domainkey.example.com.	TXT	v=DKIM1; k=rsa; p=AAAAB3NzaC1yc2EAAAADAQABAAABAQDLWvAVr5k+4nneMRKhUeb/yGjRBlpGu9CLXx4LJJb1dUZeNWBCbjpjN0P5hlXD3tyml8aBJdHWtudeBvauUmxoxIfrkQW6XNwiplAXB/2bsECd1k5lPRnWzGAt8WOVI/ztOITmykZGLz9BHFIQ8i+Zte6ORlwfNiFyTLE9VE4ubzwIaOWr95MTXwtqC+zXIVwPqjZ0FYs7Ij0PnUAx805AK0I+I/4Fb58HJ9hdMeMiMsVb3Sz+AWby208QQubkAVfm4Zf4/RjW6uBlc1pSwYKy0fq13fHb6VltVXE+Q+Cbj8tYLJHStTT8bCepOcgGsvBkw+8WiuYZBHOX6gn3L/+5
_domainkey.example.com.	TXT	o=-;

Important!

For one sender in the Admin Panel, you can select only one key.

Where else this is configured

DKIM key and selector are set in the Admin Panel:

• Keys — creation (generate key pair) or paste an existing key. Key type: dkim.
• Senders — From domain DKIM key (select from list) and From domain DKIM selector (e.g., altcraft). If mail_from_type is not aligned, additionally set Secondary DKIM key and Secondary DKIM selector.
• Sender pools — DKIM key and DKIM selector (used when mail_from_type = aligned)

The selector in DNS must match the selector in the sender settings. For example, if the sender specifies selector altcraft, the DNS record should be altcraft._domainkey.example.com.

DMARC settings

DMARC technology allows the mail server to decide what to do with email if something is wrong with the DKIM and SPF records.

We recommend setting rules that reject messages received from other IP addresses or signed incorrectly.

Domain	Record type	Example contents
_dmarc.example.com.	TXT	v=DMARC1; p=reject; sp=reject; rua=mailto:report@example.com

You will be able to receive reports at report@example.com.

Where else this is configured

DMARC is configured only in DNS. The report email (rua=mailto:...) is specified by the domain administrator. DMARC verifies that the domain in From aligns with SPF and DKIM results — make sure the from-domain (determined by the Sender Email field in the resource or template) matches the domain for which SPF and DKIM are configured.

Additional settings

BIMI (optional)

BIMI technology (Brand Indicators for Message Identification) is used together with SPF, DKIM, and DMARC to display a branded image next to the email in the recipient's inbox. This setting is optional — it is needed if you want your company logo to appear next to emails in supporting mail clients.

To use this technology, you need to specify a path to a file in svg format. The image should be square and have no additional layers.

Add the following record in your domain settings:

Domain	Record type	Example contents
default._bimi.example.com	TXT	v=BIMI1; l=https://example.com/bimi/bimi.svg

You can also use the record generator at https://bimigroup.org/bimi-generator/.

Troubleshooting

If DKIM, SPF, DMARC, or antispam headers show poor values after a test send, check your domain settings, sender configuration, and email content.

DKIM, SPF, or DMARC fail verification

If the email headers show dkim=fail, spf=fail, or dmarc=fail, the issue is most likely related to domain configuration.

Check:

• DKIM selector in the admin panel;
• DKIM key in the domain DNS record;
• SPF record for the domain;
• DMARC record for the domain;
• domain in the From field;
• reverse address domain;
• domain alignment for DMARC to pass.

If the domain uses a single DKIM selector, the admin panel must specify the same selector. For example, if the DNS publishes the record:

mail._domainkey.example.com

then the admin panel must specify the selector for DKIM as:

mail

If the admin panel specifies a different selector, the mail server will not find the correct DKIM key or will verify the email against a different DNS record.

Also check the DKIM key itself. The public key value in DNS must match the key used to sign the email. If the key was replaced in DNS but not updated in the admin panel, DKIM may fail verification.

SPF fails verification

If the headers show spf=fail, check the SPF record for the domain used in the reverse address.

The reverse address is usually displayed in the header:

Return-Path: <bounce@example.com>

or in the SPF verification result:

spf=fail smtp.mailfrom=bounce@example.com

SPF is verified not against the visible sender address in From, but against the domain from smtp.mailfrom / Return-Path.

Check that the domain's SPF record allows sending from the required server or service. For example:

example.com. TXT "v=spf1 ip4:192.0.2.4 -all"

If sending through an external service, it must be added to the SPF record via include or another recommended mechanism.

Also check that the domain does not have multiple SPF records. For a single domain, there should be one TXT record starting with:

v=spf1

DMARC fails verification

If DKIM and SPF show pass, but DMARC shows fail, the issue is most often related to mismatched domains.

Example of a problematic situation:

From: News <news@example.com>
Return-Path: <bounce@mailer-service.com>

Authentication-Results: mx.example.com;
 dkim=pass header.i=@mailer-service.com;
 spf=pass smtp.mailfrom=mailer-service.com;
 dmarc=fail header.from=example.com

In this case, DKIM and SPF pass verification, but not for the example.com domain specified in From.

For DMARC to pass, at least one of the following conditions must be met:

• DKIM passes verification, and the DKIM domain aligns with the domain in From;
• SPF passes verification, and the smtp.mailfrom domain aligns with the domain in From.

If a different domain is used in the From field, it must also be configured: it needs DKIM, SPF, and DMARC records.

A different From-domain is used

Issues may arise if the email uses one sender domain, but the settings are configured for a different domain.

For example, the admin panel has the domain configured:

example.com

but the email is sent from the address:

From: News <news@promo.example.net>

In this case, DKIM, SPF, and DMARC must also be configured for the promo.example.net domain. If this domain is not configured, verification may fail.

Before a test send, make sure the domain in From matches the domain configured in the admin panel, or is a properly configured subdomain of it.

Admin panel values override other settings

Settings specified in the admin panel may override values from other locations. For example, if the panel specifies a separate DKIM selector or reverse address, these values will be used when sending.

Check the settings for:

• sender domain;
• sender;
• virtual sender;
• reverse address;
• DKIM selector;
• template or campaign, if they allow specifying the sender manually.

If the settings differ, the email may go out with a different From, different Return-Path, or different DKIM signature.

Domain or IP address DNS records not configured

For proper sending, DNS records for the domain and sending IP address are required.

Check:

• A record for the domain;
• MX record for the domain;
• PTR record for the sending IP address;
• correctness of the reverse address;
• domain availability in DNS.

The PTR record is especially important for the sending IP address. It links the IP address to a domain name and is used by mail systems as one of the reputation signals. The PTR record is configured with your hosting provider or IP management panel, not in the domain's DNS zone.

Verifying records with dig

Check basic records:

dig example.com A
dig example.com MX
dig example.com TXT

Example successful output for an A-record:

; <<>> DiG 9.18.28 <<>> example.com A
;; ANSWER SECTION:
example.com.            300     IN      A       192.0.2.4

Good result: ANSWER SECTION contains a record with an IP address. Bad result: NXDOMAIN (domain not found) or empty ANSWER SECTION.

Check the PTR record (reverse DNS) for the sender IP:

dig -x 192.0.2.4

Example successful output:

; <<>> DiG 9.18.28 <<>> -x 192.0.2.4
;; ANSWER SECTION:
4.0.2.192.in-addr.arpa. 300     IN      PTR     mta-1.example.com.

Good result: PTR points to a domain matching the A-record (mta-1.example.com). Bad result: NXDOMAIN (PTR not configured) or PTR points to a different name.

Check the DKIM record (replace altcraft with your selector):

dig altcraft._domainkey.example.com TXT

Example successful output:

; <<>> DiG 9.18.28 <<>> altcraft._domainkey.example.com TXT
;; ANSWER SECTION:
altcraft._domainkey.example.com. 300  IN      TXT     "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

Good result: record found, starts with v=DKIM1; k=rsa; p=. Bad result: NXDOMAIN (selector not found) or p= key is empty.

Check the DMARC record:

dig _dmarc.example.com TXT

Example successful output:

; <<>> DiG 9.18.28 <<>> _dmarc.example.com TXT
;; ANSWER SECTION:
_dmarc.example.com.     300     IN      TXT     "v=DMARC1; p=reject; sp=reject; rua=mailto:report@example.com"

Good result: record found, contains v=DMARC1 and policy p=. Bad result: NXDOMAIN (DMARC not configured) or policy p=none (not recommended for production).

Domain or IP address not yet warmed

Even with correct DKIM, SPF, and DMARC, an email may receive a poor antispam score if sending started at a high rate to an unwarmed domain or IP address.

A new domain or new IP address requires gradual warming. Start with a small volume of sends and increase the rate gradually.

If you launch mass sending at a high rate immediately, mail systems may start rejecting emails, sending them to spam, or lowering the sender's reputation.

During warming, monitor:

• deliverability;
• opens and clicks;
• spam complaints;
• bounces;
• spam placement;
• domain and IP address reputation.

Email fails antispam filters

If DKIM, SPF, and DMARC pass verification, but the email receives a high SCL, BCL, or ends up in spam, the issue is most likely not related to domain authentication, but to email content or sender reputation.

Different mail providers use different antispam filters with different headers and scores. For example, SpamAssassin uses X-Spam-Status and X-Spam-Score, Microsoft 365 uses SCL and BCL, and Gmail does not publish numeric scores. For universal checking, use online testers (see below).

Check:

• email subject;
• email body text;
• HTML markup;
• text-to-image ratio;
• links;
• domains in links;
• attachments;
• presence of URL shorteners;
• domain reputation;
• IP address reputation;
• sending frequency;
• complaint and bounce history.

The email should look acceptable to antispam filters: no suspicious links, aggressive wording, unnecessary attachments, broken markup, or phishing indicators.

Useful tools for verification

For diagnostics, you can use external services:

• Mail-Tester.com — send a test email to a unique address, receive a 0–10 score with detailed analysis of DNS, headers, SPF, DKIM, DMARC, and content.
• MXToolbox — DNS record, SPF, DKIM, DMARC, PTR, and blacklist checking.
• Google Postmaster Tools — monitoring domain reputation, IP addresses, delivery errors, and complaints for Gmail.
• Postmaster Mail.ru — monitoring reputation and send quality for Mail.ru.
• Microsoft SNDS — monitoring IP address reputation in Microsoft infrastructure.

After making corrections, perform another test send and check the email headers again. A normal authentication result:

dkim=pass
spf=pass
dmarc=pass

If you use Microsoft 365 or Outlook, additionally check:

compauth=pass
SCL:0
BCL:0