The Complete Email Authentication Audit: SPF, DKIM, DMARC, MTA-STS, TLS-RPT and BIMI
Email spoofing is not one setting — it's a chain of six DNS records, and the weakest link decides whether anyone can send mail as you. Most checkers verify three of them. The complete audit covers SPF syntax depth, DMARC policy strength, eleven DKIM selectors, MTA-STS enforcement, TLS-RPT reporting and BIMI — here's how each verdict is reached.
When a phishing mail "from" your CEO lands in a customer's inbox, the question everyone asks is how. The honest answer is a chain: whether SPF authorizes the sender, whether DKIM signed the message, whether DMARC says what to do when both fail, whether TLS was enforced in transit, and whether anyone was even watching the reports. Email authentication is a chain of DNS records, and the weakest link sets the security of the whole system — which is why checking one or two records tells you almost nothing.
The basic three-record checkers (SPF exists? DMARC exists?) are table stakes. A complete audit grades each record for what it actually does, and covers the three modern records most checkers ignore. Here is the full chain as our free audit runs it.
SPF: The Sender List, Graded by Strength
SPF says which servers may send mail for your domain. The verdicts that matter:
- No SPF record — high severity, fully spoofable by any server on the internet.
~all(softfail) vs-all(hardfail) — softfail tells receiving servers "accept it anyway, but mark it." In practice most mailbox providers treat softfail as a suggestion, and spoofed mail sails through with, at best, a spam-folder coin flip. Hardfail is the only terminus that means reject. We grade softfail low-severity (it weakens your DMARC arc) and push for-all.+allor?all— a disaster in record form:+allauthorizes literally every server. Medium-to-high severity depending on the rest of the chain.- More than 10 mechanisms — SPF's DNS-lookup limit. Exceed it and compliant receivers return
permerror, and your whole SPF record stops being evaluated. This is the misconfiguration nobody notices until the audit counts the lookups. include:depth — nested includes (Google, Microsoft, Zendesk...) are how you hit the limit; we record the chain so you can see which link is expensive.
DMARC: The Policy That Has Opinions
DMARC decides what happens when SPF or DKIM fail. p=none is monitor-only — spoofed mail still delivers; you just get reports about it. p=quarantine routes failures to spam. p=reject is the only policy that actually stops spoofing. The audit grades missing DMARC as high, p=none as medium (monitoring is a phase, not a destination), and records rua (where reports go) and pct (what fraction the policy applies to — pct=25 means 75% of spoofed mail is exempt from your own policy).
DKIM: Signed, With Eleven Probes
DKIM proves a message wasn't tampered with in transit — if the key is published. Here's the catch: DKIM keys live at selector-specific addresses (selector._domainkey.domain), and there's no way to enumerate selectors from outside. So the audit probes the eleven most common selectors used by mainstream providers and mail platforms. On a domain that sends mail (MX records exist), finding zero DKIM keys is a medium finding: your mail can't be DKIM-signed, weakening the DMARC arc even when SPF passes. On a non-sending domain it's informational — the correct posture there is an empty SPF (v=spf1 -all) plus p=reject.
MTA-STS: TLS, Enforced
MTA-STS tells sending servers "when you deliver mail to us, you MUST use TLS" — closing the downgrade path where an on-path attacker strips STARTTLS and reads the mail in transit. The audit resolves the _mta-sts DNS record, then fetches the policy file itself (https://mta-sts.yourdomain/.well-known/mta-sts.txt) and grades the mode: enforce is the goal, testing is monitoring without enforcement, none or an absent policy leaves downgrade attacks open.
TLS-RPT: The Watchtower
TLS reporting (_smtp._tls) is where delivery failures and downgrade attempts get sent (rua=). Without it, an MTA-STS failure or an active TLS-stripping attack is invisible — mail silently bounces or flows plaintext and nobody knows. The audit checks for the record and the reporting address.
BIMI: The Brand Record
BIMI (default._bimi) is the newest link: it lets participating mailbox providers display your verified logo next to authenticated mail. It's cosmetic in value but diagnostic in effect — a valid BIMI record requires DMARC at p=quarantine or p=reject, so its presence is a good hint the rest of the chain is serious. Recorded as informational context.
One Audit, One Page
Each of these checks exists somewhere as a standalone tool. The difference in the free 2MNY email audit is the chain: every record graded by severity, every verdict explained (which mechanism, which policy value, which selector), and the whole thing runs on every scan of your domain — DNS records drift, providers change defaults, and yesterday's -all can become today's include-loop after someone adds a marketing platform. The audit uses DNS-over-HTTPS for the record lookups and a single browser-fingerprinted request for the MTA-STS policy file — the same view an external attacker or a receiving mail server has.
Spoofing is decided by the weakest of six records. Check all six, or don't bother checking any.
