Free tool

Email server & DNS test for github.com

Check every DNS record that decides whether your mail reaches the inbox — MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI and reverse DNS — scored out of 100 with a prioritised fix list.

  • No signup required
  • Results in seconds
  • DNS only — we never connect to your mail server

Free for everyone, 10 tests an hour. Results are shareable — the link updates with the domain you tested.

74Grade C

Deliverability score for

github.com

4 passed2 warnings0 failed3 informational

Checked in 1.0s · DNS only, no SMTP connection is made.

What to fix first

  1. 01

    Fix your MX records

    medium priority

    Publish at least two MX hosts that resolve to A or AAAA records and are not CNAMEs.

  2. 02

    Fix your SPF record

    medium priority

    Publish exactly one v=spf1 record, keep it under 10 DNS lookups, and end it with ~all or -all.

  3. 03

    Add MTA-STS

    low priority

    Publish the _mta-sts TXT record and the policy file, run it in testing, then switch to enforce.

  4. 04

    Add TLS reporting

    low priority

    One TXT record at _smtp._tls gets you daily reports of TLS delivery failures from the big providers.

MX records

Warning

1 MX host with issues

Only one MX host is published — a second host at a higher priority gives you a fallback during an outage.

Records

0 github-com.mail.protection.outlook.com → 52.101.60.2, 52.101.41.180, 52.101.194.3, 52.101.41.206, 2a01:111:f403:c902::4, 2a01:111:f403:f90a::8, 2a01:111:f403:f805::2, 2a01:111:f403:c903::3

MX records name the servers that accept mail for your domain, in priority order. They must be hostnames with A or AAAA records — never CNAMEs — and you want more than one.

SPF

Warning

SPF record needs attention

8 DNS-querying mechanisms of the 10 allowed by RFC 7208. Close to the limit. Flatten or remove includes before you add another sender. Ends in ~all, so unlisted senders are marked as a soft fail.

Records

v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com include:_netblocks.google.com include:_netblocks2.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com include:sendgrid.net ip4:62.253.227.114 ip4:166.78.69.169 ip4:166.78.69.170 ip4:166.78.71.131 ~all

SPF is a TXT record listing which servers may send mail using your domain in the envelope sender. One record only, at most 10 DNS-querying mechanisms, ending in ~all or -all.

DMARC

Pass

Enforcing policy (p=quarantine)

Policy is p=quarantine, so unaligned mail is sent to spam. Subdomains use sp=reject. Alignment is relaxed for DKIM and relaxed for SPF. Aggregate reports go to mailto:dmarc@github.com. InboxVet DMARC monitoring can receive these and turn them into readable reports. Forensic reports go to mailto:dmarc@github.com.

Records

v=DMARC1; p=quarantine; sp=reject; pct=100; rua=mailto:dmarc@github.com; ruf=mailto:dmarc@github.com; fo=1

DMARC ties SPF and DKIM to the From: address your recipients actually see, tells receivers what to do when both fail, and asks them to send you aggregate reports.

DKIM

Pass

5 DKIM keys found

Found 5 selectors: google (rsa 2048-bit), selector1 (rsa 1024-bit), s1 (rsa 2048-bit), s2 (rsa 2048-bit), k1 (rsa 1024-bit). Selectors cannot be enumerated, so other keys may exist beyond the common ones we probe.

Records

