Skip to main content

SPF, DKIM, and DMARC - How to improve spam reputation and avoid bounces

How to Improve Spam Reputation and avoid Bounces​

What's this page about?

In addition to general information about the protocols, paramaters, and DMARC-Reports you will find the following instructions with sample configurations for:

  1. Setting the SPF entry and its parameters as a TXT record in the DNS settings of your provider
  2. Setting the DKIM entries as CNAME records in the DNS settings of your provider
  3. Setting the DMARC entry and its parameters as a TXT record in the DNS settings of your provider.

Requirements:

Before you continue, make sure that e-mails from your domain (for example, "my.name@example.com") can be sent and received through mailbox.org. To do this, please follow this guide: Using e-mails with a custom domain.

This guide describes three important protocols and their settings in the Domain Name System (DNS) that help improve your domain's spam reputation: SPF, DKIM, and the protocol built on them, DMARC. As most providers use these standards to detect spam, properly configuring them reduces the risk of servers classifying and sorting out your e-mails as spam.

With the settings from this guide, you can reach your recipients more reliably, and by the way, your domain, and thus every one of your e-mails, then also meet the relevant Internet standards - which ultimately also serves security. mailbox.org generally recommends setting these parameters if you use your own domains for e-mails. Business customers, who regularly send large amounts of e-mails, should follow this advice: There are clear indications that providers sort out increasingly stricter with rising data volumes. Private customers who use email addresses "@mailbox.org" without custom domains do not need to worry about this. We have already set things up and secured for you. This article aims to increase the reliability of email delivery associated with custom domains, avoid faulty deliveries (e.g., Undelivered Mail Returned to Sender), and make email communication more secure.

So it is worth taking a closer look at the terms SPF, DKIM, and DMARC. These three protocols are core elements of email authentication and play a crucial role in the detection and prevention of spam and phishing attempts. As a result, they are strongly linked to your domain's spam reputation and have a direct influence on how likely it is that your e-mails will be classified as spam.

A number of email service providers, including Google, use these protocols to verify the authenticity of e-mails. If an email sent from your domain fails the SPF or DKIM checks, Google can reject the email and generate a bounce. A bounce is essentially an automatic response that signals that the email could not be delivered. In this case, the most likely cause of the bounce would be that the email was classified as potential spam or a phishing attempt.

Therefore, it is important to implement SPF and DKIM correctly in your DNS settings. This ensures that your emails can successfully pass the spam filters of Google and other email service providers. Furthermore, the correct implementation of SPF and DKIM helps to improve the spam reputation of your domain and to deliver your emails more reliably. These advanced settings are part of the Internet standards and contribute significantly to the security of email traffic.

Bounce - Example of a rejected E-Mail

Example of a Bounce

Von: MAILER-DAEMON@xxxxxx.mailbox.org
An: mustermann@example.com
Datum: 22.07.2023 22:29 CEST
Betreff: Undelivered Mail Returned to Sender

This is the mail system at host xxxxxx.mailbox.org.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

The mail system <xxxxx@gmail.com>: host gmail-smtp-in.l.google.com [108.xxx.xx.xx] said: 550-5.7.26 This mail is unauthenticated, which poses a security risk to the 550-5.7.26 sender and Gmail users, and has been blocked. The sender must 550-5.7.26 authenticate with at least one of SPF or DKIM. For this message, 550-5.7.26 DKIM checks did not pass and SPF check for [example.com] did not 550-5.7.26 pass with ip: [80.xxx.xx.xxx].

The sender should visit 550-5.7.26 https://support.google.com/mail/answer/81126#authentication for 550-5.7.26 instructions on setting up authentication.
m17-20020adffe51000000b00314310e5ffbsi3113311wrs.471 - gsmtp (in reply to end of DATA command)

An Overview of the Protocols and Parameters​

SPF (Sender Policy Framework) is a procedure that serves to determine which mail servers are authorized to send e-mails on behalf of your domain. By using SPF, you can prevent spammers from misusing your domain for unwanted and misleading e-mails. In practice, the recipient mail server checks the SPF entries in the DNS settings of your domain and compares them with the IP address of the sending mail server. If the sending mail server is listed in the SPF entries, the email is classified as legitimate.

