DomainKeys (DK) y DomainKeys Identified Mail (DKIM) son métodos de valicación de correo electrónico que permiten validar y firmar, mediante firma digital (clave pública y clave privada), los correos entrantes y salientes de nuestro servidor de correos. Esto permite que un dominio sea responsable por los correos que se envien a través de el para asegurarse que lleguen al inbox o que, de lo contrario, lleguen directo al junk.
Para validar la autenticidad de un remitente existen varias formas a nivel de dominio (dns) como es el SPF, Sender-ID, DK y DKIM.

Este último tiempo he estado trabajando con postfix validando los correos salientes para llegar al inbox de los servidores de correo más populares como Gmail, Yahoo! y Hotmail (msn, live, etc).
Estuve analizando las especificaciones RFC de cada protocolo (RFC4870 – DK; RFC4871 – DKIM), probandolas e implementandolas, llegando a distintas conclusiones. Básicamente, el diagrama de funcionalidad es el siguiente:

En simples palabras, el correo pasa por un filtro antes de ser enviado por el servidor, el que verifica que el correo cumpla los parametros segun una configuracion especifica y si todo esta ok, entonces lo firma y lo entrega. El recipiente, al ver que existe un header de domainkeys o dkim, hace una peticion a la clave publica que esta en el dns (como registro TXT) del dominio, segun los parametros pasados en el headerm, hace los chequeos correspondientes y si todo esta ok, entonces lo deja entrar.

Básicamente un header DK o DKIM está formado por un selector, que es el “nombre” que se le da a la clave para ese dominio, esto permite tener varias claves para varios dominios con sus respectivos selectors. El selector especificado en el header del correo debe existir como registro TXT en la zona del dominio (en el dns) de lo contrario no será validado. Seguido del dominio quien firma el correo, el tipo de encriptacion y voluntariamente, los headers que se firmarán. Algo mas o menos asi:

DomainKey-Signature: a=rsa-sha1; s=SELECTOR; d=DOMINIO.org; c=simple; q=dns;
b=NxbpGHnMKAqHiSwH5T70YLdU9ZA4GbpNG3xp+KAaYphAqpPcqByssIIqKxsN/uhg6
shbEP2CyQew2uJRERi22w==

Tipo de encriptación (el hash) rsa-sha1, selector SELECTOR, d (dominio) dominio. Eso es lo básico, pero existen más parametros para agregar a los headers:

OPTIONS
-a peerlist
Identifies a file of “peers” which identifies clients whose con-
nections should be accepted without processing by this filter.
The peerlist should contain on each line a hostname, domain name
(e.g. “.example.com”), IP address, an IPv6 address (including an
IPv4 mapped address), or a CIDR-style IP specification (e.g.
“192.168.1.0/24”).

-A Automatically re-start on failures. Use with caution; if the
filter fails instantly after it starts, this can cause a tight
fork(2) loop.

-b modes
Selects operating modes. modes is a concatenation of characters
which indicate which mode(s) of operation are desired. Valid
modes are s (signer) and v (verifier). The default is sv.

-c canon
Selects the canonicalization method to be used when signing mes-
sages. When verifying, the message’s DomainKey-Signature:
header specifies the canonicalization method. The recognized
values are nofws and simple as defined by the DomainKeys draft.
The default is simple.

-C config
Configuration control. See the CONFIGURATION section for
details.

-d domain [,…]
A comma-separated list of domains whose mail should be signed by
this filter. Mail from other domains will be verified rather
than being signed.

If the value of this parameter starts with a “/” character, it
is assumed to be a filename from which the domain list will be
read, one per line, with “#” characters indicating the beginning
of a comment.

In either case, the domain name(s) may contain the special char-
acter “*” which is treated as a wildcard character matching zero
or more characters in a domain name.

-D Sign subdomains of those listed by the -d option as well as the
actual domains.

-f Normally dk-filter forks and exits immediately, leaving the ser-
vice running in the background. This flag suppresses that be-
haviour so that it runs in the foreground.

-h Causes dk-filter to add a header indicating the presence of this
filter in the path of the message from injection to delivery.
The product’s name, version, and the job ID are included in the
header’s contents.