google._domainkey.github.com  v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAj6T5sl/RwdSqGoYWaWaFbS2UAeyPrEmd0gogocmRfS441qwR8/0KB81Hw89P0l4YiFRrXYk7NVIGfyCRHAYYZUzCkGeOysI2EjgzLFhd/NEsbRzOEc/kWkK/RO6JFq/5lOn6M9AZw/ap9tds4JG9ApgNNdSpPxp9DmvpsOSgNMVflRxQFrk3kdS4RNAPKu/OPoA7dlR/A/pECryjRoYgENtDXzdnK70HgCekems6UDzxDj61cjyoKoXtEMF/QsaHEQ1Gjfv014rDJBsubk/kT5VqHkWHa/ia68Z5r228Ety/wFfQNjXTx/J7KGZ9GkZlKED659eiJcLnWcKDSiQlhwIDAQAB
selector1._domainkey.github.com  v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCxZC/z2cK+2s1f/ktzSDSeFzkfIHrjwtGFsfKMAYvKaXjPVNzKykpbXBkX5nB7dVUTFttda7aROr2iSrIseQ27Ui+4rUZVzgFanE8RaXhYM9n5wPKNv8GtLJk7JgcsYZ7ErgID4uW2sEYyV/dnRYw6rDzOaeRKkKELTUfJI5ebLQIDAQAB;
s1._domainkey.github.com  k=rsa; t=s; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyn3fMCVpb7ryIRKOGXhXVGYmsWUitNlSckqGHOwNFZgFadplOrD+Qzf1XQkP7MH/VB/97DsAAJGtEXW1Uq71Hjnfr/DuBN/YfjF/gU70qEFb7q1sdIiNtjFL2TkOpoW+X/bhhPNheW/fYwyFb6ZHFM6LTgXyuimWRHTOUP3VjZzhNVda79nt+2WZYbS4l8HdMgWpTNHjpVw5PtXESA9KBg/evSRk5fIaXIX5eRXW3baoV9yVzD8O29/IL/DiSk+yNvaO0EHL5c4yGuZJhGzvpiznb2IDVdemJK4Dqzdy5FTN/SGYZhAEr7MguG3Z314hMS2scgMsOMgB64uj/6+6UwIDAQAB
s2._domainkey.github.com  k=rsa; t=s; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnNt2/H6bKs99C6DAaokPp62KN9mKaD20D1PBakkObejkJvzM6Un/fKHPeI2/qXdvFFBPQE3mxMNoe+hwBVDgMgCuZEn8J6gZYI4amITure9/ny6+GaNVRoH2m6xAtWwKINkKxMayGiehkWlRVb7D23F0U8y+VDHKQFz1bnXA5jDpcDiMXy8i2lV5vEys+qt+1WGhDKCAwamT8c3xkZz8aXMJaXYCiN2HMgHDU81+mVCk4+u6mY+a98APVfFhsQ0KCq/mVZXaXTV06QrG9M5PtBHUFW7VtwXKp+AFrAut0KW1NnwaA5IGA5sc+n9dma7bSqdfGS+ixdSmJ69NwmYSHwIDAQAB
k1._domainkey.github.com  k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDbNrX2cY/GUKIFx2G/1I00ftdAj713WP9AQ1xir85i89sA2guU0ta4UX1Xzm06XIU6iBP41VwmPwBGRNofhBVR+e6WHUoNyIR4Bn84LVcfZE20rmDeXQblIupNWBqLXM1Q+VieI/eZu/7k9/vOkLSaQQdml4Cv8lb3PcnluMVIhQIDAQAB;

DKIM signs each message with a private key; receivers fetch the public key from DNS to verify it. Selectors cannot be listed from DNS, so we probe the common ones.

Reverse DNS

Pass

Forward-confirmed: mail-bnypr05cu00102.inbound.protection.outlook.com

github-com.mail.protection.outlook.com resolves to 52.101.60.2, whose PTR is mail-bnypr05cu00102.inbound.protection.outlook.com, which resolves back to 52.101.60.2. This is what receivers check. Note that we do not connect on port 25, so the SMTP banner text itself is not inspected.

Records

github-com.mail.protection.outlook.com → 52.101.60.2
52.101.60.2 → PTR mail-bnypr05cu00102.inbound.protection.outlook.com → 52.101.60.2

Receivers check that your mail server's IP has a PTR record, and that the name in it resolves back to the same IP. We test this over DNS only — we never open an SMTP connection.

DNS basics

Pass

8 name servers, apex resolves

8 authoritative name servers. The apex resolves to 140.82.121.3.

Records

NS  dns4.p08.nsone.net
NS  ns-1283.awsdns-32.org
NS  ns-1707.awsdns-21.co.uk
NS  ns-421.awsdns-52.com
NS  ns-520.awsdns-01.net
NS  dns1.p08.nsone.net
NS  dns2.p08.nsone.net
NS  dns3.p08.nsone.net
github.com  140.82.121.3

The delegation the rest of the test stands on: which name servers are authoritative for the domain, and whether the bare domain resolves.

MTA-STS

Info

Not configured