DKIM (DomainKeys Identified Mail) is another email authentication procedure that serves to verify the integrity and authenticity of an email. With DKIM, the sending mail server signs every outgoing email with a digital key. This key is then stored in the DNS entry of your domain. The recipient mail server can then check this signature by retrieving the DKIM key from the DNS settings of your domain. If the signature is valid, the recipient can be sure that the email actually comes from your domain and has not been manipulated during transmission.

DMARC (Domain-based Message Authentication, Reporting & Conformance) is an email validation protocol built upon the SPF and DKIM technologies, designed to prevent the misuse of domains in email communication. Through DMARC, a domain owner can specify how the receiving server should handle e-mails that fail the SPF and DKIM checks. With such settings in place, decisions can be made whether to reject the questionable e-mails, move them to the spam folder, or deliver them normally. Additionally, DMARC facilitates the exchange of reports between the sending and receiving servers to enhance the understanding of potential security issues. In short, it's a helpful tool for improving email security and increasing the deliverability of legitimate e-mails.

Examples of DNS-Entries​

The table contains examples of the DNS entries you need for your provider to configure SPF, DKIM, and DMARC. Replace "example.com" with your domain and "postmaster@example.com" with your email address.

HostnameRecord TypeZielProtokoll
@TXTv=spf1 include:mailbox.org ~allSPF
MBO0001._domainkey.example.comCNAMEMBO0001._domainkey.mailbox.org.DKIM
MBO0002._domainkey.example.comCNAMEMBO0002._domainkey.mailbox.org.DKIM
MBO0003._domainkey.example.comCNAMEMBO0003._domainkey.mailbox.org.DKIM
MBO0004._domainkey.example.comCNAMEMBO0004._domainkey.mailbox.org.DKIM
_dmarc.example.comTXTv=DMARC1;p=none;rua=mailto:postmaster@example.comDMARC

Protocols and Parameters in Detail​

Sender Policy Framework (SPF)​

In the Domain Name System (DNS), so-called MX records define which mail servers are responsible for receiving e-mails for a specific domain. However, DNS does not control which servers are authorised to send e-mails. That is why SPF (Wikipedia) is used by administrators to announce on the Internet which server is authorised to send outgoing mail for a particular domain. As far as we know today, spam as a large-scale phenomenon continues to exist because it is still possible that a sender using any computer (like an arbitrary, hacked Windows PC, for example) can pretend to send e-mails on behalf of somebody else and for a long time, there was no way to verify senders and prevent this from happening.

SPF was devised to remedy this situation and is formalised in the Internet standard RFC 4408. The Sender Policy Framework allows administrators to specify one or more mail servers for a domain and thus, define legitimate origins of e-mail for that domain. A typical SPF record is stored in the DNS as a TXT record and may have the following content:

v=spf1 include:mailbox.org ~all

What does this entry do?

In this example, "v=spf1" indicates the SPF version used; the statement "include:mailbox.org" means that all SPF settings of mailbox.org automatically apply to this domain. In other words, all mail servers of mailbox.org (both the domain mailbox.org but also all IP addresses used by the domain) are authorised to send e-mails for this domain. While it remains possible to use other mail servers besides mailbox.org to send e-mails, these should be legitimised in the same way by providing the corresponding DNS entries.

Avoid multiple SPF-Entries!

Make sure that only one SPF record exists in the DNS settings of your provider. Contradictory information can lead to problems!

The permitted SPF parameters in the TXT record are the following​

