Email authentication checklist

Step 1: publish and verify SPF

• Inventory every service that sends mail as your domain: your own mail server, a marketing platform, a transactional email API, a helpdesk tool, and anything else

• Publish an SPF record covering every one of those sources, ending in ~all while still confirming the list is complete

• Check the record with an SPF checker to confirm it parses correctly and stays under the 10-lookup limit

• Tighten to -all only once confident no legitimate source is missing

SPF alone authorizes sending IPs but is checked against the invisible return-path domain, not the visible From address a recipient sees, which is part of why DKIM and DMARC still matter even with SPF correctly configured.

Step 2: configure and verify DKIM

• Enable DKIM signing on every sending platform that supports it, using a distinct selector per platform

• Publish each platform's public key at its selector under _domainkey.yourdomain.example

• Send a real test message from each platform and confirm it carries a valid DKIM-Signature header that a receiving server can verify

• Use a checker to confirm each published selector resolves and uses a 2048-bit key

DKIM proves a message was not altered after signing and genuinely came from whoever holds the private key, independent of which network it was sent from, which is a different and complementary guarantee to what SPF provides.

Step 3: publish DMARC at p=none and review reports

• Publish v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.example

• Review aggregate reports for two to four weeks, confirming every legitimate sending source passes SPF or DKIM with alignment to the visible From domain

• Fix any gaps found in the reports by returning to steps 1 or 2 for that specific source

Do not skip this monitoring period even under time pressure; it is the step that catches a forgotten sending source before enforcement blocks its mail rather than after.

Step 4: move DMARC to enforcement gradually

• Move to p=quarantine once reports are clean, and watch for a further one to two weeks; expect any sender still failing alignment to start being quarantined from the moment the record goes live

• Do not add a pct tag: RFC 9989 removed it, some receivers still honour it and others ignore it, so it makes enforcement unpredictable rather than gradual. pct=100 is equally unnecessary — full application is what an absent tag already means

• Move to p=reject once quarantine has run cleanly with no legitimate mail being set aside

• Keep monitoring rua reports indefinitely afterward, since new sending sources added later need the same verification as the original inventory

Step 5 (optional): BIMI, once DMARC is enforced

• Confirm DMARC is at p=quarantine or p=reject, with no sp=none, no t=y and no leftover pct tag, before starting; BIMI will not display anywhere without this

• Prepare a logo in the SVG Tiny PS profile and host it over HTTPS

• Publish the BIMI TXT record, and obtain a Verified Mark Certificate if display in providers that require one, such as Gmail, matters

• Verify with a BIMI checker that the record, logo and DMARC prerequisite all line up correctly

Step 6 (optional): MTA-STS and TLS-RPT, for inbound mail encryption

• Publish a TLS-RPT record so encryption failures on inbound mail become visible

• Publish an MTA-STS DNS record and policy file at mode: testing, listing every current mail server hostname

• Review TLS-RPT reports for one to two weeks, confirming no unexpected failures

• Switch MTA-STS to mode: enforce once clean, and continue monitoring TLS-RPT reports afterward

This step protects inbound mail delivery to your domain from downgrade attacks, which is a different, complementary concern to SPF, DKIM and DMARC, all of which protect outbound authentication of mail claiming to be from your domain.

Ongoing maintenance, not a one-time project

Every mechanism in this checklist depends on the current, accurate state of who sends mail for the domain, which changes over time as new tools are adopted and old ones are retired. Treating the initial rollout as complete and never revisiting it is how a domain slowly accumulates gaps: a new marketing tool added next year without an SPF include, or a DKIM selector for a decommissioned platform left in DNS indefinitely.

A practical habit is a recurring review, quarterly or after any change to sending infrastructure, that walks through the same checklist: confirm SPF still covers every active sender and is under the lookup limit, confirm DKIM selectors match currently active platforms, and confirm DMARC aggregate reports show no unexplained failures. This is a small, recurring cost compared with re-discovering the same gaps from scratch during a future incident.

Running a full domain health check periodically is a fast way to cover this review in one pass rather than checking each mechanism separately, since it surfaces DNS, email, TLS and web security findings together and flags exactly which category regressed since the last time it was run.

What to check when something looks wrong

When legitimate mail unexpectedly starts failing authentication, work backward through the same order this checklist builds forward in. Check DMARC aggregate reports first, since they usually name the specific sending source and specific mechanism, SPF or DKIM, that failed, saving time compared with guessing at the cause from scratch.

If SPF is the failure, check whether the sending source's IP is actually covered by the current record, and whether the record itself is still under the 10-lookup limit, since exceeding it causes every mechanism in the record to stop being evaluated correctly. If DKIM is the failure, check whether the selector referenced in the failing signature is still published and whether its key matches what the sending platform is actually using, since a platform-side key rotation that was not mirrored in DNS is a common, easy-to-miss cause.