[{"data":1,"prerenderedAt":19},["ShallowReactive",2],{"blog-why-gmail-rejects-your-email":3},{"slug":4,"title":5,"description":6,"date":7,"author":8,"image":12,"tags":13,"content":17,"readingTime":18},"why-gmail-rejects-your-email","Email authentication explained: why Gmail rejects your email","Gmail, Yahoo, and Outlook now reject unauthenticated email. Here's what SPF, DKIM, and DMARC actually do and how to set them up.","2026-04-02",{"id":9,"name":10,"avatar":11},"sendkit","Sendkit Team","/images/authors/sendkit.png","/images/blog/why-gmail-rejects-your-email/cover.jpg",[14,15,16],"authentication","deliverability","best-practices","\u003Cp>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.\u003C/p>\n\u003Cp>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.\u003C/p>\n\u003Ch2>What changed\u003C/h2>\n\u003Cp>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.\u003C/p>\n\u003Cp>That era is over.\u003C/p>\n\u003Cp>\u003Cstrong>Google\u003C/strong> and \u003Cstrong>Yahoo\u003C/strong> both started enforcing authentication requirements in \u003Cstrong>February 2024\u003C/strong>. 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.\u003C/p>\n\u003Cp>\u003Cstrong>Microsoft\u003C/strong> followed in \u003Cstrong>2025\u003C/strong>, applying similar rules to Outlook.com, Hotmail, and Live.com. The threshold is lower and the enforcement is stricter than many expected.\u003C/p>\n\u003Cp>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.\u003C/p>\n\u003Cp>\u003Cimg src=\"/images/blog/why-gmail-rejects-your-email/inline-1.jpg\" alt=\"Email security and authentication\" width=\"1080\" height=\"720\" loading=\"lazy\" />\u003C/p>\n\u003Ch2>SPF: the guest list for your domain\u003C/h2>\n\u003Cp>SPF stands for Sender Policy Framework. Think of it as a guest list at a private event.\u003C/p>\n\u003Cp>Your domain is the venue. Every server that sends email on your behalf (your email provider, your marketing tool, your transactional \u003Ca href=\"/email-api\">email API\u003C/a>) needs to be on that guest list. SPF is how you publish that list.\u003C/p>\n\u003Cp>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.\u003C/p>\n\u003Cp>Here is what a simple SPF record looks like:\u003C/p>\n\u003Cpre class=\"shiki dracula\" style=\"background-color:#282A36;color:#F8F8F2\" tabindex=\"0\">\u003Ccode>\u003Cspan class=\"line\">\u003Cspan>v=spf1 include:spf.sendkit.dev include:_spf.google.com ~all\u003C/span>\u003C/span>\u003C/code>\u003C/pre>\u003Cp>That record says: Sendkit's servers can send for us, Google Workspace can send for us, and everyone else should be treated as suspicious.\u003C/p>\n\u003Cp>\u003Cstrong>The key thing to understand:\u003C/strong> 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?"\u003C/p>\n\u003Ch2>DKIM: the wax seal on your letter\u003C/h2>\n\u003Cp>DKIM stands for DomainKeys Identified Mail. If SPF is the guest list, DKIM is a wax seal on a letter.\u003C/p>\n\u003Cp>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.\u003C/p>\n\u003Cp>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.\u003C/p>\n\u003Cp>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.\u003C/p>\n\u003Cp>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.\u003C/p>\n\u003Ch2>DMARC: the policy that ties it together\u003C/h2>\n\u003Cp>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.\u003C/p>\n\u003Cp>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.\u003C/p>\n\u003Cp>A DMARC record looks like this:\u003C/p>\n\u003Cpre class=\"shiki dracula\" style=\"background-color:#282A36;color:#F8F8F2\" tabindex=\"0\">\u003Ccode>\u003Cspan class=\"line\">\u003Cspan>v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com\u003C/span>\u003C/span>\u003C/code>\u003C/pre>\u003Cp>The \u003Ccode>p=\u003C/code> value is your policy:\u003C/p>\n\u003Cul>\n\u003Cli>\u003Cstrong>p=none\u003C/strong> -- Monitor only. Failures are reported but mail is still delivered. Use this while you are setting things up.\u003C/li>\n\u003Cli>\u003Cstrong>p=quarantine\u003C/strong> -- Failed messages go to spam. This is the minimum Google and Yahoo require for bulk senders.\u003C/li>\n\u003Cli>\u003Cstrong>p=reject\u003C/strong> -- Failed messages are blocked entirely. This is where you want to end up.\u003C/li>\n\u003C/ul>\n\u003Cp>DMARC also requires \u003Cstrong>alignment\u003C/strong>. 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.\u003C/p>\n\u003Cp>The \u003Ccode>rua=\u003C/code> 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.\u003C/p>\n\u003Cp>\u003Cimg src=\"/images/blog/why-gmail-rejects-your-email/inline-2.jpg\" alt=\"Server infrastructure and DNS\" width=\"1080\" height=\"720\" loading=\"lazy\" />\u003C/p>\n\u003Ch2>How to check if you are set up correctly\u003C/h2>\n\u003Cp>You do not need to be a sysadmin to verify your records. Here are the quickest ways.\u003C/p>\n\u003Cp>\u003Cstrong>Using dig commands\u003C/strong> (if you are comfortable with a terminal):\u003C/p>\n\u003Cpre class=\"shiki dracula\" style=\"background-color:#282A36;color:#F8F8F2\" tabindex=\"0\">\u003Ccode>\u003Cspan class=\"line\">\u003Cspan style=\"color:#50FA7B\">dig\u003C/span>\u003Cspan style=\"color:#F1FA8C\"> TXT\u003C/span>\u003Cspan style=\"color:#F1FA8C\"> yourdomain.com\u003C/span>\u003Cspan style=\"color:#F1FA8C\"> +short\u003C/span>\u003Cspan style=\"color:#6272A4\">        # Check SPF\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#50FA7B\">dig\u003C/span>\u003Cspan style=\"color:#F1FA8C\"> TXT\u003C/span>\u003Cspan style=\"color:#F1FA8C\"> _dmarc.yourdomain.com\u003C/span>\u003Cspan style=\"color:#F1FA8C\"> +short\u003C/span>\u003Cspan style=\"color:#6272A4\"> # Check DMARC\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#50FA7B\">dig\u003C/span>\u003Cspan style=\"color:#F1FA8C\"> TXT\u003C/span>\u003Cspan style=\"color:#F1FA8C\"> selector._domainkey.yourdomain.com\u003C/span>\u003Cspan style=\"color:#F1FA8C\"> +short\u003C/span>\u003Cspan style=\"color:#6272A4\"> # Check DKIM\u003C/span>\u003C/span>\u003C/code>\u003C/pre>\u003Cp>For DKIM, replace \u003Ccode>selector\u003C/code> with your actual DKIM selector. Your email provider will tell you what it is.\u003C/p>\n\u003Cp>\u003Cstrong>Using online tools:\u003C/strong>\u003C/p>\n\u003Cul>\n\u003Cli>\u003Ca href=\"https://mxtoolbox.com\">MXToolbox\u003C/a> -- checks SPF, DKIM, DMARC, and MX records\u003C/li>\n\u003Cli>\u003Ca href=\"https://postmaster.google.com\">Google Postmaster Tools\u003C/a> -- shows your domain reputation with Gmail\u003C/li>\n\u003Cli>\u003Ca href=\"https://www.mail-tester.com\">Mail Tester\u003C/a> -- send a test email and get a deliverability score\u003C/li>\n\u003C/ul>\n\u003Cp>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.\u003C/p>\n\u003Cp>For a full walkthrough, read our \u003Ca href=\"/blog/setup-dmarc-dkim-spf\">step-by-step guide to setting up DMARC, DKIM, and SPF\u003C/a>.\u003C/p>\n\u003Ch2>Common mistakes that break authentication\u003C/h2>\n\u003Cp>Even teams that set up authentication often get tripped up by these.\u003C/p>\n\u003Cp>\u003Cstrong>Too many SPF lookups.\u003C/strong> SPF has a hard limit of 10 DNS lookups. Every \u003Ccode>include:\u003C/code> 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.\u003C/p>\n\u003Cp>\u003Cstrong>Leaving DMARC at p=none forever.\u003C/strong> 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 \u003Ccode>p=none\u003C/code> for months or years, receivers know you are not serious about enforcement and treat your domain accordingly. Move to \u003Ccode>p=quarantine\u003C/code> once your reports look clean, then to \u003Ccode>p=reject\u003C/code>.\u003C/p>\n\u003Cp>\u003Cstrong>Missing DKIM alignment.\u003C/strong> 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 \u003Ccode>bounce.thirdparty.com\u003C/code> instead of \u003Ccode>yourdomain.com\u003C/code>, DKIM passes but DMARC fails. Make sure your provider supports custom DKIM signing with your own domain.\u003C/p>\n\u003Cp>\u003Cstrong>Forgetting about subdomains.\u003C/strong> If you send from \u003Ccode>mail.yourdomain.com\u003C/code> but only set up authentication for \u003Ccode>yourdomain.com\u003C/code>, messages from the subdomain may fail. DMARC has an \u003Ccode>sp=\u003C/code> tag specifically for subdomain policy. Do not ignore it.\u003C/p>\n\u003Ch2>How Sendkit handles this\u003C/h2>\n\u003Cp>Authentication setup is one of those things that should not require a weekend of reading RFCs.\u003C/p>\n\u003Cp>When you add a sending domain in \u003Ca href=\"/email-api\">Sendkit\u003C/a>, 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.\u003C/p>\n\u003Cp>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 \u003Ca href=\"/email-api\">email API\u003C/a> or \u003Ca href=\"/smtp-service\">SMTP relay\u003C/a>, and both paths get the same authentication treatment.\u003C/p>\n\u003Cp>For the full setup process, check the \u003Ca href=\"https://docs.sendkit.dev\">Sendkit docs\u003C/a>.\u003C/p>\n\u003Ch2>The bottom line\u003C/h2>\n\u003Cp>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.\u003C/p>\n\u003Cp>If you have not checked your authentication records recently, do it today. And if you want to \u003Ca href=\"/blog/improve-email-deliverability\">improve your email deliverability\u003C/a> beyond authentication, start with your list hygiene and sending patterns. Authentication gets you in the door. Everything else keeps you there.\u003C/p>\n",8,1775845597620]