ParameterDescription
v=spf1The SPF version used. Here: 1
ip4:213.203.238.0/24All servers within the IPv4 range 213.203.238.0/24 are authorised to send e-mails for the domain.
ip6:fda0:6a92:125f:0:42f6:6f7e:f9fb:b531/64All servers within the IPv6 range ip6:fda0:6a92:125f:0:42f6:6f7e:f9fb:b531/64 are authorised to send e-mails for the domain.
mxAllows those mail servers specified in the MX records for this domain to send e-mails for the domain.
include:example.comAllows all servers under the domain example.com to send e-mails for the domain. This will require another DNS query for the domain example.com after the TXT record was processed.
?allAny mail servers not listed in the record may also send e-mails for the domain, and without receiving a negative (or positive) rating as a result.
-allAny mail servers not listed in the record are not authorised to send e-mails for the domain.
~allReceiving mail servers are asked not to reject any incoming e-mails from this domain. However, they will treat those e-mails as potential spam and perform additional checks to confirm the sender.
Complete List of SPF Entries​

A complete list of defined SPF record entries is available at OpenSPF.

SPF - Sample Configuration at Hetzner, Netcup, and INWX​

The DNS entry forms in provider administration interfaces may come in different layouts. The figures below illustrate how the SPF-TXT entries should look like at Hetzner, Netcup and Inwx.

Figure 1: Hetzner will insert the quotation marks in "Target" automatically and uses an "@" symbol as a placeholder for the domain name.

Figure 2: Netcup also uses the "@" symbol as a placeholder for the domain name.

Figure 3: At INWX, the "Name" field does not require a value.

DomainKeys Identified Mail (DKIM)​

DKIM (Wikipedia) is a technical protocol that is used to establish the authenticity of senders. It goes even further than SPF by securing the information in e-mails with a digital signature, for which a special key must be stored in the DNS. Only with this key can another mail server verify whether a message with a corresponding header was really sent from the specified domain. If the check fails, then the e-mail may receive a negative rating and it becomes more likely it will be treated as spam. The e-mail header used here is called "DomainKey-Signature-Header" and for the entire mechanism to work, the mail server administrator (i.e., the mailbox.org admins) must create and cryptographically sign a signature and make this available for e-mail communication (i.e, add it to the Domain Name System). If you enable DKIM as per the following instructions, then this will reduce the likelihood that servers receiving e-mails from your domain will incorrectly mark these e-mails as spam.

DKIM Parameter & Settings​

There are several ways to successfully create DKIM entries. mailbox.org recommends entering it as a "CNAME" record. We currently provide four keys for DKIM that you need to deposit as DNS entries with your domain registrar. Deposit all four keys in four separate CNAME entries:

Individual Key (replace example.com with your custom domain)Record TypeTarget
MBO0001._domainkey.example.comCNAMEMBO0001._domainkey.mailbox.org.
MBO0002._domainkey.example.comCNAMEMBO0002._domainkey.mailbox.org.
MBO0003._domainkey.example.comCNAMEMBO0003._domainkey.mailbox.org.
MBO0004._domainkey.example.comCNAMEMBO0004._domainkey.mailbox.org.

Figure 4 (table) shows how a typical entry would look like at the provider Hetzner, where the full stop at the end of the entry is an important part of the key. Please make sure to store the four keys in four separate CNAME entries.

DKIM - Sample Configurations at Hetzner, Netcup, and INWX​

Figure 5: CNAME DNS record for the key MBO0001. at Hetzner

Figure 6: CNAME DNS record for the key MBO0001. at Netcup does not require a full stop (.) after your domain...

Figure 7: .... and the same goes for provider INXW.

Deprecated method: Specifying DKIM information in TXT records

mailbox.org changed their configuration recommendations for DKIM back in 2021. Previously, we recommended to set DKIM entries as described below by creating TXT records. While this method will continue to work, it comes with a major disadvantage: Whenever we need to make changes to our keys, all TXT entries referring to these keys will become invalid, causing users a lot of hassle as a result. Customers and admins who still use TXT entries for DKIM should act now to avoid their e-mails being increasingly flagged as spam. Those who set up their DKIM key with a CNAME entry don’t have this problem as they don’t need to make any changes to the CNAME entry - the key reference there will always remain valid.

If your current setup has DKIM information specified in a TXT record, it will continue to work for now and you can switch over to a new configuration at a later date. However, whenever the changes are being made, it is crucially important to perform the steps in the right order: First, delete the TXT record from the DNS and then add the CNAME record. If you can make both changes quickly without delay, then DKIM should remain available while the information is automatically getting updated on the Domain Name System.

