BetaSPFWise is in beta, and every feature is free until it ends. More information after you sign up.

Email Authentication Report for gitlab.com

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

B

gitlab.com

70 out of 100

Scanned: Jul 6, 2026, 1:13 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
SPFToo many DNS lookups (13 of 10).
-30
Your score
70
  • SPF

    -30Fail
    • -30

      Too many DNS lookups (13 of 10).

      SPF allows at most 10 DNS-lookup mechanisms. Above that, receivers return a permerror and ignore SPF entirely, even for legitimate mail.

      How to fix: Reduce the number of include, a, mx, ptr and exists terms, or flatten some includes into ip4 and ip6 ranges, until you are at 10 or fewer.

    • Ends with -all (hardfail).

      A hardfail tells receivers to reject any sender that is not listed. This is the strongest and recommended setting.

    DNS lookups13 / 10
    v=spf1 include:mail.zendesk.com include:_spf.google.com include:mktomail.com include:_spf.salesforce.com include:_spf-ip.gitlab.com a:zgateway.zuora.com include:mailgun.org include:_spf.sendergen.com ip4:35.80.141.6/32 ip4:44.229.121.55/32 -all
    allQualifier
    -
    Read the SPF guide
  • DKIM

    Pass
    • DKIM is set up (5 valid selector(s) found).

      At least one valid signing key was found, so your outgoing mail can be signed and verified by receivers.

    selectors
    google, k1, mail, zendesk1, zendesk2
    keyType
    rsa
    keyBits
    2048
  • 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; pct=100; rua=mailto:dmarc_agg@vali.email;
    policy
    reject
    subdomainPolicy
    reject
    pct
    100
    rua
    mailto:dmarc_agg@vali.email
    adkim
    r
    aspf
    r
  • MX

    Pass
    • MX is configured (5 mail server(s)).

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

    mxHosts
    aspmx.l.google.com (1), alt1.aspmx.l.google.com (5), alt2.aspmx.l.google.com (5), alt4.aspmx.l.google.com (10), alt3.aspmx.l.google.com (10)
    mxCount
    5
  • 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
    108.177.125.26, 192.178.211.27, 192.178.158.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

    Optional
    • MTA-STS is not set up.

      MTA-STS is optional but recommended. It tells sending servers to require TLS when delivering mail to you, which blocks downgrade and man-in-the-middle attacks on your inbound mail.

      How to fix: Publish a _mta-sts TXT record and host a policy at https://mta-sts.<yourdomain>/.well-known/mta-sts.txt with mode enforce.

    Read the MTA-STS guide
  • TLS-RPT

    Optional
    • TLS reporting (TLS-RPT) is not set up.

      TLS-RPT is optional. It asks receivers to send you reports when TLS fails while delivering your mail, which is how you catch MTA-STS or certificate problems before they hurt delivery.

      How to fix: Publish a _smtp._tls TXT record with v=TLSRPTv1 and a rua address, for example rua=mailto:tlsrpt@yourdomain.

    Read the TLS-RPT guide
  • 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

Here is how gitlab.com has set up SPF, DKIM, and DMARC for the mail it sends. For a service that relies on notifications, invoices, and account alerts reaching users, these records are core infrastructure rather than an afterthought.

What this report checks

The grade above is derived directly from what gitlab.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 gitlab.com and is provided for informational and educational purposes only. SPFWise is not affiliated with, endorsed by, or connected to the owner of gitlab.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