Email: sending domain configuration

Requirements from major email providers

Major email providers (Gmail, Yahoo, Outlook, etc.) require that the email address specified in the From field actually exists on the mail server. Additionally, it is recommended that the domain of this address have an A-record pointing to a real resource.

For example, if From: info@example.com, then example.com must have an A-record, and the mailbox info@example.com must be created on the mail server for that domain.

SPF configuration

Sender Policy Framework (SPF) is a technology that verifies 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 emails from various hosts.

We recommend adding records for different SPF versions:

Domain	Record type	Contents
example.com.	TXT	v=spf1 include:spf.akmta.net ~all
example.com.	TXT	spf2.0/pra include:spf.akmta.net ~all

The domain spf.akmta.net contains the current list of Altcraft sender IP addresses.

note

If you are using the Cloud version, SPF is covered automatically by the include:spf.akmta.net record.

If you are using the On-premise version, the domain used for MAIL FROM is determined by the sender and pool settings. Make sure the SPF record for your domain allows sending from that domain.

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 include:spf.akmta.net 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 include:spf.akmta.net ~all

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

DKIM configuration

DomainKeys Identified Mail (DKIM) adds a digital signature to your email, linked to the from-domain. The signature is automatically verified on the recipient side, then used to refine sender reputation and displayed to the user. The email is signed with a private key installed on the sender side and unknown to anyone else. The public key is placed as a special TXT record on a subdomain of the from-domain.

You need to add the following records. Choose a selector — for example, ak. The selector is the prefix in the DKIM subdomain name. Selectors allow different senders to use the same domain: for example, ak._domainkey.example.com for Altcraft and mail._domainkey.example.com for another service.

Domain	Record type	Contents
akru2022._domainkey.example.com.	TXT	v=DKIM1; k=rsa; p=<your personal key>
_domainkey.example.com.	TXT	o=-;

note

The selector in DNS must match the selector specified in the platform's sender settings. The from-domain is determined by the Sender Email field — set in the resource, template, or mailing. Priority order: mailing, template, resource.

DMARC configuration

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 third-party IP addresses or signed incorrectly.

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

note

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 mailing, template, or resource) matches the domain for which SPF and DKIM are configured.

Tracking configuration

You need to add the following record on a subdomain of your from-domain:

Domain	Record type	Contents
trk.example.com.	CNAME	trk.aksend.net

Additionally, you can use as many tracking domains as needed; the configuration is the same.

note

The record trk.aksend.net is used only for the Altcraft cloud solution. If you are using an On-premise solution, enter your own record. In the UI when creating a resource, the Tracking Domain field allows you to set a domain for a specific resource.

CNAME settings for processing bounces

Cloud clients must also configure an additional CNAME record pointing to the domain akmta.net:

Record example:

ac-bounces.example.com IN CNAME akmta.net

Here ac-bounces is the subdomain, and example.com is your from-domain. This subdomain will be used in the Return-Path, allowing SPF authentication and "alignment" to improve email deliverability.

A-record configuration for the sender (AKMTA)

On-premise only

A-record, PTR-record, and MX-record are required only for On-premise clients. Cloud clients use Altcraft infrastructure and should not configure these records.

For the sender to work correctly, you need to add an A-record pointing to the IP address of the mail server (AKMTA). Choose a subdomain for your from-domain and add the record:

Domain	Record type	Contents
mta-1.example.com.	A	<IP address of your AKMTA>

Additionally, it is recommended to configure a PTR-record (reverse DNS) for the sender IP address:

Domain	Record type	Contents
<reverse IP>.in-addr.arpa.	PTR	mta-1.example.com.

For example, for the IP address 192.0.2.4, the PTR-record would be 4.0.2.192.in-addr.arpa. with the value mta-1.example.com.. The PTR record is configured with your hosting provider or IP management panel, not in the domain's DNS zone. The PTR value should match the A-record.

MX-record configuration

To send emails through your own domain, you need to add an MX-record pointing to the sender's mail server:

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

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.

note

BIMI email authentication is supported by email services such as Fastmail, Gmail, and Yahoo!

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

Add the following record in your domain settings:

Domain	Record type	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 verification fails

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 DKIM selector as:

mail

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

Also verify 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 verification fails

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 check result:

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

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

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

example.com. TXT "v=spf1 include:spf.example.net -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. There should be only one TXT record per domain starting with:

v=spf1

DMARC verification fails

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

Example of a problematic scenario:

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 domain example.com 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 its own DKIM, SPF, and DMARC records.

A different From-domain is used

Issues may arise if the email uses one sender domain while the configuration is set up 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 domain promo.example.net. 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.

DNS records are not configured for the domain or IP address

For correct email delivery, DNS records for both the domain and the 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 ak with your selector):

dig ak._domainkey.example.com TXT

Example successful output:

; <<>> DiG 9.18.28 <<>> ak._domainkey.example.com TXT
;; ANSWER SECTION:
ak._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).

The domain or IP address has not been warmed up yet

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 warm-up. 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 warm-up, 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 the 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;
• history of complaints and bounces.

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

Useful verification tools

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