Support Start > Email > Advanced Email Questions > DKIM

This page is showing a generic answer.
To see a more detailed answer customized for you, type your domain name here:

A system called “DomainKeys Identified Mail” (DKIM) allows mail servers to digitally “sign” messages they send. Receiving mail servers can check the signature and know that the message was really sent by someone @example.com, which can help them detect forgeries. This page has a good non-technical introduction to DKIM.

We automatically sign mail that our customers send through our servers. This includes both mail sent from scripts you install on your website, and mail sent through an email program or Webmail.

On this page:

• What keys do you use?
• Why didn’t a particular message get signed?
• Can I disable DKIM signing?
• Are Mailman list messages signed?
• What if I don’t use Tiger Technologies DNS servers?
• Do you use DMARC?

What keys do you use?

We sign mail using one of two keys we provide for your domain name. If you're familiar with DKIM, the keys are one of:

1.tigertech._domainkey.example.com
2.tigertech._domainkey.example.com

The two different selectors to allow us to seamlessly rotate keys by switching between the two.

These keys are “aligned”, in DKIM terms: mail from addresses @example.com is signed by a example.com key, leading to higher trust levels than if third-party keys are used.

We don’t currently allow customers to provide their own private signing keys for mail that goes through our servers. But if you need to add an extra public DNS key using your own selector for mail that goes through other servers, you can easily add that TXT record in our control panel.

Why didn’t a particular message get signed?

Messages are signed if the “From” header matches a domain name you host with us.

If you use a script that sends mail using a different “From” domain name, it won’t be signed.

To avoid this problem, send mail only “From” your own domain names. For example, if a visitor fills out a “contact us” form on your site with their own “example@aol.com” AOL address, your script should not send a message that looks like this:

From: Visitor <example@aol.com>
To: example.com Webmaster <address@example.com>
Subject: Feedback form

Instead, it should send from your own domain name, like this:

From: feedback@example.com
Reply-To: Visitor <example@aol.com>
To: example.com Webmaster <address@example.com>
Subject: Feedback form from Visitor (example@aol.com)

The first example will not be signed as coming from example.com, but the second will.

Can I disable DKIM signing?

The main reason people ask this is that they’re already signing their mail before submitting it to our servers. If that’s the case, there should be no need to disable our signing: DKIM allows messages to be signed twice with different selectors.

If you have another reason you’d like to disable DKIM signing for your mail, please contact us and we’ll help.

Are Mailman list messages signed?

We currently don’t do anything special with Mailman list messages. If they have a “From” address in your domain name, they’ll be signed; otherwise, they won’t.

If you want to sign all of your Mailman list mail, you can change your list settings to send “From” the list address. To do this:

1. Login to your list management page
2. Make sure you’re viewing the “General Options” section
3. Scroll down to the setting for “Replace the From: header address with the list's posting address to mitigate issues stemming from the original From: domain's DMARC or similar policies”
4. Change the setting from “No” to Munge From
5. Click Submit Your Changes.

If you do this, your list will change from sending messages like this:

From: Poster’s Name <example@aol.com>
Sender: "listname" <listname-bounces+something@example.com>

To this:

From: Poster’s Name via listname <listname@example.com>
Reply-To: Poster’s Name <example@aol.com>
Sender: "listname" <listname-bounces+something@example.com>

All messages will then be DKIM signed because the “From” address ends with “@example.com”.

What if I don’t use Tiger Technologies DNS servers?

In most cases, customers who use our mail service also use our DNS service, and the necessary DNS TXT records for our public key selectors are automatically published.

If you use your own DNS to point mail at our servers, you’ll need to add these two DNS records:

1.tigertech._domainkey.example.com.  CNAME  1.tigertech._domainkey.tigertech.net.
2.tigertech._domainkey.example.com.  CNAME  2.tigertech._domainkey.tigertech.net.

Adding these will allow other servers to verify the signatures. You won’t get any benefit from us signing your mail unless you do this, although the “extra” signatures won’t do any harm either (see section 4.3 of RFC 6377).

Do you use DMARC?

DMARC is a related technology that allows you to ask receiving servers to reject your mail if they find it doesn’t have a valid DKIM signature (among other things).

By default, we publish a DMARC record for customers that asks other companies to report DMARC failures to us, but not to block suspected forgeries (the record looks like v=DMARC1; p=none; ruf=mailto:dmarc-reports@tigertech.net). That’s because we don’t know whether you’re also sending mail through other servers. We also publish a default spf record of v=spf1 include:tigertech.net a/24 mx/24 ptr ~all for all customers who use our email service.

If we receive reports of failures, we’ll try to add missing SPF or DKIM records if that’s possible based on published documentation from other companies (like this example from MailChimp), or work with you to fix it.

Technically advanced users can publish their own more restrictive DMARC policy by adding an appropriate TXT record if they wish. For example, you could add a TXT record at _dmarc.example.com with the data v=DMARC1; p=reject; ruf=mailto:address@example.com, which asks receiving servers to reject all suspected forgeries and possibly report rejections to you at ”address@example.com”.

Keep in mind that common email practices, including “tell-a-friend” scripts on websites and mailing list postings, can occasionally “break” DKIM signatures. Asking other servers to reject such mail will almost certainly mean that a few of your legitimate messages are blocked. Because of that, it perhaps makes sense to use DMARC only if you’re seeing a problem with other people forging your mail addresses.

Even if spammers are forging your addresses, keep in mind that DMARC can’t completely solve it. Only receivers that actually check DMARC records will block forged mail (most large ISPs do, but many smaller companies don’t). And when they do block forgeries, you might get more false “bounces” than you would without DMARC, simply because more messages are blocked.

In other words, neither DKIM nor DMARC can prevent spammers from forging your domain name in spam they send. The purpose is to make it easier for receiving servers to detect when those forgeries happen, and then block the messages and notify you about it. This third-party page has more useful information about DMARC.