Your mail is not DKIM-aligned

Your mail is passing DMARC, so nothing is failing today. It is passing on SPF, and SPF is the leg that breaks when a message is forwarded — the forwarding server is not in your SPF record, so SPF fails and there is no aligned signature to fall back on.

DKIM alignment fixes that permanently: the signature travels with the message, so it still verifies after a forward. Until it is in place, tightening your policy to p=quarantine or p=reject will send your own forwarded mail to spam or have it refused. That is why Sojka holds the recommendation to enforce.

What "not aligned" actually means here

Usually your mail is signed — just not by you. A sending platform that has not been told your domain signs with its own instead (d=sendgrid.net, d=gmail.com, d=tenant.onmicrosoft.com). The signature verifies, so DKIM "passes", and it does not match your From: domain, so it does not align.

The two steps, and the second one is the one people miss

1. Tell the platform to sign as your domain. This is what generates the key. 2. Publish the record it gives you. Then, on most platforms, turn signing on — publishing a selector that nothing signs with changes nothing at all.

Google Workspace

• Admin console → Apps → Google Workspace → Gmail → Authenticate email.
• Select the domain and Generate new record (selector google, 2048-bit — take 2048 unless your DNS host cannot hold the record).
• Publish the TXT record it shows at google._domainkey.yourdomain.
• Come back and click Start authentication. Until you do, Google keeps signing with its own fallback domain and nothing about your reports changes. This is the step that gets skipped.

Microsoft 365

• Publish two CNAMEs: selector1._domainkey.yourdomain and selector2._domainkey.yourdomain, each pointing at the corresponding …_domainkey.tenant.onmicrosoft.com target Microsoft gives you.
• Then enable DKIM signing for the domain in the Defender portal (Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM). The CNAMEs alone do not start anything.
• Two selectors is not a mistake — it is how Microsoft rotates keys. Publish both.

Amazon SES

• In the SES console, open the verified identity for your domain and enable Easy DKIM.
• Publish the three CNAMEs it generates.
• SES starts signing on its own once they resolve — no switch to flip.

Any other platform

The shape is always the same: find the DKIM or "email authentication" section, add your domain there, publish whatever record it hands you, and then confirm signing is actually enabled for that domain. If the platform offers a "verify" button after the record is published, press it — that is usually the switch.

Check this first, before generating anything

If your reports show DKIM passing and not aligning, and the signing domain is a subdomain of yours (mail.example.com signing for example.com), look at your DMARC record for adkim=s. Strict alignment demands an exact match; relaxed — adkim=r, the default when the tag is absent — accepts the subdomain. Removing adkim=s is the fix in that case, and a new key would be wasted work.

Never rotate a key that is verifying. A signature that passes is proof the key is right.

How long until it shows

DNS propagates in minutes to an hour; DMARC reports arrive on a 24–48 hour delay, so the colour in Sojka changes a day or two after the mail does. Send yourself a message in the meantime — Sojka's source check gives a verdict on a single message in seconds, without waiting for reports.

If this source can never be fixed

Some senders are not yours to change — a forwarder, or a service somebody else operates. Mark it in the app and it stops asking. That is reversible, and it does not silence the source: if it starts failing DMARC outright, it comes back.

Related: what DMARC alignment means.