SPF, DKIM and DMARC: Email Security Setup Guide

Affix Center Softech Services Pvt. Ltd — Fri, 25 Sep 2026 12:32:34 +0000

Originally published on the Affix Center blog.

Anyone can send an email that claims to come from your domain unless you tell the world's mail servers otherwise. Fake invoices, fake payment change requests and fake HR notices sent in a company's name are among the most common frauds Indian businesses face. This guide explains the three DNS records that stop most of this spoofing and how to put them in place without breaking your genuine email.

There is a second reason to act. Since February 2024, Google and Yahoo have required bulk senders (around 5,000+ messages a day to their users) to authenticate mail with SPF, DKIM and DMARC. Microsoft introduced similar rules for high-volume senders. Even if you send far less, missing records make it more likely that your quotations and invoices land in spam.

What SPF, DKIM and DMARC each do

SPF (Sender Policy Framework): a DNS record listing the servers allowed to send mail for your domain.
DKIM (DomainKeys Identified Mail): a digital signature added to every outgoing message, checked against a public key in your DNS.
DMARC: a policy that tells receivers what to do when a message fails SPF and DKIM, and where to send reports.

SPF and DKIM prove a message is authorised. DMARC ties them to the visible "From" address and enforces the result. You need all three.

Step 1: Inventory every system that sends your email

List every service that sends mail using your domain: Microsoft 365 or Google Workspace, ERP/accounting (invoices), HRMS/payroll (payslips), CRM and newsletter tools, website forms, helpdesk, and scanners or on-prem apps that relay mail. The finance team's invoicing tool is the one most often forgotten.

Step 2: Set up SPF correctly

v=spf1 include:spf.yourmailprovider.com include:mail.invoicetool.com -all

Only one SPF record per domain.
Stay within 10 DNS lookups (nested includes count).
-all rejects anything not listed; ~all soft-fails. Many teams start with ~all and rely on DMARC for enforcement.
Remove includes for tools you no longer use.

Step 3: Enable DKIM signing

In each sending service: generate a key (2048-bit where offered), publish the public key at the selector it gives you (e.g. selector1._domainkey.yourdomain.in), turn signing on, and check test headers for dkim=pass. Repeat for every sender.

Step 4: Publish DMARC and move to enforcement

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.in

Monitor with p=none and read the aggregate reports.
Fix every legitimate sender that fails (2-4 weeks).
Quarantine with p=quarantine.
Reject with p=reject: the goal.

For parked domains that never send mail, publish v=spf1 -all and a DMARC policy of p=reject.

Step 5: Test, document and maintain

Test after every change, keep a DNS change log, add SPF/DKIM to vendor onboarding, rotate DKIM keys, and restrict DNS access with MFA on your registrar.

Common mistakes

Stopping at p=none.
Multiple SPF records added by different vendors.
Forgetting that forwarding breaks SPF (so DKIM on every sender matters).
Overlooking subdomains.
No owner for DMARC reports.
Relying on authentication alone: lookalike domains and compromised accounts need other controls.

Full guide with FAQs: SPF, DKIM and DMARC setup guide on affixcenter.com

DEV Community: Affix Center Softech Services Pvt. Ltd