Domain-based Message Authentication, Reporting and Conformance (DMARC)​

DMARC entries determine whether and how mail servers will verify DKIM signatures and SPF entries for incoming mail. If you are sending e-mails via mailbox.org, a DMARC record will provide a kind of "recommendation" to the receiving server on how to deal with e-mails that have your sender address, but which may not be DKIM-signed, for example. In order to make use of DMARC, you must have made a DKIM entry in the DNS and have SPF set up as well.

  • In your DNS settings, create (another)"TXT" record.
  • In the field "Host", "Name" or "Hostname", insert the value "_dmarc.", followed by your e-mail domain name. For example: "_dmarc.example.com". Pay attention to the labelling variants used by different providers (see info box).
  • In the field**"Value","Target"** or**"Destination"**, add an entry like "v=DMARC1;p=none;rua=mailto:postmaster@example.com". Whatever e-mail address you specify here will receive any error messages resulting from future DMARC checks.
  • For "TTL" (Time-To-Live) we recommend the value "400".

DMARC - Sample Configurations at Hetzner, Netcup, and INWX​

Figure 8 shows how a provider's dialogue (here the German provider Hetzner) presents the entries relevant for your settings:

Figure 8: Hetzner – Creating a DMARC TXT record in the DNS

Figure 9: Netcup – Creating a DMARC TXT record in the DNS

Figure 10: Creating a DMARC TXT record in the DNS at INXW

DMARC - Options and Parameters​

The main parameters for the DMARC TXT record in the DNS are the following:

ParameterDescription
v=DMARC1Uses DMARC protocol version 1
ruf=mailto:e-mail addressThe owner of the stated e-mail address receives error reports in the form of a "Forensic Report". In Germany, the use of this option is not permitted, as you might be receiving e-mails that were not addressed to you. We advise against using this parameter.
rua=mailto: e-mail addressThe owner of the e-mail address**(note: this email has to belong to the domain being monitored)** will receive detailed reports about all DMARC activities. Note that these reports can be very long and arrive frequently, so we advise you use a separate e-mail address for this purpose. The reports normally contain the date, time, recipient and sender domains, IP addresses, SPF and DKIM information, the DKIM policy used and the domain associated with SPF and DKIM.
p=noneThis parameter is mandatory and defines how the receiving server should proceed if an email could not be authenticated. Available options are the following:

p=none: No special action will be taken, meaning the message will be delivered to the destination mailbox. The e-mail will be logged in the daily report, though, and the report will be sent to the address stored in the "rua" parameter (above).
p=quarantineIncoming messages without correct authentication are marked as spam and placed in the recipient's spam folder. Recipients can check the spam folder to see and open the e-mails or to check if the e-mails were moved there correctly.
p=rejectUnauthenticated e-mails are rejected outright and the receiving server will send a bounce message (mail undeliverable) to the sender.

DMARC - Monitor, evaluate & adjust​

Please be aware that you should not initially set the "p=" parameter to the restrictive values "quarantine" or "reject". We initially recommend using the "p=none" option, monitoring the situation, evaluating the reports, and using them as benchmarks for necessary adjustments. Typical issues arising from overly restrictive settings include emails (bounces) rejected by the receiving server or invalidated electronic signatures during email forwarding. Occasionally, other departments within your company might utilize the mail server for applications unknown to the mail admin, yet they might be of high importance to the business (such as monitoring, marketing newsletters, etc.). From the reports, you can extract valuable information and take the necessary actions. Once everything is clear, you can impose stricter rules. When evaluating DMARC reports, pay attention to the following three factors:

  1. Which servers or external providers are sending emails on behalf of your domain?
  2. What proportion of emails from your domain meets DMARC requirements?
  3. Which servers or services are sending emails that do not comply with DMARC guidelines?

Evaluating & Understanding DMARC Reports​

There are two types of DMARC reports:

DMARC Aggregate Reports

