You're trying to figure out why a message that looked fine in your outbox still ends up questioned by the next mailbox provider. In many cases, the missing piece is a DKIM record, because it lets the receiving server verify that your message really came from your domain and wasn't altered on the way.
In plain terms, DKIM meaning is simple. It's a signing system for email, and the DKIM record is the DNS entry that publishes the public key used to check that signature. If you've ever wondered why one inbox sees your mail as normal while another treats it with suspicion, DKIM is often part of that answer, especially when it's paired with SPF and DMARC.
A useful mental model is this. Your sending system adds a seal to the message, and your DNS record gives the recipient the public reference needed to check that seal. That's why publishing a correct record matters for deliverability and for reducing spoofing risk, not just for “security checkbox” reasons. People start with the definition, then quickly realise they also need the workflow, the record format, and the common failure points.
What Is a DKIM Record
A DKIM record is a DNS TXT record that publishes the public half of a cryptographic key pair. The sending mail system keeps the private key, signs outgoing mail, and the recipient looks up the public key in DNS to verify that signature. That's the core idea behind what is a DKIM record, and it's why the record lives in your domain's DNS rather than inside the message itself.
The simple version is this. If your domain signs a message, the receiver can ask, “Does this signature match the public key that domain published?” If the answer is yes, the recipient gets a strong signal that the message came from a system that knows the private key and that the signed parts of the message weren't changed in transit. The key point is that DKIM checks authenticity of the signed content, not just the sending IP.
That's also why DKIM sits between your outbound mail system and the recipient's filtering logic. The sending server creates the signature, DNS provides the reference key, and the mailbox provider uses both during verification. For a plain-language map of how email routing works alongside DNS, see our note on MX records and mail flow.
Why the record matters in practice
DKIM isn't only about theory. A 2024 measurement of the top 1 million domains found that 96.6% of DKIM records were valid when they existed, which suggests that published records are usually configured correctly once domains deploy them. But adoption is still uneven, because a 2022 USENIX study found that only 28.1% of Alexa Top 1 Million domains had enabled DKIM, and 2.9% of those were misconfigured, so publishing the record is still a meaningful baseline rather than an automatic default for everyone (adoption and validation data).
Practical rule: DKIM helps most when it's one part of a complete authentication setup, not a standalone fix.
That distinction matters if you send from a custom domain, run a small business, or route mail through more than one service. A correct DKIM record gives receivers a stable place to verify your signatures, and that can improve trust in your mail when the message reaches spam filters and authentication checks.
How DKIM Signatures Work
The signing process starts before the message leaves your server. The sending mail transfer agent, or MTA, selects parts of the email, usually specific headers and the body, and creates a hash of that content. It then signs that hash with the private key and places the result into a DKIM-Signature header.
Reading the signature header
A DKIM signature usually carries several fields that tell the receiver how to verify the message. The important ones are the signing domain, the selector, the algorithm, and the signature itself. In current guidance, the v=DKIM1 tag identifies the version, p= holds the base64 public key in DNS, k= defaults to RSA but can also support ed25519 in newer guidance, and h= restricts acceptable hash algorithms, with sha256 commonly recommended over older options (technical DKIM tag guidance).
The receiver then does the reverse work. It reads the selector and domain from the DKIM header, looks up the matching public key in DNS, recomputes the hash, and checks whether the signature still matches. If the message changed after signing, verification fails, which is how DKIM flags tampering or rewriting during transit. This verification flow
is why DKIM provides evidence of message integrity.
A header often looks conceptually like this, even though your exact fields will vary by provider.
DKIM-Signature: v=DKIM1; a=rsa-sha256; d=example.com; s=default; ...
The d= value shows the signing domain, while s= shows the selector. The selector matters because it tells the receiver which DNS name to query, usually something like selector._domainkey.yourdomain, and that structure is one reason key rotation is practical. According to DKIM deployment guidance, DKIM is commonly deployed as a TXT record with a long selector-scoped hostname, so DNS length and quoting rules matter when you publish it.
A valid signature tells you the message was signed and the signed content stayed intact. It doesn't, by itself, prove the sender should be trusted for policy enforcement.
That last point is where many readers get stuck. A passing DKIM check is strong evidence of message integrity, but mailbox providers still combine it with other signals before deciding whether to place mail in the inbox, spam, or quarantine.
DKIM vs SPF vs DMARC
DKIM, SPF, and DMARC solve different problems, and email gets messy when people treat them as interchangeable. SPF authorises sending sources, DKIM signs the message itself, and DMARC ties those signals to the visible From domain and a policy decision. The best way to think about them is as layers, not competitors.
What each protocol proves
SPF asks whether the sending server is allowed to send for the domain used in the SMTP envelope. DKIM asks whether the message was signed by a domain that holds the matching private key. DMARC then asks whether one of those authenticated domains aligns with the address your recipient sees in the From field (DMARC and alignment overview).
That alignment piece is the part many people miss. DMARC passes when either SPF or DKIM passes and matches the visible From domain, which is why a message can have a valid signature and still fail policy if the authenticated domain doesn't line up with what the user sees. SPF also has a well-known forwarding weakness, while DKIM often survives forwarding if the signed content remains unchanged, so most operators configure both for resilience.
| Protocol | What it proves | Where the record lives | Limitation on its own |
|---|---|---|---|
| DKIM | The message was signed by a domain that controls the private key | DNS TXT record under the selector-scoped DKIM host | Doesn't enforce policy by itself |
| SPF | The sending server is allowed to use the envelope domain | DNS TXT record on the sending domain | Doesn't authenticate the visible From address |
| DMARC | The message aligns with the From domain and follows a policy | DNS TXT record at the DMARC host | Depends on SPF or DKIM working correctly |
For a sender who wants to keep mail under direct control, this matters as much as the record itself. DKIM sits in your DNS control plane, so you choose who signs, what key is published, and how you rotate it. That's one reason many privacy-minded operators prefer keeping their authentication setup close to their own infrastructure instead of leaving it scattered across multiple vendors.
How to Set Up a DKIM Record
A solid DKIM setup begins with the record format. The TXT payload is a tag-value string, and the important pieces are v=DKIM1, k= for the key type, and p= for the base64 public key. Some deployments also use optional tags like t=s and t=y, which can affect enforcement and testing behaviour, so you should only set them when your provider tells you they're appropriate (record format guidance).
The normal setup flow
First, your mail provider either assigns a selector or lets you choose one. Then it generates the key pair, gives you the public portion, and tells you where to publish it in DNS. After that, you add the TXT record at the selector-scoped hostname, wait for propagation, and enable signing in the provider console if signing doesn't start automatically.
A realistic example looks like this in structure, even though your exact key will be different:
v=DKIM1; k=rsa; p=BASE64ENCODEDPUBLICKEY
The selector usually forms part of the hostname, which is why people often publish the record at a name like default._domainkey.example.com. That scoping lets one domain rotate keys, separate mail streams, or run more than one sender without replacing everything at once. It also explains why long records need careful quoting and escaping in DNS tools, because a pasted key can break if the provider wraps text badly.
What to watch during publishing
DKIM records rarely fail because the idea is wrong. They fail because the hostname is off by a character, the key was copied incompletely, or the provider expects the record in a slightly different format. Neutral documentation also notes that DKIM supports long selector-scoped TXT records, so you should expect DNS length limits and formatting rules to matter when you publish the key (DNS publishing guidance).
Some providers also support multiple selectors, which helps during provider changes or key rotation. That's useful when one service sends transactional mail and another handles newsletters, because each service can sign with its own key without stepping on the other. If you switch platforms later, you can keep the old selector live long enough to avoid breaking messages that are still in flight.
If you publish the record but don't turn on signing, the DNS entry exists, but outbound mail still won't carry a valid DKIM signature.
Testing and Troubleshooting DKIM
Publishing the record is only half the job. The other half is checking whether a real message can still be verified after it leaves your system, passes through DNS, and lands in a recipient inbox. A simple verification path is to inspect the DNS record, send a test message, and then read the message headers for the DKIM result.
Three checks that catch most problems
The first check is a DNS lookup. You want to confirm that the selector resolves to the TXT record you expect and that the key text is intact. The second is a test email to a mailbox where you can open the full headers, like Gmail or Outlook, and look for the DKIM-Signature line plus the authentication result.
The third is an online validator, which can catch syntax mistakes before they turn into mail failures. We recommend using a validator alongside your provider's own test tools, because a record can look fine in DNS and still fail if the selector, key, or signing domain doesn't match the mail being sent. For a real-world setup checklist that includes mail authentication as part of the larger flow, see our email authentication setup guide.
Common breakpoints show up during migrations. Old selectors stay published after a provider switch, a DNS change hasn't propagated yet, a long base64 string was pasted with the wrong quotes, or a marketing platform signs from a different domain than the one your messages show to recipients. Those are ordinary operational mistakes, not edge cases, and they're especially common when a small business moves from one mailbox provider to another.
A short troubleshooting pattern
Start by checking whether the selector in the header matches the selector in DNS. Then confirm that the body and headers weren't rewritten by a relay, list manager, or forwarding service in a way that breaks the signature. If the DNS record is correct but the message still fails, the problem often sits in the sending app, not in DNS itself.
When you change providers, test every sender separately. Transactional mail, staff mail, support systems, and newsletter tools often use different signing paths, and each one can fail for a different reason. A careful rollout catches those differences early, before customers start asking why your message looks suspicious.
Why DKIM Matters for Private and Canadian Email
DKIM is mature, but it's not universal. The adoption data earlier showed that many domains still don't publish it, and that unevenness is exactly why impersonation remains easy for attackers. A domain with a valid DKIM record gives mailbox providers a stable way to judge whether the mail was signed by the domain owner's own system.
For privacy-sensitive senders, the location of the record matters too. The DKIM public key lives in your DNS control plane, and the same is true for DMARC reporting addresses, so your authentication policy sits under the governance of the domain owner rather than inside a vendor's black box. That's relevant when you care about where your mail metadata lives and which jurisdiction controls the infrastructure around it.
A few common myths keep causing confusion. DKIM does not block every phishing attempt on its own, and a valid signature does not mean the message deserves trust without DMARC alignment and other checks. It also isn't something that magically appears just because you signed up with a big provider, because custom domains still need their own authentication setup and maintenance.
Typewire is one option for that model, because we run our own email infrastructure and support DKIM for configured domains. In practice, that means the signing setup stays tied to the service you control, instead of being bolted onto a wider cloud stack you don't manage directly. For small businesses that want email under Canadian jurisdiction and want to keep authentication records in their own control plane, that separation can make day-to-day operations much clearer.
If you want help setting up DKIM, SPF, and DMARC on a custom domain without adding extra cloud complexity, visit Typewire and start with a setup that keeps your authentication records and email infrastructure under your control. If you're moving mail from another provider, we can help you plan the switch so your signatures, selectors, and DNS records stay consistent during the transition.
