How to check my domain email security?

To check a domain's email security, look up the DNS records that receiving mail servers evaluate, then confirm what happens to a real message. In practice that is seven checks in a fixed order: who handles your mail (MX), SPF, DKIM, DMARC, the verdict on a test message, inbound transport security (MTA-STS, TLS-RPT and STARTTLS), and reputation (reverse DNS and blocklists). The order matters because each step depends on the one before it: DMARC means nothing until SPF or DKIM passes, and reputation work is wasted while authentication still fails.

Every check below works with dig on macOS or Linux; on Windows use nslookup -type=TXT name or Resolve-DnsName -Type TXT name. Replace example.com with your domain. A free IntoDNS.ai scan runs most of these checks in one pass and explains each result; the commands show exactly what it looks at.

1. Find out who handles your mail

$ dig +short MX example.com
1 smtp.google.com.

The MX host tells you which provider receives your mail: smtp.google.com (or the older aspmx.l.google.com set) is Google Workspace, <tenant>.mail.protection.outlook.com is Microsoft 365. That in turn tells you which SPF include and DKIM selector to expect in the next steps. No MX record means the domain does not receive mail; it still needs SPF and DMARC so nobody can send as it.

2. SPF

$ dig +short TXT example.com | grep -i spf1
"v=spf1 include:_spf.google.com ~all"

How to read it:

• Exactly one string starting with v=spf1. Two of them is a permanent error, and SPF fails for every message.
• Every service that sends as your domain is covered by an include:, ip4: or ip6: entry.
• It ends in ~all or -all. ?all protects nothing; +all authorises the entire internet.
• No more than 10 DNS lookups in total, nested includes counted. The record alone does not show this; the SPF checker counts them for you.

3. DKIM

DKIM keys live at <selector>._domainkey.<domain>, and DNS cannot list selectors, so you need the selector first. The fastest source is a message you sent: the s= tag in its DKIM-Signature header, explained step by step in how to find your DKIM selector. Provider defaults: Google Workspace uses google, Microsoft 365 uses selector1 and selector2.

$ dig +short TXT google._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

A healthy record starts with v=DKIM1 and has a non-empty p= holding the public key. For RSA, the length of that value tells you the key size: about 392 base64 characters for a 2048-bit key, 216 for a 1024-bit key that should be replaced. An empty p= means the key was revoked. No answer at all means the selector is wrong or not published.

4. DMARC

$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@​example.com"

• One record, starting with v=DMARC1, at _dmarc.example.com, not at the root.
• p=none only monitors. p=quarantine or p=reject is enforcement.
• rua= is where aggregate reports go. Without it you cannot see who sends mail as your domain.
• If subdomains never send mail, sp=reject closes them too.

An empty answer means there is no DMARC record. Gmail, Yahoo and Microsoft require one for bulk senders.

5. Send a test message and read the verdict

DNS shows what you published; a delivered message shows whether it works. Send a message from every platform that mails as your domain (mailbox, newsletter tool, CRM, helpdesk) to a Gmail address, open it, and choose Show original. Gmail summarises the result at the top:

SPF:   PASS with IP 192.0.2.25
DKIM:  'PASS' with domain example.com
DMARC: 'PASS'

DKIM must pass with your own domain. "PASS with domain sendgrid.net" means the platform signs with its own domain, which does nothing for your DMARC alignment. The raw Authentication-Results header carries the same verdicts and is explained in how to analyze email headers. The email deliverability tester does this analysis for you: send a message to the address it gives you and read the report.

6. Inbound transport: MTA-STS, TLS-RPT and STARTTLS

These protect mail sent to you against being downgraded to plaintext in transit.

$ dig +short TXT _mta-sts.example.com
"v=STSv1; id=20261030000000"

$ curl -s https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: smtp.google.com
max_age: 604800

$ dig +short TXT _smtp._tls.example.com
"v=TLSRPTv1; rua=mailto:tls-reports@​example.com"

The policy's mx: lines must cover every MX host from step 1, and the policy file must load over HTTPS with a valid certificate. mode: testing reports problems without blocking anything; move to enforce once TLS-RPT reports are clean. To test STARTTLS on a mail server directly, run this from a server, because many home and office networks block outbound port 25:

$ openssl s_client -starttls smtp -connect mx.example.com:25 -servername mx.example.com -brief
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Verification: OK

TLS 1.2 or 1.3 and Verification: OK for a certificate that names the MX host is what you want. The SMTP TLS checker and the MTA-STS checker run the same tests from the outside.

7. Reputation: reverse DNS and blocklists

This step matters for IPs you control. With Google Workspace or Microsoft 365 the provider manages reverse DNS for its own sending IPs. For your own mail server:

$ dig +short -x 192.0.2.25
mail.example.com.

$ dig +short A mail.example.com
192.0.2.25

The PTR name must resolve back to the same IP (forward-confirmed reverse DNS). Gmail can reject mail from an IP without it with error 5.7.25. The FCrDNS checker tests every MX IP at once.

Blocklists are DNS lookups too. To check 192.0.2.25 on Spamhaus ZEN, reverse the octets:

$ dig +short 25.2.0.192.zen.spamhaus.org

No output means not listed; an answer in 127.0.0.0/8 means listed. Spamhaus refuses queries that arrive through large public resolvers and answers 127.255.255.254, which is an error code, not a listing. Run the query through your own resolver, or use the blacklist checker, which checks the common IP and domain lists together.

Optional layers: DNSSEC and BIMI

$ dig +dnssec SOA example.com @1.1.1.1 | grep flags:
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

The ad flag means a validating resolver verified the answer, so the records above cannot be forged in transit. DNSSEC is also the prerequisite for DANE (TLSA records on your MX hosts); the DNSSEC setup guide covers enabling it. BIMI (dig +short TXT default._bimi.example.com) only becomes relevant once DMARC is at quarantine or reject; see the BIMI technical reference.

What the results mean, and what to fix first

• No SPF, or two SPF records: receivers cannot authorise your servers. Publish one combined record.
• DKIM passes only for the platform's domain: the mail authenticates but does not align. Set up custom-domain DKIM at that platform.
• DMARC at p=none for months: spoofing is reported, not stopped. Fix the failing sources shown in rua reports, then move to quarantine.
• MTA-STS record without a reachable policy file: senders ignore MTA-STS. Serve the file over valid HTTPS.
• No PTR, or a PTR that does not resolve back: mail from that IP is likely to be rejected or filtered. Ask whoever owns the IP (your ISP or host) to set it.
• Listed on a blocklist: some receivers reject your mail right now. Fix the cause, then request removal through the list's own process.

Checking more than once

Email security drifts: platforms get added, DKIM keys are rotated on one side only, certificates expire, IPs get listed. Re-run the checks after every DNS or provider change, and scan every domain and subdomain that sends mail, not only the main one: a subdomain does not inherit the SPF record of its parent. An IntoDNS.ai scan reports a grade from A+ to F with the failing checks and the record that fixes each one, which makes regressions easy to spot between runs.