DMARC Aggregate Reports provide insight into the DMARC activities of a specific domain over a defined period. These consolidated DMARC reports deliver information such as the number of messages that have successfully or unsuccessfully passed the DMARC authentication, the IP addresses of the sending servers, and the authentication methods applied.

DMARC Forensic Reports

DMARC Forensic Reports offer deep insights into specific email messages that failed the DMARC check. These forensic DMARC analyses include both the complete email message as well as data on the authentication status and the reasons for failure. With the help of these reports, specific cases of email deception or misuse can be traced.

There are different formats in which DMARC reports can be generated, including XML, CSV, and JSON. The chosen format depends on the preferences of the domain owner or their DMARC service provider. Some email recipients also provide the domain owner with DMARC error reports, which supply information about messages that failed the DMARC verification and were thus rejected or quarantined.

More Details about DMARC-Reports

More information about how to read and understand DMARC-Reports can be found here: What are DMARC-Reports and how to read them? (available in multiple languages)

Troubleshooting​

SPF-Troulbeshooting​

Linux & macOS​

Linux and MacOS users can use the terminal application to issue the command "dig", followed by their domain name and any other desired entries:

DNS TXT query using the Linux terminal application

dig example.com txt

; <<>> DiG 9.11.3-1ubuntu1.13-Ubuntu <<>> example.com txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64449
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;example.com.            IN    TXT

;; ANSWER SECTION:
example.com.        1800    IN    TXT    "v=spf1 include:mailbox.org ~all"

;; Query time: 120 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Aug 28 12:33:50 CEST 2020
;; MSG SIZE  rcvd: 174

Please double-check the line after "ANSWER SECTION" has an entry that starts with "v=spf1" and contains "include:mailbox.org".

Windows​

Windows users can query the DNS through the command line interface (cmd.exe) by running “nslookup”. Please make sure to replace "example.com" with your own domain name:

DNS TXT query using the Windows command line interface

nslookup -type=TXT example.com

Server:  UnKnown
Address:  192.168.179.1

Non-authoritative answer:
example.com       text =

        "_globalsign-domain-verification=ZKyu_ATrp-l27Q11kIjqiPNjI6Tt_g7vnp3qYsViBk"

       "v=spf1 include:mailbox.org ~all"

Please double-check if the response contains a line that starts with "v=spf1" and contains "include:mailbox.org".

DKIM-Troubleshooting​

Linux & macOS​

Linux and MacOS users can issue the “dig” command in the terminal application - it is important that the following string comes up in the ANSWER SECTION of the output: "v=DKIM1; k=rsa;" "p=....", followed by the correct key.

DNS DKIM query using the Linux terminal application

dig MBO0001.\_domainkey.example.com TXT

; <<>> DiG 9.11.3-1ubuntu1.13-Ubuntu <<>> MBO0001._domainkey.example.com TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64519
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;MBO0001._domainkey.example.com.    IN    TXT

;; ANSWER SECTION:
MBO0001._domainkey.example.com. 3403 IN    TXT    "v=DKIM1; k=rsa;" "p=MIIBIkANBgkqhyiG9w0DETJUIICAQ8AMIIBCgKCAQEA2K4PavXoNY8eGK2u61" "LIQlOHS8f5sWsCK5b+RGYfo0M+aNHwfqlVdzi/IwmYnuDDuXYuCllrgnxZ4fG4yV" "aux58v9grVsFHdzdjPlAQfp5rkiETYpWRZwgsmdseJ4CoZaosTHLjPumFE/Ua2WA" "QQljqelttM9TONM9L6KxrO9t5IISD1XtJb0bq1lVI/e72k3sxPd/q77qzhTDmwN4T" "STBFDRT5sxzUJx9HNSMRRoEIHSDLTIJUK+Up8IeCx0B7CiOzG5w/cHyZ8UM5V8lkqB" "aTDK46AwTkFWETf59QxUZArG3FEH5vy9HzDmy0tGG+063/x4RqkhqMg5/ClDm+lp" "ZqWwFRAQAB"

