---
title: DKIM
description: Cryptographic email signatures so receivers can verify mail from your domain was not altered in transit.
canonical: https://penasihathosting.com/en/hosting-wiki/dkim
type: wiki
locale: en
updated: 2026-07-15
author: Willya Randika
---

# DKIM

## Overview

- **Summary:** Cryptographic email signatures so receivers can verify mail from your domain was not altered in transit.
- **Author:** Willya Randika ([profile](/penulis/willya-randika))

## Article

**DKIM** (DomainKeys Identified Mail) cryptographically signs outbound email so receivers can verify the message really came from your domain and was not altered in transit. The public key is published in [DNS](/en/hosting-wiki/dns-domain-name-system) (TXT), while the private key stays on the sending server or mail service.

Unlike [SPF](/en/hosting-wiki/spf), which checks the sending IP, DKIM checks a **signature over headers/body**. They complement each other, and [DMARC](/en/hosting-wiki/dmarc) uses both results for domain policy.

## A Simple Analogy

DKIM is a **wax seal** on an envelope. The recipient has a sample of the official seal (the public key in DNS). If the seal is intact and matches, the contents are treated as untampered.

## How It Works Briefly

1. The sending server builds a signature from parts of the message  
2. The signature is inserted into email headers  
3. The receiver fetches the public key from DNS (selector such as `s1._domainkey`)  
4. Verification passes or fails  

In panels you often see “Enable DKIM” under [cPanel](/en/hosting-wiki/cpanel) Email Deliverability, Google Workspace, Microsoft 365, or transactional SMTP providers.

## When You Need It

- Business mail that should reach the inbox, not spam  
- Store notifications (orders, password resets)  
- Domains that send from several services (hosting + CRM + payments) — each sender needs correct setup  
- After mail migrations when SPF exists but inbox placement is still weak  

## What to Watch For

- The DKIM selector must match between the mail panel and DNS  
- Do not delete an old key record before cutover finishes if something still signs with it  
- Occasional key rotation is good practice for larger orgs  
- Forwarding can break DKIM verification; DMARC alignment then matters more  
- Test by mailing yourself and reading `dkim=pass` in headers  

## FAQ

<Accordion>
  <AccordionItem title="Is SPF enough without DKIM?">
    Better to have both. Many receivers and DMARC policies lean on DKIM, especially when mail is forwarded.
  </AccordionItem>
  <AccordionItem title="Does DKIM encrypt the message body?">
    No. DKIM signs; it does not hide content the way TLS protects the transport.
  </AccordionItem>
  <AccordionItem title="Where does the DKIM record go?">
    Usually a TXT under `_domainkey`, for example `default._domainkey.example.com`, exactly as your provider instructs.
  </AccordionItem>
  <AccordionItem title="DKIM passes but mail still hits spam?">
    Auth is only one factor. Content, IP/domain reputation, engagement, and blocklists still matter.
  </AccordionItem>
</Accordion>