Shows up a detailed process on how to set up SPF + DK + DKIM with Postfix in Plesk 11.5 on Debian Wheezy, step by step, and how to test to make sure everything is working correctly
I leased a dedicated server from Hetzner, and I got the Plesk option, for administration, so I don’t have to bother with administration, but turns out I’m not so lucky, I’ve ran into a lot of issues with using Plesk, so I had to do my own fixes.
So let’s take a look at how we can integrate SPF + DK + DKIM with Postfix in Plesk 11.5 on Debian Wheezy.
First things, first, if you are using QMail switch to Postfix, to install Postfix you can either use the GUI, or you can do it from a console.
Let’s open the DNS Template, you will see there that, there is an entry for SPF
v=spf1 +a +mx -all
This means the SPF is enabled on our domain.
Let’s modify it a little bit to be better, if you are gonna host multiple domains from your server, then you should probably modify it too.
v=spf1 +a +mx +ip4:<ip.mail> ?all* <ip.mail> - Is the IP of the mail server that is responsible for sending the mails, it is automatically filled in when you apply the zones
After you do this modification you should apply it
Ok, now that this has been enabled, let’s go and enable for the domain in question, if it was already checked, uncheck it press OK, and then check it again and press OK, this is so it will regenerate the DomainKeys data in the DNS zone, as I’ve had some problems with the data not present in the DNS zone file
OK, now let’s see if the correct data is there, usually it takes a long time for DNS to propagate between 24-48h, there is a simple way to test if the data is there, by querying the Nameserver that hosts your DNS zone, in my case I host my own Nameserver
In the Answer section you should see something like
default._domainkey.myserverplace.de. 600 IN TXT "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAruBNqdsSCKBLwMrFNNKH8z0e7zmlAic7iRoJsDDJK3IlnW8j6G/T6a93m+jqYc6R38MBAZbeSv2LQJ0SepJEsr4Iqk41WFXPBKnyXReO1RXPW5/YnRe6dpJMEqsmPpl2TjInY7ve/6VCiVDOHn9RRrdB+x7CGeK2crgqSZVlFwIDAQAB\;"
As you can see everything is in place now for DomainKeys to work, now let’s continue on to DKIM
DKIM (DomainKeys Identified Mail)
As always lets update the system first
aptitude update
aptitude safe-upgrade
Now we need to install the DKIM filter, or as it’s called now OpenDKIM, for full specification take a look at their site.
aptitude install opendkim opendkim-tools
Now we need to create the necessary folders so OpenDKIM can work proplery
This will create the directory where we will hold the keys for OpenDKIM, after this step let’s take a look at how the process will look like, so we can create a script to automate this.
mkdir -p /etc/opendkim/keys/myserverplace.de
cd /etc/opendkim/keys/myserverplace.de
opendkim-genkey -d myserverplace.de -s mail
chown -Rv opendkim:opendkim /etc/opendkim/keys/myserverplace.de
chmod -v u=rw,go-rwx *
This easily understandble, what happens here.
Now you have two files /etc/opendkim/keys/myserverplace.de
ls -lah /etc/opendkim/keys/myserverplace.de
total 16K
drwxr-xr-x 2 opendkim opendkim 4.0K Oct 9 18:43 .
drwxr-xr-x 5 opendkim opendkim 4.0K Oct 9 19:39 ..
-rw------- 1 opendkim opendkim 887 Oct 9 18:43 mail.private
-rw------- 1 opendkim opendkim 303 Oct 9 18:43 mail.txt* /etc/opendkim/keys/myserverplace.de/mail.private
contains the RSA PRIVATE KEY* /etc/opendkim/keys/myserverplace.de/mail.txt
Contains the record you need to add to your DNS zone
Next set is to setup the key tables, signing tables, and trusted hosts
needs to contain some data before we continue, so add the following information to this file, and adjust accordingly
127.0.0.1
localhost
144.76.163.46
144.76.163.57
ns1.myserverplace.de
ns2.myserverplace.de
myserverplace.deSo let’s see what does what:* /etc/opendkim/KeyTable
cwd=`pwd`
opendkim="/etc/opendkim"
location="$opendkim/keys/$1"
[ -d "$location" ] && die "There is already a directory in the folder, delete the folder if you want to create a new one"
mkdir -p "$location"
cd "$location"
opendkim-genkey -d $1 -s mail
chown opendkim:opendkim *
chown opendkim:opendkim "$location"
chmod u=rw,go-rwx *
echo "$1 $1:mail:$location/mail.private" >> "$opendkim/KeyTable"
echo "*@$1 $1" >> "$opendkim/SigningTable"
echo "$1" >> "$opendkim/TrustedHosts"
echo "mail.$1" >> "$opendkim/TrustedHosts"
echo
echo "Put this in the DNS ZONE for domain: $1"
echo
cat "$location/mail.txt"
echo
cd "$cwd"
So if we run the script, we should get output like this, and this is the data we need to put in the DNS zone.
/opt/generatedkim.sh test.de
Put this in the DNS ZONE for domain: test.de
mail._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPzE0GmvFwAQsgcFzopy4zMNWUbL6JM5XIyjBy3bUnANI5axeb/Lw/GBjUoSFLEiO80Tt8m3A5YrBKcodRQQURYiW6/YtElhLupHyfcxQhfNLU4z9JUOJKPjcpMZCj0Xv873QgVOl+7U605JdBHSPOx4ybBZwDq68cw9YFYRPmEwIDAQAB" ; ----- DKIM key mail for test.de
Unfortunatly I don’t have time to create a script to do this automatically, you can always insert a record in MySQL database so it’s in the ZONE and you can regenerate the DNS Zone from the command line, and I won’t be having a lot of domains, so I can add this entry manually to a domain I want DKIM enabled
Let’s open the domain and go to DNS Settings, and you can click ** Add Resource **
You popuplate the following data in the inputboxes* Record type
TXT* Domain name
mail._domainkey* TXT Record
In the text record you copy a part of the contents from the file /etc/opendkim/keys/myserverplace.de/mail.txt, it data should start from v=DKIM1; k=rsa; to the end, without the quotes as you can see it’s in quotes.
In the example above for domain test.de you add only the following contents in the input box
In the selector fields try with both mail, and default, you shold be getting valid results
OpenDKIM
We need to edit the configuration file to configure DKIM, open /etc/opendkim.conf with your favorite editor and add the following lines to the end of the file
# Always oversign From (sign using actual From and a null From to prevent malicious signatures header fields (From and/or others) between the signer and the verifier)
OversignHeaders From
As you can see we added the OpenDKIM milter too, and milter_protocol is set to 6, this is important, if it’s not set to 6, the psa-pc-remote process will segfault like so,
psa-pc-remote[18523]: segfault at 0 ip 00007fa5be18c034 sp 00007fa5bccffd30 error 4 in libc-2.13.so[7fa5be123000+180000]
And your messages won’t be signed with DomainKey, only with DKIM
service postfix restart
Testing
There is an easy way to test if everything is correct, create an email account if you haven’t already and send a test mail to the following recepients, and the results are cut down because the text is too big* check-auth@verifier.port25.com
============================================================
DomainKey result: pass
============================================================
Signed by: admin@myserverplace.de
PublicKey: default._domainkey.myserverplace.de
IN TXT = "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAruBNqdsSCKBLwMrFNNKH8z0e7zmlAic7iRoJsDDJK3IlnW8j6G/T6a93m+jqYc6R38MBAZbeSv2LQJ0SepJEsr4Iqk41WFXPBKnyXReO1RXPW5/YnRe6dpJMEqsmPpl2TjInY7ve/6VCiVDOHn9RRrdB+x7CGeK2crgqSZVlFwIDAQAB;"
============================================================
DKIM result: pass
============================================================
Signed by: admin@myserverplace.de
Expected Body Hash: frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=
PublicKey: mail._domainkey.myserverplace.de
IN TXT = "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDMziMcgPTWK0kSUKxrgHHzEiWxNkZ2/M0Ugyr/8H9WtoCsJUM+Bc1C9VwqJ6yjTidecDrX7aL0lFZ9Mylku/wtSiPw6KLxMg2LG2vrMzlPTB2lmJNmg/EOu3KPC8BtAuOhXfwVH/ttQbzdKJKWqiCJn7jhF5oqEKnOCORxOQXKIwIDAQAB;"
Logs
You can check the following locations to see if there are errors* /var/log/mail.err
/var/log/mail.warn
/var/log/mail.info
/var/log/syslog
Note
Make sure you enable testing mode for DKIM if you plan to test, you can also cut down the EXPIRY time so the results propagate faster, so to enable testing mode set the key _domainkey to t=y; o=-
Shows up a detailed process on how to set up SPF + DK + DKIM with Postfix in Plesk 11.5 on Debian Wheezy, step by step, and how to test to make sure everything is working correctly
I leased a dedicated server from Hetzner, and I got the Plesk option, for administration, so I don’t have to bother with administration, but turns out I’m not so lucky, I’ve ran into a lot of issues with using Plesk, so I had to do my own fixes.
So let’s take a look at how we can integrate SPF + DK + DKIM with Postfix in Plesk 11.5 on Debian Wheezy.
First things, first, if you are using QMail switch to Postfix, to install Postfix you can either use the GUI, or you can do it from a console.
Let’s open the DNS Template, you will see there that, there is an entry for SPF
v=spf1 +a +mx -all
This means the SPF is enabled on our domain.
Let’s modify it a little bit to be better, if you are gonna host multiple domains from your server, then you should probably modify it too.
v=spf1 +a +mx +ip4:<ip.mail> ?all* <ip.mail> - Is the IP of the mail server that is responsible for sending the mails, it is automatically filled in when you apply the zones
First let’s activate DomainKeys, take a look at the screenshot, and compare my options with yours.
Ok, now that this has been enabled, let’s go and enable for the domain in question, if it was already checked, uncheck it press OK, and then check it again and press OK, this is so it will regenerate the DomainKeys data in the DNS zone, as I’ve had some problems with the data not present in the DNS zone file
OK, now let’s see if the correct data is there, usually it takes a long time for DNS to propagate between 24-48h, there is a simple way to test if the data is there, by querying the Nameserver that hosts your DNS zone, in my case I host my own Nameserver
In the Answer section you should see something like
default._domainkey.myserverplace.de. 600 IN TXT "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAruBNqdsSCKBLwMrFNNKH8z0e7zmlAic7iRoJsDDJK3IlnW8j6G/T6a93m+jqYc6R38MBAZbeSv2LQJ0SepJEsr4Iqk41WFXPBKnyXReO1RXPW5/YnRe6dpJMEqsmPpl2TjInY7ve/6VCiVDOHn9RRrdB+x7CGeK2crgqSZVlFwIDAQAB\;"
As you can see everything is in place now for DomainKeys to work, now let’s continue on to DKIM
DKIM (DomainKeys Identified Mail)
As always lets update the system first
aptitude update
aptitude safe-upgrade
Now we need to install the DKIM filter, or as it’s called now OpenDKIM, for full specification take a look at their site.
aptitude install opendkim opendkim-tools
Now we need to create the necessary folders so OpenDKIM can work proplery
This will create the directory where we will hold the keys for OpenDKIM, after this step let’s take a look at how the process will look like, so we can create a script to automate this.
mkdir -p /etc/opendkim/keys/myserverplace.de
cd /etc/opendkim/keys/myserverplace.de
opendkim-genkey -d myserverplace.de -s mail
chown -Rv opendkim:opendkim /etc/opendkim/keys/myserverplace.de
chmod -v u=rw,go-rwx *
This easily understandble, what happens here.
Now you have two files /etc/opendkim/keys/myserverplace.de
ls -lah /etc/opendkim/keys/myserverplace.de
total 16K
drwxr-xr-x 2 opendkim opendkim 4.0K Oct 9 18:43 .
drwxr-xr-x 5 opendkim opendkim 4.0K Oct 9 19:39 ..
-rw------- 1 opendkim opendkim 887 Oct 9 18:43 mail.private
-rw------- 1 opendkim opendkim 303 Oct 9 18:43 mail.txt* /etc/opendkim/keys/myserverplace.de/mail.private
contains the RSA PRIVATE KEY* /etc/opendkim/keys/myserverplace.de/mail.txt
Contains the record you need to add to your DNS zone
Next set is to setup the key tables, signing tables, and trusted hosts
needs to contain some data before we continue, so add the following information to this file, and adjust accordingly
127.0.0.1
localhost
144.76.163.46
144.76.163.57
ns1.myserverplace.de
ns2.myserverplace.de
myserverplace.deSo let’s see what does what:* /etc/opendkim/KeyTable
cwd=`pwd`
opendkim="/etc/opendkim"
location="$opendkim/keys/$1"
[ -d "$location" ] && die "There is already a directory in the folder, delete the folder if you want to create a new one"
mkdir -p "$location"
cd "$location"
opendkim-genkey -d $1 -s mail
chown opendkim:opendkim *
chown opendkim:opendkim "$location"
chmod u=rw,go-rwx *
echo "$1 $1:mail:$location/mail.private" >> "$opendkim/KeyTable"
echo "*@$1 $1" >> "$opendkim/SigningTable"
echo "$1" >> "$opendkim/TrustedHosts"
echo "mail.$1" >> "$opendkim/TrustedHosts"
echo
echo "Put this in the DNS ZONE for domain: $1"
echo
cat "$location/mail.txt"
echo
cd "$cwd"
So if we run the script, we should get output like this, and this is the data we need to put in the DNS zone.
/opt/generatedkim.sh test.de
Put this in the DNS ZONE for domain: test.de
mail._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPzE0GmvFwAQsgcFzopy4zMNWUbL6JM5XIyjBy3bUnANI5axeb/Lw/GBjUoSFLEiO80Tt8m3A5YrBKcodRQQURYiW6/YtElhLupHyfcxQhfNLU4z9JUOJKPjcpMZCj0Xv873QgVOl+7U605JdBHSPOx4ybBZwDq68cw9YFYRPmEwIDAQAB" ; ----- DKIM key mail for test.de
Unfortunatly I don’t have time to create a script to do this automatically, you can always insert a record in MySQL database so it’s in the ZONE and you can regenerate the DNS Zone from the command line, and I won’t be having a lot of domains, so I can add this entry manually to a domain I want DKIM enabled
Let’s open the domain and go to DNS Settings, and you can click ** Add Resource **
You popuplate the following data in the inputboxes* Record type
In the text record you copy a part of the contents from the file /etc/opendkim/keys/myserverplace.de/mail.txt, it data should start from v=DKIM1; k=rsa; to the end, without the quotes as you can see it’s in quotes.
In the example above for domain test.de you add only the following contents in the input box
In the selector fields try with both mail, and default, you shold be getting valid results
OpenDKIM
We need to edit the configuration file to configure DKIM, open /etc/opendkim.conf with your favorite editor and add the following lines to the end of the file
# Always oversign From (sign using actual From and a null From to prevent malicious signatures header fields (From and/or others) between the signer and the verifier)
OversignHeaders From
# Our KeyTable and SigningTable
KeyTable refile:/etc/opendkim/KeyTable
SigningTable refile:/etc/opendkim/SigningTable
As you can see we added the OpenDKIM milter too, and milter_protocol is set to 6, this is important, if it’s not set to 6, the psa-pc-remote process will segfault like so,
psa-pc-remote[18523]: segfault at 0 ip 00007fa5be18c034 sp 00007fa5bccffd30 error 4 in libc-2.13.so[7fa5be123000+180000]
And your messages won’t be signed with DomainKey, only with DKIM
service postfix restart
Testing
There is an easy way to test if everything is correct, create an email account if you haven’t already and send a test mail to the following recepients, and the results are cut down because the text is too big* check-auth@verifier.port25.com
============================================================
DomainKey result: pass
============================================================
Signed by: admin@myserverplace.de
PublicKey: default._domainkey.myserverplace.de
IN TXT = "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAruBNqdsSCKBLwMrFNNKH8z0e7zmlAic7iRoJsDDJK3IlnW8j6G/T6a93m+jqYc6R38MBAZbeSv2LQJ0SepJEsr4Iqk41WFXPBKnyXReO1RXPW5/YnRe6dpJMEqsmPpl2TjInY7ve/6VCiVDOHn9RRrdB+x7CGeK2crgqSZVlFwIDAQAB;"
============================================================
DKIM result: pass
============================================================
Signed by: admin@myserverplace.de
Expected Body Hash: frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=
PublicKey: mail._domainkey.myserverplace.de
IN TXT = "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDMziMcgPTWK0kSUKxrgHHzEiWxNkZ2/M0Ugyr/8H9WtoCsJUM+Bc1C9VwqJ6yjTidecDrX7aL0lFZ9Mylku/wtSiPw6KLxMg2LG2vrMzlPTB2lmJNmg/EOu3KPC8BtAuOhXfwVH/ttQbzdKJKWqiCJn7jhF5oqEKnOCORxOQXKIwIDAQAB;"
Logs
You can check the following locations to see if there are errors* /var/log/mail.err
/var/log/mail.warn
/var/log/mail.info
/var/log/syslog
Note
Make sure you enable testing mode for DKIM if you plan to test, you can also cut down the EXPIRY time so the results propagate faster, so to enable testing mode set the key _domainkey to t=y; o=-
References
How to define what MTA is used in Parallels Plesk Panel and how to switch from Qmail to Postfix and back?http://kb.parallels.com/en/5801
DMARC
DMARC steht für Domain-based Message Authentication, Reporting and Conformance und nutzte DNS-Einträge, die in Verbindung mit SPF und DKIM arbeiten.
Es mehren sich die Hinweise, dass Domains mit einem DMARC-Eintrag seltener zum Phising missbraucht werden, dass viele große Provider dank SPF bzw. DKIM solche Fälschungen nicht nur erkennen, sondern anhand DMARC den Inhaber auch informieren und diese durchaus über den Provider dagegen vorgehen.
Der Ausgangspunkt von DMARC ist der Schutz der eigenen Domäne gegen Missbrauch von anderen Absendern, indem Sie als Inhaber die entsprechenden Vorarbeiten leisten, damit die Empfänger prüfen können, ob der Absender für diese Domäne auch senden darf.
Es gibt mit SPF oder RMX schon ein Verfahren, um die "Source-IP" von Systemen zu veröffentlichen, die für eine Domäne als Absenderhost agieren. Allerdings limitiert dies die Möglichkeiten Mails z.B. über Relays oder Provider zu versenden, bei denen Sie Mailserver-Adressen ändern oder erweitern.
Mit DKIM gibt es daher einen Weg, wie eine Mail selbst signiert werden kann. Es ist keine klassische digitale Signatur mit SMime oder PGP aber sehr ähnlich. Die Integrität der Mail wird damit sichergestellt, d.h. der Inhalt gegen Veränderungen geschützt und der Absender bestätigt.
DMARC geht aber weiter und veröffentlich Informationen, wie die Empfänger Sie als Domaininhaber über missbrauch informieren sollen.
Die Empfänger prüfen also nicht nur die eingehenden Mails gegen SPF und DKIM-Parameter, sondern über DMARC senden Sie auch Statusmeldungen und Zusammenfassungen an die hinterlegten Rückantwortadressen.
Als Domaininhaber mit einer passenden Verarbeitung erhalten Sie also direkt ein Feedback, wir stark ihre Domäne von fremden Personen unberechtigt genutzt wird. Es dient also primär dem Schutz ihrer Marke. Interessant wird das natürlich, wenn die großen Mailempfänger und Hoster nicht nur SFP und DKIM als Spamfilter nutzen, sondern auch die Daten aus dem DMARC-Eintrag verwenden.
Es ist also kein neuer Spamfilter sondern primär addiert DMARC einen Weg, wie Missbrauch auch bekannt werden kann. Aber wenn man DMARC glauben kann, sind das zumindest in den USA schon sehr viele Postfächer.
As of early 2013 DMARC had been deployed to protect roughly 2 billion email accounts - over 60% of consumer mailboxes globally, and over 80% of consumer mailboxes in the united States.
During the first 45 days of initial monitoring, Twitter saw nearly 2.5 billion messages spoofing its domains. Twitter reports ~110 million messages/day were spoofing its domains prior to deploying DMARC, redUCEd to only 1,000/day after publishing a "reject" policy. Quelle: http://www.dmarc.org/
Achtung:
Ein DMARC-Eintrag auf einer Domäne gilt auch für Subdomains !. DMARC-Prüfer haben dazu eine Liste der "Root-Domains", um z.B. "<firma>.de" von "<firma.co.uk>" zu unterscheiden.
Achtung
Ein gesetzter DMARC Eintrag erfordert für die Domäne und alle Subdomains auch einen SPF-Eintrag. Fehlt dieser, dann lehnen viele Firmen die Mails ab, wenn die SPF-Prüfung bei gesetztem DMARC-Eintrag nicht möglich ist.
Die Zahlen sind beeindruckend, aber DMARC ist nur die Einstellung, dass die Empfänger mit DMARC-Support an die Domaininhaber auch die Zahlen melden. Der Filter solche "Phishing-Mails" basiert auf SPF und/oder DKIM und gibt es schon länger.
Der DMARC Eintrag
Dazu ist ein DMARC-Eintrag erforderlich. Aus Sicht von DNS ist es einfach ein TXT-Record, der den Namen "_dmarc" trägt. Ein Eintrag für die MSXFAQ könnte also lauten: (alles ohne Umbrüche und bitte eine gültige Mailadresse verwenden):
Warnung
Dies ist ein Beispiel damit ich für meine Domäne die Reports bekomme. Bitte nutzen Sie als Mailadresse für ihre Domains bitte ihre eigene Adresse oder einen Dienstleister.
Die Felder können unterschiedliche Bedeutung haben:
Feld
Bedeutung der Werte
v=DMARC1
Kennzeichnet die Version. Aktuell ist Version 1 gültig.
p=sp=
Policy oder "Subdomain Policy"Der Wer hinter "p=" kennzeichnet, wie der Empfänger mit Mails umgehen soll, die nicht korrekt mit SPF oder DKIM überprüft werden konnten. Der Eintrag "sp=" beschreibt das Vorgehen für Sub-Domains. mögliche Werte sind:* noneDer Empfänger soll die Mail trotzdem weiter senden
quarantineDer Empfänger soll die Mail annehmen aber in Quarantäne legen
rejectDer Empfänger soll die Mail einfach auf SMTP-Level ablehnen
pct=
Prozentsatz der Mails, die entsprechend von "p" gefiltert werden sollen. Wenn jemand aber mit DMARC einen Eintrag addiert und korrekt alle Mails gemäß SPF und DKIM versendet, sollte kein Problem mit einer "100" hier haben
rua
Receive or aggregated ReportDer Empfänger sendet an diese Adresse oder Adressen einen "Summenbericht". Das passiert in der Regel einmal am Tag
Achtung: Wenn der Empfänger in einer anderen SMTP-Domäne ist, dann senden die DMARC-Aggregatoren die Mail in der Regel erst dann, wenn die Empfängerdomäne ihr Einverständnis gegeben hat. DAs macht diese ebenfalls per DNS-Eintrag.msxfaq.de._report._dmarc.netatwork.de TXT "v=DMARC1"So gibt die Domäne "netatwork.de" bescheid, dass die DMARC-Report für msxfaq.de annehmen wird.
ruf
receiver of forensic reportAn diese Mailadresse sendet der Empfänger einen forensischen Report über die fehlerhafte Mail. Als Betreiber können Sie dann gut erkennen, welcher angebliche Absender an das Ziel versucht hat, eine Mail mit ihrer Domain zu senden. So können Sie "vergessene" Versender erkennen und korrigieren oder versuchen gegen Missbrauch vorzugehen.
Auch für hier verwendete Adressen anderer Domänen muss der Empfänger seine Bereitschaft signalisieren.
adkim
Abgleicheinstellung für DKIM.Hiermit können Sie vorgeben, wie streng die Prüfung bezüglich DKIM sein soll.* s=StrictDie Domänen müssen exakt übereinstimmen
r=RelaxedDie Kopfzeile im SMTP-Header darf auch eine Subdomain sein, z.B. "newsletter@msxfaq.de"
aspf
Dieser Parameter steuert analog die SPF-Auswertung.* s=StrictDie Domänen müssen exakt übereinstimmen
r=RelaxedDie Kopfzeile im SMTP-Header darf auch eine Subdomain sein, z.B. "newsletter@msxfaq.de"
Für eine erfolgreiche DMARC-Validierung reicht es, wenn eines der beiden Checks, SPF oder DKIM erfolgreich war. DKIM wird überwiegend genutzt, wenn die Authentizität der Mail auch über Relaisstationen gewährleistet werden soll, aber erlaubt kein Umschreiben der Absender (Stichwort Mailingliste). Hier ist dann SPF besser, wenngleich dann die ausgehenden IP-Adressen gepflegt sein müssen.
Wer mit DMARC anfängt, kann also erst einmal den Eintrag setzen aber stellt also Aktion z.B. "p=none" und schaut sich die Meldungen einige Zeit an.* DMARC Record Assistant http://kitterman.com/dmarc/assistant.html
Es ist gut zu sehen, dass die großen Versender und Logistiker, aber auch die Internet-Firmen hier Vorreiter spielen. Interessant sind hier natürlich insbesondere die Einträge zum RUF und RUA´. Scheinbar nutzen sehr viele die Dienste von agari.com, um die Ergebnisse von "Domainmissbrauch" zentral zu erkennen. Auf deren Webseite finden sich Daten wie
In fact, we get data from 85% of all email inboxes in the US and 60% of email inboxes globally.Quelle: http://agari.com/what-we-do/
Auf der anderen Seite haben gerade deutsche Domains hier noch Nachholbedarf. (Stand Okt 2014). Ich habe einfach ein paar Namen einmal durch probiert. Gerade die großen Provider scheinen hier eher auf ihr "E-Mail Made in Germany" zu setzen.
_dmarc.t-online.de text = nicht vorhanden
_dmarc.telekom.de text = nicht vorhanden
_dmarc.gmx.de text = nicht vorhanden
_dmarc.web.de text = nicht vorhanden
_dmarc.basf.com text = nicht vorhanden
_dmarc.siemens.de text = nicht vorhanden
_dmarc.rwe.de text = nicht vorhanden
_dmarc.bsi.de text = nicht vorhanden
_dmarc.ccc.de text = nicht vorhanden
_dmarc.deutsche-bank.de text = nicht vorhanden
_dmarc.netbank.de text = nicht vorhanden
_dmarc.allianz.de text = nicht vorhanden
_dmarc.aldi.de text = nicht vorhanden
_dmarc.tchibo.de text = nicht vorhanden
_dmarc.ebay-kleinanzeigen.de text = nicht vorhanden
Interessant ist auch, dass die Banken noch nicht dabei sind.
Es ist wie gesagt nicht schlimm, wenn man DMARC nicht unterstützt. Letztlich muss jede Firma selbst entscheiden, ob ihr Mailsystem die Mails per DKIM signieren kann und dann per DMARC dies den Empfängern mitgeteilt wird. Ich persönlich würde ja eh viel mehr auf eine echte S/MIME-Signatur setzen aber es ist durchaus eine Option den eigenen Namen und die Marke zu schützen.
Reporting
Die Rückmeldungen der entfernten Server, an die Mails mit ihrer Domain gesendet werden, kommen ganz klassisch per Mail und nicht "modern" über Webservices. Entsprechend muss die im DMARC-Record hinterlegte Mailadresse natürlich einem Postfach zugeordnet sein.
Das muss aber kein Postfach in ihrer Domäne sein und wenn Sie sich die DMARC-Records der oben genannten Firmen anschauen, dann erkennen Sie eine Häufung der Firmen "agari.com" und "returnpath.net". Beide sind Dienstleister die solche Rückläufer einsammeln und die Auswertung als "Hosted Service" ihren Kunden anbieten. Sie können die Mails aber natürlich auch in ein eigenes Postfach ablegen.
Ich habe dazu bei einer meiner Spiel-Domains einfach mal einen _DMARC-Eintrag addiert und als RUF/RUA-Adresse meine normale Mailbox angegeben. Hier der Mustereintrag
Der Body der Mail war leer und als Anlage war eine ZIP-Datei angehängt. In der war wiederum genau eine XML-Datei, in der z.B.: die vom Empfänger gesehenen Einstellungen wieder gegeben sind und die Detaildaten der Verbindung. Hier war es genau eine von der Source-IP "80.66.20.28".
Man sieht auch, dass sowohl die SFP- als auch die DKIM-Abfrage fehlgeschlagen sind. Leider konnte ich im Header der Mail keine Hinweise darauf sehen, dass diese Stausmail per DKIM gesichert war. So kann ich nicht sicher sein, dass nicht jemand anderes mit einen StatusBericht sendet und damit die daraus generierten Statistiken verändert.
Ein kleiner PowerShell-Einzeiler liefert eine Tabelle der Statusmeldungen:
Für Spammer sind diese Adressen zwar leicht per DNS "einzusammeln" aber natürlich kein lohnendes Ziel. Diese Mails wird wohl nie ein unbedarfter Anwender lesen. Damit niemand gefälschte Reports darunter mischt, werden natürlich auch diese Mails per SPF/DKIM gesichert, so dass Fälschungen früh aussortiert werden können.
Und selbst dann wird der verarbeitende Prozess eine Mail nur dann verstehen, wenn Sie sich an das Format hält. Dennoch scheint es Spammer zu geben, die entweder die Mailadresse hier auf der Webseite eingesammelt haben oder tatsächlich den DNS-Eintrag parsen. Auf jeden Fall kommt tatsächlich Spam an diese Adresse.
Es gibt aber dennoch ein Störpotential. Es ist heute sehr einfach eine Domäne im Internet zu registrieren und einen DMARC-Eintrag zu addieren, in dem eine Mailadresse einer anderen Person hinterlegt wird, die ich stören möchte. Wenn der Mailserver dieses Ziels nicht SPF/DKIM prüft und gefälschte Report-Mails verwirft, dann wird er die Mails in das Postfach zustellen.
Wenn ich dann absichtlich eine Mail mit dieser Absenderdomäne z.B. an einen Server sende, der SFP/DKIM prüft und die Reports anhand des DMARC-Eintrags erstellt, dann sendet dieser Server eine Mail an die hinterlegte Adresse.
Das kann schon störend sein, wenn ich von einem PC eben tausende "kleine" Mails an viele Mailserver mit SPF/DKIM-Support sende und diese dann eine deutlich größere "Statusmail" an die DMARC-Reportadresse sende. Ob das schon für einen DDoS per SMTP reicht ?
Seit Anfang 2016 hat die 1und1-Gruppe den Schutz gegen Spam mittels SPF noch etwas verstärkt. Der Versuch aber einen DMARC-Eintrag zu addieren, schlägt leider fehlt. Technisch musste man dazu bei 1und1 früher eine "Subdomain" anlegen aber im neuen Control-Center können Sie auf der Domäne direkt einen TXT-Record addieren. Allerdings ist die aktuell (Jun 2016) nicht möglich, da die Eingabe eine Validierung macht und ein einfaches _dmarc.<domain> nicht erlaubt ist.
Leider kann ich auch keine "Subdomain" mit einem "_" ersatzweise anlegen. Hier muss 1und1 wohl noch etwas korrigieren, damit auch DMARC-Einträge möglich werden* TXT-Record für eine Domain setzen oder löschen
Die Rückmeldungen von Firmen, die DMARC-Einträge auswerten, kommen in dem angegebenen Postfach als XML-Datei an. Sicher könnten Sie nun das Postfach lesen und auswerten, sei es per Outlook oder mit einem PowerShell-Skript. Aber dann steht immer noch die grafische Auswertung an. Im Zeichen der Cloud gibt es einige Anbieter, die ihnen die Arbeit hier abnehmen. Sie lassen die Reports einfach an diesen Anbieter senden oder leiten ihre Reports weiter. Per Browser können Sie dann entsprechend aufbereitet Reports betrachten.
Die folgende Liste von DMARC-Auswertestellen ist keine repräsentative Marktübersicht und darf nicht als Empfehlung meinerseits missverstanden werden.* DMarcianhttps://dmarcian.com/
Domain-based Message Authentication, Reporting and Conformance, kurz DMARC, ist eine Spezifikation, die entwickelt wurde, um Missbrauch von E-Mails zu reduzieren. Sie versucht, einige seit langem bestehende Unzulänglichkeiten im Zusammenhang mit Authentifizierungsproblemen beim E-Mail-Versand zu beheben. Sie wurde bei der IETF zur Standardisierung eingereicht.[1]
Überblick
DMARC baut auf den bekannten Techniken SPF (Sender Policy Framework) und DKIM (DomainKeys Identified Mail) auf, indem es festlegt, wie der Empfänger von E-Mails die Authentifizierung durchführen soll.
Während die vorgenannten Techniken beschreiben, wer eine Mail versenden darf (SPF) bzw. dass diese Mail in bestimmter Weise unverändert vom Absender stammt (DKIM), kann der Absender nach der DMARC-Spezifikation zusätzlich Empfehlungen geben, auf welche Art der Empfänger mit einer Mail umgeht, die in einem oder beiden Fällen nicht den Anforderungen entspricht.
Sofern der Empfänger einer E-Mail die DMARC-Spezifikation anwendet, ist dadurch eine konsistente Überprüfung der Authentizität dieser E-Mail gesichert.
Aufbau eines Eintrags
DMARC bedient sich hierzu, wie auch SPF und DKIM, der TXT-Records des Domain Name Systems (DNS). Dort wird zusätzlich zu den SPF- und DKIM-Einträgen ein weiterer RR-Eintrag mit zum Beispiel folgendem Aufbau angelegt:
Besondere Bedeutung haben die Abgleichmodi. Für SPF fordert die Spezifikation, dass erstens die Überprüfung positiv ausfällt und zweitens die From: Kopfzeile der Mail dieselbe Domäne aufweist, wie im SPF-Record hinterlegt.
Für DKIM wird gefordert, dass die Signatur gültig ist und zusätzlich die dort genannte Domäne dieselbe ist, wie in der From: Kopfzeile der Mail. Als Abgleichmodi sind s='strict' bzw. r='relaxed' vorgesehen.
Bei 'strict' müssen die Domänen exakt übereinstimmen, bei 'relaxed' darf die From: Kopfzeile auch eine Subdomäne enthalten. Über die Auswertung erhält der Sender einen täglichen Report an die genannte Adresse.
Die Policy (hier abgekürzt als 'p' bzw. 'sp' für Subdomains) legt schließlich fest, wie der Empfänger mit der Mail verfahren soll, wenn die Überprüfung scheitert. Vorgesehene Modi hierfür sind 'none', 'quarantine' und 'reject'. 'none' (auch als Monitormodus bezeichnet) wird in der Regel zum Testen verwendet und macht dem Empfänger keine Vorschriften über die Verfahrensweise. 'quarantine' verlangt die Kennzeichnung der Mails als Spam, 'reject' verlangt, die Mail zu verwerfen.
DMARC überprüft den From-Header der E-Mails und stellt an diesen strenge Anforderungen (sog. „alignment“). Im Zusammenhang mit E-Mail-Weiterleitungen und Mailinglisten ist dies extrem problematisch, da DMARC verlangt, dass sämtliche Mailinglistensoftware (und E-Mail-Weiterleitungen) den From-Header von E-Mails verändert, und die dort angegebene E-Mail-Adresse des Absenders durch die E-Mail-Adresse der Mailingliste bzw. die eigene E-Mail-Adresse ersetzt.[
müsste durch die Mailinglistensoftware folgendermaßen abgeändert werden:
From: Nutzer via wikide-l <wikide-l@lists.wikimedia.org>
Subject: ...
To: wikide-l@lists.wikimedia.org
Die E-Mail-Adresse des wirklichen Absenders würde hierdurch komplett entfernt, so dass es nicht mehr möglich ist, mit dem Absender direkt in Kontakt zu treten (es sei denn, die Mailingliste fügt einen entsprechenden Reply-To-Header hinzu, was aber ebenfalls zu Problemen führt).
DMARC fordert Änderungen an sämtlicher Mailinglisten- und Weiterleitungssoftware.
Dieses prinzipielle Problem im Konzept von DMARC hat dementsprechend auch schon zu schwerwiegenden Problemen bei Mailinglisten geführt („Yahoos DMARC-Policy führt also derzeit dazu, dass Yahoo-Sender den massenhaften Unsubscribe von Mailinglisten-Abonnenten fremder Domains verursachen.“).
Now a days mail is an unavoidable part of life. How ever the misuse of mail also increasing day by day. Spaming, Spoofing etc. There are many way which can drag you into trouble with your mailbox.
To stop such invalid sender, few new authentication protocol (like SPF, DomainKey) has been started, but it is not enough to stop spammer.
DKIM and DMARC add an extra layer of authentication using an encrypted algorithm.
Recipient mail-server can verify the DKIM signature by recovering the sender’s public key through DNS. It then uses that key to decrypt the hash value in the email’s header and simultaneously recalculate the hash value for the mail message it received.
Unfortunately, Plesk control panel user can not take advantage of this. Till Plesk 12.5, it use old DomainKey, SPF authentication mechanism. Outlook, Exchange server does not like it at all.
Plesk will add DKIM support on upcoming Plesk 17 Onyx.
Understand, what about Plesk 12.x user ?
Don’t worry, follow the tutorial, you will learn, how to install DKIM and DMARC on Plesk 12.5
Add the following value to ‘/etc/opendkim/TrustedHosts’. It will list the top trusted hosts as you desire.
@cos701.tld cos701.tld
We need to edit the configuration file to configure DKIM, open /etc/opendkim.conf with your favorite editor and add the following lines to the end of the file
==========================================================
Summary of Results
==========================================================
SPF check: pass
DomainKeys check: pass
DKIM check: pass
Sender-ID check: pass
SpamAssassin check: ham
Congratulation! you have successfully installed the DKIM on Plesk. It is very great full to me if this tutorial ‘Install DKIM and DMARC on Plesk 12.5’ helpful to you.
DMARC stands for “Domain-based Message Authentication, Reporting & Conformance”, it's an email authentication protocol that allows senders and receivers to improve and monitor protection of the domain from fraudulent email. Many ISP's now require DMARC so if you do not have it properly configured your email may not be accepted by those ISP's.
mxtoolbox.com is a great way to tell if your domain is correctly configured for DMARC (as well as SPF).
This is the process to configure DMARC for your account with our Canadian shared hosting servers:# In the server control panel (Plesk - how to log into plesk) go to your DNS Settings area for the domain you wish to add DMARC for:
Now back in the "Website & Domains" area of Plesk click on the "Mail Settings" Icon for the domain you wish to apply DMARC for as seen here: Datei:Bild15.png
Here at the bottom of the page you will find a checkbox, ensure it is selected and click "OK"
It takes time for DNS to propagate but after that has happened you can test that it's working correctly via a free online tool such as mxtoolbox.com and your emails should be DMARC compliant!
Using DNSSEC (Linux)
DNSSEC is the extension of the DNS protocol that allows signing of DNS data in order to secure the domain name resolving process. For general information about DNSSEC and its usage, visit ICANN website and https://tools.ietf.org/html/rfc6781.
Plesk enables you to protect DNS data of hosted domains with DNSSEC. You can do the following: * Configure the settings used for key generation and rollover.
Sign and unsign domain zones according to the DNSSEC specifications.
Receive notifications.
View and copy DS resource records.
View and copy DNSKEY resource record sets.
Requirements
Plesk for Linux with the Bind DNS server, starting from Bind 9.9.
DNSSEC extension is commercial and is not included by default in Plesk editions.
Enabling DNSSEC Support
To enable the support for DNSSEC, install the Plesk DNSSEC extension (Extensions > Extensions Catalog).
Configuring Default DNSSEC Settings
The default DNSSEC settings are located in Tools & Settings > Extensions > DNSSEC. You can change the default policy for generating Key Singing Key (KSK) and Zone Signing Key (ZSK) pairs.
The recommended policy for KSK and ZSK:* Use a long key and a long rollover period for the KSK (Key Signing Key).
Every time the Key Signing Key is updated, the zone owner needs to update the DS records in the parent domain zone. The recommended policy helps to update DS records in the parent zone as seldom as possible without decreasing security.
Use a shorter key and a shorter rollover period for the ZSK (Zone Signing Key).
The Zone Signing Key is updated automatically. The recommended policy helps to save system resources without decreasing security.
When hosting customers sign their zones, they can use the default values or specify different values.For details, see Using DNSSEC on Domains.
Protecting DNS Zones with DNSSEC
To use DNSSEC, domain owners must sign their DNS zones.For details, see Using DNSSEC on Domains.
How Key Rollover Works in Plesk
In order to prevent DNS outage for a domain, Plesk uses more than one key as the KSK and more than one key as the ZSK. A previously generated key exists in parallel with a new key for some time, to allow all the changes in a DNS zone to take effect. Obsolete keys are removed automatically.
KSK rollover
Plesk uses a modification of Double-RRset method for rolling over Key Signing Keys, the difference is that Plesk has two Key Signing Keys during each rollover period. This measure allows enough time for the domain zone owner to update the corresponding DS records in the parent zone (for example, the time period between rollover events 1 and 2 in the scheme below).
User actions at KSK rollover
The domain zone owner is notified about the rollover and about the need to update the DS records in the parent zone. The DS records become obsolete when the oldest KSK expires and the newest KSK is generated (for example, at rollover event 2 in the scheme below). If the domain zone owner did not update the DS records in the parent zone, then at the end of one rollover period after the notification the domain stops resolving.
ZSK rollover
To allow enough time for slave and caching DNS servers to sync with the master DNS server, Plesk does the following:* Adds a new key to the zone at a certain time before the rollover event.
Removes the previous key at the same certain time after the rollover event.
This certain time before or after a ZSK rollover is called a transition period in Plesk. The transition period is either 30 days or the sum of zone's SOA TTL and SOA Expire values (if their sum is over 30 days). However, the transition period cannot be longer than half the ZSK rollover period, otherwise the rollover functionality will be disrupted and the zone signatures will become invalid.
Therefore, to make sure that ZSK rollover is performed correctly, Plesk sets limits on the following values:* The zone's SOA TTL and SOA Expire. Their sum cannot be longer than a certain calculated value.
The ZSK rollover period. It cannot be shorter than a certain calculated value.
User actions at ZSK rollover
No actions are required of the domain's DNS zone owner when Zone Signing Keys are rolled over.
Email Bounces / Address requirements
We require that users provide a valid and properly configured email address for the purposes of being able to contact the user in case of problems and other details surrounding their account.
We thus expect users to provide an email account that they actually read on a regular basis.
A personal/non-role account is prefered.
SixXS does not send any email newsletters, hence there is no need to setup a specific account for this.
The current policy is codified and the validity of an e-mail address is determined as follows: #
It is syntactically correct (ie, it has one @)
If it is in a domain whitelist, it is accepted
If it is in a domain blacklist, it is rejected
The local name (part in front of the @) is less than 64 characters
The local part is not a role account¹
The domain name (part after the @) is less than 255 characters
The local name and domain name is valid (ie does not have two consecutive dots), do not have non ISO characters, and are quoted properly
The domain is configured properly (see below)
For the domain, the NS and MX records are looked up and resolved to their A and AAAA records so that we have a list of addresses. The MX records are then checked in the white- and blacklist again (such that we can accept e-mail domains hosted on well-known clusters. For each of the A (IPv4) addresses, we check a number of policy DNSBLs (such as zen.spamhaus.org, dul.dnsbl.sorbs.net, and dialups.mail-abuse.org) with the intent to find home-setups, which we do not accept.
Note:In a study performed by SixXS on 32019 e-mail addresses, we found that 11.2% of all addresses (3608) bounced at least once. Of the valid addresses, 9.49% bounced. Of the addresses that our new policy considers invalid, 16.6% bounced. We understand that our policy comes across as harsh, but we assert that it makes a difference to be strict.
"Information"In general: use your ISP's mail address, or a hosted solution, but don't run a mailserver at home - you may be listed in DNSBLs!
Bouncing Email
We expect that email accounts are reachable. If you are not reachable by email we cannot contact you regarding (mal)function of your tunnel. When we receive a bounce on an email address the account will automatically and directly be set into the disabled state. Connectivity provided to a disabled account will therefor be disabled.
If your e-mail address bounced, and you would like to have your connectivity back, update your handle with a valid email address in the appropriate registry and notify SixXS of the change, we can then reinstate your account.
Messages from your mailhost notifying us that the message we send could not be delivered (for example, greylisting longer than 5hrs) and other automatic replies are also treated as bounces and thus will automatically disable your account.
Make sure that the domain of your email address is RFC compliant and has at least 2 distinctly separate working MX servers or a proven cluster solution. If your DNS contains only one MX record and it has a cluster behind it, direct signups will not be able to detect that, thus contact SixXS in that case. Mail servers on dynamically-assigned IP addresses and/or DSL/cable links are not accepted as they have proven not to be stable enough.
Check your domain using for example using ZoneCheck, IIS.SE DNS Check if it looks okay. If you have weird DNS records or had problems in your DNS setup, note well these could get cached in which case you won't be reachable either.
SPF, DKIM, DMARC and forwarding email
SixXS uses SPF, DKIM and DMARC in strict modes. Thus be very mindful when forwarding email as it can cause email to bounce because the address you are forwarding from is not in our SPF records. Also make sure to not break DKIM signed headers.
Forwarding email breaks SPF verification unless you are able to control the receiving end to ignore SPF checks for forwarded messages.
White- and Blacklists
In an attempt to be transparent on the e-mail verification system, here's the currently configured regular expressions for domains and MX hosts from which we automatically reject any e-mail address:
As we do not want to encourage the usage of any provider we do not publish the whitelist. Of course, the white and blacklists are not final, if we notice that a domain is unacceptable even though it passes the above tests we may still consider rejecting the address.
If you have a properly set up ISP account, or another email account like one from work we prefer that you provide and use that. Setting up throwaway accounts will be noticed and such accounts will be rejected or disabled. To note, we specifically reject mailinator kind of accounts as these accounts are definitely not intended for proper email communication.
If you would like to file a petition to be added (or removed) from our white or blacklist, please contact SixXS and provide proper argumentation.
¹ = A role account is an account that is not associated with a particular person, but with an office, position, or task. Those doing the task use the account only to do the task. They have other accounts for other work.
² = Using a CNAME in your domain breaks your email because sendmail (and possibly other SMTP software) will rewrite the domain portion of the destination email address to that of the label in the CNAME. See also CNAME records in mail by D. J. Bernstein. Note that having a CNAME for example.tld is of course impossible unless you get the tld to have the same record. Having an MX point to a CNAME record causes additional DNS lookups, which might cross a threshold, and thus cause your mail to be dropped. Additionally "Mail loops back to me" errors might be caused by this. Also see RFC1034 - DOMAIN NAMES - CONCEPTS AND FACILITIES for more details. In short: Don't use CNAMEs in relation to SMTP.
