Email was designed in the 1970s with zero authentication. The SMTP protocol lets anyone send an email claiming to be from any address — there is no built-in verification. This is why phishing works so well. An attacker can send an email that appears to come from your CEO, your bank, or your IT department, and without proper authentication records, receiving mail servers have no way to tell it is fake.

SPF, DKIM, DMARC, and BIMI are four protocols that layer authentication on top of email. Together, they let receiving servers verify that an email actually came from an authorized sender for your domain. In 2024, Google and Yahoo began requiring DMARC for bulk senders — this is no longer optional. Here is how each protocol works, how to configure them correctly, and the mistakes that undermine their protection.

1. SPF: Sender Policy Framework

SPF lets you publish a DNS record listing the IP addresses and servers authorized to send email on behalf of your domain. When a receiving server gets an email from your domain, it checks the SPF record against the sending server's IP. If the IP is not listed, SPF fails.

An SPF record is a TXT record on your domain:

Breaking this down: v=spf1 declares this is an SPF record. include:_spf.google.com authorizes Google Workspace servers. include:amazonses.com authorizes Amazon SES. ip4:203.0.113.50 authorizes a specific IP address. -all tells receivers to reject (hard fail) any email from unlisted sources.

The 10-lookup limit: This is where most SPF configurations break. The SPF specification limits you to 10 DNS lookups total. Each "include" and "redirect" mechanism triggers a lookup, and nested includes count too. Google's include alone uses 3-4 lookups internally. If you use multiple email services (Google Workspace, a marketing platform, a transactional email service, a helpdesk), you can easily exceed 10 lookups. When you do, SPF returns a permanent error and all your email fails authentication.

To fix this: use ip4 and ip6 mechanisms instead of includes where possible (they do not count as lookups). Consolidate email services. Remove includes for services you no longer use. SPF flattening services can resolve includes to IP addresses, but they require monitoring because the IPs can change.

Common mistake: Using ~all (softfail) instead of -all (hardfail). Softfail tells receivers "this might not be authorized but do not reject it" — which is effectively useless. Use -all in production.

2. DKIM: DomainKeys Identified Mail

DKIM adds a cryptographic signature to your emails that proves the message was sent by an authorized server and has not been modified in transit. Unlike SPF which only checks the sending IP, DKIM signs the message headers and body, so a forwarded email retains its DKIM signature even though the forwarding server's IP is not in your SPF record.

DKIM works with a key pair: a private key on your mail server signs outgoing messages, and a public key published in DNS lets receivers verify the signature. The DNS record uses a selector to allow multiple keys:

Selectors: Each email service uses its own selector. Google uses "google", Amazon SES generates unique selectors per identity. This lets you have different DKIM keys for different services without conflict. You can look up any domain's DKIM key if you know the selector:

Key rotation: DKIM keys should be rotated at least annually. The process is: generate a new key pair, publish the new public key with a new selector in DNS, configure your mail server to sign with the new key, wait for DNS propagation and for all in-flight emails signed with the old key to be delivered (48-72 hours), then remove the old DNS record.

Key size: Use at least 2048-bit RSA keys. The older 1024-bit keys are considered weak and some receivers may flag them. Note that 2048-bit keys often exceed the 255-character limit of a single DNS TXT string, so they need to be split across multiple strings within the same TXT record — your DNS provider should handle this automatically.

Common mistake: Not setting up DKIM for all email sending services. If your marketing platform sends email as your domain without DKIM signing, those emails will fail DMARC alignment even if your corporate email has DKIM configured.

3. DMARC: Domain-based Message Authentication, Reporting and Conformance

DMARC ties SPF and DKIM together and tells receiving servers what to do when authentication fails. Without DMARC, a receiving server might see that SPF and DKIM both failed but still deliver the email to the inbox. DMARC gives you a published policy that says "if authentication fails, reject it" — and provides reporting so you can see who is sending email as your domain.

A DMARC record is a TXT record at _dmarc.yourdomain.com:

Breaking this down: p=reject tells receivers to reject emails that fail both SPF and DKIM alignment. rua is the address for aggregate reports (daily XML summaries of authentication results). ruf is for forensic reports (individual failure details — not all receivers send these). adkim=s sets strict DKIM alignment (the DKIM signing domain must exactly match the From domain). aspf=s sets strict SPF alignment. pct=100 applies the policy to 100% of messages.

The three DMARC policies:

p=none — Monitor only. No enforcement. Emails are delivered normally but you receive reports. Start here.

p=quarantine — Failed emails are sent to spam/junk. This catches most phishing but does not fully block it.

p=reject — Failed emails are rejected entirely. This is the goal. Phishing emails spoofing your domain will not reach recipients.

Alignment is the key concept in DMARC. SPF checks the envelope sender (Return-Path), but users see the header From address. An attacker can set a Return-Path on their own domain (passing SPF) while putting your domain in the From header. DMARC alignment requires that the domain authenticated by SPF or DKIM matches the From header domain. Without alignment, SPF and DKIM alone do not protect against spoofing the visible sender.

Deployment path: Start with p=none for 2-4 weeks and analyze the aggregate reports. Identify all legitimate email sources (marketing tools, transactional senders, helpdesk systems) and make sure they pass SPF and DKIM alignment. Then move to p=quarantine with pct=10 and gradually increase to pct=100. Finally, switch to p=reject. This staged approach prevents you from accidentally rejecting legitimate email.

4. BIMI: Brand Indicators for Message Identification

BIMI is the newest addition to the email authentication stack. It displays your brand logo next to your emails in supporting mail clients (Gmail, Apple Mail, Yahoo, and others). This gives recipients a visual indicator that your email is authenticated and legitimate.

BIMI requires a DMARC policy of quarantine or reject — you cannot use BIMI without strong email authentication already in place. The BIMI record is a TXT record at default._bimi.yourdomain.com:

Logo requirements: The logo must be in SVG Tiny PS format (not regular SVG). It must be square, hosted over HTTPS, and must not exceed 32KB. Most logos need to be recreated in the SVG Tiny PS profile — you cannot just export from Illustrator and expect it to work.

VMC certificates: A Verified Mark Certificate is an extended validation certificate issued by DigiCert or Entrust that verifies you own the trademark for your logo. Gmail requires a VMC for BIMI logo display. VMC certificates cost around $1,500/year and require a registered trademark in an eligible trademark office.

Is BIMI worth it? For large organizations sending high volumes of email, yes. The brand logo in the inbox increases trust and open rates. For smaller organizations, the VMC cost may not be justified yet. However, you should still set up the BIMI record with your logo URL — some mail clients display the logo without requiring a VMC, and the requirements may loosen over time.

5. How the Stack Works Together

Here is what happens when someone receives an email claiming to be from your domain:

1. The receiving server checks your SPF record and verifies the sending IP is authorized.
2. The receiving server verifies the DKIM signature against the public key in your DNS.
3. The receiving server checks DMARC alignment — does the domain authenticated by SPF or DKIM match the From header?
4. If DMARC passes, the receiving server checks for a BIMI record and displays your logo if present and valid.
5. If DMARC fails, the receiving server applies your DMARC policy (none/quarantine/reject).
6. Aggregate reports are sent to your rua address so you can monitor authentication results.

Each protocol covers a gap the others leave open. SPF authenticates the sending server but breaks on forwarding. DKIM authenticates the message content but does not tell receivers what to do on failure. DMARC adds policy enforcement and alignment checking. BIMI adds visual brand verification for recipients. All four are needed for comprehensive email authentication.

6. Verifying Your Configuration

After configuring all four protocols, verify everything works. Check your DNS records directly:

Send a test email to a Gmail account and click "Show original" to see the full authentication results. You should see SPF: PASS, DKIM: PASS, and DMARC: PASS. If any show FAIL, check the detailed headers for the specific reason.

Use BlackSight's email scanner at scanner.blacksight.io to get a complete audit of your email authentication setup. It checks SPF syntax and lookup count, DKIM key strength, DMARC policy and alignment settings, and BIMI record validity — all in a single scan with specific remediation steps for each finding.

Most importantly, read your DMARC aggregate reports. They tell you exactly which servers are sending email as your domain, whether those emails pass or fail authentication, and from which IP addresses. This is your ongoing visibility into email spoofing attempts targeting your domain.