Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

After testing much and retracing my steps, I still cannot get google mail to validate.

My mail server is Debian 5.0 with exim

Exim version 4.72 #1 built 31-Jul-2010 08:12:17
Copyright (c) University of Cambridge, 1995 - 2007
Berkeley DB: Berkeley DB 4.8.24: (August 14, 2009)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS move_frozen_messages Content_Scanning DKIM Old_Demime
Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite
Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
GnuTLS compile-time version: 2.4.2
GnuTLS runtime version: 2.4.2
Configuration file is /var/lib/exim4/config.autogenerated

My remote smtp transport configuration:

  debug_print = "T: remote_smtp for $local_part@$domain"
  driver = smtp
  helo_data =
  dkim_domain =
  dkim_selector = mailer
  dkim_private_key = /etc/exim4/dkim/
  dkim_canon = relaxed

  hosts_avoid_tls = REMOTE_SMTP_HOSTS_AVOID_TLS

The path to my private key is correct.

I see a DKIM header in my messages as they end up in my gmail account:

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=mailer;
    h=Content-Type:MIME-Version:Message-ID:Date:Subject:Reply-To:To:From; bh=nKgQAFyGv<snip>tg=;

However, gmail headers always report dkim=neutral (no signature):

dkim=neutral (no signature)

My DNS results:

dig +short txt
mailer._domainkey. descriptive text "v=DKIM1\; k=rsa\; t=y\; p=LS0tLS1CRUdJ<snip>M0RRRUJBUVV" "BQTRHTkFEQ0J<snip>GdLamdaaG" "JwaFZkai93b3<snip>laSCtCYmdsYlBrWkdqeVExN3gxN" "mpQTzF6OWJDN3hoY21LNFhaR0NjeENMR0FmOWI4Z<snip>tLQo="

Note that the base64 public key is 364 chars long so I had to break up the key using bind9.

$ORIGIN _domainkey.
mailer                  TXT     ("v=DKIM1; k=rsa; t=y; p=LS0tLS1CRUdJTiBQVUJM<snip>U0liM0RRRUJBUVV"

Can anyone point me in the right direction? I would really appreciate it.

share|improve this question
Was able to get this working after building a smaller key that does not make my TXT record longer than 255 chars. I followed the instructions at – Bretticus Aug 16 '11 at 20:16
up vote 1 down vote accepted

Don't break the key. Just add it as a single string. It will wordwrap in most editors. My key looks like the following.

rsa1._domainkey                 IN      TXT     "v=DKIM1; t=s; p=MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKq2Ul9a5ixDPQm9WMoPI9fUEZU8FZwfux/O9Sl5+GDCR4rt0CsBzyZj4PY5DTtVHix++EZkR5rVdM4W59DtweKCK6XVntq4Y4GSm+gfZkf/fq45BSCQNilbYux4xqsHQIDAQAB"

I don't believe DKIM supports reassembling strings. If you are using a multi-line format verify it is reassembled into one piece. If it is served with the extra quotes, it will likely break. Your DNS lookup shows that this is the case.

All to often I see SPF records showing up as "v=spf1" "a" "-all", which is read as vspf1a-all. This record should be delivered as v=spf1 a -all but would work as "v=spf1 " "a " "-all". SPF does specify support for quoted parts by concatenates the parts as is without introducing extra spaces. This allows lines to be broken mid-word.

EDIT: I am testing using a key formatted in multiple strings. However, I will need to wait until DNS updates. tells me my new key does not exist.

The format I get from bind does not match the format the documentation leads me to believe I should get. The documentation indicates that I should see a single string concatenating the fragments I entered. Instead I see the fragments as entered in the zone file.

Testing with bind indicates the text fragments can be as large as 255 characters. Anything over that needs to be split. In any case two such fragments will likely exceed the capacity of a UPD packet.

A review of the RFC indicates a 2048 bit key size is likely the practical limit. There is a warning to implementers that the may have to deal with TXT fragments and reassemble them in order.

share|improve this answer
I snipped the key because it's very long. In your example, is that a real public key, and if so, how many bits? – Bretticus Feb 11 '11 at 18:59
@Bretticus Yes that is my real public key. My key is 768 bits. – BillThor Feb 11 '11 at 22:11

You obfuscate data which is public anyway, which doesn't help us help you.

Eg, we can't check to make sure that you updated the SOA serial number and that the change made it out to all the NS servers and that this was done with a negative TTL in the SOA low enough that Gmail's not reasonably seeing no data.

Using multiple "..." sequences in DNS TXT records does not combine into one string, it provides multiple strings. It's then up to the application / protocol / specification to say how to deal with the strings; eg "join with space between them", "directly join", "only use first".

The DKIM spec says to join directly, but this is directly into the sort of area which tends to get overlooked by implementors. I encourage you to provide one string as the only string within the TXT record and see if that changes things.

I use Exim with DKIM and Gmail always validates it; your Exim configuration is correct. So either your DNS isn't visible or Gmail dislikes the multiple strings in the TXT record.

You can also try some of the DKIM test services:

share|improve this answer
Yeah, there's no need for obfuscation than perhaps public humiliation. :) Thanks for your answer. How do you get around the bind error? named-checkzone dns_rdata_fromtext: ran out of space zone loading from master file failed: ran out of space zone not loaded due to errors. – Bretticus Feb 11 '11 at 18:56
You're missing a closing double-quote somewhere. – Phil P Feb 14 '11 at 3:20
Find the line with unbalanced double-quotes; probably around line 31. Fix it, so that bind can load the zone. Gmail should then see the new data, not the last data which successfully loaded into your nameserver and verification should work. – Phil P Feb 14 '11 at 3:21

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.