Setting up SPF, DKIM, and DMARC

As major authentication mechanisms, Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) are designed to protect mail servers from domain name abuse.

SPF & DKIM authenticate the originating domain and the emails sent from this domain, otherwise the sender’s emails will be rejected or identified as spam.

DMARC is an authentication protocol that protects and authenticates emails.

To apply their policies, SPF & DKIM use DNS records in the following way:

1. The recipient’s mail server receives an email from [email protected] with mta.mindbox.cloud as the sending server.
2. The recipient’s server makes a request to the DNS of the company.com domain to check the SPF and DKIM records.
3. If SPF and DKIM records are missing, the email becomes SPF- and DKIM-neutral and goes through further filters.
4. If SPF and DKIM records have been found, the server checks if mta.mindbox.cloud is whitelisted as company.com’s sender.
5. If mta.mindbox.cloud has not been whitelisted, the email is rejected or assigned the "neutral" status.
6. If mta.mindbox.cloud has been whitelisted, the email is assigned the "pass" status and ranked higher for other filters.

DNS

All signatures are set up using client DNS records, the dashboard for which is available from your hosting provider.

Once the records are published on the domain’s DNS, it may take up to 24 hours for external servers to see the filters both on Mindbox’s side and through mxtoolbox.

Example of DNS records:

If you occasionally see an error message informing you that no DKIM record has been found, please contact your hosting provider’s support team. This might mean that external servers sometimes cannot see your domain records.

SPF

SPF (Sender Policy Framework), a sender policy infrastructure, lists the servers and IP addresses authorized to send messages from your domain name to confirm that you are the sender.

Once an email is received from Mindbox’s server with you as the sender, the mail server checks the SPF record to determine whether Mindbox is authorized to send emails using your sender name.

Setting up SPF

We recommend using the following SPF configuration:

v=spf1 a mx include:spf.mindbox.cloud ?all

Where

v is a record version;

a mx specifies that you can send messages from the IP addresses listed in the DNS records;

include specifies additional IP addresses to send emails from (which includes IP addresses that belong to other domains) or a domain that lists these IP addresses;

[spf.mindbox.cloud](http://spf.mindbox.cloud) is Mindbox’s domain that lists all of Mindbox’s IP addresses — as soon as new addresses are created, they are added to this domain’s records without affecting any senders’ records;

?all specifies that emails from unlisted IP addresses should be received and assigned a specific status rather than rejected. You are free to change this setting.

An SPF record is created once per domain and then updated with new IP addresses. So, if you use a non-Mindbox email sender, you should add include spf.mindbox.cloud into the SPF record.

The sender’s subdomain requires its own SPF record.

Checking the SPF record

Check the SPF record on mxtoolbox: make sure that it can be identified, is the only SPF record for the domain, and contains Mindbox’s IP addresses.

Click SPF Record Lookup to display the table below. Please note that when you update records, you will have to wait from 30 minutes to 4 hours until the updates take effect.

Next, send an email to gmail.com from a trusted server (any of the ones you added to SPF — for example, Mindbox’s server). Open the email and click "Show original".

Look for the "Received-SPF: pass" string. If you can find it, your setup was completed successfully.

A "failed" or "neutral" string means an error in the record so the Gmail server cannot trust the server from which the email was sent.

You can check all domain records in DNS Lookup Text Record.

DKIM

As an email forgery detection method, DKIM (DomainKeys Identified Mail) confirms that the email sender’s server is authorized to send messages from a given domain name. DKIM improves sender reputation and delivery rate by applying private and public keys to check emails.

Setting up DKIM

A public & private keys pair is generated individually for every email sender’s server. A public key is added to the DKIM record published on the sender’s domain DNS, while a private key signs outbound messages.

In Mindbox, you can generate the key pairs in Admitinstrative Settings → Communication → Email settings.

Once you add and save a sender, the "Generate DKIM" button will appear. You can find instructions on how to generate DKIM from the system in this guide.

Once you click this button, a string is generated and displayed for the domain. Add it to the DNS record.

Add the second record _domainkey o=~; to indicate that this domain can send messages without a DKIM signature.

Checking the DKIM record

Look up the DKIM record in mxtoolbox.

Make sure that the key displayed in mxtoolbox matches the exact string in Mindbox’s email settings. Otherwise, the DKIM record setup will be invalid. If this issue occurs in Mindbox’s settings, compare the strings manually.

Make sure that the key contains the relevant selector. In our case, this is Mindbox.

If the key does not contain this selector, check the mindbox._domainkey record because a missing selector means that there is no DKIM record set up or the record name contains an error.

You can also send an email to the gmail server and click "Show original" to check DKIM setup.

If you can find dkim=pass in the original email, your DKIM setup is correct.

DMARC

A DMARC digital signature allows you to set specific steps that will be applied to emails that failed DKIM and SPF checks at the time of sending.

Having found that emails mismatch the SPF & DKIM records, i.e., the sender’s IP address and server are blocklisted, the mail receiver server checks the DMARC record to determine what to do with the email: reject, mark as spam, or do nothing.

Setting up DMARC

A basic DMARC record will be structured as follows:

Record name: _dmarc.company.com

Value (TXT): v=DMARC1; p=none

There must only be one DMARC record for each domain and its subdomains.

v= is a record version;

p= is the policy used to handle emails that failed SPF and DKIM records checks.

1. p=none means that the recipient’s mail server should receive the message and apply its local message classification as usual, whatever the results of both the SPF and DKIM checks.
2. p=quarantine means that the mail server must place the email that fails both the SPF and DKIM checks in the spam folder.
3. p=reject means that the mail receiver must totally reject the email that fails both the SPF and DKIM checks.

Use the rua= tag to specify an email address where you’d like to receive reports on all emails with their DMARC check results.

Use the ruf= tag to specify an email address where you’d like to receive reports on each specific email that failed SPF and DKIM checks and had DMARC policies applied.

You can read more about DMARC reports more in Google’s Workspace Admin Help guide.

Use the pct= tag to specify a percentage of messages to which to apply a certain DMARC policy (enter a number from 1-100).

Recommendations

The p=quarantine or p=reject policies can be set up as you prefer.

If you decide to make your DMARC policy more strict, proceed gradually:

1. First, configure the p=none policy and DMARC reporting in the rua and ruf tags to ensure that you monitor how many messages fail DMARC checks and to resolve the issues.
2. Once most issues are solved, you can introduce stricter policies using the pct tag, but make sure to monitor reported issues.

Reports will show results for all messages sent across the entire domain rather than from Mindbox only.

Important notes

1. Once you select the p=quarantine policy, the email receiver will mark certain emails as spam, which will affect delivery and open rates.
2. Once you select the p=reject policy, the email receiver will reject certain emails, which will affect the delivery rate.

In both cases, you should first address any digital signatures issues.

Checking the DMARC record

To check the DMARC record, go to mxtoolbox and enter your domain name.

If the DMARC record is set up, you see a detailed table:

To check DMARC, send a message to gmail.com and click "Show original".

You can find the DMARC authentication result in the headers: