Email Authentication: SPF, DKIM, DMARC & BIMI
Email authentication is a set of DNS-based standards—SPF, DKIM, DMARC, and BIMI—that let receiving mail servers verify a message truly came from your domain and was not altered in transit. Together they prove you are a legitimate sender, stop spoofing, and are now required by Gmail and Yahoo for bulk senders.
Why authentication matters more than ever
In February 2024, Google and Yahoo began enforcing sender requirements: anyone sending to their users at volume must publish SPF and DKIM, have a DMARC policy, and keep spam complaints low. Without valid authentication, your mail is throttled, filed to spam, or rejected outright. Authentication is no longer an advanced tactic—it is the price of entry to the inbox.
Beyond compliance, authentication protects your brand. Spoofed emails that appear to come from you damage customer trust and can poison your domain reputation. The four standards below each solve a different part of the problem.
The four standards at a glance
| Standard | What it verifies | DNS record type | Required? |
|---|---|---|---|
| SPF | Which servers may send for your domain | TXT | Yes |
| DKIM | The message was not altered and came from your domain | TXT (selector) | Yes |
| DMARC | What to do when SPF/DKIM fail, plus reporting | TXT (_dmarc) | Yes for bulk senders |
| BIMI | Displays your verified logo in the inbox | TXT (default._bimi) | Optional |
SPF: authorize your sending servers
Sender Policy Framework (SPF) is a TXT record listing the IP addresses and services allowed to send email using your domain. When a receiving server gets your message, it checks the sending IP against this list. A typical record looks like this:
v=spf1 include:_spf.google.com include:sendgrid.net ~all
The mechanisms matter. include: pulls in a provider's authorized ranges. The final ~all is a soft fail (accept but mark), while -all is a hard fail (reject anything not listed). Keep one SPF record per domain, and stay under the 10-DNS-lookup limit—exceed it and SPF returns a permerror, which counts as a failure.
DKIM: sign your messages cryptographically
DomainKeys Identified Mail (DKIM) adds a digital signature to each message header using a private key held by your sending platform. You publish the matching public key in DNS under a selector, for example s1._domainkey.yourdomain.com. The receiver fetches that public key, recomputes the signature over the signed headers and body, and confirms nothing was tampered with in transit.
DKIM survives forwarding better than SPF because it is tied to the message content, not the connecting IP. Use at least a 1024-bit key; 2048-bit is the current best practice. Rotate keys periodically and never share the private key.
DMARC: tie it together and get reports
DMARC (Domain-based Message Authentication, Reporting & Conformance) builds on SPF and DKIM. It tells receivers what to do when a message fails authentication and where to send reports. A DMARC record lives at _dmarc.yourdomain.com:
v=DMARC1; p=none; rua=mailto:[email protected]; adkim=s; aspf=s
The critical concept is alignment: the domain in the visible From address must match the domain validated by SPF or DKIM. Start with p=none to monitor without affecting delivery, read the aggregate reports for a few weeks, fix any legitimate sources, then tighten to p=quarantine and finally p=reject.
BIMI: put your logo in the inbox
Brand Indicators for Message Identification (BIMI) displays your verified logo next to authenticated messages in supporting inboxes. BIMI requires an enforced DMARC policy (p=quarantine or p=reject), an SVG Tiny P/S logo hosted at a public URL, and—for Gmail and Apple Mail—a Verified Mark Certificate (VMC) proving you own the trademark. BIMI is the payoff for doing the first three standards correctly: a visible trust signal that lifts recognition.
How to set it all up
- Inventory every service that sends mail as your domain (your ESP, CRM, invoicing tool, help desk).
- Publish one SPF record that includes all of them, staying under 10 lookups.
- Enable DKIM signing in each platform and publish the selector records they give you.
- Publish a DMARC record at
p=nonewith aruareporting address. - Monitor reports, fix gaps, then move to quarantine and reject.
- Once enforced, add BIMI if you want your logo displayed.
If DNS records intimidate you, our free SPF, DKIM & DMARC generator builds valid records from a short form. IGSendMail also configures SPF, DKIM, and DMARC automatically for every sending domain on your account, so authentication is handled the moment you connect a domain.
Frequently asked questions
Do I need all four standards?
SPF, DKIM, and DMARC are effectively required to reach Gmail and Yahoo at volume. BIMI is optional and mainly a branding benefit, but it depends on the other three being in place.
What is the difference between SPF and DKIM?
SPF authorizes which servers may send for your domain based on IP address. DKIM cryptographically signs the message so receivers can confirm it was not altered. They protect against different attacks, which is why DMARC requires you to run both.
Why does my email fail DMARC even though SPF passes?
DMARC requires alignment—the visible From domain must match the domain that SPF or DKIM validated. Mail sent through a third party often passes SPF for the provider's domain but fails alignment for yours. Fix it by authenticating with your own domain.
How long does authentication take to work?
DNS changes can propagate in minutes but may take up to 48 hours. Start DMARC at p=none and give yourself two to four weeks of monitoring before enforcing a stricter policy.
Authentication is the foundation of every deliverability strategy—see our full guide to email deliverability for how the pieces fit together with reputation and list hygiene.
Ready to send email that authenticates itself and lands in the inbox? Launch with IGSendMail and get automatic SPF, DKIM, and DMARC on every domain.