DKIM on Sender Audit Blog

Email and DNS: Every Record You Need to Know

Sun, 26 Apr 2026 00:00:00 +0000

DNS is the invisible foundation of email. Without the right records, your emails won’t be delivered, authenticated, or encrypted. Here are all the DNS records a sending domain needs to know and configure.

Overview

Record	Type	Role
MX	MX	Where to deliver emails for your domain
SPF	TXT	Who can send for your domain
DKIM	TXT/CNAME	Public key for verifying signatures
DMARC	TXT	SPF + DKIM alignment policy
MTA-STS	TXT + HTTPS	Enforce TLS encryption
TLS-RPT	TXT	Reports on TLS failures
BIMI	TXT	Verified logo in the inbox
PTR	PTR	Reverse DNS for your sending IPs

MX: Where to Deliver Emails

The MX (Mail Exchange) record specifies which servers receive emails for your domain.

Email Headers Explained: From Received to ARC

Mon, 20 Apr 2026 00:00:00 +0000

Email headers contain the complete story of a message’s journey: who sent it, which servers it passed through, whether authentication succeeded, and why it landed in spam. Knowing how to read them means knowing how to diagnose.

How to Access Headers

Gmail: open the email → ⋮ → “Show original”
Outlook: open the email → File → Properties → “Internet headers”
Apple Mail: View → Message → All Headers
Thunderbird: View → Message Source

Or paste them directly into Sender Audit’s Header Analyzer for a visual analysis.

Anatomy of a DKIM Signature: Every Field Explained

Mon, 23 Mar 2026 00:00:00 +0000

You know that DKIM signs your emails. But what exactly is inside that DKIM-Signature header? Let’s break down every field and follow the verification process from start to finish.

A Real DKIM Header, Dissected

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=example.com; s=selector2024;
 h=from:to:subject:date:mime-version:content-type;
 bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
 t=1714123456;
 b=dHJ5aW5nIHRvIHJlYWQgdGhpcyBzaWduYXR1cmU/IE5pY2Ug
 dHJ5IDspIFRoaXMgaXMganVzdCBhIGR1bW15IGV4YW1wbGU=

Every Field Explained

`v=1`: Version

The DKIM protocol version. Only one version exists (1), defined by RFC 6376. This field is mandatory.

`a=rsa-sha256`: Algorithm

Two elements combined:

Cryptosystem: rsa (most common) or ed25519 (emerging, RFC 8463)
Hash function: sha256 (standard) or sha1 (obsolete and vulnerable, do not use)

Combination	Status
`rsa-sha256`	Standard, recommended
`rsa-sha1`	Obsolete, some providers reject it
`ed25519-sha256`	Future standard, partial support

`c=relaxed/relaxed`: Canonicalization

Defines how content is normalized before computing the signature. The format is headers/body:

DKIM RSA Key Size: 1024 vs 2048 Bits and the Future with Ed25519

Sat, 14 Mar 2026 00:00:00 +0000

Your DKIM setup works, signatures pass. But have you checked the size of your RSA key? A key that’s too short is a ticking time bomb: it could be cracked, allowing an attacker to sign emails on your behalf.

The History of DKIM Keys: From 512 to 2048 Bits

2012: The End of 512-Bit Keys

In 2012, researchers demonstrated that a 512-bit RSA key could be cracked in under 72 hours using cheap cloud computing power. The result: anyone could impersonate a domain using a 512-bit key and send perfectly DKIM-signed emails.

Why Do You See Two DKIM Signatures on a Single Email?

Thu, 05 Mar 2026 00:00:00 +0000

You inspect the headers of an email sent through your ESP (Brevo, Mailchimp, SendGrid…) and notice two distinct DKIM signatures: one with your domain, one with the ESP’s domain. Is this normal? Absolutely, and it’s actually desirable.

What It Looks Like in the Headers

Here’s a typical Authentication-Results example:

Authentication-Results: mx.google.com;
 dkim=pass header.i=@yourdomain.com header.s=mail header.b=xjAWgYt1;
 dkim=pass header.i=@esp-domain.com header.s=mail header.b=zNRqfud1;
 spf=pass ...
 dmarc=pass (p=REJECT) header.from=yourdomain.com

And two DKIM-Signature: blocks in the message: one with d=yourdomain.com, the other with d=esp-domain.com.

DKIM: Sign Your Emails to Prove Their Authenticity

Sat, 24 Jan 2026 00:00:00 +0000

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing email. The receiving server can verify that the message wasn’t altered in transit and that it came from an authorized sender. It’s the second pillar of email authentication, after SPF.

How DKIM Works, The Simple Version

Think of it like sending a letter with a wax seal. The recipient can verify the seal isn’t broken (the message is intact) and that the seal matches your crest (you’re the legitimate sender).