Do you offer DKIM signing and support?

AuthSMTP provides domain-specific DKIM signing, and verified AuthSMTP DKIM is required before a customer-owned sending domain can be authorised.

What is DKIM signing?

DKIM (DomainKeys Identified Mail) allows email senders to 'sign' their messages and for recipients to be able to 'verify' that those messages are genuine. It is mainly designed to reduce spoofing/faking of the sender's email addresses or message content - it does not automatically guarantee delivery but it can improve deliverability.

Email messages signed with DKIM would include a 'DKIM-Signature' field in the header - this is essentially a cryptographic signature of various parts of the message. When the recipient's email system receives the message it would decrypt this signature using the sender 'public key' which is published as part of the sender's DNS record.

Why do AuthSMTP domains require DKIM and DMARC?

Email authentication standards and mailbox-provider requirements are becoming stricter over time. Some AuthSMTP customers already send high volumes, while smaller senders may grow into high-volume traffic. We therefore require a consistent authentication baseline before authorising a customer-owned sending domain.

The domain must have a valid SPF record covering AuthSMTP, verified AuthSMTP DKIM and a valid DMARC record. p=none is acceptable as a starting DMARC monitoring policy, but the longer-term plan should be to progress to p=quarantine and then p=reject after checking reports and correcting alignment. This AuthSMTP requirement is deliberately stricter than DMARC's technical minimum, under which one aligned authentication method can be enough for a message to pass.

DKIM cryptographically signs the message so receiving systems can verify the signing domain and detect changes to signed content. DMARC relates authentication to the visible From domain and adds reporting and policy controls. Together they improve trust in legitimate AuthSMTP mail and reduce the risk of successful spoofing or impersonation using your domain.

What parts of the message do you sign?

We DKIM sign the following elements of each message:

• Header From Address
• Header To Address
• Header Reply-To Address
• Header Subject Line
• Header Message ID
• Header List-Unsubscribe
• Header List-Unsubscribe-Post
• Message Body (including attachments)

IMPORTANT: As per the RFC / DKIM standards it is very important that you only include one of the above in each message. If you include duplicate header fields (i.e. multiple 'To:' header fields) we will only sign the last one; all others will be ignored and your message may fail DKIM verification upon delivery.

Do you use a shared DKIM key?

No - we issue a unique DKIM key for each domain name so your DKIM reputation cannot be affected by other senders.

Will this affect the email I send from my domain name via other providers or servers?

No - the DKIM key uses an AuthSMTP specific 'selector' and the signing will only apply to messages sent via your AuthSMTP account.

How do I enable DKIM signing on my account?

DKIM is configured separately for each sending domain. To enable it, log in to the AuthSMTP Control Panel and go to 'Advanced Config' -> 'DKIM Signing'. The Control Panel generates the selector and DNS destination for that domain.

How should I publish the DKIM DNS record?

For new AuthSMTP DKIM configurations, we recommend the CNAME method. It allows AuthSMTP to maintain or rotate the DKIM key behind the CNAME destination without requiring you to replace a long public key in your DNS.

Always use the selector and CNAME destination generated by the AuthSMTP Control Panel. Do not hardcode authsmtp or any value shown in an example.

The CNAME format is:

<selector>._domainkey.<customer-domain>. CNAME <selector>.<customer-domain>.dkimkey.com.

Use the example below with the domain example.com and selector authsmtp, or enter your own values to preview the corresponding DNS fields.

authsmtp._domainkey.example.com. CNAME authsmtp.example.com.dkimkey.com.

Most DNS providers automatically append your domain to the Host / Name, so you will normally enter the short value <selector>._domainkey. Check your provider's instructions so the domain is not added twice. Some DNS systems display the CNAME destination with a trailing dot and some do not. Both presentations can be normal, but copy the value supplied by AuthSMTP exactly.

If an old TXT record already exists at the same selector hostname, remove or replace it before adding the CNAME. A CNAME and TXT record cannot coexist at that name.

What if I cannot use a CNAME?

Use the TXT/public-key method shown in the AuthSMTP Control Panel as an alternative. Publish the generated TXT value instead of the CNAME, not alongside it at the same selector hostname. With the TXT method, you will need to update the public key in DNS if the key is replaced later.

How do I verify the setup?

After saving the record, allow time for DNS propagation and then verify DKIM in the AuthSMTP Control Panel. Finally, send a real test message through AuthSMTP and confirm that DKIM passes for the correct signing domain.

What if I sign the messages myself?

When sending emails via AuthSMTP you can use a DKIM-compliant application or library to pre-sign your messages before sending them to us. Check which parts of each message are signed and test the complete delivery path before using this configuration in production.

If a message already contains a DKIM signature when it reaches AuthSMTP, we leave that signature unchanged and do not add an AuthSMTP DKIM signature.

Even if your main application pre-signs every message, you should still generate an AuthSMTP DKIM configuration for the sending domain, publish the CNAME record (or alternative TXT/public-key record) supplied by the AuthSMTP Control Panel, and verify it. This provides a safety net: if mail is later submitted through your AuthSMTP account from another application, system or device that does not pre-sign it, AuthSMTP can sign that unsigned message for you.

For more practical guidance, see the AuthSMTP DKIM Deliverability Guide.

What can go wrong?

The following common issues will prevent your messages from being signed (but not limited to):

• If you sign a message before submitting it to AuthSMTP, we preserve its existing DKIM signature and do not re-sign it. Keep the verified AuthSMTP DKIM configuration in place as a safety net for unsigned mail sent from any other application, system or device using your account.
• Always send DKIM-signed emails using quoted-printable (preferred) or base64 encoding. Using 8-bit encoding is not safe / compatible — it can lead to message corruption or altered line endings during transit, especially when relayed through mail servers that don’t fully support 8-bit MIME. Such changes can invalidate the DKIM signature, resulting in verification failures or delivery issues with receiving mail systems.
• The line length in your email content must comply with RFC standards. The absolute maximum is 998 characters per line, including any line breaks. Exceeding this limit can cause DKIM verification to fail and may lead to the message being filtered or rejected by receiving mail systems. For best results, keep line lengths well below the maximum.
• If the DKIM CNAME or alternative TXT/public-key record is removed from your domain's DNS after setup, your outgoing messages will still be signed but will fail DKIM verification on receipt. This mismatch can cause receiving mail systems to reject the message outright or deliver it to the spam or junk folder.
• Our systems have several redundancy features in place that trigger in the event of an outage or extreme spike in mail flow/resource usage, in the event of certain types of issues we may not DKIM sign messages to preserve the flow of email. This is unlikely, but a requirement to maintain service availability.

Is there any other recommendations when sending DKIM-signed messages?

There are several other best practices when sending DKIM-signed messages:

• Setup an SPF record for your domain name.
• Maintain your required DMARC record for your domain name.
• Ensure that your message content is standards-compliant and does not include anything that may trigger spam filters.

If you have any questions please contact us.