Email Authentication Setup Checklist

Use this checklist when setting up email authentication for a new domain, auditing an existing configuration, or preparing to move DMARC to enforcement. Work through each section in order — SPF and DKIM must be working before DMARC can be enforced.

Check your current authentication status →

SPF

• An SPF record is published as a TXT record on your root domain (v=spf1 ... ~all or -all)
• All services sending email on your behalf are covered — check CRM, support desk, transactional mail, marketing platforms, ERP, invoicing tools, and any application that sends as your domain
• No deprecated service includes are listed — remove include: entries for services you no longer use
• Total DNS lookup count is 10 or fewer (every include:, a, mx and redirect= mechanism counts as one lookup)
• Policy ends with -all (hard fail) or at minimum ~all (soft fail) — never +all
• SPF record passes syntax validation

How to verify: Run the Email Auth Checker and review the SPF result. Look for lookup count warnings.

DKIM

• DKIM is enabled on your primary mail platform (Exchange Online, Google Workspace, Postfix, etc.)
• DKIM public key is published in DNS at selector._domainkey.yourdomain.com
• DKIM is enabled on every platform that sends as your domain — not just your primary mail server
• For Exchange Online: both selector1 and selector2 CNAME records are published, and DKIM shows Enabled in Exchange Admin Center
• DKIM signature passes verification on outbound test messages

How to verify: The Email Auth Checker probes 19 common DKIM selectors automatically.

DMARC

• A DMARC record is published at _dmarc.yourdomain.com
• A rua= reporting address is set and you are receiving and reviewing aggregate reports
• Policy is at p=none minimum — move to p=quarantine then p=reject once SPF and DKIM pass rates are consistently above 95%
• DMARC alignment is passing for all legitimate sending sources (verify via aggregate reports)
• Subdomains are covered via sp= on the root domain record, or with separate DMARC records per sending subdomain

DMARC enforcement path:

1. Start at p=none with rua= reporting
2. Review reports for two weeks — identify every failing source
3. Fix authentication on all failing legitimate sources
4. Move to p=quarantine; pct=10, increase to 100 over two weeks
5. Move to p=reject

MTA-STS

MTA-STS (Mail Transfer Agent Strict Transport Security) tells sending mail servers to use TLS when delivering to your domain, and what to do if TLS isn’t available. It’s a stronger form of transport security than STARTTLS opportunistic encryption.

• MTA-STS policy file is published at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
• MTA-STS DNS record is published: _mta-sts.yourdomain.com TXT "v=STSv1; id=..."
• TLS-RPT record is published for delivery failure reporting: _smtp._tls.yourdomain.com TXT "v=TLSRPTv1; rua=mailto:..."
• Policy mode is enforce (after testing with testing mode)

Check MTA-STS and TLS-RPT →

BIMI (optional)

BIMI (Brand Indicators for Message Identification) displays your logo next to authenticated email in supporting clients (Gmail, Apple Mail, Yahoo). Requires DMARC enforcement and a Verified Mark Certificate (VMC).

• DMARC is at p=quarantine or p=reject
• SVG logo file is hosted at a stable public HTTPS URL
• BIMI DNS record is published: default._bimi.yourdomain.com TXT "v=BIMI1; l=https://...logo.svg; a=..."
• VMC certificate is obtained from a qualified CA and referenced in the a= field (required for Gmail display)

Check BIMI record →