Of the three authentication checks, DKIM is the one people misread most. SPF either lists your sending IP or it doesn't. DMARC either has a policy or it doesn't. DKIM has a middle state that looks like success and behaves like failure — and a checker that reports none or "not aligned" is pointing at it.
What DKIM signs, and what a selector is
DKIM attaches a cryptographic signature to every message you send. The receiving server reads the signature's d= (the signing domain) and s= (the selector), fetches the matching public key from DNS at <selector>._domainkey.<domain>, and checks that the message wasn't altered in transit.
selector1._domainkey.yourdomain.com TXT v=DKIM1; k=rsa; p=MIGfMA0...
The selector is why one domain can carry several DKIM keys at once — one for Google Workspace, one for your invoicing tool, one for your marketing platform — each publishing its own key under its own selector. This is also the first place things go wrong: a sending system is configured to sign as s=marketing, but the key was never published at marketing._domainkey. The signature is added; the lookup fails; the result is none.
"none" versus "fail" versus "not aligned"
These are three different states and they mean different things:
none— the message carried no DKIM signature the receiver could verify, or the key wasn't found in DNS. The system either isn't signing, or is signing with a selector whose key isn't published.fail— a signature was present but didn't verify. Usually the message was modified after signing (a mailing list appending a footer is the classic cause), or the published key doesn't match the private key doing the signing.passbut not aligned — the signature verified perfectly, and DMARC still fails. This is the one that confuses everyone.
Alignment is the part that breaks DMARC
DKIM passing is not enough for DMARC. The d= domain in the signature has to align with the domain in your visible From: address.
Say your mail is From: hello@yourdomain.com, but your email platform signs it with d=mail.sendingplatform.com — its domain, not yours. The signature is valid. DKIM passes. But the signing domain and the From domain don't match, so DMARC sees no aligned authentication and fails the message anyway.
DMARC allows two alignment modes. Relaxed (the default) accepts a match on the organizational domain, so d=mail.yourdomain.com aligns with From: yourdomain.com. Strict demands an exact match. Most DKIM-passing-but-DMARC-failing domains are signing with the provider's domain instead of their own — which aligns under neither mode.
The fix is to sign with your own domain. Every serious sending platform supports this: you publish a CNAME or TXT selector under your DNS pointing at their key, and they sign as d=yourdomain.com. That single change turns a passing-but-useless signature into an aligned one.
Why the message-modified failures happen
The other common fail isn't configuration — it's transit. DKIM signs a hash of specified headers and the body. Anything that rewrites the message after signing invalidates the hash: a mailing list that appends "You are subscribed to…", a security appliance that inserts a banner, a forwarding rule that reformats. The signature was valid when it left. It isn't when it arrives.
You can't stop every intermediary from touching mail, but you can make sure your own path signs correctly and aligns — which is what a receiving server judges you on.
How to see which state you're in
The distinction between none, fail, and pass-but-not-aligned is invisible from your outbox. Your mail sends. It looks fine. Only the receiving server sees the DKIM result, and only your DMARC aggregate reports — or a check that evaluates the record the way a receiver does — will tell you which of the three you're in.
Run your domain and read the DKIM line: check your domain. If it comes back none, a selector's key is missing or nothing is signing. If it passes but your mail still fails DMARC elsewhere, the signature is real and the alignment isn't — and that's a DNS change on your side, not a mystery.