BetaSPFWise is in beta, and every feature is free until it ends. More information after you sign up.
SPFWise
How it worksWhat we checkPricingFAQGuides

Email Authentication Report for google.com

A live look at how google.com configures SPF, DKIM, DMARC, and transport security, with the grade explained.

A+

google.com

95 out of 100

Scanned: Jul 6, 2026, 1:16 PM

Why this score

The score starts at 100. Every issue below subtracts points based on how much it hurts your deliverability or lets someone spoof you.

Starting score
100
SPFEnds with ~all (softfail).
-5
Your score
95

  • SPF

    -5Pass
    • -5

      Ends with ~all (softfail).

      A softfail asks receivers to accept mail from unlisted senders but flag it, so spoofed messages can still reach the inbox.

      How to fix: Move to -all after confirming that all of your senders are included, so unauthorized mail is rejected.

    DNS lookups1 / 10
    v=spf1 include:_spf.google.com ~all
    allQualifier
    ~

  • DKIM

    Warning

    • No DKIM record found at common selectors.

      DKIM selectors cannot be listed from DNS, so we checked the widely used ones and found none for google.com. Your mail may still sign with a custom selector, but if it does not, receivers cannot confirm your messages were not tampered with in transit.

      How to fix: Enable DKIM signing in your email provider, then publish the selector TXT record it gives you at <selector>._domainkey.google.com.

    selectorsChecked
    47
    Read the DKIM guide

  • DMARC

    Pass

    • Policy is p=reject (strongest).

      Reject tells receivers to refuse any mail that fails authentication, the strongest protection against spoofing.

    • Aggregate reporting is enabled.

      A rua address is set, so you receive daily reports showing every source that sends as your domain.

    • DMARC is present and enforced.

      A valid DMARC record was found with an enforcing policy, so receivers act on mail that fails authentication.

    v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com
    policy
    reject
    subdomainPolicy
    reject
    pct
    100
    rua
    mailto:mailauth-reports@google.com
    adkim
    r
    aspf
    r

  • MX

    Pass

    • MX is configured (1 mail server(s)).

      Your domain has MX records and every listed mail server resolves to an IP address, so it can receive mail.

    mxHosts
    smtp.google.com (10)
    mxCount
    1

  • Blacklist

    Pass

    • Not on any checked blocklist.

      Your mail server IPs were not found on the public blocklists we checked. Reputation can change, so it is worth monitoring over time.

    ipsChecked
    142.251.9.27, 142.250.147.26, 142.250.147.27
    blocklists
    bl.spamcop.net, dnsbl.sorbs.net

Optional enhancements

Advanced, nice-to-have features. Setting these up (or not) does not change your grade.

  • DNSSEC

    Optional

    • DNSSEC is not enabled.

      DNSSEC is optional, but it protects against DNS spoofing by letting resolvers confirm your records are authentic. Most domains still do not use it.

      How to fix: If your DNS provider and registrar support it, enable DNSSEC to protect your domain from DNS tampering.

  • MTA-STS

    Pass

    • MTA-STS is enforcing.

      Your MTA-STS policy is in enforce mode, so sending servers refuse to deliver to your domain over an untrusted or unencrypted connection.

    mode
    enforce
    maxAge
    86400

  • TLS-RPT

    Pass

    • TLS reporting is enabled.

      Your TLS-RPT record is valid, so receivers can report TLS delivery failures to you.

    v=TLSRPTv1;rua=mailto:sts-reports@google.com
    rua
    mailto:sts-reports@google.com

  • BIMI

    Optional

    • BIMI is not set up.

      BIMI is optional. It shows your logo next to your emails in supporting inboxes, but it needs an enforced DMARC policy and, for Gmail and Apple Mail, a Verified Mark Certificate (VMC).

      How to fix: With DMARC at quarantine or reject, publish a BIMI TXT record at default._bimi pointing to a square SVG logo, and add a VMC to display it in Gmail and Apple Mail.

    Read the BIMI guide

This report examines how google.com configures email authentication across its public DNS records. For a technology company whose services reach millions of inboxes, the records that authorize senders and sign outgoing mail are the difference between a message that lands and one that is quietly dropped.

What this report checks

The grade above is derived directly from what google.com publishes in DNS, so it reflects the domain exactly as a receiving mail server sees it. SPF lists the servers allowed to send on the domain's behalf. DKIM adds a cryptographic signature that proves a message was not altered in transit. DMARC ties the two together and tells receivers what to do when a message fails both checks. Transport records such as MTA-STS and TLS-RPT add a further layer by protecting the connection itself.

About this report

This report is generated from publicly available DNS records for google.com and is provided for informational and educational purposes only. SPFWise is not affiliated with, endorsed by, or connected to the owner of google.com. The records shown are the same ones any mail server can query, and the grade updates automatically as they change.

Want the same breakdown for your own domain? Run a free scan to get an identical grade along with the exact records to fix anything that is weak.

Check your own domain

Run a free scan and get your grade with the exact records to fix.

Scan a domain

Guides to fix common issues

Email Compliance: CAN-SPAM, GDPR and CASL Basics

A plain-English guide to the three laws that govern commercial email: CAN-SPAM in the US, GDPR in the EU, and CASL in Canada, covering consent, identification, unsubscribe, penalties, and how compliance overlaps with deliverability.

Dedicated vs Shared IP for Sending Email

A practical guide to choosing between a dedicated and a shared sending IP, weighing volume, reputation control, warmup burden, and cost, with a clear decision path.

Phishing vs Spoofing: What Is the Difference?

Spoofing is the technique of forging a sender identity; phishing is the fraud it enables. This guide explains the difference, how they overlap, and which defenses stop each.