Step-by-step guides for xteam's free email security tools.
MailCheck runs up to 16 simultaneous checks on a domain's email security configuration — instantly, with no account required.
yourbusiness.co.nz) — no http:// or www neededgoogle, selector1, or a Trend Micro timestamp selector like tm-dkim-20231106131339)| Check | What it looks for | Why it matters |
|---|---|---|
| MX Records | Mail server hostnames, IPs, and PTR (reverse DNS) records | Without MX records no one can send email to your domain. Missing or mismatched PTR records cause many providers to reject or defer your mail. |
| SPF | v=spf1 TXT record — which servers are allowed to send as you | Prevents unauthorised servers from sending email pretending to be your domain |
| SPF Chain | Follows all include: directives to check lookup count | More than 10 DNS lookups causes SPF permerror, breaking authentication |
| DMARC | v=DMARC1 policy record — policy, alignment, rua, and subdomain protection (sp=) | Tells receiving servers to quarantine or reject mail that fails SPF and DKIM. Also checks that subdomains are explicitly protected. |
| DKIM | Public key TXT records for common and detected selectors — also checks RSA key bit length | Cryptographic signature proving email was not tampered with in transit. Keys under 2048-bit are flagged. |
| BIMI | Brand logo record for Gmail/Apple Mail inbox display | Shows your verified logo in email clients — requires p=quarantine or reject DMARC and a VMC certificate |
| MTA-STS | Policy file mandating TLS on inbound connections | Prevents downgrade attacks — forces senders to use TLS to your mail server |
| DANE/TLSA | TLS certificate fingerprint pinned in DNS | Advanced TLS validation — pins your mail server certificate to DNS |
| Blacklists | IP and domain checked against 24+ RBL spam databases | Being listed blocks your outbound mail at many receiving servers |
| SMTP | Connects to MX hosts and tests: TLS version, cipher quality, certificate validity, STARTTLS enforcement, and banner version disclosure | Verifies your mail server accepts connections, uses strong TLS, and does not leak software version information |
| Open Relay | Attempts to relay mail through your server | Open relays are immediately exploited by spammers — critical to fix |
| CAA Records | DNS records restricting which certificate authorities may issue certs for your domain | Without CAA, any CA can issue a certificate for your domain — enabling impersonation attacks |
| WHOIS | Domain registration, expiry date, and registrar lock status | Expired domains are seized — check your renewal dates. DNSSEC status is also checked here. |
| IP Reputation | Checks MX IPs against abuse databases | Shared hosting IPs often carry bad reputation from previous tenants |
Each check contributes to an overall security score out of 100:
After running a full check, use the Export PDF button to download a branded, printable 5-page report. It includes a security score with letter grade, a status summary for all checks, detailed findings for authentication, connectivity, reputation, domain info, and a prioritised list of recommendations — useful for sharing with your IT team or provider.
Paste the full headers from any email to get a detailed breakdown of its delivery path, authentication results, and any anomalies or security signals.
Open the message → click the three-dot menu (⋮) → Show original → copy all text
Open the message → click the three-dot menu → View → View message source
Open the message → View menu → Message → All Headers, then copy
Open the message → File → Properties → copy the Internet headers box
| Check | What it looks for |
|---|---|
| Authentication results | SPF, DKIM, and DMARC pass/fail results stamped by receiving servers — shows what actually happened, not just what your DNS says |
| ARC chain | Authenticated Received Chain headers — explains why forwarded or mailing-list mail may pass or fail DMARC differently from direct delivery |
| Received chain & delivery path | Every server the message passed through, with timestamps, IP addresses, and TLS status per hop |
| TLS per hop | TLS version and cipher suite for each Received header that includes connection details — flags unencrypted hops |
| Delivery delays & greylisting | Gaps of more than 5 minutes between hops are flagged — likely greylisting or queue deferrals at the receiving server |
| From / Return-Path alignment | Checks whether the visible From address matches the envelope sender (Return-Path) — mismatches are a common phishing indicator |
| Reply-To mismatch | Flags if Reply-To directs replies to a different domain than the From address — classic phishing technique |
| DKIM signatures | Raw DKIM-Signature headers — shows signing domain, selector, algorithm, and body hash |
| Spam scores | Parses X-Spam-Score (SpamAssassin), X-MS-Exchange-Organization-SCL (Microsoft), and other spam scoring headers |
| List-Unsubscribe | Detects missing one-click unsubscribe support — required by Gmail and Yahoo for bulk senders since February 2024 |
| URL analysis | Extracts all URLs from headers and flags raw IP addresses, URL shorteners, and suspicious TLDs |
| Timezone anomalies | Flags Date headers that are in the future, more than 7 days old, or significantly out of sync with the first Received timestamp |
Header data is processed in memory and discarded immediately. Nothing is saved to our servers.
Mail providers such as Gmail, Outlook, and Yahoo send you daily DMARC aggregate reports showing who sent email on behalf of your domain and whether it passed authentication. This tool parses those reports and turns the raw XML into an actionable summary.
Reports are processed in memory and immediately discarded. Nothing is saved to our servers.
.xml — plain aggregate report XML (RFC 7489).xml.gz — gzip-compressed XML (most providers — Gmail, Outlook, Yahoo).zip — ZIP archive containing an XML fileMaximum file size: 5 MB. You do not need to decompress the file first — the tool handles it automatically.
Percentage of messages that passed DMARC — either SPF or DKIM aligned. Aim for 95%+ before tightening policy.
Every IP address that sent email using your domain, grouped by provider (Google, Outlook, SendGrid, etc.), with individual pass/fail counts for DKIM and SPF.
Prioritised action items based on your report data and live DNS settings — from policy upgrade readiness to specific failing sources that need investigation.
Your current SPF and DMARC records fetched at analysis time, so you can compare them against what the report shows.
p=none → p=quarantine → p=reject. Aim for reject once your pass rate consistently exceeds 95%
DMARC aggregate reports are emailed to the address in your rua= tag daily. If you haven't set up a rua= address yet, you won't receive reports — add one to your DMARC record first.
Run a MailCheck scan for your domain and look at the DMARC result. Your record should look something like:
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.co.nz; pct=100
If your record has no rua= tag, add one. The email address can be your own inbox or a dedicated mailbox.
Reports arrive as email attachments from major mail providers — typically daily, covering the previous 24-hour UTC period:
noreply-dmarc-support@google.com, attached as .xml.gzdmarcreport@microsoft.com, attached as .xml.gz or .zippostmaster@yahoo.com, attached as .xml.gzSave the attachment to your computer, then upload it to the DMARC Analyzer.
Google sends reports daily and covers a high volume of email — it's usually the most informative report to start with.
A DNS TXT record listing which mail servers are authorised to send email for your domain. Receiving servers check this to detect spoofing.
A DNS policy record that tells receiving servers what to do with mail that fails SPF and/or DKIM — none (monitor), quarantine (spam folder), or reject. Also enables aggregate reports.
A cryptographic signature added to outgoing email by your mail server, verified by the recipient using a public key published in DNS. Proves the email was not altered in transit.
A DNS record pointing to your verified brand logo. Gmail and Apple Mail display the logo in the inbox if your DMARC policy is quarantine or reject and you hold a VMC certificate.
A policy file hosted at https://mta-sts.yourdomain.co.nz/.well-known/mta-sts.txt that forces sending servers to use TLS when delivering to you — prevents downgrade attacks.
Advanced certificate pinning using TLSA records in DNS — pins your mail server certificate directly so it cannot be substituted by a rogue CA.
For DMARC to pass via SPF, the RFC5321 envelope-from domain must match (or be a subdomain of) the From: header domain.
For DMARC to pass via DKIM, the DKIM d= signing domain must match (or be a subdomain of) the From: header domain.
DMARC monitoring mode — reports are collected but failing mail is not filtered. Use this to understand your traffic before enforcing.
Failing mail is sent to the spam/junk folder. A good intermediate step.
Failing mail is rejected outright. Maximum protection — only safe once your pass rate is consistently high.
The percentage of mail the DMARC policy is applied to. Start at a low value (e.g. pct=10) when tightening policy, then increase toward 100.
The email address that receives DMARC aggregate reports. Add rua=mailto:youraddress to start receiving daily reports.
A database of IP addresses known to send spam. Mail servers check these lists before accepting email — if your IP is listed, delivery is blocked.
A DNS record that maps an IP address back to a hostname. Every mail server IP must have a PTR record that matches the hostname used in SMTP — missing or mismatched PTR is a major spam signal and causes many providers to reject your mail.
A DNS record that restricts which certificate authorities are allowed to issue TLS certificates for your domain. Without CAA, any CA in the world could issue a certificate — enabling impersonation attacks.
An SMTP command that upgrades a plain-text connection to TLS encryption mid-session (on ports 25 and 587). Distinct from SMTPS (port 465) which uses TLS from the start. A well-configured server enforces STARTTLS — refusing AUTH commands before the upgrade.
A set of email headers (ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results) that preserve the original authentication results when a message is forwarded or passed through a mailing list. Without ARC, forwarded mail often fails DMARC even though the original was legitimate.
A spam-reduction technique where a receiving mail server temporarily rejects a first-time sender with a 4xx code, expecting a legitimate server to retry. Most servers retry within 5–30 minutes. The Email Header Analyzer detects greylisting from gaps in Received header timestamps.
An email header that signals support for one-click unsubscribe (RFC 8058). Gmail and Yahoo require it for bulk senders since February 2024 — without it, providers may filter or reject your bulk mail, and users cannot unsubscribe with a single click.
Run a free scan in under 30 seconds — no account needed.