This article describes three advanced settings in the Domain Name System (DNS), all of which can help improve a domain's spam reputation: SPF and DKIM, as well as DMARC, which builds on the previous two. As more and more mail providers are starting to use these standards to weed out spam, the settings will affect the likelihood that servers will treat the e-mails you send as spam.
By using the settings suggested in this article, sending e-mail from your accounts will become more reliable. If your domain and your e-mails properly comply with established Internet standards, this will also increase security. mailbox.org generally recommends you follow the guidance below if you use your own domain name with mailbox.org. Especially business customers, who tend to send large quantities of e-mails, should follow our advice - there is clear indication that providers are stepping up their efforts to fight spam and employ stricter rules for flagging spam e-mails as the volume of data transfers continues to increase.
All customers who only use e-mail addresses ending with "@mailbox.org" do not need to do anything, as these addresses already use the correct settings on our servers.
Please ensure that your domain has been set up with mailbox.org, such that e-mails carrying your custom domain name (e.g., "firstname.lastname@example.org") are actually sent and received through mailbox.org. If you haven’t done that yet, then follow this guidance on how to set up your e-mail to use a custom domain name before you continue here.
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 domain. However, the DNS does not control which servers are authorised to send e-mails. That is why the 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
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.
The permitted SPF parameters in the TXT record are the following:
The SPF version used. Here: 1
All servers within the IPv4 range 220.127.116.11/24 are authorised to send e-mails for the domain.
All servers within the IPv6 range ip6:fda0:6a92:125f:0:42f6:6f7e:f9fb:b531/64 are authorised to send e-mails for the domain.
Allows those mail servers specified in the MX records for this domain to send e-mails for the domain.
Allows all servers under the domain example.com to send e-mails for the domain.
Any 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.
Any mail servers not listed in the record are not authorised to send e-mails for the domain.
Receiving 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.
A complete list of defined SPF record entries can be found at OpenSPF.
Only one SPF entry allowed:Note that you can only have a single SPF record for a domain. Please double-check your DNS settings – having multiple SPF entries is not permitted and can lead to problems.
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.
All four keys are mandatory:
We currently provide four keys for DKIM, which must be entered into the DNS records at your domain hosting company:
Please make sure that the "Target*" or "Destination" field in your provider's settings has the correct value, too. The URL needs to reflect the key used, and the final dot after the URL is needed at some providers (see figures below) – you should check your provider's documentation to find out their specification. And don't forget to replace
example.com with your domain name.
Figure 4 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:
Figure 4: CNAME DNS record for the key MBO0001. at Hetzner
Figure 5: CNAME DNS record for the key MBO0001. at Netcup
Figure 6: CNAME DNS record for the key MBO0001. at 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:email@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".
Figure 7 shows how a provider's dialogue (here the German provider Hetzner) presents the entries relevant for your settings:
Figure 7: Hetzner – Creating a DMARC TXT record in the DNS
Figure 8: Netcup – Creating a DMARC TXT record in the DNS
Figure 9: Creating a DMARC TXT record in the DNS at INXW
The main parameters for the DMARC TXT record in the DNS are the following:
Uses DMARC protocol version 1
The 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 address
The owner of the e-mail address 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.
This parameter is mandatory and defines how the receiving server should proceed if an e-mail could not be authenticated. Available options are the following:
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).
quarantine: Incoming 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.
reject: Unauthenticated e-mails are rejected outright and the receiving server will send a bounce message (mail undeliverable) to the sender.
Please make sure not to choose the values "quarantine" or "reject" right from the start. We recommend using the option "p=none" at first, as this provides an opportunity to have a look at the reports first and evaluate the situation before possibly setting more restrictive values.
The expected effects of using restrictive values are: Your e-mails may be rejected by the receiving server, and e-mail forwarding errors may occur if the signatures do not work properly.
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 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".
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 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).
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:firstname.lastname@example.org; ruf=mailto:email@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 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:firstname.lastname@example.org; ruf=mailto:email@example.com; rf=afrf; sp=none; fo=0; ri=86400; adkim=r; aspf=r; pct=0"
Get more information about this topic from a talk held by our CEO Peer Heinlein: SPF / DKIM-talk (in German only) and another talk held at the Minidebconf Regensburg 2021 (by Anton Dollmaier, in English).
Check your SPF, DKIM and DMARC settings using a tool: The European Commission provides a tool that allows checking the functionality of SPF, DKIM and DMARC. The check requires sending a test message, so that the outgoing mail servers used by the e-mail provider can be determined. At the end of the test, you will receive a detailed listing of the security parameters of your setup.
Old method: Until 2021 mailbox.org recommended to setup DKIM via TXT-Records. We changed this recommendation recently, but we kept the documentation here. Although this method still works, we are not recommending this procedure any more.
- You can test your setup by using gmail or yahoo test accounts: https://www.appmaildev.com/en/dkim