Email Authentication Explained: SPF, DKIM, DMARC & More

Two Different Problems That Both Cause Bounces

"My emails are bouncing" can mean two very different things. Sometimes the recipient address is simply wrong — the mailbox doesn't exist, the domain is dead, or there's a typo. That's a list-hygiene problem, and it's what BounceBuster catches: format, DNS, and mailbox-level checks run locally, before you send.

Other times every address on your list is perfectly real, and mail still bounces or lands in spam — because the receiving server doesn't trust that you are who you say you are. That's an authentication problem, and it's solved by a different set of tools: SPF, DKIM, DMARC, BIMI, and MTA-STS. BounceBuster doesn't configure or test these — they live in your domain's DNS, not in your recipient list — but understanding them is essential if you want your validated, clean list to actually land in the inbox. Here's what each one does.

SPF: Who's Allowed to Send as You

SPF (Sender Policy Framework) is a DNS TXT record that lists the mail servers authorized to send email for your domain. When a receiving server gets a message claiming to be from yourdomain.com, it checks the SPF record to see if the sending server's IP address is on the approved list.

A typical SPF record looks like v=spf1 include:_spf.google.com ~all. It's simple to set up, but it has a well-known gap: SPF checks the server that sent the message, not the "From" address a human actually reads — and it breaks when a message is forwarded through a third party. That's why SPF alone isn't considered sufficient authentication anymore.

DKIM: A Signature That Proves the Message Wasn't Altered

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to each outgoing email, generated with a private key your mail server holds. The receiving server looks up the matching public key in your DNS records and verifies the signature. If it matches, the message genuinely came from your domain and wasn't modified in transit.

Unlike SPF, DKIM survives most forwarding scenarios because the signature travels with the message content rather than depending on the sending IP. Most email service providers (Google Workspace, Microsoft 365, your ESP) will walk you through generating a DKIM key pair and publishing the public half as a DNS record.

DMARC: The Policy That Ties SPF and DKIM Together

SPF and DKIM each answer a narrow question. DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy layer that tells receiving servers what to do when a message fails one or both checks — and, critically, whether the "From" address a recipient sees actually aligns with the domain that passed SPF or DKIM.

A DMARC record specifies one of three policies:

• p=none: Take no action, just send reports. Good for a monitoring-only starting point.
• p=quarantine: Send failing messages to spam.
• p=reject: Block failing messages outright.

The recommended path is to start at p=none, review the aggregate reports major mailbox providers send you, fix any legitimate senders that show up as failing, and only then move to quarantine and eventually reject. Jumping straight to reject before you've confirmed every legitimate sending source passes is a common way teams accidentally block their own transactional mail.

BIMI: Your Logo in the Inbox

BIMI (Brand Indicators for Message Identification) is newer and more cosmetic than the other three, but it's a meaningful trust signal. If your domain has a strict DMARC policy in place (quarantine or reject) and you publish a BIMI record pointing to a certified logo file, supporting inboxes (Gmail, Yahoo, and others) will display your verified brand logo next to your messages instead of a generic avatar.

BIMI is a reward for having strong authentication already in place, not a replacement for it — most providers require a Verified Mark Certificate and a passing DMARC policy before they'll show the logo at all.

MTA-STS: Encrypting Mail in Transit

MTA-STS (Mail Transfer Agent Strict Transport Security) is different from the other four — it's not about proving who sent a message, it's about forcing encrypted delivery. It tells other mail servers "always deliver to my domain over an encrypted, certificate-verified connection, and refuse to fall back to plaintext." Combined with TLS reporting, it closes a gap where an attacker on the network path could otherwise downgrade a connection and intercept mail. Larger mailbox providers increasingly treat MTA-STS as one more signal of a well-run, trustworthy sending domain.

Where List Hygiene Fits In

None of these five records will fix a list full of dead addresses, and no amount of list cleaning will fix a missing DMARC policy. They solve different halves of the same deliverability problem:

• Authentication (SPF/DKIM/DMARC/BIMI/MTA-STS): Proves to receiving servers that you are who you claim to be, and that your mail arrived unaltered and encrypted. Configured once in DNS, maintained occasionally.
• List hygiene: Makes sure the addresses you're sending to are real, formatted correctly, and can actually receive mail. Needs to happen before every meaningful send, because lists decay continuously — see our breakdown of why lists lose roughly a quarter of their addresses every year.

Sending authenticated mail to a list full of dead addresses still produces high bounce rates, which erodes the sender reputation that authentication is supposed to protect. Sending an immaculately clean list from a domain with no SPF or DMARC record still risks landing in spam. You need both, and they're genuinely independent projects — one is a DNS configuration task you do with your IT admin or ESP, the other is a recurring list-validation habit. For the full picture of what damages and repairs sender reputation, see our guide on improving sender reputation.

What to Do This Week

1. Check whether your domain has SPF, DKIM, and DMARC records at all — free lookup tools from your DNS provider or ESP will tell you in seconds.
2. If DMARC is missing or still at p=none after several months of clean reports, work with whoever manages your DNS to move toward quarantine.
3. Separately, run your sending list through a validation pass so you know the bounces you do see are authentication issues, not dead addresses masquerading as deliverability problems.

BounceBuster handles that second half — local, one-time $19, no per-email fees, and your list never leaves your machine. It won't touch your DNS records, but it will make sure every address you're authenticating for is worth sending to. Download it here and validate your first 600 addresses free.