What happens when a customer receives an email that looks exactly like yours, carries your logo, and asks for a password reset, but it never came from your company? Without email authentication, nothing stops that message from landing in an inbox. This checklist walks through the technical controls that prove your mail is genuinely yours, the order to implement them, and the mistakes that quietly undo the work. (Email security and anti-spoofing)
Why Email Authentication Became Non-Negotiable
Email was built to deliver messages, not to verify senders. That gap is exactly what phishing exploits. Authentication adds verifiable proof that a message claiming to come from your domain actually left an authorized server.
The pressure is now commercial as well as technical. Google announced that bulk senders hitting Gmail at 5,000 or more messages per day must authenticate with SPF, DKIM, and DMARC, with enforcement phasing in from February 2024 and one-click unsubscribe required from June 2024. Yahoo published comparable sender requirements for the same period. Providers have revised those documents since, so treat published dates as announced policy rather than a guarantee of universal enforcement.
The practical takeaway: authentication is no longer a nice-to-have for high-volume senders. It is the baseline for anyone who wants reliable inbox placement.
Step 1: Inventory Every Domain and Sending Source
Before touching a DNS record, list what you actually send. Most authentication failures start with an incomplete inventory.
| What to record | Why it matters |
|---|---|
| Root and subdomains | Each one needs its own policy |
| ESPs and CRMs | Third parties send on your behalf |
| Transactional systems | Password resets, receipts, alerts |
| Marketing platforms | Often the highest volume |
| Internal relays | Frequently forgotten |
| Legacy apps | The usual source of mystery mail |
Common mistake: teams authenticate the marketing domain and forget the subdomain used by the billing system. Attackers do not care which subdomain is unprotected.
Practical tip: pull 30 days of DMARC aggregate reports before changing anything. They reveal every IP sending as your domain, including vendors nobody remembered signing up for.
Step 2: Publish a Correct SPF Record
SPF (Sender Policy Framework) is defined in RFC 7208, published in April 2014 and replacing the 2006 version. It lists which IP addresses may send mail for a domain.
What actually works:
- Keep the record in a single TXT entry. Multiple SPF records break evaluation.
- Stay under the 10-DNS-lookup limit. Exceeding it produces a permerror, and the check fails.
- End with `~all` while testing, then move to `-all` once reports look clean.
- Remove vendors you no longer use. Dead includes burn lookups.
The classic mistake is stacking includes from every tool ever trialed. A record with fourteen includes looks thorough and silently fails. Use an SPF flattening service or consolidate senders instead.
Also remember SPF checks the envelope sender, not the visible From header. That limitation is why the next steps exist.
Step 3: Sign Outbound Mail With DKIM
DKIM (DomainKeys Identified Mail) is specified in RFC 6376, published September 2011. It attaches a cryptographic signature to message headers, letting receivers confirm the message was not altered in transit.
Checklist items:
- Generate a key of at least 1024 bits; 2048 is the modern default.
- Publish the public key as a TXT record at the selector hostname.
- Rotate keys on a schedule, and keep the old key live during the overlap.
- Confirm every sending platform signs with a selector you control.
A frequent failure: the ESP signs with its own domain rather than yours. The message passes DKIM but fails alignment, which matters in Step 4. Another: signatures break when a mailing system modifies subject lines or adds footers after signing.
Step 4: Deploy DMARC in Monitor Mode First
DMARC (Domain-based Message Authentication, Reporting and Conformance) is defined in RFC 7489, published March 2015. It ties SPF and DKIM results to the visible From domain through an alignment check, then tells receivers what to do when both fail.
The work on the DMARC update, informally called DMARCbis, has been moving through the IETF process. Anyone claiming a final standard number should be checked against the IETF DMARC working group before you cite it.
Start with `p=none`. This asks for reports without changing delivery. Then:
- Add a `rua=` address to collect aggregate reports.
- Read the reports for 30 to 60 days.
- Fix or remove unauthorized senders.
- Move to `p=quarantine` with a low percentage, such as `pct=25`.
- Increase gradually to `p=reject`.
That progression is practitioner guidance rather than a standards requirement, but it is the sequence most deliverability teams follow. Jumping straight to `p=reject` is the single most common self-inflicted outage, because forwarded mail and forgotten applications start bouncing.
Step 5: Add BIMI Only After DMARC Enforcement
BIMI (Brand Indicators for Message Identification) displays a verified brand logo beside authenticated messages. It requires DMARC at enforcement level, meaning `p=quarantine` or `p=reject`, as a prerequisite.
Two cautions. First, the BIMI specification is a draft hosted by the IETF, and requirements differ between mailbox providers. Second, logo display is a cosmetic win, not a security control. Do not let BIMI enthusiasm pull resources away from finishing DMARC.
Step 6: Cover Transport Security With MTA-STS and TLS-RPT
Authentication proves who sent a message. It does not protect the connection carrying it. Two companion standards close that gap.
MTA-STS, defined in RFC 8461 in September 2018, lets a domain publish a policy requiring TLS for inbound mail. TLS-RPT, in RFC 8460, provides reporting on TLS failures. Together they catch downgrade attacks and misconfigured certificates that would otherwise go unnoticed.
A third standard, ARC (Authenticated Received Chain), specified in RFC 8617 in July 2019, preserves authentication results across forwarding. It helps mailing lists and forwarders avoid breaking legitimate mail.
| Standard | Purpose | Typical starting point |
|---|---|---|
| SPF | Authorizes sending IPs | TXT record, under 10 lookups |
| DKIM | Cryptographic signature | 2048-bit key, rotation plan |
| DMARC | Policy plus reporting | `p=none`, then escalate |
| MTA-STS | Enforces TLS in transit | Report-only mode first |
| TLS-RPT | Reports TLS failures | Aggregate address |
| ARC | Survives forwarding | Set by intermediaries |
Step 7: Harden the Human Layer
Technical controls stop domain spoofing. They do not stop a convincing message from a lookalike domain, and they do not stop credential theft. Layer account protection on top.
Enable multi-factor authentication on every mailbox and admin account. If the term is unfamiliar, this explainer on what multi factor authentication is covers the mechanics, and this walkthrough on how to enable two factor authentication handles the setup for common providers. Phishing-resistant factors such as hardware keys and passkeys are worth prioritizing for finance and IT staff. (Email authentication)
Train staff to inspect messages rather than trust branding. A short guide on how to identify a scam email makes a useful internal reference, and a companion piece on how to check whether a link is safe covers the click-before-you-think habit.
Step 8: Monitor, Report, and Recheck Quarterly
Authentication is a maintenance job, not a one-time project. Set a quarterly review:
- Re-read DMARC aggregate reports for new senders.
- Audit DNS records for lookups and stale includes.
- Verify DKIM selectors still match live platforms.
- Confirm MTA-STS policy files remain reachable.
- Recheck vendor documentation, since provider rules change.
Practical tip: put the DNS change log under version control. When mail breaks, the fastest diagnosis is a diff against last month’s records.
Common Mistakes That Undo the Work
- Multiple SPF records. Receivers treat this as a permerror.
- Skipping alignment. SPF and DKIM can both pass while DMARC still fails.
- `p=reject` on day one. Legitimate forwarded mail disappears.
- Ignoring subdomains. Unprotected subdomains remain spoofable.
- No reporting address. Without `rua=`, you are flying blind.
- Treating authentication as phishing defense. It stops domain spoofing, not display-name tricks or lookalike domains.
That last point deserves emphasis. A message from a visually similar domain can pass every check because that domain’s owner configured it correctly. Authentication validates the sender’s identity claim, not their intent.
How to Verify the Setup Actually Works
Send test messages through every platform and inspect the raw headers. Look for `spf=pass`, `dkim=pass`, and `dmarc=pass` with the correct domain in the authentication results. Then send from an unauthorized server and confirm the message is quarantined or rejected as intended.
For a second opinion, use a third-party header analyzer. Testing is the only way to catch a selector typo or a policy file served with the wrong content type.
Conclusion
Email authentication rewards patience and punishes shortcuts. The sequence matters: inventory senders, publish clean SPF, sign with DKIM, monitor DMARC, then escalate policy once reports are boring. Add transport security, harden accounts with MFA, and review quarterly.
The organizations that get this right are not the ones with the most elaborate DNS records. They are the ones that started with monitoring, read their reports, and moved to enforcement only after the data supported it. Begin with the inventory and a `p=none` record this week. The rest follows from evidence, not guesswork.
Frequently Asked Questions
What is the difference between SPF, DKIM, and DMARC?
SPF authorizes sending IP addresses through a DNS record. DKIM adds a cryptographic signature proving the message was not altered. DMARC ties both to the visible From domain and sets a policy for failures. You need all three, and DMARC depends on the other two working correctly.
Do I need email authentication if I only send a few hundred emails a month?
Yes. Volume thresholds affect provider enforcement, not risk. Low-volume domains are attractive spoofing targets precisely because they are often unprotected, and a single phishing campaign using your name damages trust with customers and partners.
How long does it take to move from p=none to p=reject?
Most teams need 60 to 90 days. The first 30 to 60 days are for collecting and reading aggregate reports. After that, escalate in stages, raising the percentage gradually while watching for delivery complaints. Rushing this step is the most common cause of self-inflicted mail outages.
Can I use multiple SPF records for different senders?
No. A domain must publish exactly one SPF record. Additional senders go inside that record as include mechanisms, subject to the 10-lookup limit. If you exceed the limit, consolidate vendors or use a flattening approach rather than adding a second record.
Does DMARC stop all phishing that uses my brand?
No. DMARC stops spoofing of your exact domain. It does not stop lookalike domains, display-name impersonation, or compromised legitimate accounts. Pair it with MFA, staff awareness training, and monitoring for registered domains that resemble yours.
Is BIMI required for good deliverability?
No. BIMI controls logo display in supporting inboxes and requires DMARC enforcement as a prerequisite. It is a branding benefit, not a deliverability requirement. Finish DMARC enforcement and transport security first, then evaluate BIMI against each mailbox provider’s current rules.
For teams that want a faster read on where they stand, a simple maturity ladder helps: authenticated (SPF and DKIM passing), aligned (DMARC published), enforcing (`p=quarantine` or `p=reject`), and resilient (transport security plus MFA). Score yourself honestly at each rung, because a domain that passes SPF but fails alignment is still spoofable. Document the ladder in your runbook so new team members inherit the same sequence rather than improvising. Finally, keep a rollback plan for every policy change: know the exact record to restore, who can publish it, and how quickly. Authentication failures are recoverable in minutes when the previous state is documented, and painful for days when it is not.
