The full authentication stack published correctly.
Six records, one fee, validated end-to-end.

SPF, Sender Policy Framework

TXT record at the domain root authorising your sending IPs and any third-party services that send on your behalf (Google Workspace, Microsoft 365, transactional providers, marketing platforms).

The 10-lookup limit is verified exhaustively. Every include: chain traversed, every a: reference counted. Most senders past three include chains hit this silently, when SPF goes over 10 lookups, the receiver treats it as invalid (PermError), which triggers a soft DMARC failure even when SPF would otherwise pass. We surface this before publishing.

Hard-fail terminator (-all) by default for stronger authentication signal. Soft-fail (~all) only where your sending profile genuinely needs it (multi-vendor setups during transition periods, complex forwarding scenarios). Each choice documented with rationale.

DKIM, DomainKeys Identified Mail

2048-bit RSA keypair generated. rsa-sha256 signing algorithm. Public key published at <selector>._domainkey.<domain> with selector naming aligned to a rotation schedule (2026q1, 2026q2, etc.) so future rotations remain clean.

Multi-string TXT format applied where the key exceeds the 255-byte single-string limit. About 35% of providers handle multi-string TXT incorrectly on first publication; we test the rendering after publishing and adjust if needed. Several DNS providers display correctly but serve incorrectly under certain query patterns.

Private key delivered securely via Telegram or encrypted file transfer. We don't retain it after handover. If you lose it, we generate a new keypair (under warranty) but the old selector becomes orphaned.

DMARC, Domain-based Message Authentication

TXT at _dmarc.<domain> with version, policy, percentage, alignment modes, and reporting addresses. Initial policy is p=none with rua= reporting active. Subdomain policy explicit (sp= flag set, not inherited) so subdomains follow the ramp at the same pace as the apex.

Reporting destination chosen with you. We strongly recommend a parser (parsedmarc, dmarcian, our managed monitoring) rather than your inbox. DMARC aggregate reports come as compressed XML hourly or daily from every receiver that processes your mail; even a small domain receives 5-50 reports per day. Parsing manually is not feasible past about three days.

Ramp plan documented: p=none for visibility (30 days), promote to p=quarantine with pct=25 (15 days), then pct=100 (15 days), then p=reject with pct=50 (15 days), then pct=100 (final). Total ramp duration 75-90 days. We provide the ramp checklist; you can execute it yourself or add it to our managed monitoring.

MTA-STS policy and DNS

Policy file deployed at https://mta-sts.<domain>/.well-known/mta-sts.txt with version, mode (testing initially), MX entries, and max-age. The HTTPS infrastructure for the mta-sts subdomain is part of the setup; we configure either CloudFlare-fronted hosting (free) or on your existing infrastructure if you prefer.

DNS TXT at _mta-sts.<domain> with policy id and cache duration. Policy id is a timestamp string that changes when the policy file changes; receivers cache the file based on max-age but re-fetch if the id changes. Our default max-age is 7 days, short enough for fast updates but long enough to reduce request volume.

Mode starts at testing, not enforce. Testing means receivers monitor TLS but don't reject mail on TLS failure; enforce means they actively reject. Promoting to enforce requires 14 days of TLS-RPT data showing no unexpected TLS failures from legitimate receivers. Don't skip this verification.

TLS-RPT, TLS Reporting

TXT at _smtp._tls.<domain> directing TLS failure reports to your chosen address. Required companion to MTA-STS for safe promotion to enforce mode.

Receivers send TLS reports in JSON format daily, listing any TLS negotiation failures, certificate validation failures, or policy violations. The reports are how you discover legitimate receivers that can't establish TLS with your infrastructure (rare in 2026 but happens occasionally with niche regional MX setups).

BIMI bootstrap (optional)

BIMI displays your verified brand logo in supporting receivers' inbox UI (Gmail, Apple Mail, Yahoo). Requires DMARC at p=quarantine or p=reject (strict alignment, sub-100% pct doesn't qualify), a registered trademark, and a Verified Mark Certificate from DigiCert or Entrust.

We publish the BIMI DNS record pointing to your conformant SVG logo and the VMC location. We can convert your existing logo to BIMI Profile (SVG Tiny PS specification) if needed; conversion adds €99 designer fee depending on logo complexity. The VMC issuance from a Mark Verifying Authority is separate (DigiCert ~$1,499/year, Entrust ~$1,799/year), paid by you directly to them.

BIMI bootstrap takes ~30 minutes during the standard setup. Reasonable to add if you have a registered trademark and DMARC already at enforcement; skip otherwise.

End-to-end validation

Each record validated against our SPF/DMARC validator and DKIM key audit tools after publication. Sample test mail sent through your sending infrastructure to verify alignment in real receiver transactions, not just DNS lookup. Headers inspected from receivers to confirm authentication results are PASS across SPF, DKIM, and DMARC simultaneously.

Aggregate reports verified as flowing within 48 hours of publication. We don't declare the setup complete until rua= reports are arriving at the configured destination.

Documentation handover

Written deliverable showing every record published, with literal content, host, type, and rationale. The document doubles as compliance evidence for SOC 2 / ISO 27001 audits where DNS authentication is a documented control.

DMARC ramp checklist included with specific calendar dates calibrated to your start date. You can execute the ramp yourself or hand it back to us via the DKIM Rotation addon (which also handles DMARC enforcement promotion as part of its scope).