DKIM

How DKIM works

DKIM starts at the sending mail server. Before the message leaves, the server computes a hash over selected headers and the body, then signs that hash with a private key that belongs to the sending domain 1. The signature rides in a DKIM-Signature header. Receivers look up the matching public key in DNS, usually under a selector name on the signing domain, and verify the signature 1.

Amazon SES describes the same flow in product terms. SES can authenticate outbound mail with DKIM so receiving servers can confirm the message was claimed by the domain and that signed parts were not changed 2. Easy DKIM and Bring Your Own DKIM are the common setup paths on SES 2. Once DNS is correct, every message SES sends for that identity can carry a valid signature without per-message manual work 2.

A pass means the signature verified. It does not mean the recipient wanted the mail. It means the signing domain stood behind the covered content at send time 1. Headers that were not covered can still change. Body changes after signing break the signature. That is why ESP templates and tracking rewrites need care when DKIM is on.

Outbound and lifecycle teams meet DKIM when they add a new ESP or change the From domain. The selector DNS record must publish before volume rises. A missing or stale key produces authentication fails that look like spoof risk to filters, next to SPF misses and weak DMARC policy.

Alignment matters once DMARC enters the picture. The domain in the visible From header should relate to the DKIM signing domain under the DMARC alignment rules the receiver applies 3. Teams that sign with a vendor domain while showing a brand From often fail alignment even when the raw signature verifies.

Sender reputation still depends on list hygiene. A perfect DKIM signature will not rescue a blast into dead mailboxes. RichAPI Email verifier returns status and mxFound for 2 credits per verdict so bad rows leave before the signed campaign goes out 4. Misses bill zero 4. New accounts get 100 free credits 4.

Selectors are public names. The private key behind them must stay protected. Limit who can rotate signing keys in the ESP, and keep a written dual-publish window so the old selector stays valid until the new one carries live traffic 2. Sudden single-selector swaps are a common way to break an otherwise healthy stream.

Forwarding can complicate DKIM when intermediate hops alter headers or body content 1. Teams that rely on listserv style paths should watch authentication reports after enabling new forwarders, not only after ESP changes.

Why DKIM matters for brand From domains

Brand From domains are what recipients see. DKIM is how those domains prove the message was theirs and intact 1. Without a valid signature, filters have one less reason to trust the brand identity sitting in the From header.

Agencies that manage many client domains should treat DKIM selectors as inventory. Each ESP and each From domain needs a live key. Rotating keys without dual-publish windows is a common outage. Publish the new selector, switch signing, then retire the old key after traffic drains.

Product teams that add open-tracking or click-wrapping mid-flight can break signatures if the rewritten body is no longer what was signed. Prefer ESP features that preserve DKIM, or resign after the rewrite. Test with seed accounts before a launch blast.

Google expects senders to authenticate mail, and DKIM is one of the standard ways to do that for Gmail traffic 3. Pair DKIM with SPF and a DMARC policy so authentication results can drive a consistent disposition 3.

When DKIM fails after a vendor change, freeze new volume. Confirm the selector DNS, confirm the signing domain, send a seed, and only then resume. Keep domain reputation and email warm-up on the same checklist so authentication wins are not wasted on a cold blast from a quiet subdomain.

Put DKIM status on the same pre-flight checklist as list verification. A signed blast into dead addresses still teaches filters the wrong lesson about the domain. Authentication and hygiene are complementary controls, not substitutes.

Example of aligning DKIM before a product launch blast

A lifecycle manager plans a launch email from news.examplebrand.com. The ESP is set to sign with Easy DKIM for that subdomain 2. DNS shows the selector live. Seed tests to Gmail and Workspace show DKIM pass and From alignment under a monitoring DMARC policy 3.

Before the blast, the CRM export is verified with RichAPI Email verifier 4. Invalid and unknown rows are held. mxFound false rows leave entirely 4. The signed send goes only to addresses that cleared verification.

Verification costs 2 credits per verdict 4. Misses cost zero 4. A new RichAPI account can cover a small pilot with the 100 free credits 4. The launch then carries a clean signature and a cleaner list, which is the combination filters reward more than either signal alone.

After the launch, the team rotates to a new selector on a planned window. Both selectors stay published for seven days. Seeds keep passing. Only then is the old selector removed. That is key hygiene treated like a production deploy, not like a console toggle.

DKIM vs SPF

DKIM signs message content for a domain. SPF authorizes which IPs may use a domain in the envelope MAIL FROM path.