SPF, DKIM, and DMARC - How to improve spam reputation and avoid bounces
What is described in this article?
In addition to general information about the protocols, parameters, and DMARC reports, you will find the following instructions with example configurations:
- Setting the SPF record and its parameters as a TXT record in your provider’s DNS settings
- Setting the DKIM records as CNAME records in your provider’s DNS settings
- Setting the DMARC record and its parameters as a TXT record in your provider’s DNS settings
Prerequisite
First, make sure that the mails of your domain (for example mein.name@example.com) can be sent and received via mailbox. Please follow this guide: Use mail address with your own domain.
This article is intended to help you increase the reliability of mail delivery when using your own domain, avoid faulty deliveries and bounces (e.g. Undelivered Mail Returned to Sender), and ensure that your mails can successfully pass through spam filters at Google and other mail providers. In addition, the correct implementation of SPF and DKIM helps to permanently improve the spam reputation of your domain. Private customers using mail addresses with @mailbox.org without their own domain do not need to worry about this – we have already set all necessary configurations for you.
This guide describes three important protocols and their corresponding DNS settings: SPF, DKIM, and the protocol DMARC, which builds upon them. Since most mail providers use these standards to identify spam, proper configuration reduces the risk that servers classify and filter out mails sent from your domain as spam. In principle, three records are required, which must be set in the DNS settings of your hosting provider.
By applying the settings in this guide, your recipients will receive your mails more reliably. At the same time, your domain – and therefore each of your mails – will comply with the relevant internet standards, which also improves overall security. mailbox strongly recommends setting these configurations when using your own domains for mail. Business customers and companies that regularly send large volumes of mails should pay particular attention: there is strong evidence that providers are becoming increasingly strict in filtering.
It is therefore worthwhile to take a closer look at the terms SPF, DKIM, and DMARC. These three protocols are core elements of mail authentication and play a crucial role in detecting and preventing spam and phishing attempts. As a result, they are closely linked to the spam reputation of your domain and directly influence how likely it is that your mails will be classified as spam or rejected.
A number of mail service providers, including Google, use these protocols to verify the authenticity of mails. If a mail sent from your domain does not pass the SPF or DKIM checks, Google may reject the mail and generate a bounce. A bounce is essentially an automatic reply indicating that the mail could not be delivered. In such cases, the most likely reason for the bounce is that the mail was classified as potential spam or a phishing attempt.
Bounce – Example of a rejected mail
From: MAILER-DAEMON@xxxxxx.mailbox.org
To: mustermann@example.com
Date: 22.07.2023 22:29 CEST
Subject: 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 protocols and parameters at a glance
SPF (Sender Policy Framework)
SPF is a mechanism designed to define which mail servers are authorized to send mails on behalf of your domain. By using SPF, you can prevent spammers from misusing your domain for unwanted and misleading mails. In practice, the recipient’s mail server checks the SPF records in your domain’s DNS settings and compares them with the IP address of the sending mail server. If the sending mail server is listed in the SPF records, the mail is classified as legitimate.
DKIM (DomainKeys Identified Mail)
DKIM is another mail authentication mechanism used to verify the integrity and authenticity of a mail. With DKIM, the sending mail server signs each outgoing mail with a digital key. This key is stored in the DNS record of your domain. The recipient’s mail server can verify this signature by retrieving the DKIM key from your domain’s DNS settings. If the signature is valid, the recipient can be confident that the mail really came from your domain and was not altered during transmission.
DMARC (Domain-based Message Authentication, Reporting & Conformance)
DMARC is a mail validation protocol built on top of SPF and DKIM, designed to prevent domain abuse in mail communication. With DMARC, the owner of a domain can define how the recipient server should handle mails that fail SPF and DKIM checks. Options include rejecting the mails, placing them in the spam folder, or delivering them normally. Additionally, DMARC enables the exchange of reports between sending and receiving servers to improve awareness of potential security issues. In short: it is a valuable tool for improving mail security and increasing the deliverability of legitimate mails.
Example DNS records
The following table contains examples of the DNS records you need to configure SPF, DKIM, and DMARC with your provider. Replace example.com with your own domain and postmaster@example.com with your mail address.
| Hostname | Record Type | Target | Protocol |
|---|---|---|---|
| @ | TXT | v=spf1 include:mailbox.org ~all | SPF |
| MBO0001._domainkey.example.com | CNAME | MBO0001._domainkey.mailbox.org. | DKIM |
| MBO0002._domainkey.example.com | CNAME | MBO0002._domainkey.mailbox.org. | DKIM |
| MBO0003._domainkey.example.com | CNAME | MBO0003._domainkey.mailbox.org. | DKIM |
| MBO0004._domainkey.example.com | CNAME | MBO0004._domainkey.mailbox.org. | DKIM |
| _dmarc.example.com | TXT | v=DMARC1;p=none;rua=mailto:postmaster@example.com | DMARC |
The protocols and parameters in detail
Sender Policy Framework (SPF)
SPF (Wikipedia) is used by administrators to publish which servers are authorized to send outgoing mails on behalf of their domain.
The MX records in the Domain Name System that are responsible for mail only define which mail servers are in charge of receiving mails for a domain. However, there was no list of mail servers authorized to send mails on behalf of a domain. Spam at the scale we know today became possible partly because senders could send mails in someone else’s name from arbitrary machines (e.g., compromised systems) and there was long no method to prevent this.
Solutions such as SPF, standardized in RFC 4408, were developed to address this issue. SPF allows domain administrators to associate specific mail servers with their domain and thereby define them as legitimate senders for mails of this domain.
A typical SPF record in a standard setup is stored in the DNS as a TXT record and may contain the following content:
v=spf1 include:mailbox.org ~all
Meaning of this entry
v=spf1– specifies the SPF version in useinclude:mailbox.org– automatically adopts all SPF settings from mailbox for this domain
This means: All mail servers of mailbox (both the domainmailbox.organd the associated IP addresses) are authorized to send mails with senders of your domain
Of course, you can continue to use other mail servers for sending mails on behalf of your domain in addition to mailbox. However, you should also authorize them with entries in the DNS.
Important: Multiple SPF entries are not allowed! Make sure that there is only one SPF record in the DNS settings of your provider. Conflicting entries may cause issues.
Allowed parameters in the TXT record for SPF
| Setting | Explanation |
|---|---|
v=spf1 | Indicates that this is SPF version 1. |
ip4:213.203.238.0/24 | Any server within the IPv4 range 213.203.238.0/24 is authorized to send mails for this domain. |
ip6:fda0:6a92:125f:0:42f6:6f7e:f9fb:b531/64 | Any server within the IPv6 range fda0:6a92:125f:0:42f6:6f7e:f9fb:b531/64 is authorized to send mails for this domain. |
mx | Authorizes all mail servers listed in the MX records of this domain to send mails. |
include:example.com | Additionally authorizes all servers listed in the SPF settings of example.com. In this case, the server must perform another query for the TXT record of example.com. |
?all | All mail servers not mentioned may also send mails under this name, without receiving either a negative or positive evaluation. |
-all | Mail servers not listed in this entry are not authorized to send mails for this domain. |
~all | Receiving servers should not immediately reject such mails but should perform additional tests to check whether the mail is spam. |
List of all SPF entries
A complete list of all permitted entries in the SPF record can be found at OpenSPF.
SPF – Example configuration with Hetzner, Netcup, and INWX
The DNS input masks of providers are not standardized. The following figures show, using examples from the providers Hetzner, Netcup, and INWX, how the SPF TXT records should appear.
Figure 1: Hetzner automatically sets the quotation marks in the target field and uses only @ instead of the domain name.
Figure 2: Netcup also uses @ as a placeholder for the domain and does not require quotation marks.
Figure 3: Netcup also uses @ as a placeholder for the domain and does not require quotation marks.
DomainKeys Identified Mail (DKIM)
DKIM (Wikipedia) is a technical protocol used to ensure the authenticity of senders. This protocol goes one step further than SPF by securing the information in mails with a digital signature, for which a special key has previously been stored in the DNS.
Only with this key can a foreign mail server verify whether a received message with such a signature in the header was truly sent by the specified domain. The mail header used for this purpose is the DomainKey-Signature-Header.
For this to work, the mail server administrator (in this case, us at mailbox) must generate a signature, sign it using a cryptographic method, and make it available for mail communication (i.e., store it in the Domain Name System). If this process fails, the sender’s mail server cannot be uniquely verified, and the mail in question is more likely to be classified as spam and filtered out.
By enabling DKIM with the following instructions, you reduce the likelihood that receiving servers incorrectly classify your mails as spam.
DKIM parameters & settings
There are several possible approaches to successful DKIM entries. mailbox recommends creating the entry as a CNAME record. We currently provide four keys for DKIM that you must add as DNS entries at your domain registrar. Add all four keys in four separate CNAME records:
Figure 4
Individual key (replace example.com with your domain) | Record Type | Target |
|---|---|---|
| MBO0001._domainkey.example.com | CNAME | MBO0001._domainkey.mailbox.org. |
| MBO0002._domainkey.example.com | CNAME | MBO0002._domainkey.mailbox.org. |
| MBO0003._domainkey.example.com | CNAME | MBO0003._domainkey.mailbox.org. |
| MBO0004._domainkey.example.com | CNAME | MBO0004._domainkey.mailbox.org. |
Figure 4 (table) shows a typical entry with the provider Hetzner. In the Record type dropdown menu, select CNAME. Under Hostname, enter the chosen key as a subdomain of your domain (e.g., MBO0001._domainkey.example.com) and in the Target field (at Hetzner), add a trailing dot.
The notation in the last field – as well as the naming of the fields in the DNS input mask – may vary from provider to provider: some providers (e.g., Hetzner) require the trailing dot, others add it automatically. You should therefore always consult your provider’s documentation.
DKIM – Example configurations with Hetzner, Netcup, and INWX
Hetzner
Figure 5: The CNAME DNS record at Hetzner for the key MBO0001 with a trailing dot.
Figure 6: The CNAME DNS record at Netcup does not require a trailing dot in the Destination field.
The provider INWX also does not require a trailing dot in the CNAME DNS record.
Old method
In 2021, we at mailbox changed our recommendation for the DKIM record. Previously, we advised creating DKIM records as TXT records. While this method still works, it has a significant disadvantage: if we need to change our keys, all TXT records referencing the old keys will become invalid. Customers and admins with TXT records for DKIM would need to take action themselves to prevent their mails from receiving higher spam scores.
Customers who configure our DKIM keys using CNAME records do not need to take any action in such cases.
You can, of course, switch this at any time – the only important thing is the order of the change: first delete the TXT record from the DNS, and then add the CNAME record. If you perform both steps within a short time frame, DKIM should remain available for your domain during the subsequent automatic synchronization of the Domain Name System.
Domain-based Message Authentication, Reporting and Conformance (DMARC)
DMARC records (Wikipedia) define whether and how mail servers verify DKIM signatures and SPF records when receiving mails. When you send mails via mailbox, you can use the DMARC record to provide a kind of “recommendation” on how to handle mails that use your sender address but, for example, are not DKIM-signed.
For DMARC settings, both a DKIM record in the DNS and an existing SPF record are prerequisites. Figures 7 to 9 show example DNS input masks from different providers – here, too, you should consult your provider’s documentation to avoid mistakes.
Step-by-step guide
- Create an (additional) TXT record in the DNS.
- Under Host, Name, or Hostname, enter the parameter
_dmarc.followed by your mail domain, for example:
_dmarc.example.com
Pay attention to the different notations used by providers.
- Under Value, Target, or Destination, enter this parameter:
v=DMARC1;p=none;rua=mailto:postmaster@example.com
The mail address you specify here will now receive the error reports from the DMARC checks – you should therefore specify your own address.
- For TTL (Time-To-Live), we recommend
400.
DMARC – Example configurations with Hetzner, Netcup, and INWX
At the provider Hetzner, for example, a correct DNS entry for DMARC looks as follows:
Figure 7: Hetzner – Creating the DMARC TXT record in DNS.
Figure 8: Netcup – Creating the DMARC TXT record in DNS.
Figure 9: Creating the DMARC TXT record at INWX.
DMARC – Options and parameters
| Parameter | Description |
|---|---|
v=DMARC1 | Specifies that DMARC protocol version 1 is used. |
ruf=mailto:email-address | The owner of the specified mail address receives failure reports (forensic reports). In Germany, the use of this option is not permitted, as you could receive mails that were not intended for you. We advise against using this parameter. |
rua=mailto:email-address | The owner of the specified mail address (this mail address must belong to the domain from which the sending occurs) receives the sometimes extensive detailed reports of all DMARC activities. Since this may lead to a large number of incoming reports, you should use a dedicated mail address for this purpose. The reports include date, time, recipient and sender domain, IP addresses, SPF and DKIM information, the applied DKIM policy, as well as the domain linked with SPF and DKIM. |
p=none | This parameter is always required. It defines how the receiving server should handle mails that could not be properly authenticated. Valid options are: p=none: No action is taken, and the message is delivered to the target mailbox as intended by the sender. The mails are logged in the daily report, which is sent to the address specified in the rua parameter. p=quarantine: Incoming messages without correct authentication are marked as spam and placed in the recipient’s spam folder. p=reject: Mails that are not properly authenticated are rejected. The receiving server sends a bounce message (non-delivery notification) back to the sender. |
DMARC – Monitor, analyze & adjust
Please note that you should not initially set the p parameter to the restrictive values quarantine or reject. We recommend first using the option p=none, monitoring the situation, analyzing the reports, and using them as guidance for necessary adjustments.
Typical problems caused by overly restrictive settings include mails rejected by the receiving server (bounces) or electronic signatures that can no longer be validated in the case of mail forwarding. Occasionally, other departments in your company may use the mail server for applications unknown to the mail administrator but at the same time important for the company (e.g., monitoring, marketing newsletters, etc.).
From the reports, you can gather useful information and take appropriate action. Once everything is clarified, you should enter a stricter rule here.
When analyzing DMARC reports, pay attention to the following factors:
- Which servers or external providers send mails on behalf of your domain?
- What proportion of mails from your domain meet the DMARC requirements?
- Which servers or services send mails that do not comply with DMARC policies?
Analyzing & understanding DMARC reports
DMARC aggregate reports
DMARC aggregate reports provide insight into the DMARC activities of a specific domain over a defined period. These aggregated reports include information such as the number of messages that passed or failed DMARC authentication, the IP addresses of the sending servers, and the authentication methods applied.
DMARC forensic reports
DMARC forensic reports provide detailed insights into specific mail messages that failed the DMARC check. These forensic analyses include both the complete mail message and data on the authentication status and the causes of the failure. With the help of these reports, specific cases of mail spoofing or abuse 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 mail recipients also offer the domain owner DMARC failure reports that provide information about messages that failed the DMARC check and were therefore rejected or quarantined.
More details on DMARC analysis
For more details on the analysis of DMARC reports, this page (available in German & English) provides useful information: What are DMARC reports and can they be read?
Troubleshooting
Linux & macOS
Linux and macOS users can use the dig command in the terminal, followed by their domain and the desired records to be queried:
DNS TXT query in the Linux terminal
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 check whether the line after the ANSWER SECTION includes an entry starting with v=spf1 and containing include:mailbox.org.
Windows
Windows users can enter the following command in the command prompt (cmd.exe). Please replace example.com with the name of your domain:
DNS TXT query in the Windows command line
nslookup -type=txt example.com
Server: UnKnown
Address: 192.168.179.1
Non-authoritative answer:
example.com text
"_globalsign-domain-verificationZKyu_ATrp-l27Q11kIjqiPNjI6Tt_g7vnp3qYsViBk"
"v=spf1 include:mailbox.org ~all"
Please check whether the answer contains a line starting with v=spf1 and containing include:mailbox.org.
DKIM troubleshooting
Linux & macOS operating systems
Linux and macOS users can run this command in the terminal – it is important that the ANSWER SECTION displays the string: "v=DKIM1; krsa;" "p...." followed by the correct key.
dig MBO0001._domainkey.example.com TXT
;; ANSWER SECTION:
MBO0001._domainkey.example.com. 3403 IN TXT "v=DKIM1; krsa;" "pMIIBIkANBgkqh..."
Windows operating system
Windows users can run the following command in the command prompt (cmd.exe):
nslookup -type=txt MBO0001._domainkey.example.com`
Server: UnKnown
Address: 192.168.179.1
Non-authoritative answer:
MBO0001._domainkey.example.com text
"v=DKIM1; krsa;"
"pMIIBIkANBgkqhyiG9w0DETJUIICAQ8AMIIBCgKCAQEA..."
nslookup -type=txt MBO0001._domainkey.example.com`
Server: UnKnown
Address: 192.168.179.1
Non-authoritative answer:
MBO0001._domainkey.example.com text
"v=DKIM1; krsa;"
"pMIIBIkANBgkqhyiG9w0DETJUIICAQ8AMIIBCgKCAQEA..."
Please check that the answer contains the string "v=DKIM1; krsa;" "p...." followed by a multiline representation of the DKIM key.
DMARC troubleshooting
Linux & macOS operating systems
Linux and macOS users can run this command in the terminal – it is important that the ANSWER SECTION displays the string: "v=DMARC1; p...." (what follows depends on the individual settings).
dig _dmarc.example.com TXT
;; ANSWER SECTION:
_dmarc.example.com. 1800 IN TXT "v=DMARC1; p=none; rua=mailto:dmarcrep@example.com; ..."
Windows users
Windows users can run this command in the command prompt (cmd.exe):
nslookup -type=txt _dmarc.example.com
Server: UnKnown
Address: 192.168.179.1
Non-authoritative answer:
_dmarc.example.com text
v=DMARC1; p=none; rua=mailto:dmarcrep@example.com; ...
Further Resources and Tools
- For more information on this topic, please refer to this talk by our CEO Peer Heinlein: SPF / DKIM Talk and a video from the Minidebconf 2021 in Regensburg.
- Check SPF, DKIM, and DMARC with this tool: MECSA Tool of the European Commission. To do so, you must send a test message so that the outgoing servers used by the mail provider can be reliably identified.
- Until 2021, mailbox recommended adding DKIM information in TXT records — you can still find the (now outdated) guide here: Set DKIM records via TXT fields in DNS.
- You can test your setup with Google or Yahoo test accounts: AppMailDev DKIM Test.
- Additional information on the requirements for mail authentication when sending to Gmail accounts can be found in the Google documentation.
