Email domain protection in one sprint: DMARC, DKIM, SPF and transport controls that actually stick
Spoofed email is still the easiest way for attackers to impersonate your brand, phish your customers, and trick your own staff into unsafe actions. Startups often leave this problem to marketing tools and transactional providers, assuming that “deliverability” and “security” are the same thing. They are not. The good news is that the controls that make spoofing difficult can be stood up in days and verified in minutes: SPF to declare who can send on your behalf, DKIM to prove that authorized senders signed the message, DMARC to set alignment and policy, TLS reporting to see where transport encryption fails, and MTA‑STS to force TLS where possible. Wrap it with sane rotation and you will be ahead of many larger companies without buying anything new.
The quickest way through is to treat this as a deployment with observable outcomes. You will publish a set of DNS records, enable signing at each sender, verify alignment across the flows you use today, and then ratchet policy from monitoring to quarantine to reject. Every step can be checked with a single command and a real message; when you are done there is nothing ambiguous to explain to auditors or partners.
Begin with a map of your outbound flows. Most startups have at least three: corporate mail (Google Workspace or Microsoft 365), transactional mail from your product (SendGrid, SES, Mailgun, Postmark, etc.), and marketing/bulk mail (another provider or the same). Each must authenticate in a way that aligns with your organizational domain. If a provider signs with a subdomain and your “From” is the apex, alignment will fail unless you plan for it. Change as little as possible: either align the From to the provider’s subdomain or configure the provider to use your domain for DKIM and SPF.
SPF is declarative and fragile when done poorly. Keep it short and ruthlessly specific. If you use Google Workspace and a single transactional provider, your SPF record should name those senders and nothing else. Publish at the organizational domain even if you send from subdomains.
You can confirm that it resolves and stays under lookup limits with a single call.
DKIM is the signature that matters in practice. Enable DKIM signing in each sender and publish the selectors they give you under your domain. For Google Workspace the selector is often google. For SendGrid or similar, you will get a custom selector. Publish the provider’s public key verbatim and then send a test message to a mailbox you can inspect. The header should show a DKIM‑Signature with d=example.com or a subdomain you control.
DMARC is where you decide enforcement. Start in monitor mode to collect reports and verify that you have not missed a sender. Then move to quarantine, and finally to reject once false positives are gone. Keep reporting turned on at every stage; it is how you will notice unauthorized sources in the future. Publish at the organizational domain.
After a week of clean reports, change policy to quarantine, and then to reject. You do not need to change anything else if all senders are aligned.
Transport encryption is the other half of trust. Opportunistic TLS is common and uneven; you can see where it fails by enabling TLS reporting. Publish a TLS‑RPT record and stand up a simple inbox to receive JSON reports. They will tell you which partners failed to negotiate TLS with your domain so you can follow up or adjust routing.
To raise the floor, publish an MTA‑STS policy and the corresponding DNS record. This tells other MTAs to prefer TLS for your domain and gives them a way to discover your policy over HTTPS. It is a small file you host on a well‑known path.
You can validate the policy and basic TLS posture with a single test connection.
BIMI is not a security control but it reduces spoofing wins by making brand impersonation obvious. If your legal and marketing teams are willing, publish a logo and, if required by mailbox providers you care about, obtain a VMC. The DNS record is simple; the process behind it is the work.
Rotation is where many programs stall. Put DKIM on a quarterly rotation. Use two selectors per sender so you can pre‑publish the new key, switch signing, and then remove the old key a week later. Keep a change log with dates and selectors; DMARC and TLS‑RPT reports will confirm that traffic has moved. For SPF, avoid vanity includes that point at systems you do not control; every third‑party include is a dependency you will have to audit later.
The last mile is verification. Send a message from each flow to a test mailbox and read the headers. You should see spf=pass, dkim=pass, and dmarc=pass with alignment. Confirm that DMARC policy is in effect by attempting to send from an unauthorized host and watching it fail at the receiver with a policy error. Confirm that TLS‑RPT emails arrive and that your MTA‑STS policy is retrievable. Keep screenshots and command outputs in your internal runbook; they are the proof that will end debates with partners who claim the problem is on your side.
When you are done, your domain will stop being an easy target for basic spoofing. Legitimate mail flows will authenticate cleanly. Unauthorized mail will be rejected. Partners will send you machine‑readable evidence when transport encryption fails. And the next time a marketing tool asks to send “on your behalf,” you will be able to say yes or no with a specific, testable change rather than a best guess. That is a sprint worth doing while your domain reputation is still young and worth protecting.
