Free tool
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.
Free for everyone, 10 tests an hour. Results are shareable — the link updates with the domain you tested.
Deliverability score for
github.com
Checked in 0.5s · DNS only, no SMTP connection is made.
Fix your MX records
medium priorityPublish at least two MX hosts that resolve to A or AAAA records and are not CNAMEs.
Fix your SPF record
medium priorityPublish exactly one v=spf1 record, keep it under 10 DNS lookups, and end it with ~all or -all.
Add MTA-STS
low priorityPublish the _mta-sts TXT record and the policy file, run it in testing, then switch to enforce.
Add TLS reporting
low priorityOne TXT record at _smtp._tls gets you daily reports of TLS delivery failures from the big providers.
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.42.14, 52.101.41.0, 52.101.60.188, 52.101.194.17, 2a01:111:f403:f909::b, 2a01:111:f403:f908::8, 2a01:111:f403:f909::5, 2a01:111:f403:c927::
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 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.
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. PilotVerify 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.
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.
Forward-confirmed: mail-mw2pr04cu00106.inbound.protection.outlook.com
github-com.mail.protection.outlook.com resolves to 52.101.42.14, whose PTR is mail-mw2pr04cu00106.inbound.protection.outlook.com, which resolves back to 52.101.42.14. 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.42.14 52.101.42.14 → PTR mail-mw2pr04cu00106.inbound.protection.outlook.com → 52.101.42.14
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.
8 name servers, apex resolves
8 authoritative name servers. The apex resolves to 140.82.121.4.
Records
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 NS dns4.p08.nsone.net NS ns-1283.awsdns-32.org NS ns-1707.awsdns-21.co.uk github.com 140.82.121.4
The delegation the rest of the test stands on: which name servers are authoritative for the domain, and whether the bare domain resolves.
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.
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.
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
Each check expands to show the raw records we read, so you can hand the output straight to whoever runs your DNS.
Do you publish mail servers, are they sorted sensibly by priority, do they resolve to real addresses, and is there a fallback?
Exactly one v=spf1 record, inside the ten-lookup limit, ending in a policy that actually means something.
Your policy, the percentage it applies to, alignment mode, and whether anybody is collecting the aggregate reports.
Nineteen common selectors probed, with the key type and length reported for every key we find.
FAQ
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.
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.
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.
Keep it fixed
A free PilotVerify 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.
Forward-confirmed reverse DNS on your primary mail server — the PTR test receivers really run.
The TXT record and the policy file itself, fetched and parsed to confirm mode, mx patterns and max_age.
Whether providers have somewhere to send their daily TLS failure reports.
Name server delegation and apex resolution — the ground everything else stands on.
Your logo record, reported for information. BIMI needs DMARC at quarantine or reject before it renders.
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.
Yes. The public tool runs up to 10 tests an hour per IP address with no account. A free PilotVerify 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.
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.