Tools / Email Security
Can someone send email as you?
Three DNS records decide whether a forged message in your domain’s name is delivered or refused. Enter a domain and this check reads SPF, DKIM and DMARC together, follows every SPF include, looks at the transport records behind them, and gives you the exact records to publish next.
SPF · DKIM · DMARC · MX · MTA-STS · TLS-RPT · DANE · BIMIFree · No sign-up · PDF report
What it checks
Can mail be forged in your name?
The headline answer, from SPF and DMARC together: spoofable, partly spoofable, or not. Most domains that think they are covered are 'partly' — a monitor-only DMARC policy, a soft-fail SPF, or a missing DKIM signature.
SPF
The record, its terminating qualifier, every include and redirect expanded into a tree with the DNS-lookup count against the limit of ten, the address ranges authorised in all, private ranges, oversized ranges, the deprecated ptr mechanism, duplicate records and includes that lead nowhere.
DKIM
Seventy common selector names, plus any selector you give it, with key type and size, testing mode, revoked keys and wildcard records. Your selector is the s= tag in the DKIM-Signature header of any message the domain sends.
DMARC
Policy and subdomain policy, pct, aggregate and forensic report addresses, whether an external report address is authorised to receive them, and alignment mode.
Transport
MX records and what they resolve to, reverse DNS on the primary exchanger, the MTA-STS record and its policy file, TLS-RPT, and DANE TLSA records on each exchanger.
What to publish next
For each gap, a ready-to-paste record: an SPF starting point matched to your mail provider, the next DMARC step, MTA-STS and TLS-RPT records, or a null MX for a domain that sends nothing.
How the three fit together
SPF lists the servers allowed to send mail for the domain. DKIM signs each message so a receiver can tell it was not altered and came from a server holding your key. DMARC ties the two to the address the recipient actually sees, tells receivers what to do when neither lines up, and sends you reports about who is sending as you. Any one of the three on its own leaves a gap: SPF breaks when mail is forwarded, DKIM says nothing about mail that is not signed, and DMARC at p=none only watches.
The order that works in practice is DMARC at p=none with a report address first, so you can see every legitimate sender; then SPF and DKIM for each of them; then DMARC to quarantine and on to reject. The recommended records at the foot of each report follow that order. MTA-STS, TLS-RPT and DANE come afterwards and protect the mail you receive rather than the mail you send.
The check reads DNS and fetches one policy file; it does not send a message or connect to your mail servers, so it is safe to run as often as you like. If the reports DMARC starts sending you are more than you want to read, the managed SOC reads them for clients and tells you when something changes.
Also in Tools