# How do you authenticate an email for Gmail? > Authenticate mail for Gmail with SPF or DKIM, plus SPF, DKIM, and DMARC for bulk sending. Verify alignment in a real Gmail delivery before rollout. To authenticate email for personal Gmail accounts, configure SPF or DKIM for every sending domain. [Google's email sender guidelines](https://support.google.com/mail/answer/81126?hl=en) require bulk senders to use SPF, DKIM, and DMARC, with the direct mail's From domain aligned to either the SPF envelope domain or DKIM signing domain. Inventory every sender, publish the records at the exact account-generated names, and inspect a new Gmail delivery. A correct DNS lookup alone does not prove that production mail was signed or aligned. ## Quick takeaways - Gmail requires SPF or DKIM for all senders to personal Gmail accounts. - Bulk senders need SPF, DKIM, and DMARC, plus alignment for direct mail. - Every legitimate sending service must be included in the design. - A provider-owned SPF or DKIM pass may not align with your visible From domain. - Authentication improves trust but does not guarantee inbox placement. ![How Gmail authentication fits together, shown as a four-step technical sequence.](/images/editorial/authenticate-email-for-gmail/authenticate-email-for-gmail-visual-guide.svg) *This diagram summarizes the article's diagnostic sequence. Use the linked standards, current provider documentation, and production evidence for exact decisions. [Open the full-size diagram](/images/editorial/authenticate-email-for-gmail/authenticate-email-for-gmail-visual-guide.svg).* ## What does the failure mean? An unauthenticated Gmail result means the message did not meet the applicable sender-authentication evidence. The header may show SPF none or fail, DKIM none or fail, or DMARC fail because a passing identity was not aligned with the visible From domain. If the message was delivered with a banner, use the full warning text to diagnose [Gmail's "Be careful with this message" notice](/learning/gmail-be-careful-with-this-message-warning). Google warns that messages lacking the required authentication can be marked as spam or rejected. Its guidelines also cover reverse DNS, TLS, complaint rates, formatting, and sending behavior. Authentication is necessary evidence, not a promise of delivery. ## What usually causes it? ### A sending service is missing from SPF The envelope domain publishes an SPF policy, but the connecting IP or provider include is not authorized. Adding a second SPF record makes the policy invalid instead of fixing it. ### DKIM is configured in DNS but not used The selector resolves, yet the application does not sign, uses another selector, or signs before a gateway changes the message. Production headers expose this gap. ### The passing domain is not aligned A platform can authenticate its own return path or signing domain while your brand appears in From. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) requires a passing domain that aligns with the visible identity for DMARC to pass. The [SPF overview](/learning/what-is-spf), [DKIM overview](/learning/what-is-dkim), and [DMARC overview](/learning/what-is-dmarc) explain the comparison. ## How do I diagnose the failure? ### 1. Inventory every Gmail-bound sender List mailbox systems, marketing platforms, CRMs, ticketing tools, invoices, alerts, and relays. Record the visible From domain used by each source. ### 2. Inspect a delivered Gmail message Use Gmail's original-message view. Record SPF and its envelope domain, DKIM and its signing domain, and DMARC for the visible From domain. Test each real application separately. ### 3. Check exact DNS owner names Query the SPF envelope domain and every DKIM selector shown in the message. Confirm one SPF record, a usable DKIM key, and one DMARC record at the expected owner name. ### 4. Compare the domains for alignment Determine whether the passing SPF or DKIM domain aligns with the From domain under the published mode. A green pass on an unrelated domain is not a DMARC-aligned pass. ## How do I fix it? Merge every authorized service into one maintainable SPF policy and stay within SPF's processing limit. Enable DKIM for each service with an account-specific selector and a domain you control. Publish DMARC with aggregate reporting, then correct unaligned sources before moving policy toward enforcement. For third-party platforms, use their custom return-path or custom DKIM feature when available. Copy values from the exact account and domain in scope. Never reuse a record from a different tenant or a generic screenshot. ## How do I validate the repair? Send a new production-path test to Gmail for every source. Confirm the expected authentication results and aligned DMARC pass, then review aggregate reports for normal traffic. Also check Google Postmaster data and SMTP responses where volume qualifies. Use Palisade's [Email Security Score](/tools/email-security-score) for a public-configuration check. Multi-domain teams can use monitored sending-source results to prioritize gaps, but the Gmail header remains the proof for each application. ## Frequently asked questions ### Is SPF alone enough for Gmail? Only for a non-bulk sender. SPF can meet Google's minimum authentication method in that case, but Google recommends SPF, DKIM, and DMARC. Bulk senders need all three under Google's current rules. ### Does a DMARC record make an email authenticated? No. DMARC evaluates passing SPF or DKIM and alignment. Publishing a policy does not create those underlying passes. ### Why does Gmail show DKIM pass but DMARC fail? The signing domain may not align with the visible From domain, or the receiver may be reporting another signature. Read the domain attached to the pass. ### Does authentication guarantee the Inbox? No. Google says authenticated messages are less likely to be rejected or marked as spam. Reputation, complaints, content, infrastructure, and sending practices still matter. ### Should I test only from my normal mailbox? No. Test every production service. A working mailbox path says nothing about a CRM, invoice system, or alert route that uses different identities.