Email authentication explained: why Gmail rejects your email

You wrote a perfectly good email. Hit send. Then got a bounce notification, or worse, heard nothing because the message silently landed in spam. You are not alone. This is one of the most common problems in email right now, and it has a specific cause: your domain is not authenticated.

If you are a marketing manager, founder, or anyone who sends email from a custom domain, this article is for you. No jargon dumps. Just a clear explanation of what changed, why your email is getting rejected, and how to fix it.

What changed

For years, email authentication was optional. You could send from any domain without proving you owned it. Spam filters did their best, but the system was fundamentally broken. Anyone could forge a From address and pretend to be your company.

That era is over.

Google and Yahoo both started enforcing authentication requirements in February 2024. If you send more than 5,000 messages a day to Gmail or Yahoo addresses, your domain must have SPF, DKIM, and DMARC configured correctly. Fall short and your email gets rejected outright or routed straight to spam.

Microsoft followed in 2025, applying similar rules to Outlook.com, Hotmail, and Live.com. The threshold is lower and the enforcement is stricter than many expected.

This is not a temporary policy experiment. It is the new baseline. Every major mailbox provider now treats unauthenticated email as suspicious by default. If your DNS records are not set up, your messages are dead on arrival.

SPF: the guest list for your domain

SPF stands for Sender Policy Framework. Think of it as a guest list at a private event.

Your domain is the venue. Every server that sends email on your behalf (your email provider, your marketing tool, your transactional email API) needs to be on that guest list. SPF is how you publish that list.

You create an SPF record in your DNS. It is a TXT record that says: "These IP addresses and services are allowed to send email as my domain." When Gmail receives a message claiming to be from your domain, it checks the SPF record. If the sending server is on the list, it passes. If not, it fails.

Here is what a simple SPF record looks like:

v=spf1 include:spf.sendkit.dev include:_spf.google.com ~all

That record says: Sendkit's servers can send for us, Google Workspace can send for us, and everyone else should be treated as suspicious.

The key thing to understand: SPF does not encrypt anything. It does not verify the content of your email. It only answers one question: "Is this server allowed to send for this domain?"

DKIM: the wax seal on your letter

DKIM stands for DomainKeys Identified Mail. If SPF is the guest list, DKIM is a wax seal on a letter.

When you send an email, your email service attaches an invisible cryptographic signature to the message headers. This signature is generated using a private key that only your sending service holds. A matching public key is published in your DNS records.

When the receiving server gets your message, it looks up the public key, checks the signature, and confirms two things: the message actually came from an authorized sender, and the message was not altered in transit.

DKIM does not prevent someone from seeing your email. It proves the email is genuine and intact. If someone intercepts the message and changes the content, the signature breaks and the receiving server knows something is wrong.

You do not need to understand the cryptography. You need to understand that without DKIM, receiving servers have no way to verify your email is real. And in 2026, unverified means untrusted.

DMARC: the policy that ties it together

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is the policy layer that sits on top of SPF and DKIM and tells receiving servers what to do when authentication fails.

Without DMARC, a receiving server might see that your email failed SPF or DKIM and shrug. Maybe it delivers the message anyway, maybe it doesn't. There is no consistency. DMARC removes the ambiguity.

A DMARC record looks like this:

v=DMARC1; p=reject; rua=mailto:[email protected]

The p= value is your policy:

• p=none -- Monitor only. Failures are reported but mail is still delivered. Use this while you are setting things up.
• p=quarantine -- Failed messages go to spam. This is the minimum Google and Yahoo require for bulk senders.
• p=reject -- Failed messages are blocked entirely. This is where you want to end up.

DMARC also requires alignment. The domain in the From header must match the domain used in SPF or DKIM checks. This prevents attackers from passing SPF with their own domain while spoofing yours in the From field.

The rua= part tells receivers where to send aggregate reports. These reports show you who is sending email as your domain, whether they are passing authentication, and where failures are happening. They are essential for diagnosing problems.

How to check if you are set up correctly

You do not need to be a sysadmin to verify your records. Here are the quickest ways.

Using dig commands (if you are comfortable with a terminal):

dig TXT yourdomain.com +short        # Check SPF
dig TXT _dmarc.yourdomain.com +short # Check DMARC
dig TXT selector._domainkey.yourdomain.com +short # Check DKIM

For DKIM, replace selector with your actual DKIM selector. Your email provider will tell you what it is.

Using online tools:

• MXToolbox -- checks SPF, DKIM, DMARC, and MX records
• Google Postmaster Tools -- shows your domain reputation with Gmail
• Mail Tester -- send a test email and get a deliverability score

If any of these checks come back empty or with errors, your authentication is broken and you need to fix it before sending another campaign.

For a full walkthrough, read our step-by-step guide to setting up DMARC, DKIM, and SPF.

Common mistakes that break authentication

Even teams that set up authentication often get tripped up by these.

Too many SPF lookups. SPF has a hard limit of 10 DNS lookups. Every include: in your record counts as a lookup, and nested includes count too. If you use multiple email services (marketing, transactional, CRM, helpdesk), you can blow past this limit without realizing it. When you exceed 10 lookups, SPF fails entirely, which is worse than not having it at all.

Leaving DMARC at p=none forever. Monitor mode is meant to be temporary. It is a diagnostic phase where you confirm your legitimate email passes authentication. If you leave it at p=none for months or years, receivers know you are not serious about enforcement and treat your domain accordingly. Move to p=quarantine once your reports look clean, then to p=reject.

Missing DKIM alignment. DKIM can technically pass even when the signing domain does not match your From domain. But DMARC requires alignment. If your email service signs with bounce.thirdparty.com instead of yourdomain.com, DKIM passes but DMARC fails. Make sure your provider supports custom DKIM signing with your own domain.

Forgetting about subdomains. If you send from mail.yourdomain.com but only set up authentication for yourdomain.com, messages from the subdomain may fail. DMARC has an sp= tag specifically for subdomain policy. Do not ignore it.

How Sendkit handles this

Authentication setup is one of those things that should not require a weekend of reading RFCs.

When you add a sending domain in Sendkit, we auto-generate the exact DNS records you need: SPF include, DKIM keys, and a recommended DMARC record. You copy them into your DNS provider, click verify, and you are done. No guessing which selector to use, no manually generating key pairs.

Sendkit also monitors your authentication status continuously. If a record breaks because someone changed your DNS, we flag it in the dashboard before it tanks your deliverability. You can send via our email API or SMTP relay, and both paths get the same authentication treatment.

For the full setup process, check the Sendkit docs.

The bottom line

Email authentication is not optional anymore. Gmail, Yahoo, and Outlook will reject your messages if SPF, DKIM, and DMARC are not configured. The good news is that setting them up is a one-time task, and the payoff is immediate: better inbox placement, fewer bounces, and a domain reputation that actually works in your favor.

If you have not checked your authentication records recently, do it today. And if you want to improve your email deliverability beyond authentication, start with your list hygiene and sending patterns. Authentication gets you in the door. Everything else keeps you there.