-H Includes on DomainKey signatures the list of headers that were
included in the signature. This makes the signature header
larger by explicitly listing the included headers, but this also
allows verifying agents to ignore headers that were added in
transit.

-i ilist
Identifies a file of internal hosts whose mail should be signed
rather than verified. Entries in this file follow the same form
as those of the -a option above. If not specified, the default
of “127.0.0.1” is applied.

-I eilist
Identifies a file of “external” hosts which may send mail
through the server as one of the signing domains without creden-
tials as such; basically suppresses the “external host (host-
name) tried to send mail as (domain)” log messages. Entries in
this file follow the same form as those of the -a option above.

-k Causes -s to be interpreted as the location of a key list, which
is a file listing rules for signing with multiple keys. The key
list should contain a set of lines of the form sender-pat-
tern:keypath where sender-pattern is a pattern to match against
message senders (with the special character “*” interpreted as
“zero or more characters”), and keypath is the path to the PEM-
formatted private key to be used for signing messages which
match the sender-pattern. The selector used in the signature
will be the filename portion of keypath.

-l Log via calls to syslog(3) any interesting activity.

-m mta [,…]
A comma-separated list of MTA names (a la the sendmail(8) Dae-
monPortOptions Name parameter) whose mail should be signed by
this filter. There is no default.

-M macro[=value][,…]
Defines a set of MTA-provided macros which should be checked to
see if the sender has been determined to be a local user and
therefore whether or not the message should be signed; if a
value is specified, the value of the macro must match the value
specified (matching is case-insensitive), otherwise the macro
must be defined but may contain any value. The list is empty by
default.

-o header [,…]
A comma-separated list of headers which should not be signed.
Ignored when verifying.

-p socketspec
Specifies the socket that should be established by the filter to
receive connections from sendmail(8) in order to provide ser-
vice. socketspec is in one of two forms: local:path which cre-
ates a UNIX domain socket at the specified path, or
inet:port[@host] which creates a TCP socket on the specified
port. If the host is not given as either a hostname or an IP
address, the socket will be listening on all interfaces. This
option is mandatory.

-P pidfile
Writes the process ID of the filter, once started, to the file-
name given.

-q Requests that messages which fail verification be quarantined by
the MTA. (Requires a sufficiently recent version of the milter
library.)

-R When a signature verification fails and the signing site adver-
tises a reporting address (i.e. r=user@host in its policy
record), send a structured report to that address containing
details needed to reproduce the problem.

-s keyfile
Gives the location of a PEM-formatted private key to be used for
message signing.

-S selector
Defines the name of the selector to be used when signing mes-
sages. See the DomainKeys specification for details.

-T secs
Sets the DNS timeout in seconds. A value of 0 causes an infi-
nite wait. The default is 5. Ignored if not using the asyn-
chronous resolver package. See also the NOTES section below.

-u userid
Attempts to be come the specified userid before starting opera-
tions.

-U popdb
Requests that the filter consult a POP authentication database
for IP addresses that should be allowed for signing. The filter
must be specially compiled to enable this feature, since it adds
a library dependency.

-V Print the version number and exit without doing anything else.

CONFIGURATION
The value of the -C switch is a comma-separated list of settings of the
form result=action which defines what the filter should do with mes-
sages that produce certain results. Each result and each action has a
full name and an abbreviated name. Either is accepted. Below, the
abbreviated name appears in parentheses.

results
badsignature (bad) the signature found in the message did not
verify successfully against the message; dnserror (dns) an error
was encountered attempting to retrieve a public key from the
nameserver; internal (int) an internal error occurred; nosigna-
ture (no) no signature was present on the message; signature-
missing (miss) no signature was present on the message which
claims to sign all messages.

action accept (a) accept the message; discard (d) discard the message;
tempfail (t) temp-fail the message; reject (r) reject the mes-
sage.

No explicaré como montar un servidor postfix con domainkeys o dkim, solo intento explicar el funcionamiento y las posibilidades que nos permite este sistema de firmas digitales para nuestros correos. Quizás más adelante exponga un documento completisimo de como montar un mail server con estas caracteristicas.

Enlaces:

RFC4870
RFC4871
DomainKeys Identified Mail HomePage
Documento explicativo sobre las DomainKeys
Como implementar DomainKeys en postfix