What happens when a customer gets a convincing email from your brand asking for a password reset, and your real password reset email lands in spam? That is embarrassing, and it also shows that your email authentication is broken and that attackers are exploiting the gap. The fixes are well documented, widely supported, and mostly free. The harder part is getting the details right.
This guide walks through the practical side of SPF, DKIM, and DMARC (plus the newer layers like BIMI and ARC), the mistakes that quietly undermine them, and what actually works when you move from theory to a live mail stream.
Why Email Authentication Matters More Than Ever
Email was built without identity verification. Anyone can put your domain in the From: field. Authentication protocols exist to close that gap by letting receiving servers check three things: did the message come from a server authorized by the domain, was it tampered with in transit, and does the visible From: domain match what was authenticated?
Get this right and you get three payoffs. Legitimate mail reaches inboxes more reliably. Phishing that spoofs your domain gets rejected. And your brand avoids the slow spiral where receivers start treating all your mail with suspicion.
Get it wrong and the failure is often invisible. A single misconfigured record can break authentication for an entire sending platform, and nobody notices until deliverability drops weeks later.
Start With SPF: Authorize Your Senders
SPF (Sender Policy Framework) is a DNS TXT record that lists which servers may send mail for your domain. It’s defined in RFC 7208, published in 2014, and it remains the simplest of the core mechanisms.
A basic record looks like this:
`v=spf1 include:_spf.example-provider.com -all`
The `-all` at the end means “reject anything not listed.” That’s the right choice for most organizations, but only after you’ve inventoried every system that sends as your domain.
The SPF Mistakes That Actually Break Things
The 10-lookup limit. SPF allows a maximum of 10 DNS lookups during evaluation. Every `include:` and `a:` mechanism counts, and includes can chain into more lookups. Large organizations with many SaaS senders routinely blow past this limit, which produces a permerror and fails authentication entirely. The fix is to flatten your SPF record, consolidating includes into fewer entries, or to split non-critical sending onto subdomains.
Forgetting the boring senders. The marketing platform gets configured. The transactional email service gets configured. The helpdesk, the CRM, the invoice system, and the on-premises printer that scans to email do not. When you flip to `-all`, those senders start failing silently.
Multiple SPF records. You can only have one SPF record per domain. Adding a second TXT record with `v=spf1` does not merge them; it breaks SPF. This happens constantly during provider migrations.
Using `~all` forever. Softfail is a reasonable staging state. It is not a destination. Organizations that leave `~all` in place for years are telling receivers “we’re not sure,” and receivers act accordingly.
DKIM: Cryptographic Proof the Message Wasn’t Altered
DKIM (DomainKeys Identified Mail) adds a digital signature to outgoing messages. The sending server signs selected headers and the body with a private key, and the public key sits in DNS for receivers to check. The standard is RFC 6376, from 2011.
DKIM does two jobs. It proves the message content wasn’t modified in transit, and it gives receivers a domain to evaluate independently of the visible From: address.
Practical DKIM Guidance
Use 2048-bit keys. 1024-bit keys are still technically valid but are increasingly treated as weak. Most major providers now support 2048-bit by default.
Rotate keys on a schedule. Quarterly rotation is a common benchmark. The catch is coordination: if you rotate the key before the new public key propagates in DNS, mail breaks. Publish the new key, wait for TTL, then switch signing.
Sign with a domain you control. A surprising number of setups sign with a shared provider domain rather than your own. That still passes DKIM, but it fails alignment for DMARC, which is the next section.
Watch for body-modification breakage. Mailing lists, forwarders, and some ticketing systems rewrite message bodies. That invalidates the signature. This is where ARC comes in later.
DMARC: The Policy Layer That Ties It Together
DMARC is where SPF and DKIM become a coherent policy. It’s specified in RFC 7489, published in 2015, and it does three things: it requires that at least one of SPF or DKIM pass and align with the From: domain, it tells receivers what to do on failure, and it sends you reports.
Alignment is the concept people most often miss. SPF can pass for a domain that has nothing to do with the From: address. DMARC closes that loophole by demanding that the authenticated domain match the visible one, in either relaxed mode (organizational domain matches) or strict mode (exact match).
| Policy | What receivers do on failure | When to use it |
|---|---|---|
| `p=none` | Deliver normally, send reports | Monitoring phase only |
| `p=quarantine` | Route to spam or a quarantine folder | After monitoring shows clean alignment |
| `p=reject` | Block the message outright | The end state for every domain you own |
The Rollout Sequence That Works
- Inventory senders. Pull every source of mail using your domain: marketing, transactional, CRM, ticketing, calendar invites, invoicing, and any legacy application.
- Publish SPF and DKIM for all of them. Verify each one actually passes by sending test mail to a reporting address.
- Start DMARC at `p=none` with reporting enabled. Add `rua=` and `ruf=` addresses. Aggregate reports (`rua`) are the valuable ones; forensic reports (`ruf`) are inconsistently delivered and often contain redacted data.
- Read the reports for at least four weeks. Look for legitimate sources failing alignment. Fix them.
- Move to `p=quarantine` with a small percentage. DMARC supports `pct=` to apply policy to a fraction of failing mail, which is a useful safety valve.
- Advance to `p=reject` and `pct=100`. This is the target state.
- Add `sp=reject` for subdomains and a strict policy for domains that never send mail at all.
That last point matters more than it sounds. Non-sending domains are a favorite spoofing target because nobody’s watching them. Publishing `v=DMARC1; p=reject; sp=reject;` on parked and defensive domains closes an easy door. CISA has repeatedly urged organizations to enforce reject policies on non-sending domains as part of broader phishing-resistance efforts.
Common DMARC Mistakes
Treating `p=none` as done. Monitoring mode is a phase, not a policy. Attackers know that `p=none` means spoofed mail still gets delivered.
Ignoring the reports. Aggregate reports are XML files that are unreadable by hand. Use a DMARC reporting service or an open-source parser. Organizations that enable reporting and never look at it gain almost nothing.
Forgetting subdomains. `p=` applies to the organizational domain, but `sp=` governs subdomains. Without `sp=reject`, `anything.yourdomain.com` can still be spoofed.
Not handling third-party senders correctly. Some vendors send on your behalf but can’t align DKIM to your domain. The correct fix is usually to have them sign with your domain via CNAME delegation, not to weaken your policy.
Beyond the Basics: BIMI, ARC, and Transport Security
Once DMARC is at enforcement, additional layers become available.
BIMI (Brand Indicators for Message Identification) displays your logo next to authenticated mail in supporting inboxes. It requires DMARC enforcement plus a Verified Mark Certificate from an approved authority. The standard has been evolving, so confirm current requirements before budgeting. The practical upside is real: verified logos raise engagement and make impersonation visually obvious.
ARC (Authenticated Received Chain), defined in RFC 8617, preserves authentication results across forwarders and mailing lists. Without ARC, a legitimately forwarded message can fail SPF and DKIM at the final destination. ARC lets an intermediary seal the results it observed, so the receiving server can weigh them. It’s not a replacement for DMARC; it’s a patch for the forwarding problem.
MTA-STS and TLS-RPT (RFC 8461 and RFC 8460) protect mail in transit by requiring TLS and reporting failures. They don’t authenticate the sender, but they stop downgrade attacks that strip encryption between servers. They’re cheap to deploy and worth adding once DMARC is done.
NIST’s Trustworthy Email guidance (SP 800-177 Rev. 1) treats SPF, DKIM, and DMARC as the baseline set for organizational email security, which is a useful benchmark for where the floor sits. (NIST Cybersecurity Framework)
Operational Habits That Keep Authentication Working
Configuration is a one-time task. Keeping it working is ongoing, and this is where most programs quietly decay.
Monitor continuously, not annually. Sender inventories change constantly. A new marketing tool, an acquired business unit, a migrated CRM: each one can break alignment overnight. Set alerts on DMARC failure rates rather than reviewing reports when something feels wrong.
Keep a sender register. A simple spreadsheet listing every system that sends as your domain, its SPF include, its DKIM selector, and its owner prevents the classic “who authorized this?” scramble during an incident.
Document your DNS changes. SPF and DKIM live in DNS, which means anyone with zone access can break authentication. Change control on DNS records is unglamorous and highly effective.
Test after every change. Send test messages to a seed address at Gmail, Outlook, and a smaller provider after any DNS edit. Check the authentication results headers to confirm SPF, DKIM, and DMARC all pass with alignment.
Treat authentication as part of a wider security posture. Email authentication stops domain spoofing, but it doesn’t stop credential phishing from lookalike domains, and it doesn’t protect accounts once a password is stolen. Pair it with strong multi-factor authentication across your mail systems and identity provider. Understanding what multi factor authentication is and how to enable two factor authentication on mail and admin accounts closes the gap that DMARC can’t reach. Phishing-resistant options like passkeys and hardware tokens, covered in this overview of biometric authentication, are worth prioritizing for anyone with mailbox or DNS access.
Train people to recognize the messages that slip through. Even with `p=reject`, lookalike domains and compromised partner accounts get through. Teaching staff how to identify a scam email reduces the number of people who act on the ones that arrive.
Apply governance to automated systems. As AI tools start drafting and routing email at scale, the rules about who may send as your domain need written ownership. A lightweight AI governance principles, risks and best practices framework helps assign accountability before an automated system starts sending mail nobody approved.
Conclusion
Email authentication rewards patience and punishes shortcuts. The protocols themselves are stable and well documented: SPF authorizes senders, DKIM signs messages, DMARC enforces alignment and reports failures. The failure modes are almost never in the standards. They’re in the incomplete sender inventory, the forgotten `~all`, the monitoring policy left in place for three years, and the DNS change nobody tested.
The sequence that works is unglamorous. Inventory everything that sends as your domain. Authenticate each source. Watch reports at `p=none` until the data is boring. Then move to reject and keep watching. Add BIMI, ARC, and transport security once the foundation holds. Pair all of it with strong account security, because a spoof-proof domain still can’t protect a stolen password.
Frequently Asked Questions
What is the difference between SPF, DKIM, and DMARC?
SPF lists which servers may send mail for a domain. DKIM adds a cryptographic signature proving the message wasn’t altered. DMARC ties them together by requiring that SPF or DKIM pass and align with the visible From: domain, then tells receivers what to do when they don’t. You need all three working together; any one alone leaves a gap.
Can I have more than one SPF record?
No. A domain may publish only one SPF record. Adding a second TXT record starting with `v=spf1` causes a permerror and breaks SPF entirely. To add a new sender, edit the existing record to include it. This is one of the most common and most damaging configuration mistakes.
How long should I stay at DMARC p=none?
Long enough to see a full reporting cycle across all your senders, which is typically four to eight weeks. If your reports show only authorized sources passing with alignment, move to `p=quarantine`, then `p=reject`. Staying at `p=none` indefinitely provides monitoring but no protection against spoofing.
Does DMARC stop all phishing that uses my domain?
No. DMARC stops direct domain spoofing when set to reject. It does not stop lookalike domains, compromised partner accounts, or credential phishing hosted elsewhere. It’s one layer, and it works best alongside MFA on mail accounts and user awareness training.
What is DMARC alignment and why does it matter?
Alignment means the domain that passed SPF or DKIM matches the domain in the visible From: address. Without alignment, a message could pass SPF for an unrelated domain while claiming to be from yours. DMARC requires alignment in relaxed mode (organizational domain) or strict mode (exact match), which is what makes the policy meaningful.
Do I need BIMI to be secure?
No. BIMI is a branding and trust-signal feature that displays your logo in supporting inboxes. It requires DMARC enforcement as a prerequisite, so it’s a useful milestone but not a security control. Prioritize SPF, DKIM, DMARC enforcement, MFA, and TLS before considering BIMI.
