Sender Audit Blog

Email trackers explained: pixels, link wrapping, and privacy

Mon, 04 May 2026 00:00:00 +0000

Every marketing email you receive likely contains one or more invisible trackers. They measure whether you opened the message, when, how many times, from which device, and which links you clicked. Here’s how it works - and how to do better.

How open tracking works

The spy pixel: an invisible image

The mechanism is straightforward: the sender inserts a 1×1 pixel transparent image hosted on their server. When your mail client renders the message, it downloads the image. The server records:

Shadow IT and Email: The Tools Sending on Your Behalf Without You Knowing

Tue, 28 Apr 2026 00:00:00 +0000

You’ve configured SPF, DKIM, and DMARC. Your email infrastructure is under control. Then one day, while analyzing your DMARC reports, you discover dozens of unknown IPs sending emails on behalf of your domain. Not phishing - internal tools that nobody in IT ever approved.

Welcome to the world of email shadow IT.

What Is Email Shadow IT

Shadow IT refers to the use of technology services without explicit approval from the IT team. Applied to email, it’s extremely common: business teams configure SaaS tools to send emails from your domain without going through IT.

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.

DMARC: Safely Migrating from p=none to p=reject

Sat, 11 Apr 2026 00:00:00 +0000

You’ve published your DMARC record with p=none. That’s a good start, but p=none blocks nothing: fraudulent emails still get through. The end goal is p=reject, and this guide walks you through the migration without breaking your legitimate mail flows.

Why p=none Isn’t Enough

With p=none, you’re asking mailbox providers to do nothing when an email fails DMARC. You receive RUA reports, but:

Emails spoofing your domain still reach inboxes
Your domain can be used for phishing
Google and Yahoo now require a published DMARC record, but the real benefits start at p=quarantine or p=reject

Recommended Timeline

Week	Policy	Goal
W1-W2	`p=none; rua=mailto:...`	Collect reports, inventory sources
W3-W4	Report analysis	Identify each source IP, fix SPF/DKIM
W5-W6	`p=quarantine; pct=10`	Test on 10% of traffic
W7-W8	`p=quarantine; pct=50`	Gradually increase
W9-W10	`p=quarantine; pct=100`	Observe for 2 weeks
W11-W12	`p=reject; pct=10`	Begin gradual rejection
W13-W14	`p=reject; pct=50`	Scale up
W15+	`p=reject; pct=100; sp=reject`	Full protection

This timeline is indicative. The key is to never skip a step without verifying that reports are clean.

Reading and Understanding DMARC Reports (RUA)

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

You’ve configured DMARC with a rua= tag and reports are starting to arrive. But what do you do with these often incomprehensible XML files? This guide teaches you how to read them, interpret them, and take concrete action.

What Is a DMARC RUA Report

An RUA (Report URI Aggregate) report is an XML file sent daily by mailbox providers (Google, Microsoft, Yahoo, etc.) to the address defined in your DMARC record.

TLS and Email: Why SMTP Encryption Is Non-Negotiable

Sun, 29 Mar 2026 00:00:00 +0000

You may have seen a red padlock in Gmail with the message “The sender hasn’t encrypted this message”. This means the email traveled in plain text between servers, without TLS encryption. In 2026, that’s a serious red flag.

Why Encrypt Emails in Transit

Without TLS, email content travels in plain text between the sending and receiving servers. Anyone intercepting network traffic (man-in-the-middle attack, compromised ISP, public Wi-Fi) can:

Read the entire message content
Modify the message in transit
Extract attachments, credentials, links

TLS encryption creates an encrypted tunnel between the two SMTP servers. Even if intercepted, the traffic is unreadable.

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.

BIMI: Display Your Logo in Email Inboxes

Fri, 27 Feb 2026 00:00:00 +0000

Have you noticed some senders display their logo next to emails in Gmail or Apple Mail? That’s BIMI (Brand Indicators for Message Identification). Beyond branding, BIMI is a powerful trust signal, and it relies on flawless email authentication.

What Is BIMI?

BIMI is an email standard that displays your brand logo directly in the recipient’s email client. But it’s not just cosmetic:

Trust: a verified logo increases recipient confidence
Open rates: studies show a 10-30% increase in opens
Anti-spoofing: BIMI requires DMARC at quarantine or reject, which blocks spoofing
Brand visibility: your logo appears before the message is even opened

Who Supports BIMI?

Client / ISP	BIMI Support	VMC Required?
Gmail	✅ Yes	✅ Yes
Apple Mail (iOS 16+, macOS Ventura+)	✅ Yes	❌ No
Yahoo / AOL	✅ Yes	❌ No
La Poste	✅ Yes	❌ No
Outlook	🔄 In progress	,
Fastmail	✅ Yes	❌ No

Gmail is the only one requiring a VMC (Verified Mark Certificate). Others display the logo based solely on the DNS record.

How to Configure DMARC to Protect Your Domain

Wed, 18 Feb 2026 00:00:00 +0000

DMARC (Domain-based Message Authentication, Reporting and Conformance) is an email authentication protocol that protects your domain against spoofing and phishing. In this guide, we’ll walk through how to set it up properly.

Why DMARC Is Essential

Without DMARC, anyone can send emails pretending to be your domain. The consequences are serious:

Phishing: malicious actors can impersonate your brand
Damaged reputation: ISPs may penalize your domain
Lost trust: your recipients can no longer tell which emails are legitimate

According to the FBI, business email compromise (BEC) scams, many of which exploit missing DMARC, caused over $2.7 billion in losses in 2022 alone.

Email Blacklists: Understand, Check and Get Delisted

Mon, 09 Feb 2026 00:00:00 +0000

Your delivery rate drops suddenly. Your emails go to spam, or worse, they’re rejected with 550 5.7.1 Service unavailable; client host blocked. There’s a good chance your IP or domain is on a blacklist.

What Is an Email Blacklist?

A blacklist (or RBL, Realtime Blackhole List, or DNSBL, DNS-based Blackhole List) is a database that catalogues IP addresses and domains identified as spam sources or abusive senders.

Receiving servers (Gmail, Outlook, ISPs, corporate servers…) query these lists in real time to decide whether to accept, filter, or reject an email.

Email Deliverability: The Ultimate Guide to Reaching the Inbox

Tue, 03 Feb 2026 00:00:00 +0000

You send emails, but do they actually reach the inbox? Deliverability is the rate at which your emails land in recipients’ inboxes, as opposed to the spam folder or outright rejection. It’s a critical issue for any business that communicates via email.

Why Your Emails Aren’t Arriving

ISPs (Gmail, Outlook, Yahoo, etc.) use hundreds of signals to decide the fate of each email. Here are the main ones:

1. DNS Authentication

This is the absolute prerequisite. Without it, you’re a stranger to ISPs.

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).

SPF: The Complete Guide to Authorizing Your Sending Servers

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

SPF (Sender Policy Framework) is the first line of defense in email authentication. It lets you declare in your DNS which servers are allowed to send email for your domain. Simple on the surface, it hides subtleties that trip up even experienced admins.

What Does SPF Actually Do?

When a receiving server gets an email from contact@yourdomain.com, it asks one question: “Is this server allowed to send for this domain?”