;; Query time: 2 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Aug 28 15:32:12 CEST 2020
;; MSG SIZE  rcvd: 485

Windows​

Windows users can query the DNS through the command line interface (cmd.exe) by running “nslookup”. Once again, please make sure to replace "example.com" with your own domain name:

DNS DKIM query using the Windows command line interface

nslookup -q=txt MBO0001._domainkey.example.com
Server:  UnKnown
Address:  192.168.179.1

Non-authoritative answer:
MBO0001._domainkey.example.com    text =

        "v=DKIM1; k=rsa;"
        "p=MIIBIkANBgkqhyiG9w0DETJUIICAQ8AMIIBCgKCAQEA2K4PavXoNY8eGK2u61"
		"LIQlOHS8f5sWsCK5b+RGYfo0M+aNHwfqlVdzi/IwmYnuDDuXYuCllrgnxZ4fG4yV"
		"aux58v9grVsFHdzdjPlAQfp5rkiETYpWRZwgsmdseJ4CoZaosTHLjPumFE/Ua2WA"
		"QQljqelttM9TONM9L6KxrO9t5IISD1XtJb0bq1lVI/e72k3sxPd/q77qzhTDmwN4T"
		"STBFDRT5sxzUJx9HNSMRRoEIHSDLTIJUK+Up8IeCx0B7CiOzG5w/cHyZ8UM5V8lkqB"
		"aTDK46AwTkFWETf59QxUZArG3FEH5vy9HzDmy0tGG+063/x4RqkhqMg5/ClDm+lp"
		"ZqWwFRAQAB"

Please double-check that the response contains the string "v=DKIM1; k=rsa;" "p=....", followed by the DKIM key (this will be printed out across multiple lines).

DMARC-Troubleshooting​

Linux & macOS​

Linux and MacOS users can use the "dig" command in the terminal application - it is important that the following string is displayed in the ANSWER SECTION of the output: "v=DMARC1; p=....". Whatever follows will depend on the individual settings made.

DNS DMARC query using the Linux terminal application

dig \_dmarc.example.com TXT

; <<>> DiG 9.11.3-1ubuntu1.13-Ubuntu <<>> _dmarc.example.com TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35986
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;_dmarc.example.com.        IN    TXT

;; ANSWER SECTION:
_dmarc.example.com.    1800    IN    TXT    "v=DMARC1; p=none; rua=mailto:dmarcrep@example.com; ruf=mailto:dmarcrep@example.com; rf=afrf; sp=none; fo=0; ri=86400; adkim=r; aspf=r; pct=0"

;; Query time: 137 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Aug 28 15:41:16 CEST 2020
;; MSG SIZE  rcvd: 191

Windows​

Windows users can issue the following command through the Windows command line interface (cmd.exe) - it is important that the following string is displayed in the response output: "v=DMARC1; p=...." what follows depends on your individual settings.

DMARC TXT query using the Windows command line interface

nslookup -type=txt \_dmarc.example.com

Server: UnKnown

Address: 192.168.179.1

Non-authoritative answer:

\_dmarc.meinname.de text =
"v=DMARC1; p=none; rua=mailto:dmarcrep@example.com;
ruf=mailto:dmarcrep@example.com; rf=afrf; sp=none; fo=0; ri=86400; adkim=r;
aspf=r; pct=0"

Further resources​

  1. Get more information about this topic from a talk held by our CEO Peer Heinlein:SPF / DKIM-talk (in German only) and anothertalk held at the Minidebconf Regensburg 2021 (by Anton Dollmaier, in English).
  2. Check your SPF, DKIM and DMARC settings using this tool: The European Commission provides a tool that allows checking the functionality of SPF, DKIM and DMARC:https://mecsa.jrc.ec.europa.eu
  3. Deprecated method: Until 2021 mailbox.org recommended to setup DKIM via TXT-Records. We changed this recommendation recently, but we kept the documentationhere. Although this method still works, we are not recommending this procedure any more.
  4. You can test your setup by using Google Mail or Yahoo test accounts following this tutorial:https://www.appmaildev.com/en/dkim