Five controls, three different jobs
SPF, DKIM, and DMARC address domain authentication. SPF authorizes hosts to use an envelope domain; DKIM verifies a cryptographic signature associated with a signing domain; DMARC connects one or both results to the domain visible in the From header and publishes a requested disposition. MTA-STS has a different purpose: it lets a receiving domain require supporting senders to use TLS and validate the recipient MX certificate. BIMI is a brand-indicator mechanism that depends on mature authentication; it is not an anti-phishing control by itself.
Deploy in dependency order: inventory senders; correct SPF; establish aligned DKIM; collect DMARC reports; enforce DMARC; enable TLS reporting; test MTA-STS; enforce MTA-STS; then evaluate BIMI. This sequence makes each failure observable before it can block legitimate mail. It also gives each change a clean rollback boundary.
Assign two owners: an email-platform owner for mail flow and a DNS/web owner for records, HTTPS policy hosting, and certificates. For every stage, define the exact record, test evidence, monitoring period, failure threshold, and previous state. Email controls are public infrastructure; casual edits can affect every sender or receiving peer.
Phase 1: SPF and sender separation
Create an envelope-sender inventory. SPF evaluates MAIL FROM or HELO identities, not the visible From address users recognize. A vendor can therefore pass SPF using its own bounce domain while failing DMARC alignment. Ask each provider whether it supports a custom return-path and customer-domain DKIM signing.
Keep one v=spf1 TXT record per domain and finish with an intentional all mechanism. The SPF specification limits terms that trigger DNS queries, including include, a, mx, ptr, exists, and redirect, to ten during evaluation. Excess returns permerror, which makes a long list of reputable vendors operationally unsafe. Use dedicated subdomains such as billing.example.ca and campaigns.example.ca to reduce coupling and simplify retirement.
Validation is a real-message test from each platform to multiple external receivers. Record the evaluated envelope domain, source IP, result, and alignment. Roll back to the previous record if a critical authorized stream fails, but fix the sender inventory or configuration rather than leaving ~all indefinitely as a substitute for analysis.
Phase 2: aligned DKIM and key operations
DKIM signs selected headers and a canonicalized representation of the message body. The receiver retrieves a public key from a DNS name built from the selector and signing domain. A passing signature shows that the signed content survived transit and that the signer controlled the key; it does not, by itself, prove that the signer matches the visible author.
Configure each service to sign with the organizational domain or a deliberately aligned subdomain. Use selectors unique to the service and rotation epoch so one provider cannot overwrite another's record. Protect private keys in the sending platform or a managed key service, restrict administrative access, and document rotation and emergency revocation. Publish new public keys before switching the signer; retain old keys long enough for delayed mail to validate.
Test normal messages, replies, attachments, calendar invitations, and paths through gateways that add footers or rewrite content. Capture dkim=pass and the header.d value at the receiver. If intermediaries break signatures, determine whether the intermediary can preserve content, reseal appropriately, or support ARC; do not weaken all domain policy to accommodate an unowned transformation.
Phase 3: DMARC reporting and enforcement
Publish DMARC with p=none and an aggregate-report destination while sender discovery is active. Aggregate reports provide receiver-observed counts by source and authentication result. Protect the report mailbox, validate report parsing, and retain enough history to cover low-frequency systems. Failure reports are inconsistently offered and can contain message information, so assess privacy before requesting them.
For each legitimate stream, require aligned DKIM or aligned SPF. DMARC's relaxed alignment allows a subdomain to align with its organizational domain; strict alignment requires an exact match. Choose strict mode only for a documented reason and after testing. Forwarding commonly breaks SPF, so aligned DKIM should be the primary success path where feasible.
Move to quarantine and then reject after unexplained legitimate failures are removed. Monitor both the parent policy p= and subdomain policy sp=. Parked domains should publish a deny posture because they have no legitimate mail to protect. Rollback restores the previous policy while a specific stream is repaired; it should include an owner and expiry, not become an open-ended p=none state.
Phase 4: TLS-RPT and MTA-STS
SMTP TLS is often opportunistic: absent a stronger policy, delivery may proceed without authenticated encryption when STARTTLS is unavailable. MTA-STS lets a recipient domain publish acceptable MX patterns and request that supporting senders refuse delivery when TLS or certificate validation fails. That can prevent silent downgrade, but a wrong enforce policy can defer legitimate inbound mail.
Begin with TLS reporting. Publish _smtp._tls.example.ca TXT as v=TLSRPTv1; rua=mailto:tls-reports@example.ca and confirm reports are received and parsed. Host the MTA-STS policy at https://mta-sts.example.ca/.well-known/mta-sts.txt with a publicly trusted, valid HTTPS certificate. The policy must list every legitimate inbound MX pattern. Start with mode: testing and a modest max_age, then compare reports with intended mail routing.
Before mode: enforce, test the policy URL without redirects or authentication, validate each MX certificate and name, simulate primary-MX failure, and verify backup MX behaviour. Increment the id in the _mta-sts TXT record whenever policy content changes so senders know to refetch it. Roll back by publishing a valid mode: none policy and changing the id; keep the web endpoint available until cached enforce policies expire. Deleting the DNS or website alone is not a safe immediate rollback because senders may use a cached policy.
- _smtp._tls.example.ca (TXT): v=TLSRPTv1; rua=mailto:tls-reports@example.ca
- _mta-sts.example.ca (TXT): v=STSv1; id=20260903T120000Z
- https://mta-sts.example.ca/.well-known/mta-sts.txt (HTTPS body): version: STSv1 mode: testing mx: example-ca.mail.protection.outlook.com max_age: 86400 — Replace the MX pattern with the domain's actual inbound MX; move to enforce only after validation.
Phase 5: BIMI after enforcement
BIMI is the last step because participating mailbox providers expect DMARC enforcement. The BIMI Group implementation guide states that the organizational domain and subdomains must use quarantine or reject, with full enforcement, rather than p=none or a partial percentage. A provider still decides whether and where to display the logo, so publishing a record does not guarantee presentation.
Prepare a logo in the required SVG Tiny PS profile and host it over HTTPS. Determine whether target mailbox providers require a Verified Mark Certificate or Common Mark Certificate; self-asserted records have limited support. Certificate eligibility, trademark requirements, and display rules are provider-dependent and can change, so verify them before purchasing a certificate.
Publish the selector record only after validating the SVG and certificate chain. A representative record is default._bimi.example.ca TXT v=BIMI1; l=https://assets.example.ca/brand/logo.svg; a=https://assets.example.ca/brand/vmc.pem. Monitor HTTPS availability, certificate expiry, DMARC enforcement, and mailbox-provider outcomes. BIMI rollback is low risk: remove or correct the BIMI record without changing the underlying authentication controls.
- default._bimi.example.ca (TXT): v=BIMI1; l=https://assets.example.ca/brand/logo.svg; a=https://assets.example.ca/brand/vmc.pem — Certificate and display requirements vary by mailbox provider.
A production acceptance test
Maintain a matrix with one row per sending stream and test recipient. Required evidence includes header From, Return-Path, SPF result and domain, DKIM result and d= domain, DMARC result, and final disposition. For inbound transport, add MTA-STS policy retrieval, MX match, TLS protocol and certificate validation, TLS-RPT receipt, and failover behaviour. For BIMI, add DNS, HTTPS, SVG, certificate, and provider-specific checks.
Run tests after every DNS, sender, gateway, certificate, or mail-routing change. Alert on DMARC unknown-source growth, SPF permerror, DKIM selector lookup failure, TLS-RPT failures, policy endpoint failure, and certificate expiry. Assign each alert to a service owner rather than a shared mailbox with no response objective.
The final deliverable is not a screenshot of a DNS checker. It is a versioned sender inventory, change record, raw-message evidence, report trend, exception list, and rollback procedure that another administrator can execute.
Implementation checklist
- Map every envelope domain, visible From domain, signing domain, and sending owner.
- Separate third-party and bulk senders onto controlled subdomains where practical.
- Keep each SPF record singular and within the RFC 7208 DNS-lookup limit.
- Enable aligned DKIM with unique selectors and a tested rotation process.
- Collect and classify DMARC aggregate reports before changing disposition.
- Move DMARC to quarantine and reject with explicit stop and rollback criteria.
- Deploy TLS-RPT before MTA-STS enforcement and investigate reported failures.
- Serve a valid MTA-STS policy over HTTPS, test all MX paths, and understand policy caching.
- Pursue BIMI only after full DMARC enforcement and provider-requirement review.
- Retest the entire matrix after changes to DNS, mail routing, gateways, or certificates.