MTA-STS lets you tell senders that mail to your domain must use TLS with a valid certificate, which closes the downgrade attack that plain opportunistic TLS leaves open. It needs a TXT record at _mta-sts and a policy file on https://mta-sts.<domain>/.well-known/mta-sts.txt. Optional, but worth having.

Records

No records published.

MTA-STS tells sending servers that mail to you must use TLS with a valid certificate, closing the downgrade attack that opportunistic TLS leaves open.

TLS-RPT

Info

Not configured

TLS reporting asks sending providers to mail you a daily summary of TLS failures they hit when delivering to your domain. One TXT record at _smtp._tls, and it is the only way to see MTA-STS problems before users do.

Records

No records published.

TLS reporting asks sending providers for a daily summary of TLS failures they hit delivering to you — the early warning for a broken MTA-STS policy or certificate.

BIMI

Info

Not configured

BIMI shows your logo beside your messages in supporting mailbox providers. It requires DMARC at quarantine or reject first, an SVG Tiny PS logo, and for Gmail a Verified Mark Certificate. Informational only — it has no effect on whether mail is delivered.

Records

No records published.

BIMI displays your logo next to your messages in supporting mailbox providers. It needs DMARC at quarantine or reject first, and has no effect on deliverability itself.

What we check

Nine checks, weighted by what actually moves delivery

Each check expands to show the raw records we read, so you can hand the output straight to whoever runs your DNS.

MX records

20 pts

Do you publish mail servers, are they sorted sensibly by priority, do they resolve to real addresses, and is there a fallback?

SPF

20 pts

Exactly one v=spf1 record, inside the ten-lookup limit, ending in a policy that actually means something.

DMARC

25 pts

Your policy, the percentage it applies to, alignment mode, and whether anybody is collecting the aggregate reports.

DKIM

15 pts

Nineteen common selectors probed, with the key type and length reported for every key we find.

Reverse DNS

10 pts

Forward-confirmed reverse DNS on your primary mail server — the PTR test receivers really run.

MTA-STS

5 pts

The TXT record and the policy file itself, fetched and parsed to confirm mode, mx patterns and max_age.

TLS-RPT

5 pts

Whether providers have somewhere to send their daily TLS failure reports.

DNS basics

Context

Name server delegation and apex resolution — the ground everything else stands on.

BIMI

Context

Your logo record, reported for information. BIMI needs DMARC at quarantine or reject before it renders.

FAQ

Questions about the test

What does the email server test check?

It reads every DNS record a mailbox provider looks at before it decides what to do with your mail: MX records and whether they resolve, your SPF record and its DNS lookup count, your DMARC policy, DKIM keys on the common selectors, MTA-STS, TLS-RPT, BIMI, your name server delegation, and forward-confirmed reverse DNS on your primary mail server.

Do you connect to my mail server?

No. Every check is a DNS query, plus one HTTPS request for the MTA-STS policy file when that record exists. We never open an SMTP connection and never send a test message, so running the test cannot affect your mail flow or your reputation.

Why does DKIM show as informational instead of a pass or a fail?

DKIM selectors cannot be enumerated from DNS — there is no record that lists them. We probe the selectors the major providers use, so finding nothing means we did not guess your selector, not that your mail is unsigned. To find yours, open a message you sent and read the s= value from its DKIM-Signature header.

How is the score calculated?

Out of 100, weighted by how much each control affects delivery: DMARC 25, MX 20, SPF 20, DKIM 15, reverse DNS 10, MTA-STS 5 and TLS-RPT 5. A warning scores roughly half of its weight. 90 and above is an A, 80 a B, 70 a C, 60 a D, and anything lower an F.

Is the test free?

Yes. The public tool runs up to 10 tests an hour per IP address with no account. A free InboxVet account removes that limit, keeps a history of every run for your workspace so you can see the score move, and adds blocklist and DMARC monitoring.

My SPF record has too many DNS lookups. What now?

RFC 7208 allows ten DNS-querying mechanisms — include, a, mx, ptr, exists and redirect. Past that, receivers return a permanent error and SPF fails for every message. Remove senders you no longer use, replace an include with the ip4 and ip6 ranges behind it, or use an SPF flattening service.

Keep it fixed

One test tells you where you stand. Monitoring tells you when it breaks.

A free InboxVet workspace keeps every run's score so you can watch it improve, and DMARC monitoring turns the aggregate reports receivers already send into something you can read.